Recertification from 100 to 0: Eliminating Access Review Fatigue with Smarter Governance

Welcome everyone to our KuppingerCole Analysts webinar, Recertification from 100 to 0 in a day, which is a bit of a provocative title as I am aware of, but I think it gives you a sense of what we want to talk about. How can we simplify recertification? How can we reduce the workload, the burden from recertification? So the subtitle, Eliminating Access Review Fatigue with Smarter Governance, hints on how we really can become smarter in governance. This webinar is supported by Pathlock and the speakers today are Damon Tompkins.

Welcome, Damon. He's CEO of Pathlock. Thanks for having me, Martin. Always good to see you. And the other one, that's me, Martin Kuppinger. I'm a distinguished analyst and co-founder of KuppingerCole Analysts. Before we dive into the subject, which will be a quick, very quick intro, hinting back on a blog post I've published a couple of weeks ago, basically with the same title. So you will find it on our website, amongst the blog posts, this recertification from 100 to 0 in a day. So I will quickly summarize as an entry.

And after that, we will then have a fireside chat where we discuss our perspectives, which I think is particularly interesting because Damon comes from Pathlock, so from a line of business, SAP, et cetera, perspective. I come probably more from the identity perspective side of things. So even while Pathlock also covers quite a number of applications, but I think we have both our perspectives on this. But before we do this, a little bit of housekeeping. So audio control, nothing to do from your end. You're centrally the control and care for that.

We will run two polls during the webinar, two quick ones. We will have a Q&A session, and you can enter your questions at any time. If you look at the lower right edge of your screen, then there's a questions area where you can enter your questions for the Q&A session. Given that we do a fireside chat today, we also will be open and able to pick up some of the questions during the flow of the chat, if this fits into the conversation we have. And we are recording the webinar, and we'll provide the recording and the slide deck soon after the webinar for your download.

So having said this, quick look at the agenda. So as I've said, there's me, Martin, and there's Damon.

Maybe, Damon, you want to say some words about you and PathLock first before we then go through the rest of the agenda and dive into our subject? Sure. Thank you.

Hi, everyone. I'm Damon Tompkins, CEO of PathLock. I've been involved in ERP and identity security my entire career, which is about 30 years, so I'm going to date myself a bit here, and recently have taken responsibility to lead PathLock into the future. I think the subject matter that we're going to cover here today is extremely interesting.

I think the world of ERP security and critical app security combined with identity security is converging in ways that we've ever seen in the past, and I think with the advent of digital workers, you're going to see an explosion of needs and opportunity for innovation. I'm looking forward to discussing it with you here today. Yeah. And maybe we'll find the time during our fireside chat later on to also have a little bit of a look at what recertification means for digital workers. Nothing we have planned for, but truly a topic that is of huge interest these days. So I'm Martin Kubinger.

I'm also more than 30 years in that business, so you have more than six decades of experience here in the fireside chats, so to speak. And as an analyst, I look at a lot of things I observe to market, and basically one of the things that triggered the blog post and then this webinar was that my impression is there's no company out there where any departmental manager would say, hey, I'm so glad next week, the next recertification campaign starts, and this is really the highlight of my business year. It just does not happen.

So if everyone feels this is really just a daunting task and there's a lot of rubber stamping, et cetera, then I think it's time that we start rethinking recertification to the better. Before we dive into that, I want to bring up the first poll, and this is more about the intervals you're primarily running your recertification campaign on. So primarily because the standard might be an interval-based one, but you do some things more events-based or so, or it might be primarily events-based. So from that, focus on what is your primary approach. Is it interval-based? Is it risk-based?

Right, varying intervals. Is it an events-based one where you'll say, okay, certain events trigger a recertification? This is our standard approach, and the others are just to cover the gaps. Why don't you have recertification in place? So the poll will remain open for a couple of minutes, so you have time, and you'll find the polls also at the screen in the lower right edge. There's the section of polls.

With that, we already come to this section around initial thoughts and rethinking recertification, and a few of the thesis we want to touch in this fireside chat, and some of them are more sort of you can do it now with what you have, and some of them are probably a bit more strategic, may require a bit of changes in technology and approaches. So this is something I'd like to look at really, really very, very quickly. As I've said, there's a blog post at our OpenCore website you should have a look at which goes deeper into details. There's more research.

There will be a lot of discussion, but I think one of the things we always should look at is how can we simplify the role models and entitlement structures, reduce the complexity. So do we really need the perfectionism of saying, okay, we have, if a few people have slightly different entitlements within a role, do we need to split the roles into multiple roles or not? I believe that's very much clearly risk-based. If it fundamentally changes the risk and is really impactful, yes.

