On Copeland, how we proceed within this webinar system, housekeeping. And then we will directly dive into the agenda. Cola is Analyst Analyst company. We are providing enterprise key research, advice, services, decision support, and networking for it professionals. And this, our overing are split into three parts. Our research services like reports, our leadership documents, which compare vendors in the specific market segment. Our advisory services, both end uses and vendors and our events. Our mainly when sites, all the webinars we are doing is our European identity and cloud conference, which will be helped. Again, next time in may and Munich it'll be held in May 14th, 17th Munich helps to see you all there. And I will provide further information by the end of the webinar on this, or just have a look at our website or ID com.com for more information about the IIC regarding the webinar itself, some guidelines.
So you are muted centrally. You don't have to mute or unmute yourself de control. These features. We will record the webinar and the recording will be available probably by tomorrow. The questions and answer sessions will be at the end, but you can end the questions anytime using the questions feature. If you go to webinar control panel, you will find a go to webinar control panel at the right side of your screen. Usually there's an area questions where you can answer questions. Okay, let's start directly our agenda for today, like usual split into three parts. In the first part, I will talk about the Analyst view on an integrated approach for privilege management and access governance. But I will also look at the areas where you still will need privilege management tools and the second part, then Marco annuity, VP enablement, of course, ideas. We'll talk about across ideas approach and integrating privilege management and access governance based on best practice.
Then in the third part, we will do our Q and a session. So when, when looking at this topic, what really drives this discussion, I think what really drives this discussion is the need we see, and the, the direct recognition of the need for improving our information stewardship. So really getting better in ensuring that information is handled correctly and correctly, especially also means safe and secure. And so we, we need to, to manage a lot of things. So the information lifecycle, we need to understand the business value, the architecture information quality, but also privacy and compliance and security and security is really one of the major concerns of organizations these days when it comes to information. And that means that all the systems which are dealing with information have to be matched in a way which mitigates the risk of information, loss, information, leak issue, especially of all the violations of good governance and all the issues around we could face around information stewardship, and there are several sources of risk.
And there's this part, there's a part of malicious activities like the coordinated attack, hacking data stuff, cetera, but there are two other big areas. One is misuse and one is mistakes. So one area start with the mistakes. The in the area of mistakes, the problem is accidental loss, exponential erasure, exponential disclosure in the area of misuse we have for, for instance, the use of privilege, but also curiosity cetera. And it's very clear. The more right someone has, the more elevated entitlements are the bigger the risk. And so from that perspective, if it's very important, when we, when we look at mitigating risk to understand, to look at how can we mitigate the most elevated risks for the highest risks at all, this is the area of, or the part of information stewardship I will look at. We have a very interesting report, our information stewardship for quite a while, which you might like to have a look at.
You will find it. Our website could be called of report. There's also by the way, a new report and privilege management art. And today, as I said, I will look on at this topic and when looking at it and information security and information stewardship, my major target always is to advise customers that they boots and design and implement solutions, which allow them to, to have a sustainable approach in place. So current situation we observe is that something goes wrong there, an audit finding, then customers switching to panic mode, invest a lot of money, fix a specific problem, particular problem, things go down again. And then when things become a little bit worse again, then the next audit finding occurs, same process starts again, panic mode spending a lot of money, cetera. And over time, it's far better to look for a strategic solution, which is sustainable as possible, which helps customers to, to really solve a problem once and then have all these issues.
The, the efforts around mitigating all is findings around addressing current problems, having them solve. I think that's a very important thing. And that is one of these areas where it's important to understand that it's better to have a more holistic view, especially when it comes to topics like access governance and privilege management access governance is one of these areas. We look at today's one part of this because GRC pictures. So GRC is governance, risk compliance and consist of a lot of disciplines like enterprise tier C it risk management, business, GRC, operational risk management, and very prominent in these days, the area of access S unfortunately, most organizations still handle these as very separate worlds, instead of trying to have one approach or GRC with various layers and type integration so that the access risks are shown as operational risks and as strategic risk as reputation risks also at the level of enterprise Tierst, that would be very helpful.
Tyler, doesn't sort of another story, but access governance is one of these important students within the broader picture of GRC. And it's really about enabling business users to request access, to manage access policies, to analyze the current status access, to understand access risk. And so more and more common architecture is to build an access governance layer, which integrates existing legacy provisioning tools, which interfaces to new types of provisioning systems to enterprise service buses, to service request management systems. And some cases also provides some integrated provisioning capability. So access governance really has one layer central point for enforcing access governance to handle all these, the entire life cycle from sort of creating and defining access and entitlements to requesting to recertification, et cetera. So that's what access governance does. There's some sort of common features like collection of entitlements and access. Warehouses recertification is a very important, very prominent feature access analytics, access intelligence, the role management aspect, access regress management, and capability to manage segregation of QT and the enforcement of segregation of duties.
So these are start of the common features. On the other hand, we have the area of privilege management or P XM tools frequently used the abbreviate abbreviation P XM, because when you sometimes talk about privileged access management, sometimes about privileged account management or identity management or privileged user management or whatever, sometimes it's also rooted con management. So the X stands for everything which could be between privilege and management. These are privileged management tools and they have some common features. One area is credentials. So storing credentials providing one time passwords change credentials providing singles and on another area is monitoring the logging of sessions terminal based and the video logging of graphical sessions restrictions. So future restricted unique self, and then the support for what some vendors qualification, identity management these days. So providing libraries and interfaces, etcetera, for replacing credentials, which you typically commonly still find and clear text and scripts and configuration files.
So it's really focused on handling access, handling these privileged identities, these higher risk identities. And it's also very much focused, but only focused, but very much focused on shared accounts. So the non personalized accounts, our, I think that's probably the most important slide in my presentation. When we look at, at this picture, then we have here two axis on the horizontal one. It's about personal accounts versus shared accounts. So that's sort of the domain of the classical privilege management, the vertical access we have sort of the standard privileges, the standard entire amounts, the standard access rights. And on top we have the elevated ones. So it's about sort of the standard domain of access governance and the standards. User accounts standard uses no elevated privileges, personalized account. This is something like this white spots in the lower left corner. However, if you look at different types of accounts, then we have technical accounts, which sometimes don't have that much elevated privileges, but they're shared.
So they're on the low, lower side. We have root accounts, shared, highly elevated privileges, the upper right side. And we have on the upper, the left side, we have elevated privileges, which are personalized. So windows accounts or active directory accounts, which have operate rights, which are entitled to do operational tasks or the SAP business warehouse power user, which is done on the business side. And what you see here is some of these accounts, especially the left side, these are not necessarily these ITF and our operator accounts. It are business accounts. They can be highly elevated. On the other hand, there are administrator operator accounts, typical it accounts, which also can, might be personalized, but are highly elevated. And if we don't look at, at other things like test development, et cetera, then some other aspects come into later also might be somewhat elevated. And we very, obviously also quickly end up with some segregation of QT conflict.
The British access can happen various ways. So someone can use this account, which has entitlements to a system which then uses a technical account to access. The next system. Someone can use together with others, a shared account, or someone can use an individual account with elevated privileges. There are different scenarios. These are soft. We major scenarios for privileged access. One of the indirect ones, you use a personal account or even a shared account to access a system which uses a shared because technical account or functional account, however you want to call it the shared account and the individual account. This elevated privileges, these are different scenarios, different use cases and to mitigate risks as part of our information stewardship, we have to cover all of them. And then the, the interesting question was when we look at the basic features of access governance, where do they provide benefits?
Where do they deliver value for P XM, one area sod. So define and identify segregation of duty conflict between privilege entitlements. So one simple example is the administrator of the production system maybe should not be the one who manage the test environment who manages or who's to developer itself. So development test production, that might be a typical area of ion of duty for segregation of duty, which another, you might say that for, for instance, the SAP administrator must not be the administrator of the spec below the SAP system. So you might say, okay, the, the guest operating system, and maybe even the, they have to be managed by different people than the SAP system, the same night of life or the database to ensure that they risks are mitigated another area, critical entitlements. There are entitlements which are per se critical, which need more recertification.
I come to, re-certification managing these critical entitlements correctly. That's the domain, which you, where you find support in support for, in your classical access governance. That's really where things become highly interesting where access governance comes into play. Even for privileged power, we have the area of access request management, how to request access, how to request privileged access, the best way to do it is to do the same way you use for any other type access audit. So how to provide an overview of which entitlements are currently assigned overall. It makes a lot of sense to say, I have one view for all entitlements, regardless, which title of titles are, why should I use specific tools for getting an overview about who is a privileged user and another for who is, and sort of business user with elevated privileges, which in fact is a privileged user.
It should be one place and access governance is a good place to do this. I clear your recertification, privilege users and privilege entitlements and entitlements each recertification. What is the place to do access governance? So there's a very good reason to look at access governance. Even when you think about your administrative, your operations, administrators, your operators, your developers, cetera. However, I think there's one big challenge. That's also something which where you might also be sometimes a little bit more blunt about, because it sometimes tends to ignore this point. There's a need for it thinking processes. So when we talk about segregation of duties, then it's about understanding which activities different processes have to be segregated from each other. We commonly use this duties indirectly. We are roles, or even at the entitlement level, but in fact, it's about which activities and which business process are or have to be segregated.
So when we define it process process, the same way we business defines its processes, then we are, we make a big step forward. As team management becomes far easier than we have a much better understanding for achieve and to the same for your roles. It, administrators also have sort of a business role, their business is it, this is their part of the business, and it must not ignore the need for describing itself and processes, roles. Cetera. If you do that, life is much easier when it comes to information stewardship, when it comes to mitigating access, risks, cetera, however, and that's slide, I've put in here for a good reason. There's still a need for specific P XM tools. So access going attached you, especially when it comes to the elevated privileges part when it comes to re-certification cetera. But this is the same slide of effect I had before with the core features of P XM.
These core features like onetime passwords to shared accounts, signals, sign onto privilege accounts, logging of sessions, feature restriction of sales, etcetera. These capabilities still are required. Access governance cannot fully replace need for privilege management, but it can complete what you really do. So when you do a traditional P XM process project program, you miss some P aspects. And that's where really, I think the story is about, it's about having a holistic view and understanding what do you, what do you do better with access governance? And where's the place for P XM tools and how do they integrate with each other? And I've a little bit changes, but it's a slide I'm using for, I think, four or five years right now around privilege management Truity level. So it's really one, one of the slides I'm using for, for pretty long time. And so there's there adopted to the standard CMM approach.
So there's the level initial, the risk is very high. You don't have a P XM at all. Yes. The level of repeatable. So it's still high. You have some basic points solutions. There's still a higher risk when you have some non-integrated P and point solutions, which cover the matrix issue issues, but leave a lot of things open, including all the access governance aspects, you reduce the risks when you have an integrated P XM approach based on the P XM suite, which then really works for your heterogeneous environment, covers all major features of P XM with some basic integration, sex governance, identity provisioning, et cetera, where you, for instance, and start managing the managers for shared accounts that every shared account always has an associated manager, which then manages the identity provision tool for instance. And ideally it's about much tighter integration of PX and with, or even into access governance, identity provisioning, and cm. So we really have to move forward to tight integrations to a solution which truly enables us to sort of manage both dimensions, the dimension of shared accounts and dimension of elevated privileges, both at a higher level and consistently, so really understanding where is X of governance, the better tool, where is P XM and where do they come together? So that's sort of my basic story right now. We'll hand over to Marco
And I, okay. Marco's your term.
Thank you very much, Martin. And thank you all for joining us today. Again, I'm mark Venki, I'm responsible for cross ideas of enablement activity and where today we have our fifth webinar along with Martin Kuppinger on identity and access governance and is relationship with other topics of the access control world. So in the next 50 minutes or so I will, I will touch a few topics. First of all, I will give you my perspective around the access control jungle, meaning the various domains and the various flavor that access governance covers. And we will touch on access governance and privileged user management, specifically the commonalities and differences and the benefits of an integrated approach. And that will lead us to what is cross ideas approach in that space and to conclusions. So talking of access controls, as I said, there are multiple ways to look at this notion, trying to put them together in one single picture.
We split between those access control types, which are more related to tracking and monitoring in nature or among those that are really around enforcing control and target system, or maybe just rather modeling than detecting the discrepancies with the expected status. And apart from this, there is another degree of variation, which is the integration that with the target system themself. So just to drop a first example, for instance, lock management is a clear example of tracking based approach with a span on a shallow integration or deep integration into target system while access governance, for instance sits on the opposite sides. It's a pretty light integration on target system is a pure modeling approach. And that's where we play with our identity and access government solution. Or at least we partially play given that at least for cross ideas, we are one of those identity and access government solution already available on the market.
So also playing in the identity space, which originally is meant to be kind of sitting in between the enforcement and the modeling space. Well talking of privileged user management of P XM, as Martin mentioned, this is really in our view and enforcement layer. This is obviously as a modeling component, but the key things, the key capability are really around enforcing the access level at a very granular way. We are tracking capability with modeling capability, but still pretty much focus on enforcement while the feature can be overcomplicated with many other boxes. Just to drop a few example, we are already touched in previous webinar. What is the relationship between access governance and other domains, like for instance, dynamic authorization management, for those of you who may be interested in the subject, I invite you to pick the recorded session out of the webinar list on the co your site.
But today we're gonna look at the relationship between these three spaces, access governance, identity management, and privilege user management. We are no, I believe over at least, or like me belonging to this market since quite some time that there are multiple names for pretty much the same playground, but different sports being played in like identity management, access governance, and privilege, user management. It's all about dealing with access, right, but with different flavor, with different root reasons. And then management is about efficiencies about making sure that I reduce manual activity while on the opposite side, after governance start from a pretty different conversation, which is around making sure that the distance between the expected state and the actual state in terms of modeling is minimal well privileged user manager is again, another flavor of it's something that has a different and special purpose approach and is really about the specific needs of administrative user.
There's no need to go into further detail given marketing introduction, but looking at the market, we have been looking around for the last few years in sort of convergence between identity management and access governance. It's already there that convergence at least is there in terms of what Analyst consistently say and what marketing brochures consistently say, not necessarily each and every vendor is there within unified solution, but definitely this is happening. And this is an ongoing effort. And for sure, in a, maybe in two years time each and every player in this market will have a unified single identity and access government solution. So the question becomes, is this something that is gonna happen as well from the identity and access government's place solution, sorry, and the privilege user manager. So to put it differently, do we really need different approaches for identity access governments and privilege user manager?
And if we, if we combine the two, is there an incremental value that can get out of it? Okay. So this is basically where we try to answer in this webinar. So making it visual as we already, as Martin already pointed out previous user manager, and I actually governance plays in different space. So that, for instance, if we kind of depict the typical stack abstracting a bit in a graphical fashion, we have application with various users that are different level of access to different application. And then underneath those application are operated by data repository and structural component, including application server and operating systems. So if we look at how we can map those user onto access control solution, we kind of find a very neat distinction, identity, access governance play just an application, regardless, the kind of user that's, where it sits while privileged user manager is working underneath with a kind of a blue edge on what we could call power user.
There are some specific domains where, which are covered by some of the privilege user management solutions for some very well known bespoken business application, but that's more an exception than a rule in general. There is a very clean line that separates the two domains, so that the question becomes given that I have such a clean line, what happened if I have somebody like this individual in my slide here that can I get access to some business level functionality, but at the same time, he also have access to some low level capabilities so that it could be potentially able to be covering the activity has been performing at the application level. For instance, example, typical example, I should say employees formerly working in the it department, but no longer there now transition to other department, other job roles, but still having access to some of the underlying technology that makes the application running.
Those individual can be in this situation. I'm not saying that they definitely would exploit them, but that's really the case that we want to prevent. Okay. This is just one of the possible use case that we should be looking at that are not covered neither by access governance alone, nor by privilege user manager alone. And that's post the question. And by the way, a very old question that dates backs already a couple of thousand years coming from the Romans, who's watching the Watchman. Okay. So I'm talking of solution that separately are already doing controls, but I need at least two of them to inject the notion of watching each other. Okay. That goes by number that's a basic math. So to put it differently, what we believe is that there will never be any sort of integration, real integration, or sorry, combination of access governance and privilege user manager, just because it's far better to have them separate with a sort of mutual integration that provide a combination of having the two of them watching each other's back.
Okay. That's already a very eye level synthesis of what is the, our experience like going into a bit more of details. Okay. How do I really make it happen? So if I, if I keep them separate, okay, the two solutions separates fine, but if I have some sort of mutual integration, okay, fair enough. But how do I really understand when I have those circumstances that I depicted in my, in my chart before? So that the same individual has too many access at the same time. How do I model in efficient way this sort of control? So well, the integration is making it very abstract is something that looks like this, okay. Having the two solution in place together. And as usual, the privilege user management solution can be used to integrate the access government stack, just like any other application. Okay. So making sure that administrators are under control and are, let's say enforce in terms of what they can be doing.
Okay. On the other end, the access governance solution can integrate the privilege user management solution. So in a way, elevating the fine grain entitlement manage there and the account manage there at application levels. So treating them out as if they were application entitlement. So to put it differently from a technical standpoint is just another integration in the same way that each solution is not really supporting the difference is in the way the policy that I'm gonna model out of it are, are, are being implemented. That's where really the conversation get interesting to explain to you what I mean with that. I need to bring you through a few slides around the way we do model segregation of beauty. Okay. This is, this is around now cross idea. So this is not a generic conversation any longer. Okay. So in cross ideas, what we do is that we model, what is the business process structure of a given company?
Like I'm not talking organizational structure or nothing like this. I'm talking processes, sub processes and business activity. This is something that changed depending on the industry, vertical of the company. Okay. So for instance, in this case, we see a manufacturing company example, and this is derived from example that we ship with or can be derived from existing GRC or process management system. So out of this model, we can then define what are the segregation of duty constraint. In my example, here, I have very, let's say toy example of purchase order creation and purchase order approval should not be delivered at the same time to the same individual. Okay. As you can see, this is a fewer business level conversation that taught business processes now with such a thing. And now just moving for a second on a screen, on a screenshot of our console. Well, what about our operation is an it operation as well.
Just another business processes among others. Isn't that something that I can treat Excel in the same way? Why should I make it any distinction between that specific one and the other? So if I have a representation of the values, it operation processes and the specific flavor that I want to handle with a given customer, well, then I can use it to model Excel in the same way it's relationship with other business processes. In this example, I just left visible one single line where I'm making visible the risk about not allowing anyone to be able to do salary payment or preparation and being a privileged user at the same time. This is something that I want to check and I want to enforce, this is the blue guy in my previous chart. Okay. This is the one with too many access at the same time. I want to be able to identify that sort of space.
This is just an example, as you can guess, it can be more granular and it can be on any given business process that you can think about. So if I have such a thing, I can get them to a situation that looks like this. This is again, another abstract representation of what can be achieved, integrating privileged user management, just like any other application. So we have a given customer with a privileged user management solution in place, and many other application application X in my slide here with user assign to various entitlement, those application. Then what we have is that this is what we wanna check. Okay. And again, the core point here is that privilege users are like any other users, okay. From an access governance perspective, then we add to the equation, the model that we just looked at that comes as pre can content in, into the solution.
Okay. Again, configurable, but still is not something to be revealed from scratches. And every time where the it operation process is one out of many, we are represented, okay. And length with many segregation of duty constraint. Then how do we plug the model onto the at estate? Well, what happened is that each and every application manager should define which permission is linked to each and every business activity. And I'm talking obviously only on the sod relevant portion of it, but once done this, we can then identify what are the violation in place. So for instance, in this example, we have this individual on the left side, which is a, which is entitled to two permission, which are themself linked to conflicting business activity. So it's a sort of loop detection that identify our notion of violations so that this same model can be reused across customer of the same nature and conserve multiple application to determine users violation and not just user violation on business processes, but also digging down into the it operation world where information has been pulled from the privileged user management space.
This is a, a short, long story around the way we model this sort of thing. But here then I would like to anticipate what is usually frequently asked a question around such model when we do explain the approach. We follow often we get the question, but can you just use ordinary sod where ordinary sod to many means sod across entitlement across permission? Well, well, yes we can, but we don't do that. We tend to skip it to avoid it because this is tends to be unmanageable very, very quickly. Let me explain to you what I mean with that. If I kind of redesign here in a larger scale, what I just bring you through. And I redefine my single segregation of duty constraint around around two processes in this, in this example, what I have here in red, one single constraint, which is kind of defining in a very abstract business level description.
What would be the relationship to the, sorry, the combination of permission that should be skipped. This is a very convenient, very manageable, very representation of the constraint in the system. If I was to represent the same degree of control mapping entitlement, one against another, this would lead to a much higher number of constraint. This is what is usually called a combinatorial explosion. And this is usually in real cases, it's not one on six, like in this case, but is more something in the two orders of magnitude in terms of differences. So really quickly, quick, very quickly and manageable. So long story short, there are good reason that cross ideas follows to model the, so in this way and is not just cross ideas. There are other solution on the market that follows out the same model to represent. So in an efficient way. So is that something that is relevant for each and every customer?
Well, as Martin pointed out, privileges and management tend to be a sort of, let's say, isolated topic compared to other, okay. In terms of access control within a customer and the sensitivity around the usefulness of such an approach in our experience is more coming from those customer, which are managing critical infrastructures, energy industry being the first one by far, but also banking financial services. And in general, any given company impacted by P C I DSS. Those are in our opinion or in our experience, those more impacted by this sort of joint solution or integration. And coming back to our original question. So kind of getting to the conclusion, do we really need different approaches for identity access governance and privilege user management? Well, yes, we do. They address different entities in different control types. And by the way, it's just a good thing to have two separate pieces.
Okay. Because of the who's watching the watches. And then is there an incremental value in combining identity access governance and privilege user management or again, yes, absolutely. Even more if the integration is coming with, from as smart ed access governance solutions, suit, model, process, level, segregation of duty and meeting, and this way extremely convenient, the additional control that I can inject. And that's why, by the way, we started this conversation, we're having this conversation because we have been thinking for a while around this topic, out of the customer demand that we got, and this is also converted into a, a partnership that we started. And the Republican announced a few months ago with Ft, which is a leading player in the privileged user management space. So this is not just coming out of, let's say direction or, or print, but more about real life experience in existing customer.
So really getting to conclusion why cross ADSS is a player in this space. Why should I consider cross ADSS if I was to having a closer look of this sort of topic? Well, because we believe we are among the few real native identity and access governance solution and not just another combination of moving parts that deserve that label then because is a privileged user management aware solution that integrates with solution third party privilege user management system, and has already partnership in place with one of the leading player. And finally, because it featured pre-canned policies for compliance, sensitive industry vertical. And with that, I, I turn it back to you Martin,
Thank you, Marco, for this information. I think this was very helpful. And right now it's time for our Q and a session. So I ask everyone to answer his question and the questions area and go to webinar control panel so that we can pick the questions if there are any, for sure, you will see our email addresses in the podcast and the slides available. You always kind of protest via email if you have first questions. But I think what becomes clear is it's not that access governance can do everything privilege management does, but privilege management wise versa can do everything access governance does. It's about right combination of these technologies. So we have to first question here, and this is a, a question to Andrea and to Marco, sorry, can you tell some use cases with Fox T if possible names probably you won't mention the personal names, but could you give some use cases on that?
Well use case meaning things that has been asked and implemented by customer? Well, it's not by, by accident that I rising the segregation of duty thing. This is what's really among the sparkle that started this conversation. And the second one is around the re-certification the ability to run recertification also in privileged users. Okay. Those two things are what has been driving since the beginning. That they're interesting that area. And there is also another, another interesting factor is that not necessarily each and every privilege, user management solution as a notion of identity, okay. They, for sure as an E notion of accounts, but not necessarily of a entities. So there are solutions where you manage accounts and you enforce what an account can do, but you have no way to bind one account to another, into another system if they belong to the same user, which with leaves us again, back to the notion of re-certification. Okay. So that, that, I don't know if I'm answering the, the, the question, but these are the three things that we started the conversation.
Okay. Thank you. Any further questions? So feel free to answer your questions now so that we can pick them as of management. We will have our conference starting soon. Unfortunately I've seen there of typo and the address changes ID com cf.com European identity cloud conference May 14th, 17th in Munich, and you shouldn't miss it. It's lead conference around identity cloud security C in Europe. So ID com.com have a look at the agenda. I think it's a very interesting one. And again, if you have further questions, just enter your questions. So, so Marco, maybe another question here. So, so how many customers do you actually see really driving this integration? So applying access government on one hand, really actually applying it for the it department and in addition, integrating it with M tools.
Okay, well that, that's two answer because there's a big distinction. One distinction is how many of your customer are really integrating the it operation in the sod checks? Well, I think that the answer to that is probably if not every, most of those of our customer, which are using our solution for the sod capabilities. Okay. I mean, not each and every of our customers doing SLE. Okay. But those who does, they pretty much include it operation as well in the process they manage in that way already, regardless the fact that they already have a privileged user management solution. Okay. When they do, then the conversation can go to the next level. But this is just started, frankly speaking, we have an end full of customers where we have this conversation moved to the next phase with an integration. Okay. Still a very early stage.
Okay. I think that aligns well with what we see in our life for. Okay. Any further questions. Okay. If there are no further questions, then up to me to say, thank you for participating in this webinar. There are some upcoming webinars within the next weeks, and for sure, there's our European identity and cloud conference that you definitely should. Don't miss. Shouldn't miss. So hope to see you in Munich now, and maybe happy again as participant in one of our upcoming webinars. So thank you, Marco for your presentation.
Thank you. Thank you, Martin. Thank you everybody.
Okay. Bye.
