PANEL: Risk, Trust, and Empowered Users: The Next Generation of Access Control

So maybe before we start, a short introduction of yourself and what is your focus on, yes, IAM in this case. Would you like to start, Keng?

It's on, yeah. All right, Keng Lim, I'm the founder and CEO of NextLabs. So we actually, for those of you who doesn't know NextLabs, we actually co-created GeoTrust Architecture and Dynamic Authorization 15 years ago. So a little bit of history there.

So hi, everyone. I'm Heiko, CEO of Nexis, the leading IVRP platform, identity guide by heart, so more than 20 years in identity and access management.

Hi, my name is Florian Kraus. I'm the managing director of DAGMA GmbH. I have a little bit of a different perspective. I'm not a vendor. I'm the distributor of one of the solutions that you can actually discover here called Segura Privilege Access Management. And what we basically do is enabling our partners and their end customers to basically solve their challenges that they have with identity access management, privilege access management, and identity governance.

OK, so let's directly start with the first question. I'd like to address it to you, Keng. What does empowered user actually mean in practice? And where should organization draw the line between user autonomy and centralized control?

OK, that's a good question. So empowerment to me, and based on what we have heard from many enterprises, is actually not to let the empowered user do all the things, but rather trying to remove or trying to allow the empowered user not become the bottleneck. Because today, that's a problem, right? Most empowered user are bombarded with a lot of tasks that they have to prove, right? So the key there is going to be balancing between what we call oversight, right?

The empowered user should be given the oversight and take responsibility for the integrity of the outcome, but not be burdened to do all the manual work. So what that means is you want to have centralized control to automate a lot of tasks that the empowered user doesn't have to go do manually, right? But provide the oversight to ensure that high priority or critical tasks are being monitored or being so-called approved by the human user, if that makes sense.

Michael, Florian, what do you think about it? Yeah, so very interesting aspects, absolutely you're right. So I'd like to add from this. So an empowered user is for sure not only an IT user. So there are so many business people involved in IAM processes. And so basically, when you want to be successful, you have to kind of cope and collaborate with the business. And so you have to have an exceptional user experience and UI.

So tech tools built for tech people will always be a challenge for business users that either don't care about IAM, because it's a burden for them in their normal business activities or their normal job. And on the other hand, it's kind of too technology driven and hard to understand. So an exceptional user experience, a proper UI, and what we call kind of explainable reasoning, especially when it comes to AI. So to help users to understand what they are confronted with so that they can make an informed decision, so to say.

I think that brings up the point, which is empowerment without oversight or over-empowerment could be a problem. So you actually want to make sure that there's always some oversight. So that in the case, for example, the AI agent, right? So if AI agents empower without any control, that's actually a problem. Yeah.

Brogan, maybe I want to address this next question to you. Are we over-complicating access control with increasingly granular risk signals? Or is this the only viable path forward in modern environments?

Yes, from my perspective, yes and no. Are we over-complicating things?

Yes, I do feel that most of the partners and their end customers are actually already having challenges addressing the topics that they face from, for example, a compliance perspective. On the other side, I do believe that a granular approach is quite needed in this area. So we should not only talk about the normal user or a privileged user, we should also talk about everything that is in between that actually needs more guidance, especially people that are trying to solve most of their challenges on their own, that are not purely saying, OK, have a challenge.

I need, for example, a dashboard. I need a specific access. I do not write somebody else. I do not use an IT ticket for somebody else to solve my problem. So we also have to think about those users in the middle. And for me, those users need to be controlled somehow. But I think restriction, or especially saying they are a risk, is the wrong approach. But we need this guidance, I would say, for those group of people. And this guidance most likely will also come with a little bit more granularity. Let me probably add on this. So I like risk signals, because they can help in various cases.

However, visibility of risk signals is not enough, because then you have yet another risk signal, like yet another ticket. So you have to do some manual actions. And then it ends up no one is doing anything. And you know it probably from your personal task management, from JIRA dashboards, and so on, where you have tickets inflation. So the proper angle is to have intelligence or remediation, automated remediation. And when you have this mapping, then it works out. So you have a risk signal. And you're not presenting it to an HR or a finance manager or consultant. And so what? What should I do?