Otherwise, no. I personally believe we can do a lot with automatic assignment of entitlements. So my tough bar I raise is 80 to 90 percent of entitlements can assign based on attributes such as the location, the job title, the job function, and all these other things. And if we know what has been assigned automatically, we don't need a manual recertification. And that can massively reduce the workload. We clearly need a proper process for handling the policies, but we can do that. So we then would focus more on the manual access non-exceptions than on everything.

Time-limited access can be extremely helpful. So if your recertification interval is six months and you assign entitlements usually only for up to six months, you don't need to recertify.

Yes, you need to ensure that if someone needs them longer, that you have sort of an extension approval that you deal with these things, but there are some smart ways to handle that. Look at usage analogies. What is used? Very important. You have technology in most tools right now to help you understand. Is something used at all? Work with priority, focus on high-risk access. What is the most critical one? Also helps you to reduce the sort of the noise and recertification. And then work with smaller campaigns, lesser fatigue here.

So some of the thoughts we'll pick up just to give you a quick idea of some of the things, at least I believe, hopefully Damon as well, otherwise we will have a very controversial conversation, which also can be interesting, can help in simplifying the entire thing. More strategically, I think it's looking at how can we improve clearly the data quality for automation, police enforcement, and especially how can we shift to policy-based access control, to zero spending privileges, to making authorizations just when the access is required.

So not assigning entitlements, but saying, okay, Martin wants to access this authorized, yes, no. And this is, by the way, not entirely new. Back in 1976, IBM released RACF, which did this on the mainframe, basically. So it's not a new idea and it's just something we need to make work on a broader scale out there to say, and there's technology out there. Event-driven real-time instead of scheduled big campaigns can be helpful. Something we also made to partially do today. So there's clearly a blurring line between what are tactical and strategic measures.

And I think also this usage-aware aspect can be something we can improve. And the more we have behavioral analytics, the deeper we can go in saying, okay, what can we reduce as entitlements? And as I said, at the end of the day, it's going away from standing access. Because if you don't have standing entitlements, static entitlements, whatever you'd like to name it, we don't need to recertify this. We clearly need other governance approaches, no doubt about it, but that's something we can discuss. And with that, we would directly jump into the fireside chat.

So Damon, I brought up some thoughts, so maybe I start also for the fireside chat. What is your perception about the real-world acceptance and perspective on recertification? So I phrased it quite negatively, but how do you see it from your experience in the field?

Well, I think it won't be as controversial. I think it's rather shared. What we see frequently is that recertification, and the term rubber stamp gets used a lot, is there are a lot of dare I say something provocative, almost performative art at some level, where organizations go through a series of activities, but it's really more to check a box than it is to authentically mitigate risk. And we see this over and over again. We think we have a very different perspective about how to address that.

I think as you move forward into more automated workloads, when you think about future state of digital worker and autonomous AI, it takes on a whole different viewpoint. And so you're starting to see a convergence of ideas, time bound access, and trying to understand what's taking place rather than what could take place becomes increasingly more important. And so I think that there's a huge opportunity for innovation around making recertifications more authentic in the act of mitigating risk.

And a byproduct of that then is to become in compliance or conforming with a particular regulatory framework, which is oftentimes the motivation when you said the various catalysts for why people do this. If you think about sort of the history of particularly Sarbanes-Oxley coming out of the Enron era, where organizations were sort of mandated to do this under regulatory frameworks, I think that's when the discipline became more pronounced and more ubiquitous amongst customers.

But when they go through these processes, you can tell they're doing it just out of an act to check the box of compliance and not necessarily to authentically mitigate risk. Yeah. And I think that is an interesting point. There are a lot of interesting things in what you said. And the one I'd like to pick up first is, yes, Sarbanes-Oxley Act was basically the starting point when access governance then emerged. So that's where everything came from. Behind that is the least privileged principle.

And if you read the regulations, the regulations commonly don't say, hey, you must implement a huge matrix of a lot of users and a lot of entitlements. No one understands what these entitlements are about and then have people making checks. This is not what the regulation says. The regulation says enforce the least privileged principles. We have some things around the regulations in certain fields, in certain areas, which sort of recommends, for instance, then taking a role-based approach to handle that, which is usually, at least to what I have on my radar, nothing.

If it's in there at all, which they say, you must use roles, but this is the recommended way, which means if you do it differently, you need to probably explain it better to your auditors and convince them that you took at least equal approach, maybe a better approach. But what is very clear is that recertification was the idea that then was created back in the days, so 2008 and the next two, three, four years, when all these solutions emerged and auditors felt comfortable with this, so companies felt comfortable with this, and then no one really challenged it again.

I think this is a bit the history because, as I've said, the regulation itself doesn't say this is the way, and I think you pointed out the other important thing. What should we look at? What we should look at, from my perspective, very clearly is effective risk mitigation.

