Road to EIC: Authorization at Scale: Designing Role Models That Actually Work

Hello, good afternoon wherever you are joining us from to this Road to EIC session. I'm welcoming you all here today about the topic modern authorization and where we are discussing approaches that really come from the reality, really reality insights. But let me start with some housekeeping first. So you are all centrally muted, so there's no need to mute yourself. Whenever you have questions throughout the webinar, feel free to ask them through the Livestorm panel. I will pick them up and then ask them.

And yeah, this should be a really practical discussion, so I highly encourage you to ask your questions. The experts are here, utilize the time and their knowledge. And of course, the session is recorded, so you can watch it later, come back to the quotes and look up the content.

So yeah, what are we talking about today? Authorization remains one of the big topics that need to be solved in organizations.

And yeah, when it becomes or when it is a bigger organization, you really need to find a way through the practical path through it to have it still manageable. So this is why we are today here and want to discuss this with real experts. And therefore, I'm delighted to welcome our discussion participants. And this is Oliver Stuger from Erste Digital and Dr. Heiko Klaal from Nexus. First of all, thank you for joining me here in the discussion. Maybe some short introduction. Maybe we start with you, Oliver. A quick introduction and then hand over to Heiko. Definitely.

Hello, everyone. My name is Oliver. I'm a cybersecurity expert in Erste Group Financial Industry Banking located in Vienna, and I'm responsible for identity and access management.

Yeah, and Heiko is the CEO of Nexus, the leading identity, visibility and intelligence platform, driving the convergence of identity and access management and GOC. I'm more than 20 years in the identity and access management space, and I'm looking very much forward to having a great discussion today with Oliver and Patrick. Thank you. Maybe I close the round. My name is Patrick Teichmann.

I'm working here at Köppinger Coal as a lead advisor consulting companies on IAM tools, the right tooling for the challenges, for the right strategies and to overcome the challenges that you have in the real world. So then let's kick off the discussion. I have prepared some questions and we discussed a bit upfront about the topic and what we want to discuss today. And I want to kick it off with one question or one statement you made, Oliver, upfront and want to get your view here. So when you're talking about or modeling roles, talking about authorization, you can do it top down or bottom up.

When you were starting into doing this practically, what happened there? What was your practical insight? What happened and what came clear?

Well, actually, yes. I guess every organization has the dream of, well, let's decide everything in paper and nail it down until you have the perfect business role model aligned to your business processes at the very end. Even we thought at the very first beginning, that's an easy exercise. So we do have a couple of permissions and let's start. So the idea was that on the paper, everything looked really, really reasonable. We had concepts, role ideas, but in a moment when we start comparing it with the reality, it was a big mess because you cannot design structure in isolation from reality.

That's a pure fact. So yes, you need a concept.

Yes, you need an idea along business processes, but at the very end, authorization starts with the permission. That's a given fact. So it's permission, it's user's behavior, and it's the actual work they are doing on a daily basis. So we swept over into a bottom-up approach. It's definitely not elegant. It's definitely not a nice behavior, but it's the reality and it's honest. So if you have a grown environment, if you have a grown authorization structure with different layers of authorization, you definitely need to invest your time also on the IT level when it comes to permission.

That's simply the reality. Totally understand and I totally agree with you.

Yes, so you can come up with the nicest concepts, but if they do not match the reality, so you have the concept as a target somehow, but if you have not thought about a journey to get there, then it becomes really problematic. Maybe, Heiko, your stake on this or your thoughts on this?

Yes, so basically, I'm completely with Oliver in it. Basically, he can second what he has told from experience from other clients and from delivering identity and access management in the past. So there is always the idea on, let's start with Greenfield, let's make the best plan and the best approach, let's build the best concept. This is a great ambition to have.

However, most of the time enterprises are heterogeneous built, grown, pieces of a puzzle have been built together by M&As, by IT integrations, something are looking good, some corners are looking really dirty and messy. So you have a reality and when you have this planned reality check, often things are not as expected. So kind of having both coming down from a bottom-up approach as well is really helpful in order to gain traction on the road because there is nothing that is that unsatisfying, like you have a great plan, but you don't have the traction to deliver really success.

But if you have a look at your current IT landscape and somehow your systems, your identities, your processes and your employees are somehow working. So your business is up and running, you're hopefully making profit, you have a proper operation. So there is at least a very, very true core in your existing IT landscapes. And so it's now finding out the diamonds, the things that are right, authorization-wide, and getting rid of the dust, of the smell, of the dirt.

