WEBVTT 00:00:01.000 --> 00:00:03.991 Welcome, everyone, to this videocast, where 00:00:03.991 --> 00:00:07.400 we're going to have a quick, hitting conversation 00:00:07.400 --> 00:00:11.139 on the topic of the Identity Fabric. I'm Matthew 00:00:11.139 --> 00:00:14.800 Gardiner, fellow analyst here at KuppingerCole, 00:00:14.800 --> 00:00:20.400 and I'm joined here with Bhanot Singh from Cross Identity. Bhanot, please give a quick 00:00:20.400 --> 00:00:21.400 introduction and say hello. 00:00:21.400 --> 00:00:24.600 Hi. Hello, everybody. This is Bhanot here. 00:00:24.600 --> 00:00:31.000 So obviously, the first question that we're going to get into, since the topic is the 00:00:31.000 --> 00:00:36.800 Identity Fabric is, well, what is the Identity Fabric? It's a topic that KuppingerCole has 00:00:36.800 --> 00:00:43.800 been hitting on for a number of years now. But to set the stage, basically, we think 00:00:43.800 --> 00:00:52.200 of it as an architecture, an operating model, a framework, use whatever term makes sense 00:00:52.200 --> 00:00:58.200 to you. It's specifically not intended to be a single product. Another way to think 00:00:58.200 --> 00:01:04.800 about it, and actually, I'll put up a very detailed graphic, which we won't go into any 00:01:04.800 --> 00:01:10.200 great depth, but just to give you a sense that there's a lot of complexity underlying 00:01:10.200 --> 00:01:13.100 the Identity Fabric. You could think of it as 00:01:13.100 --> 00:01:16.000 connecting some of the subdomains of Identity 00:01:16.000 --> 00:01:20.300 Management, like Identity Governance, Access Management, Identity Threat Detection and 00:01:20.300 --> 00:01:23.268 Response, directories, et cetera. But 00:01:23.268 --> 00:01:27.600 basically, tying it into a fabric that an organization 00:01:27.600 --> 00:01:35.700 can, over time, in a modular fashion, pull out, expand, improve, and tie together the 00:01:35.700 --> 00:01:40.700 various components that make up an Identity Fabric. 00:01:40.700 --> 00:01:47.100 So I want to hand it over to Bhanot and talk a little bit about how does he handle, how 00:01:47.100 --> 00:01:50.020 does his organization handle the conversation 00:01:50.020 --> 00:01:53.200 about platform and fabric and Identity Management 00:01:53.200 --> 00:01:55.700 with your customers? 00:01:55.700 --> 00:01:59.800 Sure. So I'd have to date myself back to almost 00:01:59.800 --> 00:02:03.900 quarter century. We have been into the Identity 00:02:03.900 --> 00:02:08.700 and Access Management for almost 25 years, at least. I've been a practitioner in that 00:02:08.700 --> 00:02:11.850 area for that long now. And in the initial 00:02:11.850 --> 00:02:15.600 years, when we saw that we were system integrators 00:02:15.600 --> 00:02:22.500 in the U.S. doing more than 450-odd projects, and we saw the genesis of the problems that 00:02:22.500 --> 00:02:29.900 led to a solution like Identity Fabric. We saw technologies being broken, and not because 00:02:29.900 --> 00:02:38.000 they were broken by design, but it was a part of the evolution. As we all know, initially, 00:02:38.000 --> 00:02:43.300 we had provisioning coming in, the single sign-on and access management came in a few 00:02:43.300 --> 00:02:49.300 years later, and that followed by privileged access management, and so on and so forth. 00:02:49.300 --> 00:02:52.100 Till today, we see Identity and Access Management 00:02:52.100 --> 00:02:54.900 domain having grown into more than nine different 00:02:54.900 --> 00:03:01.900 components, if you start looking at all kinds of identity. And so it was a problem which 00:03:01.900 --> 00:03:07.800 was supposed to be inevitable, because in the earlier times, I saw that we did not have 00:03:07.900 --> 00:03:11.472 the need of integration so much, and you could 00:03:11.472 --> 00:03:15.200 still exist as islands, but with all the changes 00:03:15.200 --> 00:03:17.939 that have occurred in technology and the 00:03:17.939 --> 00:03:21.500 demands that it has brought, it has become important 00:03:21.500 --> 00:03:23.600 to exist as one single technology. 00:03:23.600 --> 00:03:33.600 Right. And it seems like it's a recurring theme in IT. We don't know we're building 00:03:33.600 --> 00:03:38.200 Frankenstein leg by leg, and arm by arm, and head by head, and then we turn around 00:03:38.200 --> 00:03:42.050 years later and realize we have Frankenstein. 00:03:42.050 --> 00:03:45.900 I don't know if that's a good analogy or not, 00:03:45.900 --> 00:03:55.900 I just came up with it. So are we sort of abstracting the architecture now to build 00:03:55.900 --> 00:04:01.800 Frankenstein into a more attractive human being? Maybe that's a way of modeling it. 00:04:02.000 --> 00:04:09.700 Very true. So now that we have a little sense of what it is, and sort of the next stage 00:04:09.700 --> 00:04:12.934 or fraction of the identity management problem, 00:04:12.934 --> 00:04:16.100 the next question is, well, why should I pair? 00:04:16.100 --> 00:04:19.509 Why should I architect using the identity 00:04:19.509 --> 00:04:24.000 traffic approach? I think we sort of hit on it in that 00:04:24.000 --> 00:04:29.900 the complexity has now become so high, because back in the ancient time, 20 years ago, 00:04:30.800 --> 00:04:34.200 when you're mostly on-premises and the world of the web was just brand new. 00:04:35.200 --> 00:04:38.586 But now, of course, we have SaaS and cloud, and 00:04:38.586 --> 00:04:41.900 we have M&A happens with IT systems coming and 00:04:41.900 --> 00:04:45.822 going inside an ecosystem. So you have massive 00:04:45.822 --> 00:04:50.000 heterogeneity. And then you have the conversation 00:04:50.000 --> 00:04:57.600 around the classic architect that's centralized versus federated. And I think the natural 00:04:57.600 --> 00:05:02.300 inclination in the early days is to think centralized, but then you realize with all 00:05:02.300 --> 00:05:07.100 the complexity and heterogeneity that the federated model is really what's necessary. 00:05:07.900 --> 00:05:13.800 And that's where the identity fabric comes in, because it's all really about APIs and 00:05:13.800 --> 00:05:21.600 independent systems interoperating with overarching orchestration. So when you're 00:05:21.600 --> 00:05:28.300 having conversations with your customers and prospects, how do you get them from the old 00:05:28.300 --> 00:05:34.800 school identity management siloed approach to the fabric approach? How do you handle that 00:05:34.800 --> 00:05:39.097 conversation? Right. So it depends on the type 00:05:39.097 --> 00:05:43.300 of customers. And if I have to really segment 00:05:43.300 --> 00:05:48.000 the market, I would say customers who have been there, who are very large enterprises 00:05:48.600 --> 00:05:51.377 and have been in business for a long time, as 00:05:51.377 --> 00:05:54.400 opposed to enterprise, which has been in business 00:05:54.400 --> 00:05:58.593 for, which has grown very fast over the last just 00:05:58.593 --> 00:06:02.700 about eight to 10 years. And then we also cannot 00:06:02.700 --> 00:06:06.423 ignore today the mid-market and the SMBs who 00:06:06.423 --> 00:06:10.400 suddenly seem to be needing as much of identity 00:06:10.400 --> 00:06:14.473 and access management and all of it as anybody 00:06:14.473 --> 00:06:18.900 else. So when it comes to the first type, which is 00:06:19.700 --> 00:06:23.087 legacy organizations, which, as you said, have 00:06:23.087 --> 00:06:26.400 got all kinds of, they've got both the legacy 00:06:27.000 --> 00:06:32.300 applications and enterprise, as well as cloud embracement over the last few years. 00:06:33.300 --> 00:06:38.300 There, they have no choice. Obviously they have invested in identity in a big way. 00:06:38.300 --> 00:06:44.000 They already have in all probability for some IGA tool. They're using something for access 00:06:44.000 --> 00:06:50.000 management. For sure they have PIM, but then what they're looking for is now 00:06:51.800 --> 00:06:55.065 all of it to be put together in a way that they 00:06:55.065 --> 00:06:58.400 would be able to orchestrate services out of it. 00:06:58.400 --> 00:07:01.914 Because look, one issue that we have in our 00:07:01.914 --> 00:07:06.000 industry is that the solutions, the way they come, 00:07:06.700 --> 00:07:12.600 they're not coming the way problems are to be solved in the sense that traditionally 00:07:13.200 --> 00:07:18.400 solutions have come in modules, various modules like access management and all that. 00:07:18.400 --> 00:07:21.257 But if you look at a solution to be solved, it 00:07:21.257 --> 00:07:24.300 runs across the modules and therefore it requires 00:07:24.300 --> 00:07:27.400 some sort of orchestration mechanism, workflows 00:07:27.400 --> 00:07:30.500 to be created for which you need to bring these 00:07:30.500 --> 00:07:35.489 identities, management modules together. That 00:07:35.489 --> 00:07:40.700 actually staggered perfectly to the next topic. 00:07:42.500 --> 00:07:49.200 Go ahead. It's a little easier for the large organizations, the enterprises who are more 00:07:49.200 --> 00:07:52.130 recent in nature, and they have gone for a little 00:07:52.130 --> 00:07:55.000 bit of more convergence from the very beginning, 00:07:55.000 --> 00:07:59.200 because they have been dealing with issues like cloud and all right since their inception. 00:08:00.100 --> 00:08:08.700 So for these two, there is no option usually, but to build a fabric as we all talk about. 00:08:10.000 --> 00:08:14.900 There is another option that companies like us are beginning to provide. 00:08:14.900 --> 00:08:22.900 We have a converged fabric, natively converged fabric, which offers a layer of foundation, 00:08:23.000 --> 00:08:27.254 a foundational layer on which you can not only 00:08:27.254 --> 00:08:31.600 create newer modules, but your existing modules 00:08:31.600 --> 00:08:34.870 would also very easily come together. And I 00:08:34.870 --> 00:08:38.900 think a combination of all that is required for large 00:08:38.900 --> 00:08:42.302 enterprises, but when it comes to the SMBs and 00:08:42.302 --> 00:08:46.000 the mid-market customers who have not yet invested 00:08:46.000 --> 00:08:49.600 much in identity management, I think they can 00:08:49.600 --> 00:08:53.200 very seriously look at natively converged IAM 00:08:53.200 --> 00:08:57.600 solutions, which are beginning to appear in the market. And trust identity, by the way, 00:08:57.600 --> 00:09:01.035 is a good example of that. Basically, what I hear 00:09:01.035 --> 00:09:04.400 you saying is that depending on where you are in 00:09:04.400 --> 00:09:07.437 your identity management journey, whether you're 00:09:07.437 --> 00:09:10.600 a long-standing one and have lots of heterogeneity 00:09:10.600 --> 00:09:13.340 or have that Frankenstein that I was referring 00:09:13.340 --> 00:09:16.200 to, or whether you're newer or fresher with less 00:09:16.800 --> 00:09:19.500 heterogeneity, you can get a solution that takes 00:09:19.500 --> 00:09:22.200 a bigger bite out of the identity fabric and one 00:09:24.800 --> 00:09:28.700 recognizing that there's no one solution that covers everything. 00:09:28.700 --> 00:09:31.370 So you still need to get down to the how does 00:09:31.370 --> 00:09:34.100 it interoperate with the other components that 00:09:34.100 --> 00:09:38.900 you already have so you don't have to lift and shift them. So you get down to, 00:09:39.300 --> 00:09:41.933 when you're federating, you need to have APIs 00:09:41.933 --> 00:09:44.800 so that the components can interoperate with each 00:09:44.800 --> 00:09:47.833 other. But you also need to have essentially a 00:09:47.833 --> 00:09:50.800 workflow or an orchestration that goes across 00:09:50.800 --> 00:09:55.010 the multiple layers so that you get a logical 00:09:55.010 --> 00:09:59.500 flow across by leveraging the APIs that federate 00:10:00.700 --> 00:10:05.600 into an identity fabric. So I think that's more or less what you were talking about. 00:10:05.600 --> 00:10:12.200 Does that make sense to you? Yes, it does. What I always say is that 00:10:13.500 --> 00:10:16.964 one problem that you end up solving through APIs 00:10:16.964 --> 00:10:20.500 creates another problem. We are all talking about 00:10:20.500 --> 00:10:24.350 the identity bloat. We are talking about the fact 00:10:24.350 --> 00:10:28.200 that the security break happens more at the seams 00:10:28.200 --> 00:10:34.300 when we are trying to put two things together. So that's another problem to worry about. 00:10:34.300 --> 00:10:39.200 And from that point of view, for the converged solutions that are beginning to appear, 00:10:39.200 --> 00:10:45.200 they do offer, at least for the smaller organizations, that solution whereby you 00:10:45.200 --> 00:10:52.400 don't have any API bloat. You don't have what we call zero millisecond revocations because 00:10:52.400 --> 00:10:55.737 typically when you put multiple modules 00:10:55.737 --> 00:11:00.100 through APIs, it gets slower. And in orchestration, 00:11:00.100 --> 00:11:02.624 when you're trying to pass a signal to make 00:11:02.624 --> 00:11:05.500 the action in another module, it takes time to do 00:11:05.500 --> 00:11:08.482 that. At that time, it could be fairly damaging 00:11:08.482 --> 00:11:11.400 in today's world because the hacker would have 00:11:11.400 --> 00:11:14.813 done his job in that. It also derives the need 00:11:14.813 --> 00:11:18.300 for standards. You don't want to have all these 00:11:18.300 --> 00:11:22.550 custom APIs. I think the industry has done some 00:11:22.550 --> 00:11:26.800 good work in standardizing the handoffs between 00:11:27.500 --> 00:11:35.700 one domain and another domain. But clearly, a lot of work still needs to be done to 00:11:35.700 --> 00:11:40.000 standardize the APIs to make the identity fabric really work as well as it should. 00:11:40.000 --> 00:11:46.700 Very true. And we have seen lots of it. Thanks to analysts like communities like yours, 00:11:46.700 --> 00:11:52.000 you put in a lot of effort. You're promoting that, we can see. And it's very, very needed 00:11:52.000 --> 00:11:59.000 at this point in time. I think one needs to look at it from different angles. There are 00:11:59.000 --> 00:12:01.505 no perfect solutions out here. The 00:12:01.505 --> 00:12:06.000 standardization takes time. And in the meanwhile, people need 00:12:06.000 --> 00:12:10.300 solution. So it's a combination of looking at some 00:12:10.300 --> 00:12:14.600 of the available fabrics that are there like ours, 00:12:15.300 --> 00:12:20.300 and also looking at how much of convergence you can go in from the beginning. 00:12:21.200 --> 00:12:26.800 There's one important starting point. Starting with the framework. You have to have the 00:12:26.800 --> 00:12:29.578 architecture in mind and build towards it. That's 00:12:29.578 --> 00:12:32.300 right. One very important issue I'd like to talk 00:12:32.300 --> 00:12:39.000 about is this whole convergence is obviously taking time. And the solutions are required 00:12:39.000 --> 00:12:42.387 by most of the organizations given the 00:12:42.387 --> 00:12:47.200 security situation. They need solutions now. So how do 00:12:47.200 --> 00:12:49.666 you really balance between what you need now 00:12:49.666 --> 00:12:52.300 and what you need to have over a period of time 00:12:52.300 --> 00:12:55.179 where the technology is still evolving is another 00:12:55.179 --> 00:12:58.000 challenge that we see customers dealing with all 00:12:58.000 --> 00:13:04.800 the time. As an organization, since we dealt with services before, which is quite uncommon 00:13:04.800 --> 00:13:07.804 in the industry, the services vendor getting it 00:13:07.804 --> 00:13:11.000 to build products. We saw those issues of the past 00:13:11.600 --> 00:13:17.000 and we went on to develop something. But we can see the challenges because 00:13:17.600 --> 00:13:20.900 people are moving from one generation literally to the third generation. 00:13:21.500 --> 00:13:27.000 And they're really grappling with what you said. But yes, standards are emerging. 00:13:27.600 --> 00:13:33.000 Companies like us are embracing those. We try to make the problem a little simpler, 00:13:33.000 --> 00:13:38.700 at least for the smaller organizations, by building a solution which is all in one and 00:13:38.700 --> 00:13:44.100 doesn't have to necessarily deal with the problems of integration. So basically, 00:13:44.100 --> 00:13:50.100 if you're a green field, you can leverage the fact that you have a cleaner slate than the 00:13:50.100 --> 00:13:58.700 Frankenstein 20-year-old implementations. So to make matters more complicated, 00:13:59.700 --> 00:14:04.600 there's the identity type explosion, which we're sort of in the midst of experiencing 00:14:05.200 --> 00:14:10.400 and how that fits into the identity fabric. In my early days of identity management, 00:14:10.400 --> 00:14:14.000 we dealt with employees, customers, partners, 00:14:14.000 --> 00:14:17.600 human beings, basically. But in the meantime, 00:14:18.100 --> 00:14:24.500 over the last 15 years or so, there's been an explosion of non-human identities. You can't 00:14:24.500 --> 00:14:32.200 really get out of this conversation without talking about AI agents becoming the hottest 00:14:32.200 --> 00:14:34.533 new non-human identity. Fortunately, the 00:14:34.533 --> 00:14:37.800 identity fabric does address that. If you go back to the 00:14:37.800 --> 00:14:40.600 diagram, which I won't do right here, non-human 00:14:40.600 --> 00:14:43.400 identities and human identities are all part of 00:14:43.400 --> 00:14:50.500 the equation. So in your experience, when non-human identities, whether they're service 00:14:50.500 --> 00:14:53.744 accounts or the new age of AI agents come into 00:14:53.744 --> 00:14:57.200 the picture, how does organizations you work with 00:14:58.000 --> 00:15:03.200 handle them? Where are they? How do they manage them? Where are they in priority? 00:15:04.200 --> 00:15:07.360 What are they doing differently to manage the 00:15:07.360 --> 00:15:10.800 identities of these machines and these AI agents? 00:15:10.800 --> 00:15:13.138 As you rightly said, I think non-human 00:15:13.138 --> 00:15:16.400 identities are very last five, seven years phenomena. 00:15:17.000 --> 00:15:23.200 And it has, in terms of numbers, completely overpassed the human identities, 00:15:24.000 --> 00:15:27.548 including consumer identities. Especially if 00:15:27.548 --> 00:15:31.500 you look at things like AI, I think that's making 00:15:31.500 --> 00:15:34.750 things even more complex because the technology 00:15:34.750 --> 00:15:38.000 itself is evolving, if you look at AI. And what 00:15:38.000 --> 00:15:40.708 it was six months ago is different from what 00:15:40.708 --> 00:15:43.600 it is today. So it's kind of becoming that way, 00:15:45.700 --> 00:15:51.700 more complicated for technology providers and IAM like us, because we got to keep track of 00:15:51.700 --> 00:15:58.800 what's really going on, for example, in AI and continue developing things which will be 00:15:58.800 --> 00:16:04.400 appropriate to the changes that are occurring now and also taking care of the changes that 00:16:04.400 --> 00:16:07.800 we anticipate coming in tomorrow. One short-term 00:16:07.800 --> 00:16:11.200 thing I see a lot of organizations doing is they 00:16:11.200 --> 00:16:19.200 have the AI agents basically inherit the permissions of the person that it's an agent for. 00:16:19.200 --> 00:16:22.067 So if you assume an AI agent is an agent on 00:16:22.067 --> 00:16:25.400 behalf of somebody, the going in idea is that they 00:16:26.000 --> 00:16:29.087 inherit all the entitlements and account 00:16:29.087 --> 00:16:33.100 access that that person has. So I don't know if that 00:16:33.100 --> 00:16:39.700 works in all cases, but literally if it's my agent, then in theory it should be able to do 00:16:39.700 --> 00:16:43.174 the things I can do and no more. But I'm not 00:16:43.174 --> 00:16:47.200 sure what happens with these system agents that are 00:16:47.200 --> 00:16:53.400 working on behalf of the whole company, like how do you not grant it infinite privileges 00:16:53.400 --> 00:16:55.870 in the environment and thus obviously if it 00:16:55.870 --> 00:16:58.800 went rogue, it'd do bad things. Yeah, you're right. 00:16:58.800 --> 00:17:01.800 You see, we have been grappling with this as well 00:17:01.800 --> 00:17:04.800 with a large number of customers and then we came 00:17:04.800 --> 00:17:07.415 to our conclusion that there's got to be a way 00:17:07.415 --> 00:17:10.200 to combine different kinds of identities into one 00:17:10.200 --> 00:17:13.322 repository. Eventually, if you don't do that, 00:17:13.322 --> 00:17:17.000 then you're trying to deal with multiple repositories 00:17:17.000 --> 00:17:25.100 and that's even more of a complication. So we decided to put everything in one repository, 00:17:25.100 --> 00:17:30.100 way to manage all of it, and we can see many organizations moving towards that. So I think 00:17:30.100 --> 00:17:34.697 it all begins with trying to treat both human and 00:17:34.697 --> 00:17:39.200 non-human identities in a way from a way that... 00:17:39.300 --> 00:17:45.500 Exactly. So with the back to the identity fabric, and we didn't mention the question 00:17:45.500 --> 00:17:49.998 also asked about zero trust. I think my general 00:17:49.998 --> 00:17:54.400 takeaway is that zero trust is, again, another 00:17:54.400 --> 00:17:57.400 philosophy, architecture, approach, framework, 00:17:57.400 --> 00:18:00.400 that sort of thing. Similarly, identity fabric 00:18:00.400 --> 00:18:03.950 in that way, where you can't do zero trust if 00:18:03.950 --> 00:18:07.500 you haven't managed the identity effectively, 00:18:07.500 --> 00:18:11.750 but ultimately that's a key input into whether 00:18:11.750 --> 00:18:16.000 the service or the person to get access to the 00:18:16.800 --> 00:18:24.000 system or data, to trust them essentially, to verify who they are and what their act 00:18:24.000 --> 00:18:29.600 level should be. So fundamentally, identity fabric is an enabler of zero trust. 00:18:30.200 --> 00:18:33.150 I assume you agree with that. That's very true. 00:18:33.150 --> 00:18:36.100 Very well said. In fact, talking on zero trust, 00:18:36.100 --> 00:18:38.969 we have recently been talking about the name it 00:18:38.969 --> 00:18:41.900 should perhaps itself should change to something 00:18:41.900 --> 00:18:47.600 like managed trust. Because if you remember, eight, nine years ago, when zero trust began, 00:18:48.200 --> 00:18:51.678 the technology did not offer much options but to 00:18:51.678 --> 00:18:55.300 go either to a zero or a one, to disconnect or let 00:18:55.300 --> 00:18:58.584 it be there. But today there are so many options. 00:18:58.584 --> 00:19:01.800 You can manage the risk appropriately. Depending 00:19:01.800 --> 00:19:07.800 on the risk, you can take actions and it has become more of a continuous scale rather than 00:19:07.800 --> 00:19:11.916 a discrete scale of zeros and ones. But that 00:19:11.916 --> 00:19:16.500 said, I think you're absolutely right. Zero trust 00:19:16.500 --> 00:19:21.000 becoming so essential for organizations, identity 00:19:21.000 --> 00:19:25.500 fabric is the only way to take care of it because 00:19:26.400 --> 00:19:32.700 convergence of all the technologies into one singular fabric is the need of the hour. 00:19:34.100 --> 00:19:39.500 One of the issues that I see our customers struggling with, who have a lot of legacy 00:19:39.500 --> 00:19:42.016 solutions, they cannot get away from it because 00:19:42.016 --> 00:19:44.800 it's doing a lot of good work. It's been implemented 00:19:44.800 --> 00:19:49.800 over a period of time. It's not easy to get rid of anything in our kind of an industry. 00:19:50.800 --> 00:19:53.300 So they have to live with it and they have to do further work on it. 00:19:56.400 --> 00:20:01.000 The integration costs, what I call integration 00:20:01.000 --> 00:20:05.600 tax, that is burdening. Besides the technology 00:20:05.600 --> 00:20:12.300 part, the service element is becoming more and more challenging. That's another thing that 00:20:13.000 --> 00:20:16.066 customers we see struggling with today. Makes 00:20:16.066 --> 00:20:19.200 sense. So the final question is, how do we get 00:20:19.500 --> 00:20:26.800 from, help organizations get from wherever they are to this Mount Olympus identity fabric, 00:20:26.800 --> 00:20:31.061 everything works well together, federated, API 00:20:31.061 --> 00:20:35.600 orchestrated world? Obviously, it's not something 00:20:35.600 --> 00:20:39.317 we're going to do in one step. For example, I 00:20:39.317 --> 00:20:43.200 worry about some of the legacy systems that you 00:20:43.300 --> 00:20:50.000 just mentioned, specifically in my work with Active Directory and its cousin, Entry ID. 00:20:52.100 --> 00:20:56.400 The base, the core systems on which a lot of the identity management 00:20:56.400 --> 00:21:01.300 ends aren't necessarily very well maintained or very clean. 00:21:02.100 --> 00:21:05.950 And so, if you're built on a foundation that's 00:21:05.950 --> 00:21:09.800 a little bit weak, obviously the structure you 00:21:09.800 --> 00:21:15.400 build on top of it isn't going to be that great. But the basic question is, how do you, 00:21:15.400 --> 00:21:22.900 as a practitioner, help organizations get from wherever they are to directions towards the 00:21:22.900 --> 00:21:25.776 identity fabric? Any insights you can provide 00:21:25.776 --> 00:21:29.100 would be really helpful. Well, we truly believe that 00:21:29.800 --> 00:21:36.800 this has to be addressed through, there is not a single silver bullet for everybody. 00:21:37.700 --> 00:21:41.200 It depends a lot on where you are in your identity journey. 00:21:41.700 --> 00:21:46.400 There are a lot of organizations who have done investments 10, 12 years ago. 00:21:47.700 --> 00:21:52.300 Anyway, they also started believing that it's time for them to take a look at 00:21:53.400 --> 00:21:59.700 maybe doing one level of changes, if not completely replace the technology, at least 00:21:59.700 --> 00:22:06.400 look at some replacement elements. So, the technology per se has also to undergo some 00:22:06.400 --> 00:22:12.400 changes because you cannot stitch beyond a certain point something which is 15 years old. 00:22:15.200 --> 00:22:22.500 So, that extent to which they can make a change, if they have to make a change, 00:22:22.500 --> 00:22:31.600 is something that we recommend. We try to make it minimal because it's not very advisable, 00:22:31.600 --> 00:22:36.800 in our opinion, for large customers to make drastic changes in their technology, 00:22:36.800 --> 00:22:39.579 even though they're not highly satisfactory. You 00:22:39.579 --> 00:22:42.300 don't want to cost a lot of money and not get a 00:22:42.300 --> 00:22:47.600 lot of return. That's the classic challenge. You can't spend too much on architecture 00:22:48.300 --> 00:22:52.200 because then the business leaders are like, what did we get out of that expense? 00:22:53.200 --> 00:22:58.800 But at the same time, a moment comes when the cost of staying with the technology 00:22:59.300 --> 00:23:02.951 and doing band-aiding becomes much more than 00:23:02.951 --> 00:23:07.100 making a change. And the change has to be gradual, 00:23:07.100 --> 00:23:10.991 obviously, in an IAM kind of a situation. So, we 00:23:10.991 --> 00:23:14.800 recommend that when we look at an organization, 00:23:14.800 --> 00:23:17.987 we put the problems into multiple categories. 00:23:17.987 --> 00:23:21.600 One, technologies that have reached a point that it 00:23:21.600 --> 00:23:25.410 needs a change, and you don't have any other way 00:23:25.410 --> 00:23:29.300 but to do that. Two, technologies which need some 00:23:30.200 --> 00:23:37.300 amount of amendments, not truly a migration to something completely different. And three, 00:23:38.100 --> 00:23:40.952 certain elements that need to be brought in 00:23:40.952 --> 00:23:44.600 fresh. Now, what is going to be the proportion of these 00:23:44.700 --> 00:23:54.000 three is not easy to really decide. How do you find the IT and security people that are 00:23:56.000 --> 00:23:58.853 on that mission? How do they sell it outside 00:23:58.853 --> 00:24:01.900 of their organizations? Whatever you're talking 00:24:01.900 --> 00:24:08.400 about will cost time and money. And a lot of people with the money don't really understand 00:24:09.200 --> 00:24:13.107 this identity fabric and the need for it. Any 00:24:13.107 --> 00:24:17.100 hints you can give people on how they sell it, 00:24:17.100 --> 00:24:20.800 how best selling it, outside of the IT and security groups? 00:24:22.300 --> 00:24:25.614 Yeah, I can tell you the way we are looking at 00:24:25.614 --> 00:24:29.000 it, and I look at it, rather than talking about 00:24:29.000 --> 00:24:35.600 concepts like identity fabric, which many customers don't understand, we talk about their 00:24:35.600 --> 00:24:39.150 problems. For example, I was talking about how do 00:24:39.150 --> 00:24:42.700 problems really come today? Any solution requires 00:24:42.700 --> 00:24:46.073 three or four different modules. If you look 00:24:46.073 --> 00:24:49.600 at orphan account management, typically we see 00:24:49.600 --> 00:24:52.633 you need access management, you need portions 00:24:52.633 --> 00:24:55.800 of IGA for sure. If you're talking about orphan 00:24:55.800 --> 00:25:01.600 accounts in the cloud, you need CIEM. Anything requires today risk management, so IRM is 00:25:01.600 --> 00:25:04.948 required. Now, if four different modules are 00:25:04.948 --> 00:25:08.600 required to solve one problem apart from account 00:25:08.600 --> 00:25:11.436 management, then how do you do that? Because 00:25:11.436 --> 00:25:14.400 you cannot do it with four different pieces of 00:25:14.400 --> 00:25:17.230 software that you have procured. So you need to 00:25:17.230 --> 00:25:20.300 do some stitch, or you've got to look at a singular 00:25:20.300 --> 00:25:22.621 technology that can integrate all of it, like 00:25:22.621 --> 00:25:25.200 the converged technologies are beginning to become 00:25:25.200 --> 00:25:28.500 available, as I said. So we go from the 00:25:28.500 --> 00:25:32.900 solution angle rather than technology angle, because 00:25:33.700 --> 00:25:37.300 concepts like fabric are still, as you rightly said, are not so well known, 00:25:38.700 --> 00:25:42.400 even in organizations who have been there with IEM for a long time. 00:25:43.200 --> 00:25:47.200 Yeah, we certainly can't expect the business leaders to know anything about it. But 00:25:48.100 --> 00:25:51.676 yeah, it's an ongoing challenge. How do you 00:25:51.676 --> 00:25:56.000 invest from an IT and security perspective such that 00:25:57.000 --> 00:26:02.400 you're ready for when the next business initiative hits, or you're ready when the 00:26:03.000 --> 00:26:06.858 explosion of AI agents comes on the scene. And 00:26:06.858 --> 00:26:10.800 getting ahead of that curve, I guess, really is 00:26:11.000 --> 00:26:13.800 what the Identity Fabric is all about. Laying 00:26:13.800 --> 00:26:16.600 the groundwork, laying down the architecture, 00:26:17.600 --> 00:26:20.671 laying down the approach such that when the 00:26:20.671 --> 00:26:24.100 next thing comes, you can essentially plug it in 00:26:24.100 --> 00:26:28.403 without a huge level of investment and change. 00:26:28.403 --> 00:26:32.800 Well, any final comments before we sign off and 00:26:32.800 --> 00:26:36.538 give the listeners back some more time? My advice 00:26:36.538 --> 00:26:40.200 as a practitioner for 25 years of this domain is 00:26:40.200 --> 00:26:43.472 that times have never been more challenging 00:26:43.472 --> 00:26:47.200 than now. And any investment a customer thinks of 00:26:47.200 --> 00:26:55.300 making has to do it very carefully. A lot of things are blurring at this point in time. 00:26:55.300 --> 00:27:00.400 On one side, you've got solution providers who have been there for years together, 00:27:00.400 --> 00:27:05.000 and they have a lot of stability in their solution. But on the other side, you also have 00:27:05.600 --> 00:27:11.300 newer players who are offering solutions which are very agile, but they're not yet proven. 00:27:12.500 --> 00:27:15.381 The crux of the matter is to be able to study. 00:27:15.381 --> 00:27:18.200 The customer has had to never study more than 00:27:18.200 --> 00:27:24.800 what they need to do today. You cannot just go and start acquiring technologies because 00:27:24.800 --> 00:27:29.900 you've got to look at your situation, where you stand today. You've got to look at what 00:27:29.900 --> 00:27:32.808 options are available and where things are 00:27:32.808 --> 00:27:36.200 moving. I think identity fabric is one thing that 00:27:36.200 --> 00:27:40.092 every single organization, whether it's an SMB 00:27:40.092 --> 00:27:43.900 with 100 odd people or it's a large corporate 00:27:43.900 --> 00:27:49.017 enterprise with 50,000 people, everybody has 00:27:49.017 --> 00:27:54.600 to look at it seriously. That's my last message. 00:27:55.300 --> 00:27:58.098 Yeah, I agree. It's all about the 00:27:58.098 --> 00:28:03.100 architecture, the plan, and having the 6, 12, 18-month plan 00:28:03.100 --> 00:28:04.936 so that you're moving from where you are to 00:28:04.936 --> 00:28:07.200 where you need to be, at least closer to the identity 00:28:07.200 --> 00:28:15.000 fabric vision. My final comment is, that's why we're here. That's why Kubernetes Full 00:28:15.000 --> 00:28:17.486 Analyst exists. That's why the European 00:28:17.486 --> 00:28:20.800 Identity Cloud Conference exists, where the topic of 00:28:20.800 --> 00:28:28.400 identity fabric and how to make practical investments to get from where you are to 00:28:28.400 --> 00:28:33.800 the vision of the identity fabric is going to be all over this conference. My final word 00:28:33.800 --> 00:28:35.996 and suggestion is that if you've never 00:28:35.996 --> 00:28:39.000 attended this event, please do. If you have attended 00:28:39.000 --> 00:28:47.600 in the past, please come again. Check us out on the web. Please join us for other events, 00:28:47.600 --> 00:28:51.492 live and virtual. Thanks very much, Vinod, for 00:28:51.492 --> 00:28:55.300 your insights. Thank you to the listeners for 00:28:56.200 --> 00:29:01.200 listening to us chat about the identity fabric for the last few minutes. All the best. 00:29:02.200 --> 00:29:03.200 Thank you so much, Mathieu.