This is, I think, at the center of everything we do, and that would be also my big criticism towards the regulators and the auditors, that regulators and auditors must now, today, that the approach they are looking at and they are basically accepting, but they must be aware of that this is not really delivering to the target. Sure.

Well, and as the technology itself has evolved, the complexity and the variety of applications inside of any organization's estate has grown, the sort of spirit of what was said probably remains true, but the functional discipline about how to achieve these things is shifting radically. Another, I think, important key idea is who should actually have the authority to make the determinations when risk is determined, even at a role level?

So, if you think about RBAC and having strong roles, not everything is always binary, so sometimes you might have to have both sides of a risk, circumstantially, and you have to address that, so whether that's through time-bound access or through other means, and then someone has to determine whether or not that risk level is acceptable to the business.

And a lot of the products that were built around these concepts were sort of oriented around an IT professional making that decision as opposed to the authentic risk owner, and that adds to sort of the performative nature of it, which is that if someone has to make a decision as to whether or not any individual owns both sides of a risk, who should make that decision? And if it's an IT professional who doesn't either own the risk or even understand it, for that matter, whether they affirm or negate it is, in and of itself, sort of an incorrect way to think about it.

And so, I think RBAC, ABAC, these types of technologies, they still remain relevant. It's not as though you're just going to eliminate roles or, you know, controlling people's entitlements, but you have to look further down the taxonomy into the actual actions or behaviors and look at it at a transactional level as opposed to just at a user level.

Yeah, I think true, but they actually say it's not necessarily the shortcoming of the tools. So, a lot of tools will allow you to define proper ownerships and understanding everything.

So, for different types of roles, different levels of roles, different ownerships, also making this distinction between who takes the risk, etc. You can at least build it in many of these tools. I think the problem starts, in many cases, with the fact that from the very beginning of this project, there is a lack of IT and business alignment.

So, I know a lot of IT departments really complaining about the fact that they don't get the information from the business. I know a lot of business departments complaining that the IT doesn't really talk to them.

So, I think a lot of this is a communication problem. I've seen projects which work with the communication experts. I've seen projects where there was a very thoughtful ownership concept across whatever who's the system owner, what does the system owner do in this project, what is the business owner, who does what, who has which ownership, who has to do what. This requires, I think, a more proper work, not just understanding, okay, I have a technology and I put this technology in place, but I need to define my policies, my ownerships, my processes, all that stuff very thoroughly.

If I do that, then I will be much better. By the way, the interesting side effect of this is if you do that, you usually end up with an approach where the burden of recertification is spread across way more shoulders because people do what they can. A business or a departmental manager knows quite well what the jobs of the people in his team are.

Someone at the next level should be able to map this and understand this job maps to this business role and someone at a technical level might be able to understand which business role or functional role in between maps to which system level roles and then below the system level roles, if you go to SAP, to association objects, to transactions, etc. This must be done properly across multiple levels.

Yeah, it's a great point. We see this sort of in a lot of our commercial engagements where we often laugh about it a bit because if you think about how these systems came into being and the roles and responsibilities around ownership of those systems, they've almost grown up in silos at some level. A lot of times when you think about workloads that are associated with identity security, you're thinking OCIO, CISO, and they have certain responsibilities and goals that they're trying to achieve.

Then when you look at the primary ERP estate owners, they tend to be completely siloed from that group of people. Oftentimes, they'll take on processes and respective tooling independent that runs almost in concert or duplicative to what some identity security professionals will have in their estates. Then you have sort of the business owners themselves, the OCFO audience, and depending upon any given organization, the roles and responsibilities and the departmental breakdowns around these workloads is pretty fragmented.

There's an interesting persona and group of folks that we work with oftentimes called internal controls. I'm sure you're all familiar with this. They try to run zone across these things, try to bring together the different elements to bring about the outcome. It is definitely a space where not even at an individual level, but when you think about it at a departmental level, there's a lot of opportunity for better collaboration, better cohesion. To your point about the business owners being critical of the information they get from IT and vice versa, we hear that every day. Yeah.

Just as a side note, already a couple of years ago, in one of my slide decks, I have this, that if you still have it for an SAP department, then the CIO definitely did something wrong. I think this is absolutely true when you look at the reality of today's also line of business application world. It's not a single application anymore. It's usually something where you have different types of cloud applications, various processes, spanning multiple applications, et cetera. It doesn't make sense to structure something along a technology.

It makes sense to structure it along the lines of business, the processes. You should think about, okay, what are the systems that are relevant, for instance, for procurement or finance or other things? How do they come together? There must not be SAP or whatever department, most commonly it's the SAP department, because that leads to the silos and that increases the complexity. That must be more integrated. I think this is also a CIO job.