And when you're starting with this bottom-up approach, you have the chance to really identify the gold nuggets, the diamonds and all those things you have built over the years with a lot of brain power in combinations of your IT and business department. To include that, something is very crucial. You always have gray zones, definitely. So even if you're a startup where you really have a green field, you're thinking about, oh well, let's do it in a best practice way. Every paper will guide you through that, however, over the years.

And this is the truth, you will stick into complexity and you can just manage complexity with visibility. That's a given fact. And maybe to ask something following up this Heiko, so what is needed actually to identify these nuggets? So is it just the tooling or what is needed that I can identify the nuggets I want to bring into the new world, into the new role model? So I would love to say it's just the tooling. Go for Nexus and you're done and everything is solved.

However, this won't be the truth. So the first thing is go with us and then you have done an important step.

However, like in every IT project, but probably even more special in identity and access management, it's also a people challenge. And it's not just an IT people challenge, it's also a business people challenge. So you basically, you need a combination of all you need. You need to have the right tooling, a platform that creates visibility, that supports you with algorithms, with detections, with building clusters. Fabrice has asked about what role AI plays in such a critical exercise.

So AI or machine learning based approaches to kind of help you to find the nuggets and the diamonds, to clustering things, to explain why this might make sense and why outliers are somehow strange. But on the other hand, you need this domain expertise and the domain experts within the business department. So the central identity and access management team, the central IT team, has an incredible knowledge when it comes to running IT projects, doing integrations, doing implementations.

But at the end of the day, they have naturally a lack of a deep understanding how the business department operates. So why should an IT manager or an IM manager know exactly how this loan processes in the finance department works? Why HR makes these decisions that way? And who's allowed in an HR department to access this data for whatever reasons?

And so it's a very, very strong together we need, working hand in hand, the business sides in every department, the central IM team or the team that's responsible for the project, and for sure having the right and the proper tooling to get visibility and intelligence that's absolutely needed for this exercise. Yeah, so I think you partially answered already the question that came from the chat, but maybe just to, because I think there's also a second part of the question we might have to get on.

So Fabrice asked, what role AI plays in such a critical exercise and how does it potentially impact it in a world where identities and access are in constant flux? What are future-ready approaches to build resilience across organizations landscape? To whom do we address this question? To me or to Heiko? So with AI you have various flavors of AIs.

So we have, and those who know Nexus, we have delivered the identity grid which is based on machine learning, so local operations without any kind of cloud necessities, which helps kind of clustering, optimizing, and simulating an optimal set of roles and authorizations. Depending on your organization and depending on your own ambitions, you can have a very fine-grained model in order to kind of make it right to everyone, or you can have a coarse-grained model with just a lower amount of roles to make it easier for the business side to understand.

So there are pros and cons, and depending on your on your flavor or on the way you operate as an organization, approach a more complex or a more lightweight approach can be better. However, with GenAI things have changed and improved, so we got new capabilities. We can have now a kind of a chatbot helping you as a business side to understand in natural language why things are structured the way they are. We call it in parts explainable AI, so it's not just about giving the business users or the IAM team the recommendation, click yes or click no.

The proper reasoning helping you to understand why the system came to the decision or to this recommendation is super important for the majority of users. So explaining within explainable AI why do we have this recommendation to change the authorization, to change the setup of the role or to remove an assignment from Oliver or to add him into a role. This is very crucial to help those people out there because when you think you're in an HR or finance department and the managers that are doing recertification or adding users, they don't basically care about IAM.

They care about finance, they care about marketing, they care about HR or whatever their profession is. So basically they want to do their job and getting the kind of annoying IAM and IT thing when a new employee is onboarding, when someone is moving the department, that's just a burden for them. So making it easier or as easy as possible and explaining them in natural language they are able to understand not should Oliver be assigned role underscore SAP underscore procurement some numbers or so.

No one understands this but saying okay is he allowed to do purchases above 100k to approve yes or no. This is something I can decide as a human being and as a manager in an organizational unit and I think that's the important piece. Maybe Oliver also you have you know that?

Yes, you know we are a financial industry so we are strongly regulated and yes, agentic AI or agentic AI and AI in a nutshell is also now slightly but surely targeting our internal but also external IT systems. One big advantage when you talk about AI in special on authorization is analysis. It's about analysis. AI can help you to analyze your authorization data in a way that you nail down from 100 roles with no description, no names, just guessing to 10 roles which are understandable in a clear structure. So this is a fact.

