Identity Orchestration Beyond User Journeys

Hello, good morning, good afternoon, wherever you are in the world. I'm John Tolbert of KuppingerCole, and today I'm joined by Marco Venuti from Thales.

Hi, Marco. Hi, John. Thanks for having me. Very glad to be part of this conversation today.

Yeah, we're glad to have you here too, because we've got a really fun and interesting topic to talk about today. Identity Orchestration Beyond User Journeys. I think we've been talking about orchestration on and off for many years, and typically we think about probably that initial registration flow. But we're going to dive into it in more detail today. So a few logistics things before we get going. Everybody's muted centrally, so there's no need to try to mute or unmute yourself. We have two poll questions sort of scattered in here.

We will ask you to take the polls, and then we'll look at the results. You can submit questions for us at any time. There is a tab for questions, and we will take those at the end. And then lastly, this is being recorded, so the recording and the slides will be available in a couple of days. So with that, why don't we just start with a poll? I think it would be really interesting to find out how would you describe your identity estate today? Is it mostly siloed? Partially integrated? Are you moving toward a unified identity fabric?

Or do you feel that your organization is fully unified today in context driven across all the identity types? So the poll should pop up, and we encourage you to share your knowledge with us. So feel free to do that at any time, and we'll talk about that shortly. So let's think about our environments today. We did the same poll not too long ago, back in May, and here were the results. You can see that about half were partially integrated, and then say a quarter each mostly siloed or, you know, slightly less than that, moving toward a full identity fabric.

But nobody really felt like they were, you know, at the pinnacle of a fully unified identity fabric. Any thoughts on that, Marco?

Well, yeah. Well, I have to say that I'm not that surprised. The identity fabric notion has been around for, I believe, four years now.

And again, it was introduced by Kupinger Coal. It makes a lot of sense. It's clear the value it brings. Today we will explore a bit better what is the notion of orchestration within the context of the identity fabric. But we are still definitely in its infancy in terms of adoption. And that's probably the reason why we are spending time and asking people attention to elaborate on that. Because we are not yet there, and it will take a while maybe even to disseminate the value of the fabric and the approach of orchestration in that context.

Yeah, I agree. So far, our results here are 60% say they're moving toward a unified fabric and 40% roughly say partially integrated. All right. That has changed a lot, yeah. So what do you think the identity environment looks like this year?

Well, every year I like to distill what are the good, the bad and the ugly side of identity, right? Of course, quoting a movie I'm very fond of. And every year things keep changing. On the good side, we are assisting to a positive evolution, a positive trend in what is the adoption of identity solution to harmonize the way controls are implemented through a multitude, hundreds of applications that any large organization is dealing with.

Though on the bad side, many of those applications are lacking modern standard support, which is, again, the OIDC or the scheme, et cetera, and the like, which is making things harder than what they should be. Of course, legacy application, but even interestingly, some modern ones. And maybe still on the bad side, the identity component themselves are still not providing a unified perspective across the spectrum of different identity types that they are managing. So this is, to me, a definition of bad.

And then, of course, there is the ugly one. The ugly one is a very recent introduction. The entire identity industry has been dealing with carbon-based humans, carbon-based beings primarily over the last 25, 30 years. And now all of a sudden we have an urgency emerging, which is introducing the notion of agent security, which found the industry unprepared. So most vendors, including us, are indeed evolving very quickly what is the next step in the controls and in the solution to address those emerging needs. Why is that ugly? Because it was fast.

And so it didn't benefit of the same time for organic evolution, so to speak, that we had the luxury to have in dealing with human identity before. So that is a very high-level, 10,000 feet overview of what is my assessment of 2026.

Yeah, you make a good point there. We've been calling the last one NHIs, non-human identities. Maybe we should call them silicon-based identities or SBIs. Yeah.

Well, you know, that's interesting, too, because you think about we've had NHIs for a long time. You know, think about service accounts. But we always have treated service accounts like they're people. Yep. And that in itself is problematic. Yeah. And to this day, you still have indeed the NHIs, the workload identity, the very important distinction again, and then the agents. And depending on who you talk to, agents are considered closer to humans in terms of nature of the control you need to implement or closer to service account.

I'm more inclined about considering them similar to humans in many ways. If it wasn't, they are much faster. And while a human, if overprovision, being lazy, doesn't necessarily exploit all the provisioning and authorization you have, an agent definitely will. So it poses an all new spectrum of urgency and control required to make sure that is never overprovisioned. But this is maybe part of other parts of the conversation later on, even today and in other dedicated webinars. The subject is, of course, mainstream.