But aside of this more fundamental thing, and I can easily say that as an analyst, tapping on other people's feet maybe, going maybe a little bit back to the way we can improve access recertification. We talked about time-based access. So what is the approach you are taking to manage time-based access? I think the biggest challenge clearly is how do you handle the extension? So if you give me access for six months and I need it more than six months, how do you avoid that there's an interruption? Sure. I think that we tend to think of it as a continuous process.

And we think that ultimately these issues are data problems. They're a result of data that's amassing through transactional activities that are occurring in any critical system, whether it's your ERP or the supporting SaaS applications that may be integrated. So your point about procure to pay or acquire to retire these processes, if you think about what's happening digitally to facilitate an end-to-end process, cutting a purchase order, taking materials received, paying the invoice, accounting for all these things, that's creating data sets.

And if you had access to those data sets in a persistent fashion, then time-based approaches to this may still have some relevance for certain circumstances. But instead of it being interval-driven, it's continuous. And so you're looking at things as they happen and determining the risk factor associated with that particular behavior or transaction. And then you're making a judgment call in that moment to take corrective action if it's deemed necessary. Which goes, in fact, beyond a time-based access. So the time-based would say, okay, for the next six months I handle this.

And what you're saying is basically already the next step, something you look at to do in Pathlog saying, okay, I give really a trust in time access that is based on various signals I can gather from a variety of sources. And depending on the risk score at that particular moment, I load it. And also I think that the huge advantage is you also can take the risk of the transaction itself into account. So the risk score you look at may vary depending on, for instance, the amount of a financial transaction, which is clearly the smartest way.

I think the time-based thing, that was something I started discussing and I see also implemented in various areas a little bit before because my analogy always is when you look at recertification and my analogies I use is your inbox. In the inbox, there are some things which are handled automatically you don't care about. You have rules and whatever, trunk mail or other rules come in like trunk mail, which process some of the stuff. And then there are a couple of remaining things. And some of them are easy to handle. It's more a yes, no, very short answer.

And then there are the things you look at and say, okay, well, this is the long mail. I need to put this a little bit away. And then when I ever find time, I start working with this. And recertification is a bit the long mail. While a single approval, this statement allowed to do that yes, no, is more than short mail, as well as an extension is this statement still in this project is the short thing. I think the art is to avoid that there's too many of these yes, no decisions at a single point in time, because then again, it gets complex.

But for instance, I'm saying, this process is still running is still correct, you can simplify it and you can find something in between and say, okay, I checked this sufficiently ahead, I inform people. And then from that I can can basically reduce the workload. I thought it was a by the way, in another scenario, which wasn't a Dora's or digital operations, resilience act in Europe, for financial services related to there's the aspect that you also need to implement the governance and physical access.

And the technical integration to the physical access systems is a bit tricky, not because of the identity security world, but because of the physical access systems, which sometimes like good API's, etc. And basically, they decide, okay, that'll be grant access only for maximum six months. And we are on the safe side. By the way, there are quite a number of questions coming in. And we will cover them. We also will go deeper into detail, we will have a period where we then enable also Damon to look a bit to talk a bit more about three very specific pathlog capabilities.

And you also can upvote questions. So that we can look at that we can ensure that we have the most relevant questions for you definitely covered. I still want to quickly, or spend a little bit more time on some of the aspects. And one of these already relates to a question, because this was also one of the sorts I brought up. And I said, we can probably do a lot with a lot of people call it birthright provisioning. I'm not a big believer in this birthright term, because that happens only at when we assign the first time entitlements.

It also happens when we have a mover process, and stuff like that. But one of the questions we received here is, if you had to eliminate 80% of access certifications today, what signals or controls would you rely on to still stay compliant? Maybe let me quickly elaborate first, what is behind that. So this 80%, what I say is, if you look at what can we do policy based, so we know that Damon is the CEO of Pathlog. So he has a certain role, he's at a certain location, he's in certain projects, etc. Then a lot of the entitlements, even we assign statically, can be assigned based on our policy.

And the point is, if we know this is something we assign on a policy, not on Damon or someone for Damon, manually requesting a certain access, a certain role or whatever, then we know for these 80%, let's say it's our 80%, which is ambitious, no doubt, we know that they have been assigned by policy. And if we know that, we can say, as long as the policy is correct, and if we know the attributes are correct, there's no need for a manual review of all the results.

So the 80% sort of resulting entitlements, we don't need to look at each of them individually, in contrast to what has been manually requested and approved. And that is a means where we can reduce it. So we still, I clearly would recommend and probably every auditor will recommend to do at least probes for that, or looking at some of the high-risk things, the high-risk items. So if we have a risk assigned to entitlements, we can use that.