On the other hand, yes I would like to see a target operating model where an identity and access management expert would simply say oh well I need a new role which can approve a loan above 100k and the system generates it you know just need to say well roll it out and that's it.

Yes, I believe in one or two years we are on that stage so that such roles can be deployed in your system automatically, can be linked to the job profile, is also able to do an exception when it comes to oh well my colleague which normally has that role is now on vacation so I automatically shift over the role temporarily to another employee who can then do this kind of approval. This would be an approach where a manager just need to take care on this annual reconciliation stuff to focus on roles which are requested manually.

So from that perspective I see a big big big chance in using AI in the authorization management but also in a way like if you're the step before. So AI will then work perfectly fine if the underlying data quality is that high that AI can work with it. This is a given fact. So if you want to clean up your system and this exercise is actually our current activity across the whole group. If you clean or need to clean up your environment in terms of authorization data, AI can support you.

So Nick asked, there are ideas in the market suggesting that in an RBAC model permission should be first grouped into technical roles per application function and then assigned to business roles. Do you actually see this in practice? I have an opinion on it. Please stop. I'm happy to hear. Please stop. So basically nearly more than 20 years ago I did my PhD in, guess what, identity and access management. Back in time I published a paper and funnily I discussed this last year with an analyst. So it's 20 years old research but still somehow up to date and I would say yes and no.

So from a theoretical perspective if you are modeling everything fine-grained it looks super nice. You have this fine-grained entitlements and applications. You build technical roles. You have technical roles to business roles and business roles assigned to users. So this works quite nice.

However, we believe there is the need and this is what we're seeing with our customers, the need for flexibility in the companies out there. Because when I'm working in a company like Airstead, they do have an application landscape. So when I insist on you have to build this and this doesn't fit into their existing applications, whether it's commercial software they have just procured or whether it's a DIY build solution, they won't start refactoring just fitting my model.

So we believe there should be a flexibility whether you go for commissions into technical roles, whether you just assign permissions to business roles, whatever helps to move them forward. At the end of the day it's always a human being or potentially a non-human being. So an NHI or an agentic AI agent is assigned some roles and authorizations. And this role and authorization should be understandable by business users and should be maintainable. They should have the right granularity so not too fine-grained, not too coarse-grained to set up a proper system.

And if this fulfills the need then everything is good and the kind of heterogeneous system landscape at customers, the legacy that's there, that can be supported. So this is the way I would recommend. Instead of just fulfilling the sake for making the best scientific role model ever is a very pragmatic one. Take what you have and try to get wins and gains out of it. What's your perspective, Oliver? And welcome back Patrick. Classical airbag is your baseline. This is your baseline, your daily business, what is perfectly matching to software developed 10 years ago. This is your baseline.

Yes, it will work. It is still valid regardless whether it's a human user, non-human user, we don't care at the moment. But it's static. That's the creepy point. It's static. As I meant before, we are now, yes, agents. Everyone has a different opinion of an agent, but let's read it in a way. I have an agent which does something. At the very end, it's not the agent who is executing an activity, it's the combination of the agent and the data.

So, and then you're automatically in a context. So in the context of the agent and the data, for Oliver, the agent is executing a specific task and then you're automatically in context-based authorization models. Whether it's then rebat or policy-based access control, we don't care. With classical roles, you will not, and this is my personal opinion and it's proved right now, you will not succeed with ARBEC alone. This is a given fact.

So yes, it's your baseline. There are definitely use cases where it's nice to have, nice to fit. You can match it perfectly to job profiles or what the regulator expects to see. This is the job profile. This is the business role.

Yes, agreed. And if it then comes more into a dynamic world, Patrick, you know it. If it comes to a dynamic world, the question mark is always the what and why. So how do you govern it? And this is now being challenged on every level. So regardless whether it's the regulator, legal basis, or even your manager, which doesn't know about the context or authorization context putting into an authorization. So I would say it in that way. That's from the agentic perspective and the NHI perspective, that's a super crucial point you brought up, Oliver. So with humans, it's often easy.

So you have an HR systems and you have job description. So you can deduce a lot of this information. What is the person actually intended to do? Who's the manager? What is the person actually intended to do? Who's the manager?

So in HR, if it's maintained well, there is a manager relationship. If it's not maintained well, at the end of the day, you have a manager. Probably you don't find it in an IT system, but there is normally a manager assigned to you. So there are a lot of capabilities there that make identity and access management easy. With non-human identities and agent, it's different. So it's built somehow. There is not a job description that fits in into a department or based on your education. There is not necessarily directly a manager. There might be an owner, a business owner, a technical owner.