And I think you at Kupinger Cole just had in Munich two days ago, a very nice event, the Identity Fabric Impact Day, which was, again, another clear demonstration on how the relevance of the subject is. There was a significant number of companies represented there because that's top of mind. I think I'm not saying anything new here, but it was yet another validation on how important that is.

Yeah, thinking more on the NHIs, you know, there's also the broad category of machine identities. And, you know, those became important many years ago, too, because we realized there was a security benefit to, let's say, linking particular users to particular machines. We can raise the overall assurance level of a session. So yet another kind of NHI we've been working with for many years. But they're really kind of coming into their own as a special class of identity that needs to be treated differently than the way we've been treating them before. Yeah. Yeah. And we're not finished, probably.

Right. Again, the definition of non-human includes, even to me, organization. So in the context of B2B, we had the pleasure to have a webinar together on the subject. When you look at B2B, you have now constituents that you're dealing with, which are organizations made of people. But you need to treat the organization as a first class identity, again, in turn.

So, again, there is a very extended notion of identity, especially about non-humans. That is maybe more nuanced than what most would think about.

Yeah, that's a great subject in itself, too. You know, we've been doing KYC, know your customer, on the consumer side for years.

KYB, know your business, is also increasing in importance. There's lots of attributes that can be collected and evaluated.

And, you know, it's not even on the consumer side. But if you think of supply chains and wanting to get the organizations within your supply chain, that's a consideration that I see becoming increasingly important. So here's a good question. How many identity products does your enterprise run? And I've tried to include all our favorite acronyms or some of our favorite acronyms from the identity world. And as you can see, I'm trying to indicate that we've got sometimes more than one.

And especially if you're in a company that's maybe purchased other companies and you have to try to integrate those, you might wind up with multiple copies or, you know, different vendors. And you have to figure out how do these things work together. Yeah. And last time I checked, there are 12, 15 categories of identity product. So it's indeed on average six or seven components that an average company is running. The larger the company, the higher the number. And this is defining to me the identity layer on top of the business application layer.

Of course, this is what identity is there for. But we've built on top of them another architectural layer, which is the identity infrastructure, which is what we see here represented. Where each of those boxes might have a different degree of maturity or maybe some notion of depth with respect to the required capabilities and functionality it should deliver.

Which is, of course, as you depict here, over complicated by merger and acquisition that introduce duplications and now also drives the needs for later consolidation very often. I think this is a very abstract, but still very relevant representation of what reality is like for each of us looking at the identity infrastructure to have an understanding of where the technical depth is in the distribution of identity component operated to implement the required controls. I like the fact in this slide that IGA is red.

I think it's kind of ironic and this is kind of a joke, but I'm not aware of any single company which is fully happy about this IGA solution. It feels like it's impossible.

But again, by the way, SIAM as well. So that's very, very good catch that those two are maybe highlighted as red, meaning with room for improvement for many, many, many organizations.

Yeah, you know, you don't even have to be in an organization that's acquired another one. You may have been in one that decides, you know, we need additional features. So we buy a second product with the intention of running them in parallel and eventually retiring one. But that period of interoperability can be many, many years where they have to learn to coexist.

Yeah, yeah. I mean, a running joke is that on average, an organization is running any identity solution for roughly 10 years.

OK, this, by the way, was also the subject of Martin Kupinger on stage at EIC last year. Right. So what is the lifecycle? How long before you replace it? So it's 10 years before you replace something. The average marriage in my country lasts seven years.

OK, so again, to pick an identity solution is a long term commitment that should be carefully evaluated. OK, so it's not a trivial decision. There are consequences to those decisions. Yes. Many. So we've said orchestration. Let's let's look at it in some more detail. Yeah.

You know, here that same set of representative systems. And there are many others that you can think of.

I mean, like even within access management, you can have discrete authentication and authorization services, for example, or IDV identity verification. But how do these things work together? Because an access management system that doesn't interoperate with IGA or PAM isn't really giving you the value that you need.

And again, that's indeed the question and maybe the driving subject for for what was originating the conversation today. Right. So those components are now leaving isolated one another.

