So, welcome to the session. You are in the track Governance, Privacy and Compliance, finally part five, which is with the subtitle The End of Recertification, Automating Trusted Scale. We start with a 40-minute panel, and I think we will need the 40 minutes for this topic, and then we will continue with a presentation around the same topic, but I think this will still be needed. So we have an hour about killing this thing that we all really hate by heart. We're talking about recertification, about attestation, about implementing this privilege manually. This is what we're talking about.
I have the pleasure to have three distinguished guests, experienced guests from different backgrounds, and I really would like to welcome, and I would also like to briefly introduce yourself after that. I would like to welcome Laurie Robinson from SailPoint, VP Identity and Access Management.
We have, you have to help me with the surname, Henrique Teixeira, is that right? Yeah, that's good. Yeah. Okay. It's Henrique. Yeah. He's Senior Vice President for Strategy at Zavient, and of course, my colleague and founder and distinguished analyst with KuppingerCole, Martin Kuppinger. So please raise your hand for the three of them to start. And maybe we give, I gave a bit away already, but maybe Laurie, if you want to spend a few words on what you are, why you're here, and what you're doing. Sure. So let me just put my mic on. Okay. So I am a VP of Product at SailPoint.
I own ISC, so I get the security cloud, and some of the products we're going to talk about today in our preferred security management area. And before being at SailPoint, I was at Salesforce for about four years, ran their identity program. There we go. And can you stop the timer, please, just for me. And then did a stint at SailPoint, and before that, was at Gartner with Henrique for many, many years. So happy to be here.
Yeah, me too. It's a pleasure and honor to share the stage with Laurie, Martin. Yeah. My name is Henrique, Senior Vice President of Strategy at Zavient, where I'm in the product organization as well. So shaping the vision and strategy of our product lines. Very excited to talk about this interesting topic, or recertification. And Martin, I think you set up us here really good, eh? Because you choose Laurie from SailPoint, and you choose the worst-looking guy from Zavient to be here.
And no, but it's an honor. It's an honor. And I hope you guys enjoy.
Martin, briefly. Yeah. You have to. I'm Martin.
No, I think everyone knows me, probably here at the conference. So I'm in identity management for some 35-plus years, starting with early LAN manager, early network versions, back in the days, and in some way, I always ended up around identity security and stuff like that. And some more than 20 years ago, I was one of the founders of Pinnacle Analysts. And since then, I did even more on this topic. And I still was looking, or I was raised this question when I was in an audience, was there anyone in the room who would say, hey, my departmental managers really love to do recertification.
They're waiting for the next campaign. No one ever raised their hand on this question. Short before Christmas, of course.
Yes, short before Christmas, exactly. And if no one likes it and no one believes in it, then I think that we need to discuss it. Right. I realized that I didn't introduce myself.
Matthias, director of practice IAM, working with KupingerCore for 11 years in identity since 1993, which gives you a hint how old I am. Okay. Opening question. I was talking with the lady, with Lori. Recertification was designed to implement least privilege. That was the idea, as far as I understand it. In your experience, does it really do that or has it become just an exercise to demonstrate compliance rather than managing risk? Yeah. And so I believe that closer. It's working. Okay. I'm projecting. Okay. I definitely do not believe that we are getting risk reduction from certifications.
So I think I would answer it by saying really it's turned into what I refer to as compliance theater or compliance rituals where people are certifying and we have to, have to, I'm going to air quote that, for audit purposes. But really the purpose of audit is to recertify, to look for least privilege, make sure people have the right access, and that isn't happening, the control. So as a compensating control, it's ineffective. And I don't think we're getting least privilege out of it.
And along those same lines, as we look across our cloud at sell point and what customers are doing, vast majority of access in organizations is provisioned through request and approval flows, not through policy. So you get someone who's looking at access when somebody requests it and they have no context and don't know if the person should have access. So there's over a 90% approval rating, automatically provisioned, over provisioned, permissioned. And then those same people are the ones certifying and looking at it again with little to no context and certifying.
So essentially you have no control and that's a bad state to be in when our goal is least privilege. Right.
Martin, so we're talking about an exercise that really doesn't help and it's tedious and we hate it. Is this true? I think so.
You know, I think we all know it's rubber stamping. I think there were a couple of vendors trying to improve it in some way, but at the end of the day, it always was, at the end of the day, everything is about curing symptoms, not the cause. And I think this is the point. At the end, we all know the cause clearly is static entitlements or standing privilege, which are the root cause of all bad in identity management. And then we had the situation, I think, that there was something which needed to be done.
So we had the Sovereign Sox Act and we had least privilege principle and then the solutions came out. The auditor said, okay, you need to have something like that. And then everyone did it. But I think what I missed over the years is stepping back and saying, hey, okay, if it doesn't really deliver to what it promises, why don't we rethink the entire approach fundamentally? Right. Yeah. Okay. And if we think of, I don't know, 20 years back, we have 2026, if you go back 20 years, 2006, and I don't remember, I have not made my history lessons when was Sovereign Sox Year 2000. It was Enron, right?
So that those guys decide to commit fraud and say, well, we got to do something about it. The auditors came up with this. So to your question, the reason certification campaigns were invented was not because of least privilege, was because of compliance. They need some sort of evidence or generate the evidence that auditors could look at. That was the reason. Right. And there was a bunch of companies back then. There was the Rickify. There was a Vexa. I think SailPoint was back then. SailPoint was of the early ones. Yeah. Vayu.
Vayu, which later, yeah, our CEO is saying it now, Satchin. And that was a market, right? It was evidence collection for auditing. I don't think it did a good job in least privilege. But I... And I agree with you. Yeah. It was part of... I think least privilege was part of it. The principle to enforce it, which meant you have to have the proof, the audit proof.
And yeah, we failed. I would say that least privilege was the control that we were aiming for and the certification itself was the compliance. Yeah. Yeah. The evidence generating piece. And I think it became... What we always should be clear about is audit and compliance and security are three rather different things. So passing an audit is the one thing which means you convince the auditor, at least, which doesn't necessarily mean that you're really fully compliant in reality. And it not at all means that you're secure. Yeah. Compliance about avoiding violation of policies.
That being said, that audit and compliance is critical to our teams. So while I think we're all aligned, certifications, I'm on a mission to kill certifications, which is sort of weird to hear from a product person at sell point, but I am.
However, it has to be replaced with some type of audit adherence. So how we do that, I think, becomes part of this conversation. It should be. Yeah. Okay. Quick check so that you also... First of all, I need your questions later.
Second, I want your feedback just right now. A show of hands briefly, how many of your organizations could... Or of you representing your organization, can you honestly say that your access certifiers understand what they're approving? Who thinks their certifiers are in a situation that they understand descriptions, role names, et cetera, that they're approving, so that they really know what they're doing? Please raise your hands. Either they're asleep or nobody raises their hands. They don't care. Most of them don't care. Okay. So I repeat that for those who are listening outside. Yeah.
Vlad said they don't care. They don't care. If you need to do it because of the policy and nobody wants to go deep, spend time to understand why, unless something bad happens. Right. What does that tell us, Rory?
Well, everybody hates it. I think it's not a newsflash. Nobody likes doing certifications. Nobody cares. But I think to Lory's point, we're not bashing the importance of governance and audit. I think it's super important. I think we are in a better place now than we were before. I think running organizations without transparency, without that type of respect for policies and rules, I think is the wrong thing to do. So I think we got to establish that as well. We're not bashing. Right. It's absolutely true. And I think we all agree on that. We just need to do it better and smarter. Yeah.
So better results and less work. Yeah. I want to say something. Sorry. Two years ago, right here at this conference, I had a talk which I proposed something I call task-based compliance governance. Nobody is asking for any kind of entitlements just for fun. It's usually related to the tasks. You have two types of tasks. One of them is birthrights, which you have to do all the time. Another one is project-based. Somebody gave you the task. So in my humble opinion, the only way to get improved is at the creation of the task, someone has to do the work and figure it out.
What entitlement do you need to perform those tasks? And instead of requesting and approving, it has to be done on the creation of the task. That was my talk two years ago. Yeah.
Vlad, I think that's going to happen with Agentic because it's going to move to intent-based and we'll be certifying intent, which is much closer to certifying task, if you will, the purpose. We're seeing that already with intent-based access control emerging. I don't think we're going to certify line items like this user and this intent, but we'll certify policy, if you will. By the way, I don't like the term intent-based because intent for me is something which is not really explicit, but that would be a very different conversation. We may have another time.
I get the spirit of what I'm saying. I get the spirit of it. I still don't like this idea of calling it intent-based because I think it's the wrong terminology, but that's a different story. But I think what you're saying and I think we probably all agree. I'm not sure. We talked about it earlier today, so maybe Enrique disagrees. I didn't talk with him about that yet, but I think one of the things which is very important and also what you said is I always say you can easily, even today, you can easily assign 80%, probably more, of all the entitlements via policies.
I don't like the term birthright because it implies you do it once. Obviously, every mover process also will need to change that. It's more than just the birthright thing. It's the automated assignment. The good thing with that is, from my perspective, when you assign it via a policy, then you don't need a manual access review. If you achieve the 80% target, it means you're 80% down with your access review tasks. And that is doable. And I think that this is one of the things, I think, which goes exactly in the direction you were saying. And I think there are a couple of things.
I recently – you may mention it later – I recently wrote a blog post with a little bit of the provocative title of saying how to get from 100 to 0 in recertification in a day because we have – and I think that's the point – we have a lot of stuff available in today's technology where we can massively reduce access recertification workload. Okay. I have that blog post on my list for the next question after the next question. Okay. Let's do it here. When you say that is true, what needs to be in place? What do you need to create first that this holds true?
And what is the reality in many organizations that breaks that? Are they mature enough to write these policies for 80 to 90% of policy-based access assignment, maybe, Enrique? Yeah.
No, they're not. And I think a lot of times it's hard to even expect business leaders outside of IT to understand policy.
So, that's why I don't disagree. Intent is something that humans can understand.
So, what was the intent? Was it something destructive? Was something that – no, this is something productive. That is a clear intent in what you're trying to do. I think before we get to intent, there's a transition in maturity that we're going to get perhaps recommendations and other type of things, better descriptions for the approvers that can help them.
But also, if we look at certification campaigns on the exception versus the rule, I think could also reduce a lot of the manual labor for these approvers. So, for example, if you are approving and accepting 90% of the time the same things over and over, why are you even asking the business owner to approve that again? But if it's something that deviates from the norm, I want to certify that exception. I think this is perhaps a transitional way. Would that be the 80 to 20% ratio? Exactly.
Then, hopefully, we can reduce that to 20 to 10% of the volume we are asking leaders to approve today. Matias, can I comment on policy too in addition to what Enrique is saying? I actually think the world of policy management is changing, and I think it's changing with AI. One of the things we do wrong as identity professionals is when we define a role or we define a birthright policy, if you will, anything, any type of policy, we think, okay, I have to get this right. It has to be right-sized, perfect, least privileged.
And because of that accountability or responsibility hanging over us, we don't do policy at all. We flip too far the other way. We say we don't know. I think what's going my recommendation if I was starting Greenfield inside of an organization would be to define very coarse-grained policy, at least when you have guardrails, and put learning models on top of it. And that's a reality of where we're headed is start to learn what users are doing, and then you can self-adjust.
It's part of an autonomous story, but you have to have at least the baseline for your policy there, and then over time, you can figure out how to adjust those policies. I think that we have a bit of a tendency sometimes to go for or shoot for perfection on the wrong end. So if you have too many roles, then probably because you try to be too perfect, and sometimes it helps to be a little bit more pragmatic and start with the coarser grain because the nitty-gritty details don't really help you. And at the end, they don't really add more security. But back to your question, basically.
Your question was about why does it fail. So how many of you, if you're responsible for that, have a really well-defined, nice process charts, etc., a comprehensive process model for your identity management? How many had this before they started with their IGA project, for instance? So really doing all the processes you need on paper. At least one or two. I can answer that one.
Okay, not that many, obviously. You're asking the wrong questions. Nobody moves.
Yeah, exactly. No, I think they probably are tired after these days. They would all raise their hand because they have it, but they're just too tired to raise their hand.
No, I think it's one of the points. We need to define the processes. That helps a lot. If you define your process actually more or less on paper in quotas, then you end up with asking all these questions about how do we really set up this, or whatever, join a process to use this term.
And okay, then there's first the automated assignment. Where does the policy come from? And then we say, okay, and then there's some manual request left later on.
It helps, by the way, also saving a lot of money in implementation because there's much more guidance for the system integrator when you have a well-defined process model. That's one thing. And by the way, Matthias loves doing this process modeling stuff. At least he did it. I think he doesn't love it really, but he can do it. But it's a different theme. The other thing is it relies on data. So you need the data for the policy, and that also means you need to speak with people outside of the identity management world because the data comes from different places.
And you need to come to a point where everyone knows. The problem is I've talked to a lot of organizations where the people said, yeah, but HR, they don't give us the right data. And then you ask them, did you ever really go into a conversation with HR and also explain the rationale behind and which data you need, why? Mostly the response is not really. They don't talk with us. It doesn't help. Interestingly, if you go into that conversation, my learning is most of these conversations led to, okay, right now I understand why you are asking for that, and let's define who is responsible.
Then you can define where does the data come from. And maybe HR is not the right part or someone else is not, but start talking with the other departments in your organization to explain why you need which data and to figure out who is responsible for delivering the data at which time in the process. And that is the foundation for doing the next step. I agree.
Sorry, Laurie. Sorry.
No, I agree, Martin. I think understanding the process is important, but I don't think it's the most important thing. I think at all leaders, I think they will be more successful if they're more pragmatic and thinking about the outcome. What is the outcome? We start with the first question. The outcome was we want to reach least privilege. So when I hear things like what is the outcome of this certification campaign is to reduce unnecessary entitlements, unnecessary privileges that are running this organization.
So if we have that as the outcome, I wouldn't recommend anybody to obsess about the process if the outcome is not clear. I heard Satyen say this one day. He was on stage. He said if you're doing certification campaigns today and you're removing 5% of your entitlements, you're doing compliance.
Now, if you're doing certification campaigns today, you're removing 60%, 70% of the entitlements, you're doing security. And I think having that outcome in your mind and the goals of what you want to achieve with the certification campaign, I think it's a better starting point than just obsessing about the process. I'm a German, so I love overengineering. I start with the process.
No, I think the process is important. It's helpful. And interestingly, it's not that much work. But I also agree with you. We need to think what is what we want to achieve. And at the end of the day, I think this may be an important point. We should start thinking our goal with that is not primarily – one goal, the first thing is, yes, we need to pass the audit. But our real goal should be something different. And this is increasing security. And then we have a very different perspective on the entire thing. Because then we don't do it because we have the audit pressure.
We do it because we want to increase security. Yes, and right now to Laurie.
Oh, you're good. I love that. Moving from compliance rituals to risk reduction is sort of the theme, right? But I do want to say something about being policy-driven real quickly. We're talking about, oh, how can we start doing that? And it's hard. We have to do it, guys. Like the time is now because in an agentic world, think about this like paying with a credit card. What if every time you went to pay with a credit card, you had to call the bank to get approval? If I was just me going up and nobody else was behind me, that might work. But that doesn't scale in the real world.
That's what's going to happen in agentic. So people are talking about agentic, human-in-the-middle requests. It won't scale. Not at all. Not at all. Such a bad idea. Such a bad idea, and we have to. We have to be policy-driven. So while we're all lamenting about how hard policy is, we have to get to a place we have policy. We just do, and that's here now.
Policy, by the way, isn't hard. I think policy is so logical.
Child, don't touch the hot oven. It's a policy. It's the same structure like a firewall policy. It's the same structure like a policy in IGA. Policies are something we do every day. The structure is always the same.
Subject, action, object, or however you'd like to name it. It's always the same structure, so it's easy. We know how to do policy. But let me jump in here because I think we're talking about two different types of policies. One is the assignment policy during workflows that says, okay, Matthias has the job description, I don't know, DB admin, and that's the reason why he should have access rights ABC, and that is a birthright that changes over time, so it's not really birth, but anyway.
I think that is one part of policy, but it's a placement policy or an assignment policy, not really what we think about when we talk about feedback. That's true, but in the world of just in time, some of that formation is being formed just in time. That's true. It's real time. So that's one of the key differences is this admin time policy where we've had that previously and provisioned kind of goes away in some of these scenarios of just in time access. That was my setup, actually, for that. But you actually concluded my thought, which is at least it was not that weird. It was not weird.
It was great. The question is because last year when we did EIC, there was, I think, something that Martin did or I did, which said, okay, the root of all evil is standing privileges, and standing privileges is something that we approve with recertification campaigns. That is what we did. That is the case. So the question is, it's just in time. It's policy-based access, reducing standing privileges, not also a means to reduce the work for recertification campaigns? It's where we should go for. I always say, especially this year, it fits very well.
So we are in 2026, and you know which software has been released in 1976? IBM RACF. So since five decades, we know how to do it. Since five decades, we know basically how to do dynamic authorization. Clearly not at the level of perfection, et cetera, but it's not that this is a new concept at all. So having applications asking for authorization at runtime is not entirely new. It's not. You said something, Matthias, that long-standing privileges is bad. I think I always question when somebody says some universal truth like that.
I say, no. When you join an organization, you have an email address. You have Internet access. You keep those for the entire duration of your employment. So you're going to have those long-standing entitlements, which are amazing to be assessed through birthright access. And those don't change very much. But now if you're in a project, you are deploying this digital transformation initiative, and yes, everything new should be in that principle that just in time you get, once you're done, you lose it. I think there's a combination of both.
So that's why I really don't like when people say RBAC is horrible, this is toxic, or be back is the future. No, man, it's a mix of everything. Agree? I would say I actually feel a utopian state would be zero-standing privilege. I think it's just, in other words, yes, you as an employee or a worker, you have access to email indefinitely. But it doesn't mean it has to be provisioned indefinitely. I think you can make that decision when you go to log in. That would be an ideal state because then you don't have entitlements of any kind sitting out to be exploited.
That being said, I agree with what you're saying because we have to start somewhere. So I think one of the call to actions that I would have for you all is whether it's policy or it's just in time, all of it starts at the entitlement level. And so really understanding where you have privileged entitlements and classifying those, honing in on your highest risk entitlements and putting your strictest controls around that should be the priority.
Oh, yeah. You're right.
Like, hey, this sounds nice to be in this utopian state of zero-standing. Yeah. But the reality is we're going to be in less standing for a very, very long time until applications change. So how do we hone in on what really matters?
Yeah, so the email example, right, Lori? We could say, well, you have your email account forever, but the distribution lists, they are just in time, depending on the department you are. So I think it's a great example of what you're saying here. But I think what is also important from the discussion is there are a lot of places where we can start reducing the workload for recertification, which was our starting point. There are a lot of things we can do now without waiting for the utopian state, but just saying these are things where we can start.
These are things where we can really simplify a lot. And I think there are other things like we touched on this morning, time-based entitlements, obviously something which is relatively easy to do. And if your recertification interval is six months and you have a maximum assignment of six months of an entitlement, then you don't have recertification, which doesn't work that easy because there are a lot of other things that come in. So you need to reassign, et cetera. So be careful around that. But obviously it is if something is not needed forever, then think about not assigning it forever.
The assignment, right? So if something is requested, so there's the birthright assignment of entitlements. But if you requested an entitlement after you are in the job for six months, I think that's a great candidate to be recertified later. If it's not just in time removed, maybe that's a good candidate to add.
Hey, you requested this. Do you still need that? And the birthright is really not a good term because a lot of this comes when someone brought up the project thing.
Yes, you're assigned to a project and then you get something automatically because you're on that project. As a birthright, it's at the birth of the project in a sense. Let's call it that. Exactly. I think we should get rid of the birthright because it's not a perfect term. But at the end, it means – and then you have a project. You said this project runs three months, so assign it for three months. And if the project is extended because you missed the deadline, then you extend it for another four weeks or so.
And then you probably will be below the recertification interval or you have, with the extension, sort of automatically the review, the reapproval, and then you're done. I want to attest to the legitimacy of what you're saying but maybe not put on my sell point hat but put on my Salesforce hat. When I was at Salesforce running their identity program, we tested this with our auditors. And our auditors approved us. Anything that was provisioned with an end date of less than 90 days did not have to be certified. So auditors are willing to do exactly what you're saying.
I just want to attest to that. I witnessed it in the wild, as they say. And experience says, yes, you can talk with auditors and discuss with them. It works. They're people too, right? Yes. Then let me follow up on that. As you said, regulators and auditors are comfortable with the traditional recertification scheme because they know it for tens of years and they know what to check and how it looks like and what they need to tick off.
When we go towards this more dynamic policy-based, PBAC policy-based access management that is done at runtime, what are the discussions that you as vendors, as project leads, as responsible persons in organizations lead with the auditors when you say, yeah, this happens at runtime when we look at the following attributes and we have this policy? Are they comfortable with that? Or would it be nicer to just stay with the recertification because it's easier for them? I'll jump in. I have really strong opinions about this. So do I. Part of this is about money, let's all be honest.
It's self-serving to a certain extent, so you have to keep that in mind as a practitioner. There's a time to push back and say, okay, I own defining the controls. You own that. Your company owns defining the controls, and the auditors help you influence those, and then they come in and check the efficacy of them. So remember, you still own it, and so take that control. But I will say, excitingly, we've been evangelizing this with our partners.
I won't name names because it's theirs to advertise, but one of the audit firms has an initiative called CertList, a play on shirtless, but they are promoting this idea of reducing certification. So it's not just vendors. It's not just customers. The SI and audit sister companies are moving in this direction too. So we were super thrilled to hear that. I wish we would have thought of it first, the CertList, but I think their support, it's going to take education. And I think, yes, I agree 100%, Laurie, that it is a money's game. So certifications are expensive. Auditing in general is expensive.
And to your question, I don't think auditors care that much if it's JITA, just-in-time or not. I think the way just-in-time helps is by reducing the number of entitlements that need to be recertified to begin with. So by implementing just-in-time, you have fewer things to review. Those audits become quicker. They become more efficient as well. So I think it's a benefit. And the auditors are very open to discuss this.
Even AI, for example, if AI is recommending something, but are you afraid of AI? In that sense, AI would be better in a way of providing the evidence or what was the reasoning for approving or rejecting something way more tangible than perhaps the human mind. I was in a bad mood and I revoked everything. I actually implemented this within my team, my employees that work for me.
I said, you know what? I'm going to go and accept everything that AI recommends without looking. I didn't look. I didn't look at descriptions. I didn't look at anything.
AI said, safe to remove. I removed everything.
Of course, I had a meeting with them. I said, if you guys detect anything, call me. It's been a year. Nobody called me. Okay. Let's stop here. We have three minutes left. It's Friday morning after a long EIC. We have a room full of 50 plus people who listened to a topic like recertification. So there must be a reason for that. So the question to the three of you is really the final takeaway.
Of course, this moderator question that comes at the end of many of these panels. If someone in this room goes back to their organization on Monday and wants to start moving away from this tedious type of recertification, get better, and you have 30 seconds to answer what should they start with, what would that be?
Starting, Laurie? Sure. We've given advice, but I'm going to give a piece of advice that's different than what we've already said. And that is, as you're staging your campaign, look for opportunities to run a policy check on top of that. I don't mean access control policy. I mean filter your campaign. So filter out inactive accounts. Filter out access that was assigned by birthright. Filter out people who haven't used it for whatever your threshold is. Six months. Some of them you'll automatically revoke, and some of them you will automatically approve.
But what should go to your audience should be the things that actually matter and actually need review. So apply a filter during your staging. That would be a simple win. Martin? I think the thing where you can really do a lot of stuff very quickly is policies take a little longer. I would say that the starting point is clearly time-based, so assign it only when it's for the time needed. That helps to start very quickly. And so I propose in this blog post that we've mentioned quite a number, which is on our website, quite a number of things we can do.
Keep in mind it's about security, and keep in mind that I think a rule of thumb is that whatever some 40% to 50% of the entitlements assigned are never needed. So this is going to what Rory said. There's a huge potential in just reducing the recertification workload by removing entitlements no one needs. Right. Final answer. Have they taken away too much from you, or do you have five more to serve? You have 30 seconds.
No, I'm going to be quicker than that, and I'm going to repeat myself. It's very hard to remember everything we said here, but if there's one thing, one thing you remember, be outcome-driven. And the outcome must be let's revoke, revoke, revoke, revoke, revoke as much as we can. Every year we're going to revoke more entitlements. So be outcome-driven, revocation. That's the KPI we've got to chase. Remember that. Thank you. Thank you very much, Enrique. Thank you very much, Rory. Stay seated.
Thank you, Martin.