So things are getting more complex. And so I'm absolutely with you. This complexity from non-human identities, agents, but also from in certain cases where it makes sense for human identities, where dynamic access policies can be a game changer, where you bake in different attributes, where you bake in context, where you bake in probably risk signals. And what we believe in is when you're bridging the IAM to the GRC, where you have far more important attributes to include third party risk management, certification status, risk scoring, you have an understanding about systems and processes.

And when you imagine you can bake in this kind of treasure of attributes into policies, then they are getting really, really mighty. Yes. Yes. Sounds great. But now I need to challenge you a little bit. Go ahead. Okay. Yes. I'm totally with you. But what is your plan if you're now sweeping away, well, you know, DORA. It's a fantastic framework. We all love it. And you know, there is this kind of principle of get your critical important functions done. And there is this small piece of three letters, this SOD. So the segregation of TOTs.

And I'm really excited to hear your opinion on how do you sweep SOD within the policy driven authorization layer? I know, Patrick, I know, Patrick, it should be your question. But I'm really curious to hear about Heiko's opinion. That's a good question. Probably Patrick decides to go out again to grab another cup of coffee or so. So let's do it on our own. Yes. That's super critical. So in the old and easy world, SOD could have been easily modeled. So you have role one and role two and both roles are in a easily modeled nexus.

So you have two roles and you have the SOD metrics and you say, okay, this roles are conflicting and that's it. And then you are not allowed to assign this roles, not allowed to request the other role when you have already this role, which is also a critical feature. A lot of IGA tools don't have this capabilities.

Within a dynamic access policy, and actually I had this conversation just yesterday, just yesterday afternoon with a great partner of us, it's getting a little bit more complex because you have, for example, in a static RBAC or even dynamic RBAC rule, you have and you have a four I principle built up in roles. You have your role one, your role two, and then you have done it.

However, from an organizational perspective, it makes sense probably to have just one role. So you are the loan clerk in a bank, for example, and when you have done the initial check, you're not allowed to approve. And when you are allowed to approve, you are not valid to have done the check before of some conditions whatsoever the bank's business is.

This would be crucial to bake in on the one hand in dynamic access policies where you can build such policies in the right way saying, okay, when the person who has checked the loan application, this can't be the approver, that's easily to model into a policy. However, what's the hard pieces? We don't want to have this preconditions in the policy because then you have to have this domain knowledge in each and every policy and the likelihood to mess up is super high. So we have to kind of extract it into our central SOD repository, SOD metrics, and kind of bake it into this role scheme.

I know that's for certain cases sophisticated and you can make it super sophisticated if you do it on a very, very fine-grained level, but this would be the way to go that you have on the one hand kind of proper SOD constraints out there defined in your tool, kind of being reflected as a constraint when you are modeling dynamic access policies, thinking of OSN or OPA standards, for example.

And on the other hand, being at the same time then compliant and having the proof that you have have implemented those guardrails because you can't expect that every IM manager and every business department has a proper understanding of each and every corner case. So this should be kind of baked into the system, especially coming to an agentic world where it is sad that business users are kind of building up agents by themselves. There will be also the challenge on who creates the kind of proper policies when IT gets more and more without borders and business and IT are growing into each other.

Let me answer on that. Yes, I agree with you. Policies can be easily designed that you get completely lost in the area where you define your policies. When we found out this, and this is exactly where I want to conclude, you need a context or you named it not context database, but you named it in a similar way where you put the business logic somehow in a database or in a repository where it's then an evidence for your policies. So this is actually what we are now trying with critical and important functions.

Coming from the business process side, we have the gap and this is actually filling the gap. We have the gap between certain tasks among the business process like approval or something like that. We don't care at the moment and there's a missing link between the actual permission where you transfer the money at the very end and what needs to be happened before. So if you put this in a kind of database and this is what we are currently doing, then policy-based approach is a good idea.

Even if it's then usable for if you do the transition from a human user is actually approving something to an agent can approve it based on the risk score or whatever reason you have to do. So from that perspective, yes, ABAC is your baseline and from ABAC to REBAC or policy-based approach, it is a journey with getting things visible and done. Patrick.

Perfect, hello again and I think it's a perfect bridge to where we are talking now about dynamic authorization and there is another concept and Fabrice Paul brought the question up around just-in-time. So how does this fit into this world from your perspective? Do you have an opinion on this? Maybe Eiko to start, just-in-time access. How does this work into the world between RBAC, traditional static access and then going into the dynamic world?