They, yes, are there to provide to implement controls, different sort of controls, runtime, admin time controls for humans, for machine. But they are required to interoperate or to integrate one another. So we just discussed that each of those boxes might have some notion of technical depth. But what we lately understood better than before is that very often there is another notion of technical depth, which is not in the boxes, but rather in the links in the way those integration are performed one another.

Now, in this picture, it feels like everything is connected to everything else, which is not necessarily the case. But usually you have a fairly complex mesh of integration that evolved over the years performed by the system integrator that deployed that solution of some internal team. And that resulted into, again, a meta level product and integration about identity product, which is not a product.

OK, is a set of controls and with technology, with interfaces, with contracts that need to be respected in making those solution working, which is not subject to the same lifecycle. Which makes that notion of that particularly relevant and risky in managing and having a resilient posture in your identity infrastructure.

So, again, my take is we've been obsessed about the component, the module, we might have overlooked the relative importance of the integrations among them. Yeah, you know, and I think we use the word integration almost too loosely, because it's if you think back on the history of identity systems and how difficult it has been to get them to integrate.

You know, you also mentioned interfaces. I remember a time when all interfaces were custom. Many of them were proprietary. And there were people that were dedicated to maintaining these interfaces between systems.

You know, if you're a really large enterprise, you probably had multiple directories of different kinds. I mean, not just LDAP. And then that needed to connect with the HR systems. And there was all this manual work around automation, believe it or not. And I think that's what we mean when we're talking about technical debt here, too.

It's much, much more deeply ingrained and older in many organizations than we probably even know. Yeah. And then talking of interoperability and standard, we also had some interesting phenomena, such as standard which never took off and maybe were not appropriate. I remember SPML, for instance, for those of you online old enough to remember that.

Well, nice try, but didn't go very well. Or maybe you have at times the opposite problem. In policy-based access control, you have four or five standards. And if you have four or five standards, it means that you have no standards. So it means there are too many for converging and leveraging a single one. So it's indeed an open conversation and ongoing part of the evolution that as vendor and member of community, which are trying to evolve, the posture of the identity infrastructure is still not fully... there's no end of it, of course.

And with some interesting, indeed, episodes to keep in mind not to do the same mistake again in the future. But we're definitely not there in having full standard support to provide a standard-based integration among all identity components, for sure.

Yeah, we do have many tried and true standards that we've been using for many years. But, you know, it feels like we're sort of on the precipice of a whole new level of standards work to deal with the NHIs and AI agents that we were hinting at at the beginning.

Yeah, yeah. With some nice names such as PFI, WIMC. And the name is very nice. Okay.

But again, there are indeed new standards emerging specifically devoted to that. Yes. Exactly.

So, question, why does every program in identity wind up here? You know, you've got competing goals, I guess I would say. Everything from trying to find something that works the best for you, of course, keep the cost down. But then also deal with vendor risk because CISOs don't really want to manage hundreds and hundreds of contracts.

Yeah, yeah. That's indeed the dilemma of the architect of their identity responsible in any organization whenever they need to evolve their solution, their solution, the overall identity solution. And I'm still here talking of solution to be acquired so that the buy, not the make. Okay. Which would be another probably level of the same conversation and another dualism make versus buy.

But looking at the buy, to buy time and to be faster in implementing those control, of course, every time you are looking at another component to replace what you might have or to fix a gap, you still feel to be having and you need to balance different objective, three of them. And we're having this conversation because the three objective cannot spin being cogs and this slide cannot spin at the same time. You can only spin two of them. They jam one another. You might be picking the best, looking for the best fitting solution. At the same time, trying to reduce the vendor risk.

There is always a vendor risk involved, whichever solution from any vendor you pick. And of course, minimizing the integration costs.

Though, if you pick the best fitting solution, you're likely to be required to integrate that and depending on which one you have your vendor risk might be lower or higher. At the same time, if you pick a single vendor with a unified solution. This is by definition, not necessarily the best in each and every domain is likely to be suboptimal in selected capabilities. Okay. And anyhow, the vendor risk is spiking again. This is the conundrum. This is what each practitioner in identity and organization is trying to balance and different people have different Preferences.

Okay, but nobody starts Greenfield, you don't have the gluttony. And by the way, there's no such a thing as a vendor. I can name one but doesn't need there is no such a thing as a vendor that does it all. That provide all the components that a modern identity infrastructure required.