I don't have a clue. You get an automated action on getting rid of the problem. That could be on the provisioning. That could be an additional authentication. That could be some data cleansing whatsoever. But when you are not able to find the next automated step, the risk signal is ending up and just creating more noise and more mess within your business departments.

OK, maybe. What do you think about this? Are we overcomplicating access control?

Well, I don't think so. I think the answer to the questions is probably, what is the model that you use in the first place, right? So a lot of companies are still stuck with a so-called static access control, right? So to some extent, you've got a model that is already, you've got business needs that have outgrown the model. And you're trying to build what we call a lot. You try to put a lot of band-aid around it, right? Or you start to make customization around it. So I think the complication is all the customization around the core that is already insufficient, right?

So therefore, the problem is not adding more stuff around it, but rather fixing the core, right? And that's why I think a lot of time, we advise our customers to look at, hey, maybe the static control is what you need to change first, moving to a more dynamic control, right? But the problem is, it's a very drastic change from a static model to a dynamic model, right? So I think that is a trade-off. A trade-off between are we overcomplicating it by adding more stuff around the core that's already insufficient, or do we leapfrog and basically change the fundamental foundation of the core?

And then maybe you can solve the problem longer term. But you're probably going to have a short-term pain, right, because of the change that you have to endure and going through. OK.

Michael, I'd like to know from you, what do business users actually need in order to make decentralized or delegated access decisions responsibly? And are organizations doing enough to enable them with the right context or accountability on tooling? Good question. So there are several aspects. So one aspect is involve your business colleagues immediately at the beginning. I have had recently a webinar with Matthias from HCOB, a banker in Hamburg, or in Hamburg, not here in Hamburg. And he did something very smart.

So he has, with every new joiner who's responsible from a team leader or a manager perspective, a coffee chat and kind of informal onboarding meeting to make him aware about the IM team, what IM is about, and so on. So every person starting there in a function to recertify or to access something is educated. And you have a human relationship. It also has, in each and every department, kind of ambassadors to bridge the gap and lower the burden to reach out to the central IM team.

So probably your colleagues are far easier and more open to give a call to a person in the neighbor department instead of raising a ticket to the central IT team. I don't know these guys, and probably better not. That's one thing. So kind of sort out your human relations and your human processes. On the other thing, decentralization is super important, because the central IT team can't manage the complexity anymore and the amount of work. And basically, it doesn't have a clue.

So basically, you in central IM departments, you don't basically know what is the finance consulting, what's the marketing guy, what's the sales lady actually doing, and what should she be allowed to be doing. So basically, you have to delegate, divide, and conquer. And persons in those departments have to be acting on their own.

Therefore, you need proper usability. You need a proper user experience. You need clean UIs. And you need anything that helps the users, or giving them proper recommendations, leveraging machine learning or gen AI, but also with kind of a reasonable explanation so that the user can understand why is the same thing asking of me? And is it probably better to remove access or to fix some attributes on the identity? Because you don't know, was it probably a mover from London to Munich? And identity attributes have not been updated. And that's why the authorization is wrong.

Or is the authorization wrong, and the person is still there where it always was? And we have the data, so we can interpret the data and help our business users to make better decisions. Thank you.

Maybe, Florian, this question is based on your experience about adaptive access. Is it delivering better security or just shifting complexity into systems no one fully understands anymore? Adaptive security.

Actually, a tough one, to be honest. So maybe a question to the group. What is adaptive security for you? I think adaptive security, to me, means it needs to be one that can be adjust or flexible enough that can adjust to the business need, as well at the same time address what we call the risk vector, or the risk profile of the companies.

And yet, be able to evolve, i.e. dynamic enough, that can deal with any unknown circumstances that emerge. That sounds pretty complicated.

No, I get it. The good news is, technologically, it's all there. It can be done. So I thought about it, actually. And I do agree with what was just said.

To me, it's not moving the risk. It's basically an approach to make things easier. If it works out quite well in the end, depends on how you did it. But I do truly believe that the current state of access already is very complicated. And everything that makes it a little bit more dynamic actually helps to lower the burden that administrative teams has to solve, and also to basically enable users to be a little bit more dynamic, to be a little bit more flexible, to be quicker in what they do and what they are trying to reach. I actually want to shout out to two companies.