Yeah, that's also a good question. So just-in-time has been a topic in the PEM space for a longer time already where it makes absolutely sense. So I'm an administrator of the system and I should get then my privileges when I'm actually using them. That can be done and transferred to business users and business applications as well.

However, the thing is always what kind of landscape do you have? So most of the enterprises out there have a completely heterogeneous landscape and now seeing a stack, just pick one of the IGA player, the leading ones, the not leading ones, the strong performers, the performers. Most of them and most of the audience probably has had their experience. So IGA in the past and probably up to date was never intended to do a kind of real-time provisioning. So basically no one cared about whether a role was provisioned and it takes one second, 10 seconds, 60 seconds or so.

I would say basically most of the IAM teams don't even know how long it really takes because the bottleneck was in the past always the kind of manager approval. The manager has the approval mail, does not do something until Friday afternoon when he or she's cleaning up the mailbox. So basically role provisioning was always kind of the bottleneck, was the human approver in so many cases. And from a business and operations point of view, it was not critical. So when you have onboarding on your first working day, probably the accounts have been provisioned the day before or something like that.

Whether it takes 10 minutes longer or 10 minutes shorter, no one really cared as long as it's not taking days or weeks. So I'm speaking from a bit of time. So when you do a just-in-time authorization or access, probably it will be good for you, Patrick, to grab another coffee whilst waiting for authorizations. But when you're doing a real business operation, it will be annoying. So coming from that, I think in an existing customer landscape, the majority of cases, it will be challenging.

There are valid use cases where it makes sense, where you have that kind of win-back right for getting some authorizations in order to have previous access. But I would doubt that the majority of clients out there are currently able to do it on a large scale across the enterprise. It's the discussion of stunning accounts versus just-in-time. On IT level, so use cases, you're absolutely right. It's the use case. Analyze your use case where just-in-time is really something you can run. Every auditor will love just-in-time because it's stunning.

You don't need to reconfigure something so you decrease the level of reconfiguration activity. It sounds perfect. It really sounds perfect. There is a drawback. If your IGA is down or your network connectivity is down, there is no just-in-time. And there is a golden rule, never put an evident system into an operational system. You should not do it. You will have challenges. So how and where we use just-in-time as of now, because it makes sense. So we do have a multiple account concept. So if you have administrative tasks, you need to have a separated account. It's reflected in the IGA.

Everything is perfectly nice. You provision the account fine. At the very end, it makes no sense that you force the employee to authorize through multiple systems until you get to your virtual machine. So just-in-time allows you to provision an administrative account to a database, to a virtual machine, to whatever system in terms of administrative access needed. But be careful, don't break the glass. So stunning accounts will also be, yeah, you're laughing, but this is a break the glass, break the glass. It looks really pretty nice.

Oh, well, everything is just-in-time. If an administrator needs access, he never ever needs to have a second account, a second password, another authentication system. It's all done in the pump.

Yes, it sounds great, but don't forget to break the glass procedure. That's a given fact.

So yes, just-in-time has definitely the pros, and we consume just-in-time, but more on the IT side and less on the business side. I would maybe conclude it here. It's again, it's a nice concept. It's a very good concept, yeah, with which you can reduce the risk, but it needs to work in your environment, yeah. So you don't, you cannot adopt just a concept because you find it nice. It still needs to work in your particular environment, and yes, as Oliver, you said, you have to think about what can go wrong.

Yeah, what can, yeah. And it will go wrong. It will go wrong. So what can go wrong will go wrong. Definitely, yeah, this is true. But also the question, what does it require that identity access management is a business topic, right? And it's actually this big question mark. So what does it mean? It should be driven by an IT project, right?

It is, yes, it's a continuous project. It's not, oh, well, my roles are now designed. I'm happy. Now lean back and let the system do the rest, and the rest is done by any agentic AI framework.

No, that's not. We learned in the past one and a half years that authentication management is a journey. It never will end. You will not reach the goal. You come closer to the goal, but then the goal shifts. That's a given fact. And the question there is, if you drive it on IT level, you will end up exactly in the situation that what Heiko mentioned before, a role SAP underscore one, two, three, four, five, because it was just in time put into the system. It's then going live. This would absolutely happen.

So from that perspective, it's really something where you need to put your governance on a clear level. Don't check in entitlements you don't understand. Don't create roles which are not understandable by your manager. It's enough by your manager because he needs to approve it. And from that perspective, yes, IT has a supporting function. They have a consulting function. They know their entitlements. They know the criticality of entitlement. But in the context of the business process, they have no clue where this actual entitlement or permission is then required.