So that's an interesting Root cause or original sin, so to speak, of why an identity infrastructure is intrinsically fragmented from multiple vendors from different component which requires an integration, which requires to be maintained and we're back again to the gap between in the links, not in the in the components that we discussed before Yeah, I can confirm what you said about no vendor does it all and working on the identity fabrics leadership compass right now and some do more than others. But like you said, even for those that have Nearly complete lists of functions and features.

There's differences and how they do it and maybe how well they do it. And then also, does it really meet the requirements of your particular organization. So almost always, you're going to wind up with the need to interoperate with other components within an identity fabric.

I mean, that's what identity fabric means and So standard support easy ability to integrate and then orchestration really become very important, just as much as the the individual functions that compose a identity fabric product to An orchestration is indeed A keyword for this presentation and in general for the fabric for the fabric motion. So, Why is nobody fixed this already Good question.

Okay, probably because there are so many domains to be addressed that it takes a while to even spot them before being addressed. But I like this claim.

Indeed, the, the, the, the architecture of your infrastructure is probably a reflection of your org chart and meaning that When it comes to integration, by definition, there are multiple parties involved. Why we have a clear notion of ownership of who owns Siam who owns identity governance and keep rolling depending on where you are. How about the integration between the two. Okay. It's a mutually owned thing if something is mutually owned. It feels like The analogy I made with if you have five standard, it means you have no standard.

If you have somebody something mutually on means that nobody owns that. So you might have an ownership problem when it comes to integration among identity infrastructure components.

Yeah, you know, previously I've been in organizations large organizations where It and it security services are centralized and I think there are many advantages to that where you can have your, you know, your general it security people working alongside your I am crew, but it's not always like that, you know, if we go back to the whole mergers and acquisitions, you sometimes wind up with Business units that can be fairly autonomous and yet there is a need for some degree of centralization, or at least using shared services.

So this is one reason why I think you often see, you know, if you think back to the earlier diagrams with blocks, you will see even multiple access management products that have to learn to get along with one another. You know, maybe multiple in different kinds of directories and it's not only just LDAP.

I mean, when you think about like the CIM world. You may see people using SQL databases know SQL databases for storing customer information and then you need a layer over the top of that that can help with the access management. Including things like authorization, which, you know, has for many, many years been you know what we might call the last mile because it's so difficult to To handle authorization.

I mean, you mentioned that there are four or five. I won't say competing but four or five different standards within authorization.

I mean, I feel like we're at the point where we're doing a pretty good job with authentication. But even authentication can vary, you know, in a very complex organization that maybe is made up of multiple companies. You might see different authorization services being run by business units drawing on different directories and of course having different authorization requirements to so You can see the reason why silos have grown up and can be very hard to break down or even get things to work together.

Yeah, yeah. Perfect analogy. There's no IDC for authorization right at this stage equivalent. So it's still not not spread and not mutually adopted as On what authentication is now authorization is nowhere close. We still have the dualism of static admin time provisioning based for, of course, for legacy application, the IGA connectors and propagation story.

We have an emerging trend driven by the zero standing privilege vision right to come to continuously evolve to a more Secure and not static and runtime and context that the right authorization level, which is now catalyzed by the agentic securization. So it was there already, but now it becomes more relevant than before. Because before was a best practice now is a must.

Okay, because of agentic so it will be accelerated. But again, we are not. We are still assisting to A gentle slow adoption of that and it's still probably what is going to be part of future conversation because I truly believe this will be The core subject for in for moving the needle in the security posture for securing agentic but also as a consequence also making a better job on human authorization as well.

You know, one other thought I have about the org chart here is thinking about organizations where Maybe correctly.

So the central IT organization will say authorization is a business function because it's the people in the business that understand What the policies should be and who should be authorized to get access to what But I think that also greatly complicates how you do identity in those organizations, because if you Sort of give up some of the central control and try to push that to individual business units, you can easily wind up with not only multiple solutions, but multiple interpretations of what policies should be in the first place. Yeah.

That this is the implication of having a scatter and lack of governance on what the rules and the policy should be like So I think this was a really interesting idea that you had about let's talk about orchestration and what do people really first think of when we Say the word orchestration. I think what first comes to mind is, you know, the initial user registration, because this is probably the easiest one to picture. It is a flow. We know there are various steps to the flow.