But this is a way where we can reduce quite a lot of the burden by saying, okay, this is automated, and we ensure that the input and the policy are correct, and we do some probes. And then we have reduced a lot of the manual recertification burden. We concentrate on the stuff, on the extra, so to speak, the things which are out of bands. In that sense, a manual request approval would be the out-of-band access, where we, also from that logic, would put some specific emphasis on.

So that would, on this question, which already came in, which fits well to some of the things I brought up in this case, hopefully explain a little bit. Maybe, Damon, you would like to add a bit from your experience on that. Sure.

You know, there's an interesting company in your hometown there, Martin, that I was out and visited with, and they told me that they had 2.2 million unique roles on their ERP system. And at that point, when you think about recertification, or even controlling things through roles, it just becomes completely untenable.

And so I think, you know, applying it more towards the process, or the control around the process, to see if a process was violated, and then back into who did it, what's the context in which it was done, and should they have been allowed to do it, is kind of the future state, where recertifications become, you know, not completely null and void, but they're more for exceptional behaviors or exceptional authorities at a given point in time.

Whereas, you know, the vast majority of things that you're recertifying on, you're looking more at it from a behavior perspective than you are from a user perspective, and then backing into it from the viewpoint that says, this event just occurred, it seems anomalous, or out of conformity for the following reasons, should we investigate that particular event, who did it, should they have been able to do it, and what's the context in which they were able to do it, sort of flips the script on the whole kind of idea.

And I think, as we sort of look forward into the coming agentic age, the year of agentic age, I guess you could say, this is going to become increasingly more important, because you're going to have digital workers acting autonomously, and you're going to have to understand the behavior as they're doing it, not as they have done it, or could do, and take corrective action, or have line of sight into those actions in real time. And I think that is also something we need to be aware of, a lot of what happens in the agentic age now, that's happening autonomously, and it's happening automatically.

So there might be things that happen where the usual ideas of, okay, we onboard a new employee, and then we assign entitlements, and then we do some additional manual access requests, et cetera, over a couple of hours, or days, or longer, don't apply, or don't work anymore in the same manner. And that means, also, we need to think about, how can we do it more dynamically? And I think we must be, in that entire field, be very cautious and conscious about, where can we bring up this human-to-loop element?

Because the problem is, compared to computers, that's what AI runs on, humans are super slow, and they are not very scalable in doing things. And so, we must rethink the ways we do, and I think this brings us automatically to this behavioral perspective that we need to rethink, that we, as we can't do, I think we need to think about, where do we need to recertification? Where do we need to have a human look at anomalies and outliers in the behavior of these sort of digital workers? But clearly, it is different, very different than what we know today.

So, the good thing, I think, from your responses is, what you're saying is, basically, a lot of the responses, or the changes and the improvements we can make to the way we handle access risk, beyond traditional recertification approaches, a lot of that also fits to the emerging world of digital workers. That's right. Because digital workers, the attribute of time is changed immensely.

So, when you think about intervals, there is no interval, it's continuous, it's 24-7 running around the clock. And so, stopping at any given point in time to check the entitlements or the can-do aspect of a digital worker is a bit of a fool's errand, because it changes second by second. And having line of sight to that is ultimately what we believe is a data problem. Because if you think about any given application as performing business tasks, as it's doing that, it's creating enormous amounts of log data. And we can even see that in time-bound sessions.

So, when you think about time-bound sessions, understanding whether or not somebody had a certain authority at a point in time from fence post to fence post is important, but it's not enough. And so, you have to know not only did they have that authority between certain parameters, but then what took place during that period of time. And that is a data issue. It's a data in what they did, and what they did can manifest in many different records, manifest in activity logs and the behaviors. It also manifests in the actual changes that they made.

So, imagine you have a situation where somebody goes into an ERP or a procurement system, and they have strong authority for a point in time, and they change vendor credit, and they change vendor credit from $1 million to $10 million. Having immutable information about that event manifests in multiple different systems of record, including the before and after values associated with the changes that they performed.

And if you think about that at a digital speed that's going on around the clock, these types of different behaviors, that creates a tremendous amount of data that is generated from that. And then being able to sift through that data, collect the appropriate cuts of data that keep you in conformity for assurance for audit purposes, but moreover, just understand the behavior itself so that if something anomalous happens, that the human in the loop is alerted to that and can take action to determine the legitimacy of any given activity at any given time.

So, to summarize a bit, basically, we have quite a number of capabilities and all tools that will be touched in a minute in the Q&A part for Passlock specifically, which help in optimizing the way we do recertification in an existing world. We need to move forward to a more dynamic behavioral-based, signal-based, and risk-based approach that is really looking at what is the current state and what we do. This also will help us to do better in an agentic world, so to speak. I'd like to basically already shift to the Q&A because we have a very long list of questions here, which is good.