And I guess this is one of the core topics. We'll get to the other questions from the audience in a few seconds. But I think this is one of the core questions we see out there with a lot of clients that actually IT authorization was developed as from the IT and not together with the business, not to get combined with the business knowledge. What does this particular authorization do in relation to my business, to my daily doing? And I think this is the disconnect we need to handle today. And this is the reason why we have to go the bottom up approach and have then to combine it.

And maybe I jump to the next question from the audience. There are now questions popping in. So Alfred asked, for organizations that are just starting to mature authorization, what is the best first step to take without oversimplifying the problem? Maybe Heiko, you want to start? I'm happy to start. So what's the best approach? We have defined an approach we call the nexus health check, which is basically, first of all, knowing your data. Because there is a lot of truth in the data. And you have probably this gut feeling my authorization landscapes is messy, doesn't look nice.

But most of the time, you don't have really approved. So it's hard that you get budget from your manager. And that's why we have designed the health check, which is you get the software for a while, you get a bit of support, you can work on your actual production data. Most of the time, it's a copy that customers feel safe. And then you get immediate insights on how clusters can look like on how roles can be built. And you have learnings that you can use to kind of start conversations within your organizations with the state or stakeholders to get your buy-in.

As initially said, it's not just an IT project. It's also a business project. So you have to get the buy-in from your business, business owners and from your business stakeholders. And this is extremely convincing. And I love the, the analogy that we call it health check. So it's like going to the doctor where you do a blood test. So you get the results of your blood tests. And you can decide what you what you want to do, because all the blood values are really bad. I don't care. I keep on drinking smoking, eating, whatever I do, or you change your behavior. So it's completely up to you.

And the kind of granularity what you're doing is, is up to you. So probably you will say, okay, I'm I'm so much into pizza. I'm so much into hamburger. I have to stick with it. But I stop smoking and I stop drinking on a daily basis, something like that. So you can kind of adapt what's what's good. There is the recommendation to get it to the upper level, to eat the best food, not to drink, not to smoke. In reality, it's probably a mixture and very much depending on your personal preferences. And so it is with with Rhodes. So it's probably not cleaning up the whole organization immediately.

Why not starting with finance? Why not starting with HR? Why not starting with marketing whatsoever or ever, and then working down? And I think that's the that's the easiest approach. But Oliver has for sure, his opinion and experience on that point of view as well.

Now, okay, now, the bed of roses as a customer of Nexus, and as a customer of doing this health check, actually right now in our company, we so once we started with our identity access management project, we phased out that we do really, eight, seven, 10 different authorization systems. So there is a proper system which was developed many years ago, a common authorization layer, you can think about it like, like in Azure, where you manage all your permissions for landscape connected to this authorization layer, then you have Office 365, AWS, GCP, you have SAP, the nightmare of SAP.

So you have everything in a company, in the financial industry, what is what is on the market, really everything. And all of these all of these different authorization layers, then to analyze in an environment with 80,000 users.

In Excel, and we did this exercise is underrated. This is simply underrated. And it makes no sense, because you will not reach out a certain, a certain overview level, a level of maturity level, if you do it hand by hand. So we searched the market, we found, we found Nexus.

And it is, and I'm, I was really surprised. It is that simple. You don't need to connect. It is easily important, you can immediately start.

That's a, that's a given fact. And now we are now we are in the phase of getting more insights. And the idea is not that we do a simply a health check where we have some quick wins, because we are asked by the regulator to provide some evidence that we are doing our cleanup exercises. Now we start more in the statistic way like, okay, and this is the next topic, I guess, you want to point out, Patrick. So we want to provide a kind of a kind of basis for an SOD metrics.

So it's a, it's a bottom up approach to analyze not only the permissions, because the permission, we actually don't know what the permission is. Yes, we know it's critical, it's not critical, but we don't know in the business process where it's where it's needed and required, but we know the people. This means you don't, you need the permission, then the role is a complete other story, because you can refactor your roles in Nexus.

Easy, it's a pre-flight check, you have the recommendations there, you can combine it, you can cluster it, perfectly nice. But the added value, if you do such an exercise of refactoring your landscape and to bring it on a higher level, like you need it for an SOD metrics, is then to consume all this data alongside a business process where you've noted people doing a certain thing.