So yeah, talk a little bit about Identity orchestration and more typical use cases here. Yeah, I mean the notion of orchestration initially was starting to properly name that as user journey orchestration was a way To model and capture and define flexibly what the onboarding flow that we see here represented or the authentication flow or the password recovery flow or the Progressive profiling human interactions were model flexibly in a visual fashion to adjust the deployment time to capture the the user requirements.

But also to evolve more flexibly without coding and having a visual approach, which of course helps. So there was a kind of an intrinsic binding of orchestration meaning user journey orchestration. That's very Limitative in terms of understanding on what orchestration might means in the context of a broader notion of identity orchestration.

Where my even apply if there is no human in the loop that most interesting part of what identity orchestration deliver is not even involving a human Is around brokering integration among components where those components can be identity components and we are addressing now the link The technical depth in the link that we discussed before or or being the place where You have policy implemented to because every orchestration flow as branches as decision which in terms means that left and right is defined by a rule by a policy by Variables and attributes and context information that define that that trigger so orchestration was sold a bit sold was understood a bit Limitatively as a user journey is way more than that modern orchestration solution can also do user journey orchestration, but are not limited to user journey.

And even thinking about, you know, this more introductory test case of User journey orchestration. Think about how that's grown more complex over the years, you know, a sign up used to be a sign up where you might create a username or user email address, you know, now post GDPR consent is going to come up front. Due to fraud and cyber crime. We need to do IDV. We need to increase the identity assurance levels, depending on your use case, you might be subject to anti money laundering laws, you might have to throw in a step here. And of course, there's authentication.

So we've added steps or we've added the need to be able to provide extra steps for organizations that that do need to do this. Yeah, and each of those steps as a visible in the context of user journey that we're talking in this example as a visible human part that you the screen that with the human interact But there is a back end side of it, which is the interaction with the selected component that deliver the service to keep going to the next phase.

And yes, there is indeed an evolving number of tools or modules that you need to to compose to build the flow according to introducing consent right level of identity verification liveness detection deep fake, etc. And, and this brings me back to the contract of the integration. So if you need to swap a vendor to pick another solution for one of those components, say the liveness detection in my example now. You need to be able to do that without disrupting the overall perception of experience that you're delivering.

So that's where an orchestration solution can be a sort of Way to isolate to to manage that abstraction from the service in this case liveness from the overall capability that you are architecting in the orchestrated flow. So yes, there is a human interaction. There's a lot of beginning direction and the job of the orchestration flow is to make it intelligible understandable, but also flexibly amendable faster than otherwise. That what otherwise other approaches would would entail Yeah, you know, we're trying to keep it simple on our diagram.

But, you know, there are many other steps that we could add here. I think it's interesting you talk about breaking out liveness detection from IDV itself and And really, one thing I like about this diagram. Is there a lot of orchestration products today sort of take this very view. It is a flow chart.

I mean, that's what I call it when I'm writing it up. This is a, you know, a drag and drop flow chart where you as an identity administrator in an organization can You know, look on on one frame and pull in the different steps that you need double click on it, edit it. And hopefully, just as simply as that, you know, plumbing a new lives detection service that gets called out of that IDV function.

Yeah, yeah, I'm making that distinction because again when it talks to identity component and swapping There is a spectrum. I pick the liveness detection, because it's an easy one to be replaced with another one. API might be different, but that's what the orchestration layer is shielding the rest of the workflow for. It's a very different conversation. If you need to Replace your IGA solution. The complexity there is that is different is a different order of magnitude is not as simple. Okay.

So is, again, I just want to be clear that is now that an orchestration solution is now inevitably intrinsically making much faster in days, the swap from one governance solution to another. No, that's not what I'm saying. I'm just saying that foster a discipline of the way you integrate those components one another to at least reduce the complexity that you're dealing with. So some other examples of orchestration that go a little bit beyond what we're just talking about here.

And thinking back to administration days, you know, one of the things that used to be pretty hard to do is connected IDP to assess or, you know, federate Between members of the supply chain, you'd have to exchange information about your SAML endpoints and build all that manually and it could be quite cumbersome. But here we've come up with a few other examples. What are your thoughts on orchestration beyond that initial user journey orchestration.

Those are perfect example in the to expand beyond the user journey because of, for instance, the first one is about contract orchestration, so to speak, or making sure that you have the proper translation on protocol and token translation, depending on what the endpoints are involved. So there's a notion of proxying, which is usually the word we use in this context that that can be well be modeled within an orchestration solution as part of steps and built usually modern solutions built in nodes that are helping in making it faster than manually created.