So, the audience is very, very active here, and I want to ensure that we have sufficient time to cover all the questions we have here. So, before we do that, I want to quickly bring up a second poll, which you can then respond to during the Q&A part, which is, do you think you can easily reduce the recertification workload?

So, you've got some ideas, some thoughts. You may have already read the blog post I wrote.

So, do you think it's a really straightforward thing to do to reduce it? Maybe not by 80%, but maybe at least substantially. Is it doable, but not super simple? Or do you think, come on, we will always have this recertification burden? I'll leave it to you to respond to this. If time allows, we will look at the results a bit later on.

With that, I think we go back to the Q&A. So, Damon, and maybe exactly bring it back to the forefront, we have, as I've said, we have quite a number of questions. I will go through these questions right now in the order of upvoting.

So, the first one here is, what is the best way to recertify non-human identities, such as user service accounts, user assigned managed identities, and shared privileged accounts? In post-debate? Sure.

So, I think when you think about non-human identities and service accounts, user assigned identities, shared privileged accounts, I think our viewpoint is going to be pretty consistent across all this, which is to look at the signal data that's a result of the behaviors of those particular accounts.

And so, if you're capturing all the usage logs, change logs, config logs, table data, all of the activities associated with those accounts, and you're capturing that in a highly performative way, and you have a strong set of controls or a control book around those particular accounts and what they're purposed for, then you can look for behavior that is out of conformity, and at which point you would intervene and understand the motivations or the rationale behind that. And so, we would see this as what we refer to at Pathlog as continuous controls monitoring.

And so, obviously, there's a discovery element to all this, making sure that you have it all under your state, but then looking at the behaviors on the applications that these accounts are performing activities on, and then looking for signal data that would suggest to you that something has gone off kilter, and then being able to manifest that in a timely fashion, particularly if you write chat tools or something to this effect, to where when the event happens, the appropriate risk owner associated with those accounts can take corrective action associated with it.

Which I think is a very important point, the appropriate risk owner. For that part of the challenge, it becomes even more important to have a really proper management of ownership.

So, for a lot of these, I don't like the non-human that much. So, I think it's workload identities, for instance, it's the traditional privileged ones, and clearly, it are the agents out there, which are, again, very different. But I think the ownership, we haven't solved it well.

So, honestly, when we look at privileged access management, most functional, traditional accounts don't have proper ownership handling, even in that relatively simple world. If you look at workload identity, it becomes even worse, and it becomes more complex.

So, is the developer the owner, or is the application owner the owner, or who else? So, I think we need to do a good job here also to handle the ownership, because otherwise, we have no one that can then say, okay, this is okay, or it's not okay.

So, I think this is important to keep in mind when we look at this entire scene. We need to do a good job on that side as well. It's not just a technology problem, it's way more than a technology problem.

Yeah, digital twinning is a term that we hear coming up a lot, so that any non-human accounts associated with a human account and that's the actual owner associated with it. And then, I would also look at the process under which that lies underneath it, and assuming that the digital twin associate was the process owner, or the risk stakeholder associated with it, and it could be multiple people as well.

Yeah, and I think one more thing to add before we end, so to speak, this question. I think one thing is clear. In a world where a lot of...

So, if you go to traditional shared privileged accounts, it's still relatively simple. This is a relatively slow-moving sort of environment of accounts. It is a limited number of accounts. We have some capabilities here, and it's not fundamentally different to the way we handle the workforce, the employees.

So, we can handle it probably relatively traditionally. When we look at workload identities, where the various sources say this is 40x to 80x the number of our sort of human identities, then we are in a world of automation, of volatility, etc. And it's very clear that our traditional ways of handling recertification or anything else, accesses, etc., will not carry for this very different world.

So, we need to do it differently. We can't try to use a standard recertification approach on workload identities when they are ephemeral, when they are very short-lived. It will not work.

So, this is exactly, I think, where what you mentioned comes into play. And this is clearly on the, I would say, more on the strategic solution side, which is shifting to continuous approaches, to risk-based approaches, to consume signals, and to focus on the behavior and the outliers in the behavior.

So, full agreement on that. Next question. This is definitely one of... I want one more quick footnote on that, because each of those accounts that were mentioned have sort of a different purpose. When you think of privileged accounts, too, shared privilege accounts, that's interesting because it's somewhere between maybe this continuous idea and sort of the present moment of AI. And you can kind of combine these ideas in a way.

So, if you think about like a time-bound session, having faculties where whoever's granting that authority can write in natural language, my intent is to give this person zAdmin for a period of time for the following reasons. They're going to go in and make these changes. This is what the spirit of the purpose of that particular body of work is. Then the human account goes in, uses the shared privilege account, performs whatever task here is intended to do. And at the conclusion of it, that's summarized.