It's like, I need the permissions of my former colleague. It's completely the same approach we do now with the analysis capabilities of Nexus. So from that perspective, I would treat it exactly in that way. I would say, but this highlights again the importance of to have a close look at what is the result, and to do something with the result. You still need to know the organization and combine this knowledge with the results you get, for example, from Nexus, from the tools.

You still need to have someone who has the clue about the organization, the people, to know what they are doing, to actually then drill it down and combine it with the knowledge from the results you get from Nexus, for example. Okay, perfect. We have another question from the audience. So before jumping again to my questions, I will, of course, take the opportunity to ask you the question from the audience. Solomon asks, as the IAM PAM vendors are enhancing their products to suit AIML adoptions, is it prudent for the organization to evolve the IAM approach from RBAC to ABAC?

Share your viewpoints. Maybe, Heiko, you want to start again?

Yeah, happy to start. I would always see it's a combination of both. That's what we see in practice. So there is neither an organization with pure RBAC, nor an organization with pure ABAC. It's often a mix. When you think, for example, we have what we call dynamic RBAC, so the policies behind, and it's not a static RBAC. So we can say, okay, depending on your organizational unit, which is at the end, an attribute of an identity. And so you have this kind of transition functions from ABAC to RBAC and vice versa, probably not in every case, but for quite a lot of use cases.

And so I believe that something in between is the right thing. With attributes, the thing is, the hard thing is for organizations to have leading systems for the attributes that are kind of setting. So a master system for some attributes, an authoritative system, and you have a clear understanding what attributes means. There are simple attributes, and there are organizational unit.

Normally, you're part of a team. The team is maintained in HR. HR can hopefully say, okay, you are part of this team, and they have this team ID, this OU ID, and so on. And then you can start from there, knowing, okay, you're in the marketing department, you have access to the overall marketing share point or so. You're working in Munich, so we have probably some special Munich rights versus where you are when you are working in Vienna.

You might have some different rights and permissions based on your location, probably entering some office buildings, booking meetings rooms at the location whatsoever. But there are so many other attributes, and then it gets more and more tricky, because someone has to say, okay, this is the kind of schema behind the attributes, and this is the kind of schema behind the attributes, and this is the kind of schema behind the attributes, and this is the master system.

And I think that's the crucial thing in ABAC to figure out, is my organization mature enough to maintain a proper set of attributes? Yes or no? But Oliver, from his practitioner point of view in a real organization, has for sure an opinion as well. I'll give you the perfect example. It is expected by auditing regulators that, what I meant before, 60 to 80 percent of your actual commissions are bound to your job profile. And in a financial institute, you have a kind of degree level. So you are a junior, you're an expert, you're a senior, depending on your learnings.

So the more learnings you have, the more online webinars you successfully finish, the higher is the degree of things you can do. Perfect example for ABAC. Because it's evidence. The idea of the regulator is having the job profile and the job description on paper in HR. It also describes, in a perfect world, to be honest, in a perfect world, you're actually a day-to-day business. And the higher your education level, the more permissions you get. I must confess that, yes, in theory, this is true.

Practically, it would lead to the situation that not only business in terms of a bank or an institute needs to be part of the identity and access management. We immediately involve HR. And then things get in complex, because the job profiles, job description, all those things must fit together in order to derive an authorization model.

So, yes, it's easy to link a job code 12345 to a roller. That's easy. But if you have multiple institutes with the same job code, but with different portfolios, with different processes, then it's getting more tricky. Coming from this example, you must be careful that you don't create three out of one simple attribute. It's the combination of multiple attributes. It's what you meant before. It's either Vienna or Munich. It's either a big bank or a small bank. It's either a bank which has a treasury or markets department or not.

So, if you put this all together, it's very easy to design. You don't need to approve such things, because they are automatically deployed to the employees. And maybe to conclude here, I think Heiko, that was a very good statement about this.

You know, I think it's very important to think about the role design and the role design and the role design and the role design and the role design and the role design and the role design and the role design and the role design was a very good statement about this. You need to have the maturity. Because the thing is, when you have RBAC and static access control, where you do everything with request and approval, you have someone who has some particular decision tree in their mind when they are approving something or declining something.

You need to be able to put this into rules, into rules the system can do. And the thing is, what we see from the practice, a lot of organizations really struggle to formulate these rules. Because a lot of things are not like formalizable in this manner.

So, maybe to come back to Solomon's question. So, the thing is, it's a journey. RBAC is a start. And to move forward in the direction of ABAC is a necessary next step. But it requires the maturity of the organization to do so. We have another question from Prater Bahn. I hope I pronounced it correctly. And I think it might be the last question we are able to do.