Attributes everything related to attribute lookups attribute propagation is of course identity related is not necessarily human interaction related can be triggered by a human interaction can be triggered by signal by events by schedule task. As l check of the posture of the relative value of attribute whenever an identity is amended where we are another even though the human is not necessarily present in front of the screen. And then we saw and we elaborated before around identity verification or more in general, the notion of validation that you need to have it on board in time.

Is never is usually never a single flow. It depends on the level of trust of the provenience of the users, different countries, different company B2C and B2B. So you need a decision of which is the most appropriate flow to follow.

Well, in this case, there is a human interaction because we are ultimately presenting a verification flow, probably to a user, but the definition of which one is the one to pick. Is in itself a process with no human involved out of contextual information in terms of provenience in terms of security information and signal and that is to be defined to be managed and to be able to over time.

Yeah, I think we can't gloss over the one about normalizing attributes. I remember working with government consortiums in the past. The classic example was, you know, one one organization calls this a fire truck. Another one calls it a fire engine.

So, you know, you can have different names for the same attribute. And if you're trying to federate across the supply chain, then that's really important to work that out and work it out automatically so that you don't have to pay somebody, you know, to get that right to do that normalization for you. It needs to happen automatically. And then I think you make a really good point, too. And it's kind of reflected in that last red box about route by country on IDV. IDV tends to be very country specific in many places around the world.

So there will be authoritative identity providers that we need to be able to work with. And getting that right in your registration phase is really important. If you want to, let's say, sign up consumers, you don't want to cause them any undue friction in a case like that.

Yep, indeed. There's lots of information that can be harvested, you know, usually through SDKs or maybe APIs for security decisions and then delegated admin and consent propagation. Anything you'd like to add to these?

Well, device registration to me is a perfect example of a non-human identity that matters more than before. So your silicon avatar that is always with you has a reputation in itself is part of the security context that defines you. So it's indeed providing signal on where you are, but also has its own history. A device can be, again, with an interesting past that define it intrinsically insecure. And that's part of the checking in risk management that you might want to check.

But again, the third point, you need to enroll and manage the life cycle of the binding between a user and the device. That per se is already a flow. Another notion of a non-human identity involved is that, and we're back again to the business to business with delegation management, is that in delegation management, you need to onboard companies and you need to onboard users belonging to that companies. And some of those users are delegated manager.

So this is probably, in terms of user onboarding, the highest peak of complexity that today identity on human entails, because you usually have, and we're all familiar with, human coming from the HR system when they are an employee or human register when they are consumers. The B2B is providing this extra layer, which is a company registration and then a human belonging to that company registration. And I'm still talking human. The same applies to agents as well, of course, nowadays.

But yes, something to be modeled, something to be defined and orchestrated. Why that? Because back to my ugly good, the bad, and the ugly list. There is no such a thing as a product that manage today natively in full this dualism of the life cycle organization and members of that. So you orchestrate that and you create the flow depending on your specific need.

Consent, just to elaborate on that as well, is a specific case of attribute propagation or propagation to system which are not necessarily the usual suspects for provisioning and deprovisioning. But in this case, other nature of marketing analytics tool where consent is instrumental for, of course, what you can now notify a user about. But it's indeed where the integration and the payload, the transformation back to your analogy of calling things the right way, kick in and need to be to be mapped and transformed before being delivered.

So those are technically speaking, going to identity orchestration processes right in a in a in a in terms of nomenclature. Okay. And what identity orchestration is about.

Yeah, having done the leadership compass on B2B, I am earlier this year and I can say for certain that delegated administration is a really key feature that large organizations in particular are looking for because They do have to orchestrate functions across, you know, multiple organizations, especially if you're in a big supply chain, maybe, you know, there's so many different kinds of organizations out there. Some might have hundreds or thousands of contractors.

And it's not really reasonable to expect somebody who sits in the prime company to to know the attributes and be able to vouch for the employees or contractors or even You know, temporary gig workers that we see that need some kind of access, you know, they maybe they don't need a long lived account, but they need You know, a short term set of entitlements that enable them to perform those specific tasks and again without delegated administration and and without that being implemented in an easy to use way, it can be very difficult to achieve the business aims that you have Yeah, yeah, absolutely.