And so, you can apply AI into that as well to look across the actual behaviors of what took place in that session, and then manifest any outliers that were not intended in the written spirit of why they should have that. And the conclusion analysis of that can be then shipped to the appropriate risk owner to say, yeah, they use zAdmin for the following purposes, but then they did all these other things on top of it that were outside the scope. And you might want to take a look into why they did that sort of thing.

So, there are sort of what I'll call brackish waters between complete autonomous accounts that are acting that you're having streaming data to understand behavior in real time, time-bound access where there is a human being involved, but you want to simplify and streamline it, and that human might be somewhat anonymous because it's a shared account, and that you can apply some of these agentic learnings and AI into that particular process to really bring clarity to it.

And a lot of organizations in the past would use things like screen scraping and video logging, which is ineffectual for actual attestation or assurance data for audits. So, not an important distinction to make, because there was a series of different types of users that were posed in that question. Okay. To the next question, that's one clearly for you.

Damon, can you please let me know what are the abilities that PathLock has in regard to access certification? So, probably from traditional to, we talked a lot about the modern stuff, but maybe you give a condensed overview here. Yeah.

So, I think the distinction with what we're doing here at PathLock is that, you know, you kind of start with should this person have access, period. And then you get into what kind of controls or access should they have that sits underneath the business role or role level.

And so, we see the full application security model for about a hundred different critical business applications out of the box. So, we can get all the way down to T-codes and table data or functions or permissions.

You know, Workday has like, I think, a four-tier security model. And so, we see the entire application security model down to the most fine-grained entitlements associated with that user. But the real important part of it is that not only do we see the static application security model, we're actually capturing all of the behavior of that user on top of it.

So, we see all the usage logs, change logs, config logs, table data changes. And so, when you think about a recertification campaign, the question is, should this person be able to do this? Should they be able to do it under these conditions?

And then, moreover, did they do it? And what is the context in which it was done?

And so, this can kind of cut in both directions where you might find someone that has both sides of a risk. They may have never used it. And in the recertification campaign, you can kind of tidy up their entitlements because they've never actually used it. On the other side, maybe they have both sides of a risk or they have a risk that they used in a way that was not intended. Or potentially, they have an entitlement on application one that allows them a series of behaviors that they can engage in, and entitlements on application two that give them a different series.

And when you combine those two, you get a cross-application toxic combination that allows them to do something that they were never intended to do. Now, it's real important to be able to understand that.

And then, it's also very important to be able to understand whether they actually did it or not and the context in which it was done. And so, we give you full fidelity visibility into that, which is pretty distinct and unique. And it's that technological differentiation about what Pathbox is doing that separates us in our view. And that same phenomena allows you to be applied to things like elevated access management, continuous controls monitoring.

And even when you think about Earthright, the ability to understand not only a business role or an application role, but fine-grained access entitlement to that application in combination with a multitude of different applications. Because you might have an employee that has multiple SAP roles, multiple Oracle EBS roles. They have entitlements on Manhattan Warehouse, Ariba, et cetera. And there's no good way to understand that with the composite of all of those different entitlements, whether or not that user exposes the business to elevated risk in a way that you had not intended. Yeah.

So, basically, what you're saying is your differentiation comes on one hand from deep insight into a very wide variety of applications at all levels and the ability to also understand the relationships between different things. So, if you have just one, say, okay, role A versus B, it still might be that certain transaction codes are in conflict.

So, all these steps, you have the ability to do very traditional certification up to very modern continuous controls monitoring and doing that across a wide range of applications. So, in summary, that would be...

So, there was a second question around the competitive advantages. I think this probably summarizes them very briefly, let's say it like this. Yeah. And a layer of intelligence around the processes themselves.

So, think about not only the ability to extract, transform, and normalize that data across multiple applications, but then also the intelligence to interpret what's taking place. So, you have to have some degree of subject matter expertise that in Procure2Pay, maybe I have a purchase order, I have a materials receipt, I have an invoice, I have all these artifacts that are differentiated or in different systems. How do they relate to each other and what should my control framework be across Procure2Pay or any given process that you might have across your critical app estate? Okay.

Well, one more question. What matrix do you track?

So, such as completion rate, revocation rate, exception volume, overdue review is false positives, review burden, whatever else. So, anything you can share around that? Yeah.

So, that's fairly standard capabilities within the product. The false positives is an interesting one. I think eliminating false positives is a huge part of how you tune your rule sets. And I think there's a huge opportunity for AI to ingest what good looks like and what normal is through a multitude of signals like Martin had mentioned earlier.

And so, I think that's where we start to eliminate all the false positives through our intelligence based upon actual usage metrics associated with any given user. Okay.

Then, one more question that is, how do you ensure fragmented recertification campaigns still provide management with a complete picture of excess risk? So, maybe I start here. I think this is a more generic question. My perspective is that you can measure that risk and combine that risk in various manners.