I think they are in the audience. One is Deutsche Telekom. They have actually done that to some extent. They have actually embarked in a process to try to simplify access control, using a hybrid model, role-based and dynamic. So it's almost an example of you don't have to. The static model can still be preserved. But you add the dynamic aspect to make the static model become more extensive. And then there's another company, AXA. I don't know here. Is AXA here? OK.

In fact, AXA is even more innovative. They actually attempt to make onboarding and offboarding 100% automated. So that's to answer your point. All this can be done. So it doesn't mean that the complication is have to be. I just mean you don't have to trade off between reducing the complication or do I taking on more risk. I think you can actually achieve the best of both worlds. OK.

Heiko, next question to you. So how do you operationalize adaptive access at scale without creating governance bottlenecks or losing transparency and decision making? That basically pays into the question before. So if you reinvent the wheel and start everything from scratch, then it's hard. But there is so many data already there in the enterprise you can easily use to leverage kind of adaptive security.

Think, for example, about the conversions of identity and access management and GRC, governance, risk, and compliance. When you do a vendor onboarding, you collect so many data about your external identities or even for agents. Are they ISO 270 certified? Are they hosting or operating in Europe or the US or somewhere in Asia? When it's an LLM, you probably collect data. Is the LLM kind of certified and compliant to the EU AI Act? Is it non-biased and kind of this stuff?

And when you have all this data in your GRC database anyway, if you bring it into a system and not just an Excel spreadsheet stored by procurement somewhere on a SharePoint and in a write-only-once manner and never open again, then you can operationalize this data quite easily in dynamic access policies without bothering the business. Giving you an example, you have some operations provider doing your operations in an offshore team. Then it's an easy rule. They have to get production access. So for sure, they have to do operations. But you want them to be ISO 270-1 certified.

You want them to have managed hardware. You want them to do x, y, z. And all the data is there. Bake it into a policy. And when the team is moving, let's say, from India, where you are open to, to China or to the US or to Vietnam or wherever, I don't have GDPR contracts whatsoever with these countries. No. It automatically shuts down and prevents this. The same goes for agents. And for agents outnumbering human identities by 50 to 100 plus, it will be even harder.

So you have to have policies in place that bring in a basic level of security and basically can deny a lot of actions where identities are accessing to and leveraging this data is quite simple on the one hand, but can create so much value and especially avoids that your colleagues in the business department, and it's now again the business, have to think about each and every corner case. Because when you're onboarding an external contractor, why should someone in the business think about, is it OK to give him access to this or that?

And do kind of all this kind of prechecks that are requested by your ISO or CISO. So basically have it once defined in a policy and then things can be done and interpreted in an automatic way. I'd like to address the next question to all of you. So feel free to answer it.

Well, organization collect vast amounts of contextual data. So how do you distinguish meaningful risk signals from noise? And what are the consequences of getting this wrong? So you said you are a fan of thresholds and risk signals.

So yeah, what is your opinion? So probably I am starting as you pointed to me. So when it comes to risk signals, there are kind of standards there. So think about the shared signals framework, for example. So you can easily implement it and you have your receiver of the SSF events that are sent. You can emit SSF events by yourself. And then kind of building up this kind of risk event space within your company.

So it's not just kind that you just pick up anything and you have to interpret everything by yourself, because you have standardized event types that are far easier to process them before everyone is inventing the wheel completely new. And especially, you are using kind of standard software out there. When all those players are following the SSF, you have far easier integration scenarios compared to when you reinvent the wheel by yourself.

Yeah, I actually think that the, I don't think, OK, so it's a very different way to look at the pictures. I actually think that most companies already collected the contextual data that is really meaningful.

And yet, they are not using them. So I actually don't think that they need to collect more contextual data anymore. So I actually have a very different perspective, which is use the contextual data that is useful that you have collected, such as your threat intelligence, right? Your threat intelligence system, if you implemented it, it has some very powerful contextual data, i.e., what is a threat factor of a certain identity, right? Another example could be, what is your device posture? What is your identity posture? What is your location, right?