It's quickly unmanageable, it's overwhelming. Delegation is instrumental to distribute or to release, relieve from the centralized control the approval, for instance, the human interaction approval. And that's what delegated administration is about is when a human is required to make the final call about an authorization decision on somebody else. In a few years from now, we will be in a different world where those determination will be automated by contextual decision. The human will be removed from the chain of approval.

The notion of delegation will still be there, but without the nomination of a delegated manager, because that will be part of the fabric of the texture that deliver the access. That's maybe interesting for a future webinar.

Okay, to be further elaborated about You know, and I think we can undersell consent propagation to, you know, again, if you think back to the previous slide with the I mean, we were about what eight and a half years post GDPR implementation. So we think often in terms of GDPR, but now many other places around the world have different regulations for privacy. Many of which require the collection and proper treatment of consent, but those implementations need to vary because the regulations vary around the world. So you need to know where a user is coming from.

So you can orchestrate the right consent journey. So I feel like we've been building up to. And of course, we have to spend a little bit of time talking about AI agents. So where do AI agents. How do we orchestrate AI agents Marco Well, good question. If I had the full answer already, probably I would be the only one. Okay.

So again, the subject is still cooking and is evolving as we speak in each and every buzzer. Okay. And that's why that's why you have daily news about evolution of product reference architecture approach. But in the context of orchestration in the context of identity orchestration. The key message is that there is a lot of control and extra level of assurance that you can implement taking the most of the existing infrastructure you already have without buying anything is not by about adding components is about improving the integration among them.

And when it comes to to agentic AI, of course, the composing a bit. What is the key touch point that they go through, of course, there is a notion of That intent need to be captured and need to be mapped and need to be involved the human to make sure, first of all, that they have a real human behind expressing that intent and not another agent in the first place. And to make sure that they capture that link.

Okay, so the intent based authorization is what is now is emerging is not about orchestration per se the evaluation of the appropriateness the yes or no. Yes, you can go.

No, you cannot go is still a policy that is managing a policy engine in a feedback component in equivalent of what today we call feedback. But how do you loop in the brain, which is the centralized policy model of the feedback in the context of the now agentic interaction with human and among agents that were orchestration kick in.

Because it can flexibly allow you to model the human interaction and the agent to agent interactions to be subject to the fences and to the approval that is central instead of policy defines That the key part here for an and five are where indeed the, the root, the root, the core of the controls for agentic, in my opinion, are so intent based access control. Is is what benefit greatly from a proper adoption of orchestration solution to put the pieces together. We might already have in my example here. If you're already a payback solution. That's the perfect tool for the job.

You don't need to buy another tool. Okay, for, for, for that very, very neat. I'm trying to keep it well to my standard short because I feel we are maybe a big running long john so I Oh, we're, we're fine. I just want to add, you know, intent is interesting. I think there's some nascent work that's going on there. And D provisioning is an important piece to I think back to the yes the talis executive survey that we talked about earlier this year, you know, if you don't be provision accounts. This is an element of excessive risk, really.

So that's another real driver for orchestration across not just a agents, but the human identities as well. Absolutely in two ways. First of all, because it can be a control point to automate the provisioning or to make the provisioning happen. But it can also be the way by which you remove the need for the provisioning in the first place. We're back again to the zero standing privilege. If you implement and if you have systems already, which can be subject to a zero standing privilege approach.

Well, the provisioning doesn't even apply any longer or applies only to account, but not to entitlements because entitlements are not statically there and not be required to be the provision because they are injected on the fly session time So that indeed also part of the of the conversation as well. So for those who are thinking about identity fabrics and how to buy them. How do you tell a good orchestration product from a demo. Good point.

Yes, because there are, as we said before, orchestration was born with user journey mind. There are still many solutions which are user journey based and I would say mature as soon as they are used in the user journey context only Not so much as you now look at the extended notion of a broader adoption for system to system integration or signal processing. We haven't touched on signal, but that Again, today, maybe to contain myself but signal processing and a semantic of signal. Signal is carrying what happened. But what should be happening next is in itself an orchestrated process.

Okay, so to to be the Reflected inside effects on third party system that sort of use cases are not user journey. There's no user involved. That's where the maturity and what you might want to consider in your scrutiny and evaluation should go.

So indeed, it should not just be about users. It should not just be about Connecting for single sign on or things like that, which are kind of a given and maybe is where of course is valuable, but it's just a fraction of the entire story. The key element is is control is to have a manageable solution which is not just visually pleasant in being in being used, but is also version and can foster the discipline of allowing for control of the lifecycle of the orchestrated process which is key. Then runtime and performance.