So, at the end of the day, it's just a matter of how you handle the results of that. So, what has changed? What has been revoked? What has been done or detected during the recertification? You can have more sliding risk, so to speak, where you say, okay, this is my continuous average risk. Or it could be something which is probably more this certification campaign run that way.

So, the one is more continuous, the other is more a point in time thing. I think the continuous one anyway helps for continuous reporting as well, where you say, okay, that's what we see, how things go up and down. And if you take more, we just talked about the various metrics. If you ingest more metrics, then you can have a quite good continuous sort of excess risk exposure picture done that way. Yeah. I think if you think about recertification, it's like a form of a control and how you think about your controls framework and how you monitor controls.

There's an interesting dynamic that we see play out. It tends to gravitate towards larger corporations, larger entities that have significant regulatory issues. But it's this notion of continuous controls frameworks and the ability to look at things from a control viewpoint. And you have groups of folks like internal controls that come along, and their ambitions are often kind of a bit different. They coincide with IT, but they're a slightly different view.

And so, we look at, and what's interesting about it is organizations will spend tons and tons of money to do sample testing. So, they'll look at controls outputs, they'll maybe try to create their own data lake, they'll hire lots and lots of consultants to come in and start matching up transactions manually to determine if a control is durable. And then they take the output of that and they write into their control book, like a WorkKeeper or an audit board, this type of product, so that they can have evidence or assurance.

And we think that that behavior is one, very expensive, very time consuming. You could think of a recertification campaign in the same vein as this. And it's also not indicative of authentically mitigating real risk because you're just doing sample testing.

So, the sample set that you have might not show the violations. And so, our viewpoint is that we want to see everything all the time. One of the things that I often say to organizations is, you know, one of the things that I often say to organizations to sort of make an analogy is, if you think about very successful products in like the sim space, like Splunk or QRadar, these types of offerings, what they do for network signal, for security signal, is our intent to do for business signal.

And if you think about how they operate, is they take signal data from a variety of sources, they amass it, and they look for anomalous. And I think we need to fully agree. I think we are running a little out of time.

So, I think we need to keep the, we have still two questions and very brief. But I think, fully agreed, we need continuous insights are much better.

So, it does help us saying, okay, we had a cool recertification campaign. And three months later, the world looks fairly different.

So, I think there's a continuous approach. We're always in a better situation. Two questions, very short answers, maybe on these. The one final question, do you think it's challenging to implement from a cyber perspective? This is interesting, given that you're digging deeper into security configurations and entitlement analyzers, multiple applications.

I think, from a cyber perspective, I personally believe that combining signals will become more and more important. My sample is, you have a signal from a Zoom video call, you have some strange behavior at the network level, you have some strange access, and you have a 25 million transaction at the end of the day. If you combine signals across all domains, you can do very different things than we do today. We can mitigate risk better.

So, we need to think this broader in the security context. Anything very shortly to add on this, Damon?

Yeah, I think it's a great idea. I used to live in Redmond, Washington, home of Microsoft.

So, I'm very from Microsoft. I was out meeting with them, and they have their data lake in Sentinel for security signal. And we're working actively with them to provide context to business signal from the application estate in conjunction with a lot of the network signal. And some of the sentiment I heard from some of the thought leaders at Microsoft was that the convergence of IPGC or sort of security signal with business signal is definitely something that there's a lot of appetite that we're hearing from our ISV partners as well as customers. Exactly.

Final question, also very short answer on that. Who are the typical organizations that come to PathLock, and what are they struggling with when they arrive? 30 seconds. Sure.

So, we service a pretty wide variety of the market. I would say that organizations that have regulatory responsibilities that have to report for audits tend to be more excited about what we're doing as a company. We do have privately held corporations that just want to engage in best practice, but a lot of times the catalyst is some form of a regulatory framework, more often than not SOX. And the first use case that we hear over and over again is about separation of duties analysis for cross-application, as well as the primary ERP estate.

We have a brand notoriety around SAP, and that's certainly true. We feel that we can bring more to the table for SAP than even SAP, but it's by no means exclusive.

So, we work with tons and tons of different applications, and we really think it's the cross-application risk associated with organizations. And in the future, even the cross-use case, cross-domain combination of signals. I think this is where we need to head for.

Damon, I think this was a super interesting conversation. We have been touching a lot of topics. We probably weren't able to touch all of these topics, so there are still way more we could discuss about, but we are really at the end of the time, up to the minute.

So, thank you again very much for being here, for delivering your insights, and I hope this was helpful to all of the attendees. Thank you.

Thank you, Martin. Always good to see you, and looking forward to talking again in the future, and thanks to everybody that attended today. Thank you.