So all that contextual data is already provided and available. So I don't think you need to collect more contextual data. And therefore, to some extent, arguably, there's no more concern about the noise, right? Because the right signal is already available. So just focus on using those signals and not collect any more, to some extent, OK?

Florian, do you share their opinions? Or is there anything you want to add?

Actually, I learned a lot. Thank you very much, guys. I think the approach is very clever. I also believe that we already have more than enough. It's just finding out how to use it in the most respective way, definitely. So I'm coming to my final question for this panel. And this is a bit focused on AI agents. So as organizations increasingly introduce AI agents and other non-human identities into business processes, should these entities be empowered, similar to humans or users? Or do we need different governance and access models?

OK, I think this is actually one of the questions I raised. I think the answer is yes. I think the non-human identity should be empowered, but not to the same extent as their human counterpart, right? Because the reason I say that is because you don't want to increase complexity by introducing additional landscape, right?

Like, for example, we have company think about, oh, I need to have a separate identity system to manage non-human identity versus the human identities. So my advice to them is no, no, no. You actually want to have one single identity system managing both human and non-human. So the same thing applies to governance, right? So if you manage human and non-human identity separately, then you now need to have two separate governance, right? So you just exponentially increase the complexity of your solution. And by nature of that, you're ultimately going to have a failed solution, right?

Because the complexity will guarantee you'll kill the solution. So therefore, I would advocate a single governance model, a single empowerment model, right? Except treating the human and non-human, understanding the relationship between the human and non-human, right? I think some, you know, go back to the point I said earlier, empowerment of user is important, but over-empowerment is a problem, right? So agent is example, right? You probably don't want to have agent. You don't want to empower agent to spawn sub-agent and sub-agent of sub-agents, right?

The advice is make sure that you have a proper delegation model in place, agent need to have an owner, right? And then the delegation of an agent by the human owner need to be defined, right?

You know, I may be delegating 50% of my responsibility to the agent, but the agent cannot act 100% on my behalf. So therefore, human identity still is responsible for the action of the agent, right? So that kind of define a little bit of governance model, right? But at the end of it, if you break out the two, now you break out the governance. You actually create more problem than introducing solutions.

Okay, so I'm with you. You have to have one kind of VIP layer, so for visibility and intelligence for kind of all kind of identities to break up the silos. Absolutely with you, you have to have ownership assignment and you have to bind this ownership assignment to your IGA lifecycle events, because when your internals are moving department, leaving the company, going on parental leave, you have to act accordingly. You have to do a kind of governance or recertification of policies. What is an agent allowed to do? Not on an agent level, but on a policy level. These are really up to date.

You have to define also SOD constraints, because an agent has the same challenges like a human being and can accidentally probably make an SOD violation when there are the permissions there. However, there are a couple of things difference for sure between agents, and I mean now the long living ones and human beings. So your human employees or your human external identities normally have a kind of job description. So someone in the company knows at least what this person is intended to do, hopefully.

They have normally a manager, or that you might not know the manager in your systems, because you have probably a bad manager relationship in the sense that you don't maintain the data, but normally everyone has a manager and the person is knowing her manager. You have principles like following the money. So HR is paying a salary, and if HR doesn't, the person will complain. So you have a lot of kind of actual guardrails, because someone will raise the hand when some of the kind of human related processes are not working. And this is not the case with agents.

And last but not least, most companies have an HR system, or more HR systems, or a lot of HR systems, but there is nothing like an HR system for agents already. So kind of an agent's registry, or it's not yet standardized as it's in the kind of human identities world, where all this data is maintained. And last but not least, unfortunately there is still a lack of standards that describe or kind of finally resolve exactly those cases you've described. Impersonation, delegation, partial delegation, and so on.

So these standards will hopefully evolve super quickly, then our life will all be easier. But from my perspective, one thing is clear, start acting now. You can resolve the ownership challenge. You can resolve the SOD challenge already. And when standards are in place, then kind of just adapt them, but then you are prepared and you're not starting from a completely green field. Thank you. Unfortunately we are running out of time. Thanks to all of you for sharing your information and your experience with us, and give them a applause, please. Thank you very much.