So nice to be here. As he mentioned, my name's Todd Peterson, I'm with one identity. I'm now the leader of product marketing content and partner marketing. So basically that means that my job is to tell stories. So I'm gonna try to tell interesting story today who hair has heard of one identity, raise your hand. Oh, so lots of you. Good. Usually we are kind of the, the greatest IAM vendor that you've never heard of, but here it sounds like people have heard of us. So we're gonna talk a little bit about identity governance, administration or IGA and how one size does not fit all. So we're, we're all involved in this, whether it's, you know, kind of an ad hoc thing we're doing just with whatever tools we've got, or we've invested in a big framework to do it, or we're doing other stuff, but let's level set on what IGA actually is.
So if you look at this wheel, it, we generally break it down into these 5, 7, 7, 7 categories. So it includes access requests. How do I, as an employee ask for access to something on workflow, what processes, what approvals, what things do I have to go through or does the organization have to go through in order for me to get that access that I requested fulfillment or often called provisioning is how does that access actually get set up identity? Life cycle is what happens when I need different access. What happens when I leave? You know, what's the whole life cycle of that identity. We, I like to think of it as, as a person it's born, it grows up, it changes its voice gets deeper, it grows hair and then it dies. And that's kind of what our identities are like policy and role management, what rules we have to follow access certification.
That's generally what people count as governance. The ability to say that I attest or I prove, or I certify that all of these things happened in the correct way that, you know, the permissions that we gave somebody on the fulfillment that the, you know, the request would follow the right rules that, you know, you're certifying, it's all correct. And then auditing, being able to track that whole process. So if that's what IGA is, how come it's such a problem. So the really, it boils down to a couple of things. It's getting the right people, the right access to the right stuff in the right way at the right time. And that you can prove that it's all right. If you've got all those rights happening, then you've got IGA nailed. And I think, you know, very, very, very few of us actually have it all, you know, all right, all the time.
So we did some research about a thousand. I think it was actually 1,008. It security pros. We asked them a bunch questions about all aspects of identity and access management. The first one was, how long does it take for them to fully provision a new user? So somebody starts at the company and how long until they have access to every single thing they need to do their job. And that access is correct only what does that say? 18, 18% said that they can do it in a matter of minutes or immediately everybody else. It was taking hours, days, weeks, months. So we turn that around. How long does it take to deprovision a user that's probably even the more important thing. You know, if it's inconvenient for an employee to not have access, it's dangerous for an ex employee to still have access. And there, it was 28% were able to do it in a reasonable, acceptable amount of time.
Everybody else, it was taking too long, giving them a lot of risk. Then we asked them if they have the ability to execute den, execute identity, life cycle management actions in active directory. So do they have a tool that helps them do this request fulfillment, you know, change identity, life cycle stuff within just their active directory environment. And there we had 36% said they did have tools for that. Okay. Then we ask them the same thing. How long do you have tools to help you do that stuff for your on-prem applications? The number went down a little bit down to 33%. Then we asked them if they had the same thing for their cloud applications that went down to 30%. So if you look at it, the bottom line is that everybody has to do this stuff. Everybody's trying to do this stuff. And the vast majority of us are not doing it as well as we think we should, or as well as, you know, regulations and best practices say that we should.
So the ideal is to do all this stuff great. But the things that really get in the way are money. How are you gonna pay for making all this happen? Skills? Do you actually have the skills on staff on site to be able to do this work? Do you need to get new people in to help you with it? Do you need to get a partner to help you with it? Governance? How are your regulations changing? Did you know you had everything taken care of for PCI, but now GDPR came up, did that change your requirements? And now you have to do the whole thing again. And finally complexity's really the big problem. It's fine. If you're doing all of these things on a single platform, a single system, it's not too difficult. You could even do it with manual processes and probably be okay, but then you had two, three, a hundred, a thousand tens of thousands of different systems and lots and lots of different types of users.
And all of a sudden it becomes very difficult. So the more complex you get, the more often you're doing this stuff. And the more often it breaks, the more difficult it gets. So everybody has some options. Here's here. They are. We're gonna go through through each one, one at a time. I'll talk about some examples of people that have done some of these and we'll figure out what's best for you. First one is do nothing. I think that's not really even an option. If you don't do anything, you're going to end up being breached. You're gonna end up being inefficient. You're gonna end up going out of business. So we'll just skip that one. Is there anyone here who's in the do nothing bucket? I think just the fact that you came here means you're doing something, all right, build it yourself, manual processes or native tools.
So this would be things like you use a duck for provisioning of active directory. You, you know, use the native tools or you build some scripts to help you do the identity lifecycle stuff. And maybe the attestations on, on specific systems. It's got some advantages. Number one is that you get exactly what you want because you're defining it. You can do it. It's free. And you're probably already doing some of it. Just the fact that people have access to things means that somehow IGA or at least the, a part of IGA happened, but it's got some disadvantages as well. So you get exactly what you want, but you get exactly what you build. So if you want something, then you're uncapable of incapable of building it. You're not gonna get it. You have to support it. You don't have a vendor with this staff of help desk people ready to jump in and help you solve whatever problem you've got.
You've got to, you know, do all that yourself. Your native tools only go so far. How many of you, you know, do manual provisioning in active directory and exchange and all those other things through, through ADUC or native tools. So the long process, you have to do a lot of different things. You can make a lot of errors. So the native tools only go so far. It ends up being extremely disjointed and siloed. You're gonna do, you know, we solve this problem here, but this problem's different. We're gonna build something else to solve that problem. And then this new problem comes up and we're gonna try to solve that one. And then what are you actually settling for? Are you saying, well, this is as good as we could do and that's good enough. And is it really? And then it is free, like a puppy's free.
All right, next one is point solutions. You have a specific system that you want to do IGA for. You're gonna go out and shop and you're going to evaluate and deploy and then manage a solution just for that environment. We have a solution that does that for active directory. So the pros of this is it's great at one thing or one target. If you have a specific target that you're trying to do IGA for, then this one tool can do a great job, give you everything you need there, it can quickly satisfy an immediate audit need. So if you have a single system that, you know, has a, a need, an immediate need to satisfy one of those things on that IGA wheel, you can do that with a specific tool and, you know, get the problem out of the way and move on to other things.
You can go best in breed. You can buy the very best solution for active directory IGA in the world. It may not be the best solution for another problem, but it can do it for active directory. And if your environment is very homogenous, if you're, you know, really fairly Blands the wrong word, but I'm gonna use the word bland fairly homogenous, then you're probably in great shape. An example of that would be a technology company that I'm aware of that has been very, very rigorous about doing everything within the Microsoft stack. So their approach to IGA is just to make sure that active directory and Azure active directory and all of the, you know, ancillary systems that those affect are taken care of. They're able to do their identity administration very efficiently, very cleanly, just with a tool dedicated to active directory. So the cons, what about everything else?
If you know, you don't have just this one system, what are you gonna do with those other systems? It ends up giving you a disjointed and siloed approach. If you have more than a couple of things that have these type of solutions, you've got repeated effort, repeated investment, you have to do the same activity again for this system. Again, for that system, maybe a different tool, maybe a different team, maybe a different process. And does it do identity administration and identity governance, or does it only do one or the other? Are you able to solve that whole wheel with this solution? And how often do you have to research purchase, test deploy, update an additional solution for something else? So point solutions are, can be good, but only in the, you know, the right circumstances. Then we've got your legacy provisioning frameworks who in here is, is using one of these things that have been around forever.
Your IBM's Oracles, CAS, maybe a Nobel, maybe somebody still has a sun framework laying around. So that's what I'm talking about here. These provisioning frameworks that have been around for a long time, they've got some advantages. These guys have been doing it forever. They've been succeeding. They're entirely customizable. If you need this framework to do something from an identity administration standpoint, you can get it to do it. And they're very well established vendors with thousands of customers. You know, they're not gonna go outta business next week and leave you hanging with, you know, no support for your solution, but there's some disadvantages as well. They've been doing it forever, but they've been doing it the same way forever. So they are difficult for these kind of cumbersome, customized things to keep up with the rapid pace of, of change, you know, cloud stuff, digital transformation is more difficult with one of these legacy systems in with another.
And they are entirely customized, which means you had to build everything from scratch more or less. They're extremely complex. We have, you know, dozens of customers with, you know, they had a three year IGA project with one of these and they are five, six years into the project and millions and millions over budget. The project never ends. One customer that I'm aware of has one of these. And they employed 16 Java developers to write the connectors, to, to do the administrative stuff. After three years, the 16 developers had developed one connector. It was to active directory and it only did provisioning. It wouldn't do deprovisioning yet. So obviously it's not the best investment sometimes. Does it do governance or does it just do administration? And then they end up being very, very expensive. Cause I think many of you probably are aware. So what have we moved onto from that?
The kind of what I would call the modern IGA framework. So number of vendors, us included that have these more nimble, more flexible, more future ready approach to the same problem. They do both identity administration and identity governance. They're much more flexible than the legacy frameworks able to deal with change much easier. You know, your digital transformation can be handled by this type of thing. They're generally less expensive to deploy and own because they can go in quicker. They, you know, get up to speed and they deliver value sooner. And sometimes they have areas of very specific strengths. So just as an example, our solution in this category is awesome at SAP. So if you have a specific system, you may be able to find a one of these modern IGA frameworks that can solve your problems, but they have disadvantages as well. It's still a fairly heavy project.
It's not, you know, plug and play it's, you know, gonna be a several month or, you know, a year or more project. And then sometimes it's beyond the budget and skill and scope of many organizations. They want to do this, but they just simply don't have the money to do it. They may not have the skill in-house to do it. And so they're stuck with one of these other options. And then the last one, what I would call ad centered actually second to last one ad centered identity governance administration. So this is what I described that technology company that bases everything on ad they're able to, well, this type of solution would be optimized for an ad heavy environment. You can extend it often to other systems. So an active directory bridge could make it work on Unix and Linux skim connectivity could make it work on, you know, a number of cloud applications.
So it can go beyond that Microsoft environment, but it can't go everywhere. It's usually much easier to implement because it's fairly common use cases and fairly easy stuff that you're gonna be doing with it. So it's not, you know, a, a year long project it's a month or two long project. It can often compliment an IGA framework. We had a number of customers that have one of these old legacy things, and they were just simply having trouble with the active directory piece of it. They couldn't afford to build it. It was taking too long. So they just throw in one of these ad centered solutions. And all of a sudden all that active directory stuff is taken care of. And they can move on to the harder things and not worry about, you know, the, the ad piece. And then it can fill the gaps in the legacy provisioning frameworks.
I just mentioned the cons are it often requires ad hoc additions to get complete idea, you know, your access request or your fulfillment. You may have to go and find another way to do that or an additional way to do that, but they're there. So it's not that bad a thing. It may not serve certain systems. You know, for instance, this organization with the ad Senator approach, they don't have SAP and that's fine. If they did have SAP, it would be more difficult for them to do this approach because it just don't talk well. And they can only extend so far. Then the last one is what I would call ad hoc. You just pick and choose what you need. Maybe you need access request. Let's go find one and do that. Maybe I need access cert, let's go find that. Maybe I need provision.
Let's go find that and, and do it. So that's nice. Cuz you can start wherever you want and build from there. It's a great gap fill if you've got this ad approach, but you need to add access cert to it. You can fill that gap. Usually these are delivered as software as a service. So that's got some definite advantages financially deployment wise, et cetera. They're easy to implement. The problem is they're not ideal for highly customized environments. SAS also has disadvantages that many people you know, are aware of and that maybe redundant if you're using other approaches as well. So you have all these options. So ask yourself these questions. What do I need to do in the short term? What's the stuff that I have to solve right away. And which approach will be best for it. Where do I need to get to in the long term?
What's my end game here. Or at least what's the path that I'm gonna be on? How complex is my enterprise? The more complex you are, the more diverse you are, the kind of higher up that chain. You're gonna have to go to solve your problems. How complex are my requirements? We have some very small organizations with very complex requirements that have to go with a modern IGA framework. And then what can I live without? Am I okay? Not including my mainframe or not including this legacy system and what can I not live without? Is SAP a piece of it? Do I have to absolutely take care of SAP is active directory important. So bottom line is you can do all of this stuff if you get the right advice. So don't take the advice from the vendors like us. We're gonna come in and you know, we'll say here's what we sell and it's the only way to do it. And you won't be happy unless you do it. Another vendor's gonna do the exact same thing. We sell this thing. And it's the only way SAS is the only way because we only sell SAS ad base is the only way because we only sell ad. So find somebody that you trust to help you through that journey and get the thing that's right for you. So we'll leave it there.
There's the examples we already talked about. I'm done. Okay.
Thank you Todd. I like that. That presentation very much. And you know, it, it's something, obviously we are talking again and again about these things. The one thing again, and you touched it to some extent is so wanna, for the most important recommendation, don't try to build your own identity management system. I currently see some trend in saying, oh, I have this smart it service management from wherever it comes. And I reinvent, I am using a tool which is not built for doing so I can at least give an exact number of the project failure over a certain period, which is exactly 100%. So these things never will work, but it's about integrating it right. Choosing the right approach. I think this is very insightful. Very informative. So thank you. Yeah. Thank you.