Otherwise, we are running over time. And there's another question in the chat.

So, I'm very happy that we were able to trigger the questions. But I think this is kind of the fun one. Let's see how the time works.

So, his question was, how important is it to follow standards like SSF, the shared signal framework, and risk for authorization signals? Is compliance mandatory to ensure access control for agentic AI?

Heiko, you have an opinion on that? I do.

So, we're building SSF. So, when there are standards out there, it makes sense from an interop perspective to kind of follow the standard and not reinvent the wheel. SSF fits a bit better to the runtime perspective compared to the IGA perspective.

However, there are a couple of signals defined that make also sense for an IVRP or IGA world. And so, we have a signal emitter. We have a signal receiver. And those signals that make sense are mapped to kind of functions within Nexus to kind of do the proper action or the proper remediation. Clients are able to configure it whatever they want.

And so, from my point of view, it makes sense to kind of fight against any threats. For example, Nexus being a signal emitter, so sending signals to the wider organization, is we have some built-in ISPM functionality. I said identity security posture management for IGA.

So, when we see deviations and anomalies from what this could look like, we should inform someone. It's probably not enough to inform the manager, hey, Oliver's identity looks now kind of over permission, please check it.

So, we're sending it to the organization that might be on SOC immediately reacting, that might be an additional approval to the manager. But this might also be a signal that's caught by some authentication software, by an ITDR software that probably cuts off Oliver's access cost. On a Sunday night, he's suddenly working in an IT department, gets high-risk financial privileges in the overall organization. Seems a bit smelly, could be that an attacker is preparing his account permission-wise for going the next step.

And so, I think following the standards is an important feature in the overall target picture to be a part of the big cybersecurity piece. Yes, it's not an identity and access management topic, you agree? It's a psychops topic. I can just add on what you said in the beginning, Heiko, it is really about sticking to standards enables you like to integrate, yeah, and with everything moving so fast now, you were asking here, is it mandatory for being compliant? I would say it makes it at least easier to be so, yeah.

So, the thing is to integrate these signals and it is becoming more, yeah. If you look at Martin Köppinger's view on the identity fabric of the 2040s, everything is supported by the shared signal framework, yeah.

So, this is going to be changing how we are doing IAM authorization, yeah, when we are moving in the next evolutionary step. So, to stick to such standards is always a good idea. In respect to the time, maybe one or a round of, yeah, kind of closing statements from you.

So, what could be a very practical tip, yeah, hint you would give organizations which are there and need to like, yeah, redesign, they are standing at the beginning of the journey and need to now implement a role model, are facing the situation that they need to implement as a team. What is the first thing they should make their head around and start the journey with?

Oliver, from your practical experience, what is the first thing you would hint at? Just another tool will not solve your problem. That's a given fact, but just another tool will not solve your problem. It's not an IT topic, you need the right guys, the right people on the table, you need the business involvement, you have different, we already discussed them very briefly, HR, very important. You need business process guys, you need portfolio managers, you need IT.

So, it is on the very end, a comprehensive story journey. And I would sweep it in a way, you don't have an authorization problem because you're working, you might have a visibility and ownership problem mostly. And this is- In governance. In governance, yes. The bottom line, yes. Thank you.

Heiko, maybe also some final words on this review. So, I can fully second what Oliver has said. From my perspective, go for a health check. It's worth, so there is exceptional user feedback on that. And last but not least, EIC in Berlin is approaching. I'll be there, Oliver will be there, so feel free to meet us, have a conversation, whether it's at the booth, whether it's at the coffee break somewhere, together with probably Patrick, who loves coffee, obviously, I have to make this joke again, or join our dinner on Wednesday and Thursday. Drop me a message if you're open to that.

So, I'm really, really looking forward to meeting you in Berlin. And for sure, you can get a live demo on how these things Oliver described, I described, looks like on a screen with real data, getting a feeling. And I think that's always important, something live and in action.

Yeah, this would also be my closing words. If we get you interested into the topic and you want to continue the journey, join Oliver and me in our talk about from capabilities to clarity, where we talk about this journey. And then afterwards, we have a panel exactly about this topic again, about the authorization, about scaling it together with Heiko and some other people, some experts there. And I would be very happy to see you there. Thanks a lot to all of you for joining. And I wish you a nice rest of the day and hope to see you again. I will get you now another cup of coffee. Good stuff.

So, thanks Oliver. Thank you. Thanks everyone. Thanks. Have a nice day.