Welcome to the KuppingerCole Analyst Chat. I'm your host. My name is Matthias Reinwarth. I'm an analyst and advisor at KuppingerCole Analysts. My guest today is Martin Kuppinger. He is the principal analyst and one of the founders of KuppingerCole.
Hi, Martin. Hi, Matthias. Pleasure being here. Great to have you. We are still on our road to EIC, and we want to talk about a topic I know you for more than 11 years now or 12, I don't know. This has accompanied us over the time because it's more or less a challenge, a problem, a nuisance for many organizations. You've just written a blog post about that, and I really like the angle that you chose, especially that we maybe have the tools to solve parts of the problem. We want to talk about the problem, and please don't go away. This is an important topic, and maybe it helps you.
We want to talk about recertification. The blog post you've written is called Recertification from 100 to Zero in a Day. This is a bold statement, but first of all, to lay the groundwork, why is recertification still a problem? So recertification or access review or whichever term you want to use, there are quite a number of access certifications. There are quite a number of terms. It's a challenge, and yes, it's a bit of a provocative title, but I think there's also a lot behind that.
So my starting point is when I look at things and I feel there are things that remain unsolved or not very well solved over a very long time, then it's time to step back and think about do we take the right approach, or are there better other ways to address a challenge? And for recertification, I think that my starting point is no one likes it. So I haven't seen a single organization globally where anyone would say, hey, my departmental managers, they are really so happy next week, the next recertification campaign starts for all the excellent entitlements of their workers. It never happens.
And then something is wrong, plus the results of how we still most commonly do access certification are not good. So this entire thing popped up with the idea of we need to regularly review, or basically the idea is we need to ensure that we enforce the least privilege principle. This is basically the mandate. And then someone ended up with, okay, then let's review the entitlements. The problem is when you have a long list or a huge matrix, I also have seen stacks of paper of 70 pages of paper where someone should then check all the entitlements.
But regardless of which approach you take, there's a tendency to rubber stamping. Vendors have invested a lot in saying, okay, we help you, we split this into smaller trunks, we do it on occasion when there's a certain event, when there's a certain change there, we focus on the most critical ones, we provide you with context, et cetera. But it still means it's a complex thing and the quality of what is done is not overly good. So at the end, we are not where we should be.
And I believe we can really simplify the life of everyone that sort of has to deal with that by just taking some obvious, easy to, in many cases, really easy to implement very logical measures. And you've mentioned 70 pages of documents to look at, to do an access recertification. But I think there is a general problem behind that. Could it be that access models are too complex, are over-engineered, are too large? And maybe that could be a starting point at first to say, okay, maybe I don't need 15 dimensions and three approvers. Okay.
So if you have that, then you anyway did something wrong and yes, blame on me. I've been talking in very early Copenhagen Call webinars also about multi-tier role models.
No, don't go for too sophisticated entitlement models, be pragmatic. I've been in projects where already men months, probably men years or person years to be precise and politically correct, have been spent. But I think when these projects were running, the common term was the older one. So there has been a lot of time spent on just discussing about terminology.
And yes, then you have your business role in your IAM project and that business role is not the same as the business role in SAP. And that leads to endless discussions. And then the question is about, can I, in this multi-tier model, map a system role directly to a business role or do I need the IT functional role in between?
Oh, by the way, what's an IT functional role? And so we create complexity and that doesn't help. And then there's also frequently a tendency to over-sophistication, that every exception is ideally treated by another role, which can lead to this role explosion thing. You have more roles than you have employees. Latest time you should know, OK, something went wrong. So the number of roles, which is an abstraction grouping, must be very, very, very significantly lower than the number of identities, full stop. Right.
And I think technologies, processes and concepts are available right now to actually do things better. And in your text, in your blog post, you suggest that 80 to 90 percent of entitlements that are currently recertified could be policy based, so automated. And based on that, policy could be taken off the list of recertification. Is it necessary to allow for this? Because we've promised or I've promised in the beginning that there might be help for those who struggle with recertification. So there needs to be groundwork to be done. I think that there are two important things you need.
The first one is you need a technical solution that knows which entitlements have been granted via policy and which have been granted via manual requests and approval. This distinction is important because if the entitlement came via policy, it has a very different status from a recertification perspective because then it's just a question, does your system work correctly? Is the policy correct? And is the data used by the policy correct? So you end up with a policy and data governance requirement, but it's not that you need a manual access review.
And my thesis, and that is something that comes from a very long experience in identity management, is that probably 90% of all entitlements can be assigned automatically and managed, not only assigned. It's not just birthright. Birthright is oversimplifying. You need it for the mover, the relocation, the leaver process as well.
But 90%, that is my statement, can be automated. Let's be 80%. But if you have 80% that come in because someone is in a certain organization, in a certain location, has a certain job title, a certain organizational roles, which require that you have this information, but that exists in, ideally you have some business process, business activity information, which exists in many, many organizations, then you can use that. You can assign and change automatically based on policies. Something you, Matthias, and me have built into our process models that you can get from Kubernetes Code Analysts.
So we've built the process models that reflect this difference between manual and automated assignments. It must be in every proper identity management implementation, there must be a defined, visible, described process model, and that must reflect this difference. If you don't have this, you anyway have an issue in your IAM, a major issue, because then you fail in the processes and then you anyway fail in identity management.
So, but having said this, if you have these, whatever, 80% automatically assigned, that means there are 80% of the entitlements that don't need to go into your manual access review process and your recertification, and you're already down 80% with one logical measure and one you already should have these, honestly. If not, step back and ask our advisors to help you in sort of optimizing your IAM implementation. That's the latest time to do that. It's a process perspective, as you said, so it needs to be baked into the overall lifecycle plus provisioning part.
On the other hand, of course, and that's the prerequisite that we need to think of, but we should have thought about that 20 years ago as well. So it's not nothing new, it's data quality. So having the right information available to achieve this automation, to have these automated policy-based assignment of access rights to people.
Otherwise, you get to garbage in, garbage out, and using not properly maintained data for automation is a recipe for disaster, of course. So cleaning up the data, having current data and automation in the processes, I think that's a starting point. So you don't always need AI and nice nifty new features, just doing the groundwork right might help already. So this is not a selling a tool, it's improving processes. And another idea that we both discussed very early at Köppinger Coal is time limited access.
So really making sure that even if access is assigned manually, it should be only assigned for a limited time. Ideally, a time that is shorter than the typical recertification period, so that it ends before you need to recertify it. And if you really need it, then you just order it again. Is this the simple idea behind that? It is a simple idea and it's a practical one.
I just saw this happening in a project that a customer of ours in the financial services industry, where it's about physical access and it's not super easy to automate physical access because the integration into the systems that handle physical access from an IGA tool is tricky, not because of the IGA tools, but because of the state of immaturity of the physical access control systems. And that means if you just say, okay, six months is for the critical access, the review period or recertification period, and I go up to six months, then you never have to do a recertification.
You need to reissue or re-approve. Yes, but that is something which can be done much easier than the access review. And my analogy comes from email. So when you have an email system, a lot of your mails are handled by rules. So they are handled by the trunk mail or spam filters. They are handled by maybe who's you've set up or you just move their mails into certain folders because you anyway, don't look at these. And then you have two other remaining groups of mails. So once you can very quickly handle where you say yes, no, short sentence, direct response, and that is the one.
And the other is the ones that you look at and say, oh God. And then you move them somewhere or you leave them in your folder. And when you have time or when you need to find time after the third escalation, the third reminder, you start working on that and approving an access request, extending an approval and say, okay, it's still valid for the next three months. That is the first type of mails. One where a decision maker looks at and say, okay, yes, Matthias is still in my project team, click done. Recertification, so where you have to look at multiple things.
And even if it's sort of reduced to a limited number of things, where you need to look at these people, this access across these projects, across these business processes, it's a complex thing. And you don't do it too frequent. So you need to think about how to do it again. You don't like to do it. So it is the other type, so to speak. So when we work with time limited, we reduce complexity and we simplify the handling.
We need to be a bit smart so that not on the 1st of January, a departmental manager receives 300 individual mails for extending a certain type of access, that there can be then again, smart grouping for the similar things or just sort of distributing a bit the mails over time. So I think there are some smart ways to handle it, but we can do it. It's an element, but it's clearly not the first one. The first one is automation. Maybe it's not even the second one, maybe it's the third one. Because you already touched AI. Exactly.
But up until now, everything that we explained and talked about is something that you can do without upgrading your infrastructure, extending your identity fabric with additional capabilities, because they are already there. And this is also part of the beauty of the EIC. We will have lots of best practices sessions where people talk about how to do properly and lessons learned and what can be derived for yourself. And this is what we wanted to do with this episode as well to say, okay, yeah, you can just do this with everything you have on board right now.
Having said that, of course, there are new capabilities that can support in getting from 100 to zero in a day. And that of course is the elephant in the room.
It's AI, it's usage driven, it's pattern matching, it's understanding how people actually work, and this is an additional factor that you've mentioned in the blog post, right? Yeah. And I think, you know, when we saw AI coming into IGA solutions, so identity governance and administration, the first thing was around, we analyzed the existing entitlements, we proposed role candidates, stuff like that. And from the very first day I said, hey, why don't you look at how entitlements are actually used? And I think this is where the potential of AI comes in.
Not just saying, okay, these are the existing entitlements, but how are these used? And then there are very obviously scenarios where entitlements are not used at all. I talked recently with an expert in the SAP space and he said, we have numbers. And so my estimate was that 40 to 50% aren't used. And if you look at the higher level of entitlements, yes.
He said, when we go deeper into the SAP transactions, it's 80 to 90% that are not used at all. Plus you have certain entitlements that are only used in very defined situations, like certain types of things you do in financial systems at certain periods, like years end booking, stuff like that. So certain things don't happen frequently or they just happen in certain defined periods. So when you have a factory, when you have manufacturing during a summer break, there will be a lot of very different access because all the suppliers come in, update firmware of the machines and stuff like that.
But that's something which is predictable where you can move to a trust in time access and AI can help in that. And, but just going back to removing what never is used, if we take the 50%, so we have 80% of wire automation, we have 20% remaining, half of them we remove because it's never needed.
Okay, a bit oversimplifying the mathematics here. We are at 10% maybe. And then we do a bit of time restricted for the remaining few entitlements. And then we've moved to the strategic solutions. And that is a topic that, that, that, that we've discussed also very often.
It's, it's, I don't want to take it away. So what is the root of all evil when it comes to having the necessity to do access recertification? Static entitlements, standing privileges. Very clearly.
You know, we have role models introduced to manage all these entitlements and to assign them to all the people. So that's already where the problem starts. Role project and to be complex, they take a long time. They have a tendency to over sophistication and we have recertification because of that. So we have a couple of obvious challenges stemming from standing privileges.
And, oh, interesting. We are in 2026 now. It's the 50 year anniversary of where we should know how to do it better. You know why? IBM. IBM RACF.
1976, IBM released RACF, the Resource Access Control Facility. A solution where different applications can basically author some external authorization system.
You know, in this case, a very defined environment, but at the end of the day. It's out there for five decades. So there's absolutely no excuse for not doing it now. So every good software should support externalization of authorizations. There must not be anything baked into the software, not today anymore. As I've said, no excuse for that because we know how to do it better for five decades now, at least. And that means basically over time, we need to shift to better approaches in the software and in the way we handle authorizations.
And so we have also better standards nowadays to handle that. We see quite some stuff happening, be it OSX and be it OPA, policy agent, other stuff, so we see some tendency towards that.
But yes, we also need to, I would say, become more mature in software development, but you know, honestly, as long as most new services in the net still come with username, password, as long as most software does not support modern authorization schemes, we probably still have some way to go. But clearly, yes, we need to overcome static entitlements because this is really the root cause of where things become problematic. And they are a risk because they are standing.
And yes, there's a logic in saying we move to zero standing privileges. We move to approaches where there are no permanent assignments because all of that is part of the attack surface. And if you're interested in learning more about these mechanisms that you, Martin, just described, so I'm talking to the audience, of course, just a few weeks ago, we had a conversation with Philip, our colleague, and David Brossard from the OfficeN working group. And they just finalized the interoperability standards around OfficeN and the implementations that allow the interoperability can be there.
The standards are available. So it's now really, really evangelizing and doing things differently to achieve all these principles that you've just mentioned.
Of course, also this modern authorization will be part of the topics to cover at EIC in Berlin in May. But this is something where you can educate yourselves immediately also with research from our side and talk to us as advisors.
So again, that was, I think, a really useful session because most of what we discussed can be done with what you have on board already. You can extend, you can get better when it comes to user behavior analytics and to drilling down the access rights assigned. And you can actually change the way you do authorization in general as the next big step. Any final words from your side before we close down or anything you're looking forward to at EIC when it comes to modern authorization? So I am really eager to discuss with the OfficeN people about where they are and where they are heading.
I think that is one of the things. Also to exchange maybe with vendors about how to bake some of these things into their solutions, because there's a lot which can be done. And just educating about this because at the end of the day, I think, as I've said at the beginning, if we have a challenge we are facing for years and we haven't solved it well, we are always coming up with sort of patches and small improvements and doing it as a bit better here and a bit better there. And we really should step back and think about how can we do it fundamentally different?
What is the sort of the root cause and how can we cure or address the cause instead of curing symptoms? Absolutely. Thank you very much, Martin, for your explanations. For the blog post, if you as the audience have not yet read it, please do. It's available on our website. Recertification from 100 to zero in a day. Bit over-exaggerated, but hey, but it's the right way to move forward. So thank you very much, Martin. See you at EIC and thank you for your time. You're welcome.