So, of course, the as as you don't just have users involved, but also signal and also system to system integrator that pose the next level in order of magnitude. More of questions around what performance level should be like.

Okay, because there are more more interaction more in general. Is nice to have a visual designer. Is that the key point.

No, it should be there, but it's not the key thing more and more we assist the to AI assisted the designer. So you still have the visual rendering. But you are no longer drag and dropping because the AI is building the picture for you. Okay. On what is the process that you are that you are depicting I agree, but I'm someone who reviews a lot of these products. I do like the visual designer quite a bit.

Yeah, yeah. I also like it too. I cannot read the too long.

Okay, I think each of us is subject to reading fatigue by AI so visual helps because it's, it's a more concise way to get the point from So I like the points you have here. What, what should people actually be looking for.

Yeah, again, the way I like to capture is by less integrate better. What do I mean with that. You most likely have already a number of identity solutions, you are most likely not caching the value they can deliver Which you would be caching if you were to integrate them better. The integration is key. The depth is the integration. And so probably an orchestration solution can help you get there, though I'm not strictly suggesting to buy an orchestration tool, although we just talked about that.

Again, as I say here fool with the tool is still a fool is not about the tool is about the mindset is about the process is about the discipline. A product and orchestration product should be seen as a mean to accelerate the implementation, but also to promote a discipline. Because the product itself is defining fences and approaches and best practice or now should be used To me, the analogy is just like when I sign up for a gym to work out. Can I just work out at home.

Yes, I can. But if I don't buy if I don't pay the gym my discipline is less I don't end up not working out So what I'm buying is not the gym access is the gym disciplines, the workout discipline is the same thing here.

Okay, so an orchestration tool is essential. No. Can I buy the code such a thing. I wouldn't do that because you end up by coding integration. If you want to buy the code by the code, the orchestration solution, not the individual orchestration. Individual integration.

Otherwise, you're back to square one in a managed uncontrolled and version integration gaps. Excellent point. So last poll here. What share of your integrations have an owner. And you'll see a few different choices. So in the few minutes we have left, feel free to take that poll and I'll try to jump back here before the end. But we do have a couple of questions. I can get the button to work. Let's see.

Do you feel the architects tend to default to the technologies and approaches, they are most comfortable with rather than change the modern tools and methods, even when doing that adds unnecessary technical debt. I, yes. Short answer.

Yes, I think is very human is to do with a human reluctancy to change. So that's an effort. And so that's also, by the way, very often why being familiar with the technology approach with tools of a certain topic for certain kind result into suboptimal usage of those tools for stretched use cases.

So, yes, I think it's part of what I define of the root cause for the technical debt that I commented on before. Yeah, I would agree. I think it's inertia.

You know, once you've got something in place, it's hard to want to change it hard to want to take on new tools, new standards. It's easier to try to adapt what you have often. So next question is, why would I want to integrate my identity services across different demographics, maybe use the same software. But is there that much overlap of identity types. No.

Well, I think that is a, I mean, apart from the IVP motion, which is on unified visibility on across the board, which would be an answer to that, to that point. No, that's not necessarily what I mean.

I mean, I might have suggested that we need to integrate system, even though they manage different tops types of demographics know what I'm what I'm talking is that when when you are When different components.

Are still requiring among them synchronization of policies of identities, or at least of attributes of the identity, but even often at policy or at least the notion of extended Join a mover lever equivalent implementation, a side effect on a given system need to reverberate another I disable a user from IGA is that user a privilege user that should be also disabled in the palm solution as well, just to make a simple example. In this case, we're within the same demographic.

Okay, so no, I understand what what the spirit of the question is probably a misposition. The fact that no makes no sense to blend them up and to and to have a cross demographics integration use cases, except for the IVP consolidation. Okay.

Well, the results on the last poll. What share of integrations have an owner about 60% say most of them. So that's encouraging.

Still, still plenty of work for us to do, though. Yeah.

Well, I wanted to thank everyone for being here today and thanks Marco for participating. This was a really fun webinar. I think you've set up some really good things for us to think about Thank you very much, john. It was my pleasure.

And again, while looking forward to our nest the joint delivery. Okay, thanks everybody for joining. Sounds good. Have a good rest of your day, everyone.