Before You Build: IAM Customization Governance in the AI Era

Welcome to the KuppingerCole Analysts chat. I'm your host, my name is Matthias Reinwarth, I'm analyst and advisor for KuppingerCole Analysts. Today we talk about something that many IAM identity and access management teams are seeing right now. And when we get to the end of the episode, you have learned everything about AI for IAM, I assume. So let's wait and see if we can make that. So what we are seeing right now is that AI assistants, so yeah, agents more or less, build a custom approval workflow or a connector in an afternoon or faster.

This is the promise of what the vendors are currently presenting to the audience. Backlogs that were stuck for months suddenly move. And we covered that just recently. I had an episode together with Martin Kuppinger. We started with orchestration and we ended up also talking about integration, debt and vibe coding and IGA solutions customized to depth.

And today, and that's the promise for this episode, so no pressure to my guests, we want to look at what organizations can actually do about that. He has written an advisory note that asks what that means for IAM customization, AI getting faster, faster delivery of new solutions. This will be published on the KuppingerCole website shortly. So if when you're now listening to this, chances are you can already access this advisory note. And today we want to get a first look at the findings. But stopping talking on my side, first of all, welcome, Patrick.

Thanks, Matthias. Great to be back. Great to have you. And we really want to start with this because you are talking from an experienced practitioner's perspective. So you are in IAM projects for several years now in very different roles. Now you're with KuppingerCole Analysts as an advisor for several years right now. We need advisor to be precise. And first question for me, when we start here right now, if AI can build your extension, your connector, your integration with a data source, your recertification campaign in an afternoon, where's the problem?

Shouldn't IAM teams be just happy about that? Partly, yes, I would say. So the thing is, so let's first look on what does it solve actually. So for a long time, the integration part, creating connectors, building connectors, configuring the connectors, took a big share of IAM projects and the efforts that were consumed. And for this, we all had also kind of a filter on what we did, right? Because everything that produced costs, yeah, somehow needed an owner and budget and so on.

But yeah, on the negative side is, yeah, nothing or producing code, producing connectors now with AI does not cost anymore. We have removed this filter, yeah.

And yeah, today we are looking a bit on what does this mean for IAM. If this filter is gone and we can, yeah, produce connectors, custom integrations, custom workflows in, yeah, just an afternoon. Right. So if I understand you correctly, the question is not whether we can build it. Of course we can now much faster, but whether we should and more importantly, who takes care of that afterwards, who carries it on. So let's start with the first part of that. So let's really unpack this.

First of all, the real life before that in your projects before AI, before AI supporting the IAM architecture or the operations team, where do, or where did IAM initiatives actually get stuck if not in development capacity? Yeah. So the thing is, of course, in a lot of times the development capacities are under pressure. Yeah. I need to deliver code and to deliver the integrations and so on. But from the practice we see also that there is a lack of people, yeah, of resources who understand the business, who understand the organization and are able to define actually what the business needs.

Yeah. So a proper definition of what is really needed and also to understand where the requirement belongs to. Yeah. So kind of the organizational negotiation that around development artifact kind of, yeah. So that is one of the major concerns. There are a lot of other things, but for today I would say let's focus on this portion.

So yeah, to define what you really want is kind of a big issue in a lot of organizations, yeah, to understand it and to define it. Right. So if we do not do this properly, this analysis, this requirements definition, requirements gathering, if we don't do that properly, if I understand you correctly, that means we are speeding up the things that were never the problem because we are speeding up things that are the results of something that has not been properly executed.

Kind of, kind of, yeah. So the thing is, and this is where I'm actually advocating for at the moment, yeah, if I'm now putting AI and IAM for producing custom code, for example, do I really solve a problem that currently exists? Yeah. Or is my bottleneck not somewhere else? Yeah. So in kind of the business analysts and the experienced internal people who can tell how the organization actually works. Okay. Understood.

Of course, this is not our first podcast episode that we did to do together. And if I remember correctly, you once said that there are some requirements that land in IAM, although they are not really within the capacity or even the responsibility of IAM, but IAM not fast enough says no. So what does that look like in practice? Is this something that also influences the requirements that then are, yeah, attempted to solve with AI? I would say so. So the thing is, as IAM is kind of, or IGA more commonly is kind of a platform where you can put a lot of custom configurations.

You have a workflow tool in the most of the cases inside your IGA platform. A lot of requirements are solved in these platforms that do not directly belong here. And now the danger is actually that you have AI. You don't have like a barrier of a lack of resources anymore. Yeah. So beforehand you said you had to say no because you had limited resources.

Now, if someone just arrives with the requirement, the risk is high that you actually said, yes, okay, let's build it with AI without actually questioning it. And the consequences, then you have something in your tool that does not belong there, but needs to be maintained, needs to be kind of looked through with every upgrade of the IGA platform on the one hand, but also of the target system, for example. Yeah. So if you have not made a proper lifecycle around it, this will haunt you with every upgrade. Yeah. With every change in your organization. Right. Okay. We've promised results.

So let's go into the gory details. Let's talk about the code, the code itself. And you did some evaluation there, used existing sources and compiled them and built them into your advisory node and extended them. How good is what AI or LLMs or tooling agents produce for IAM from a security perspective? Because we want to give some foundation for good discussions within organizations. Yeah. So the thing is, or why did I had a closer look on the code quality in terms, for example, of security? Yeah.

Because there now figures out as research out from organizations, for example, the Veracode 2026 gen AI code security report that I actually had a look into, because a lot of organizations now to rush on the deployment of AI without really thinking about the consequences it has, and maybe put too much trust in what it actually produces. Of course, we know AI can hallucinate and so on, but is this really considered during the implementation or during the deployment? So I wanted to have some foundation to build on my view I have on this.

And this report shows actually that there's only a security pass rate of 56% for across 100 models. So that means the models produce around 44% of known vulnerabilities. So on the first hand, this means you cannot directly trust the output. You still need a proper pipeline around it. Yeah. Good security testing, for example, and like everything you need in a good development organization or engineering organization. And also specialized models are not better. Yeah. They are slightly better, but in general, the pass rates are not that good.

So the conclusion I can draw here is you cannot just trust the code AI produces. You have to still have proper pipeline testing and so on in place. Right. That was also my point that I was thinking of, because everybody knows if you give a bad prompt to your LLM, if you give too vague instructions, you will end up with something that could look like the solution, but surely it's not.

So adding proper expertise, so adding the human into the human developer, into the loop as well, and with proper, as you said, pipelines, with proper regression tests and everything that is required here might still really improve the quality of the code. So doing things better with AI also means being better in controlling the AI, right? Yeah. So this is, I think, the conclusion we can draw from this. So AI will not solve bad software development practice.

And as we know from a lot of organizations who are doing just configuration and customizing and IAM are not applying the same principles, they would apply to normal software development practice because kind of the promise is you're just doing configuration and adjustments and so on. But yeah, if now adding AI on this, you might produce, yeah, in your code, security flaws and so on. Right. So to put it the other way around, if you do not apply these proper guardrails, if you are not a well-trained developer, is then AI bad news for IAM and for IAM programs?

So yeah, if you don't have this proper practice, then it will be bad news because it will, or in a lot of discussions, we hear kind of the term AI amplifies what is already there. So if you have a bad software development practice, you will amplify the issue. And this means, yeah, for example, more security vulnerabilities. On the other hand, if you have a proper organization around it and now just, for example, yeah, let the AI code, but the rest of your software development practice is not AI supported, then the volume growth can really become the bottleneck of your organization.

And yeah, then you will slow down at this end. Yeah. So you have to really look at the whole software development cycle or the whole development cycle, the whole customizing cycle. You have an IAM to really not create just a bottleneck at another position in the cycle. Right. And you've already segwayed into the second blog of this podcast episode because we talked it through and as we finally managed, we started with the point, the code is not the problem. Now we arrived at the point that maybe the code is the problem or at least the code lifecycle management might be the problem.

So if the number of extensions grows, so if you add more and more connectors, more and more routines that do stuff on top of your IGA or as part of your IGA as a connector, do we need a way to manage them over their whole life? I think that that is something that I took away from Martin on the episode with him, but this is really a challenge. Having nice solutions is fine, but having a growing pile of solutions that are not well maintained, that might be the real challenge, right? Yeah.

So I would say, and I think we were, or IAM was bad at this the whole time and we see this without AI also already. So customization happens, but actually the documentation at the end, there's never time for documentation. So when we are now called by a customer to help to select a new tool, there's a lot of customization in the IGA tools and the documentation is not explained anymore. So now we can take away AI and have to really talk about that customization is a lifecycle commitment. So I just can't look only at the build process or the go live until the go live.

I have to think, how do I keep the customization, the adjustments that I do up to date to the demands of the organization, that there still is the proper knowledge about it and to keep it in line with the architecture. And so therefore I'm advocating for a lifecycle for customization. So I'm not thinking only until the go live, but also beyond. Who is responsible for testing it, for example, during a version upgrade. And this means not just the IAM team, but the person who actually requested it, for example. Or what is happening if the adjustment, the customization is not needed anymore.

So there should also be a kind of retirement for these additional functionalities that you need. I had the chance to have a sneak peek at your document and one figure that struck me was from the Verizon Data Breach Investigation Report. I am an IAM analyst and advisor, so I should know. I was assuming that stolen credentials, leaked credentials are still number one in the key or root cause for breaches. And Verizon says, nope, software vulnerabilities is the top breach entry vector with almost a third of all breaches. This sounds like there's more to come with AI? I would confirm on that.

Yeah, so I think it's also the whole world was kind of an anxiety or something like this when Anthropic was releasing Mythos, I guess, or holding it back because it would be so dangerous in finding vulnerabilities. So the thing is, I think AI comes again from two sides for this issue. On the one hand, AI can faster find vulnerabilities and can exploit it. And on the other hand, bad code will create even more vulnerabilities. So improperly developed code and deploy code.

And now you see everyone with a cloud or a codex up on a mall can actually develop software and put it to production without security tests and so on. So this means at the end, AI will, I guess, amplify again this issue. Right. So we had the statement, code is not the problem, but requirements, but organization. Now we say, okay, code might be the problem or part of the problem. Then we need to get to measures, to mitigating measures, to controls that actually help in solving the issue. And that was the promise at the beginning of the episode.

So one thing that I'm always preaching is governance, is ownership. And ownership is something that is essential also here. From your perspective, who should own such an IAM extension, a connector, a recertification form to request access or something like that? Yeah. So the thing is, I would really start here with a person who has the proper knowledge to explain what this artifact should actually do. Who has the requirement, who raised the requirement and is able to explain what it should actually achieve.

But in the reality, we see a lot of cases where actually just the IAM or nobody, IAM team or nobody owns it. This is the consequence, but the person who actually requests it and this person should be then informed about his or her duties and what this ownership at the end means. So this should be really thought through before implementing something. Right. So one takeaway would be ownership would be some kind of registry to know who is the responsible people, person, and also with everything that goes with ownership. So also handover of ownership.

It cannot stay with the developer, which leaves the team in six months. So there needs to be a complete process, also life cycle for the IAM governance side. And Martin, I like that. I'm old enough.

Sorry, go ahead. Yeah. I think we should handle it kind of the same way we are doing already with access reviews. So we are good in IAM with doing reviews with governance and so on. Why not apply the principles that we have here already to this? Having an owner, if no owner is there, we have kind of a process to find one. Otherwise we put it down as an audit finding and have a full life cycle, a documented life cycle on it. Right. I think that makes perfect sense, especially when the numbers grow.

At numbers growing, that is what Martin also mentioned in an episode and I'm old enough to remember. He mentioned the Lotus Notes analogy of thousands of databases that were multi-user and were running somewhere, sometimes even on the boxes of the end users who created the database. And before that, it was DBase and all these network capable systems that I can remember. And nobody knows who built them, where they're running, why they were built and whether they are still needed or not. And I think the same holds true for every addition that you add to your IGA IAM solution.

So a customization register is the answer. Where does this idea come from and what goes into it? This is one of your key recommendations in your advisory note. Yeah. So I'm also old enough to remember Lotus Notes and I have worked with Lotus Notes. I had the pleasure and I also know a lot of organizations who are still struggling today to get rid of it because it's so woven into the organization. But as you said, the key issue today is the ownership and the lack of documentation. It does things and is necessary still to work. And we see the same inside IAM.

So the thing is, you said the registry, the customization registry. So the thing is, I have copied this from the German financial supervision, the BaFin, which has in it circulars for the banks and the insurances, a classification procedure and a central register for applications developed outside of the central IT and where they're documenting it. And the thing is, somehow this register has good ideas in terms of documenting who owns it, what are particular conditions under which it runs. And I would apply the same for IAM, for IGA platforms.

So when you have the opportunity to have the platform and these customizations inside where you then define at least two fields, I would say, two fields that are most relevant and should be documented. There are also others, but I would say very important is to have an owner, documented owner, which is checked if the person is still there, has the appropriate knowledge still and a retirement condition.

A lot of customization efforts are also there for temporarily, because you have a particular system, which is like for a time where two systems coexist, for example, or on the other hand, you have something for M&A activities, for portfolio activities that you have a particular identifier to identify someone from a particular legal entity or something like this. And these are two things I would recommend for inventory. If you want to know more, then look into my advisory note, which is going to be published soon.

And as I said, it might be already available when you're listening or watching this episode. So there's a lot more around that. So what you're asking for is also just completing the lifecycle, not always onboarding such an extension, but also off-boarding it and with defined criteria that make sure that this happens when needed. So that you just, as I said, don't just pile up extension, non-extension, which is more or less what I call the hotel California syndrome, where it says in the lyrics, you can check out anytime you like, but you can never leave.

So this is something that we see here as well. And you've mentioned already a typical retirement condition. So if the M&A program is over, you don't need the M&A connector anymore. But how do you actually get rid of customization beyond such a connector? How do you identify that it can go? It's no longer needed. It's even making upgrades more cumbersome or it's just no longer needed. How do you do that? Yeah. And as I said, this retirement condition is quite important to have documented under which circumstances you need this particular extension.

And as you said, if I'm not looking at it again, then the estate will just grow. And the thing is that we see in a lot of organizations who want to replace their IAM platforms, their ITA platforms, they just can't do it because the effort to understand what is there might be too high or it prolongs at least the project at the end. But as I said already, we have the instrument of the access review and where we already know how to implement it, how to do it. And also we know we have lessons learned from it, from the access review. So the thing is, I would apply the same principles.

Look at it regularly. And if you have too many items in it, then it starts to become rubber stamping. So you have like guessing or if it's the wrong owner, that's guessing if it's still needed and so on. So you have to ensure that there is a proper owner to decide it. You have to see that it is not too much to decide. So also here applies a risk-based approach at the end. So understand what is the risk or the importance of this particular customization.

Might be also in alignment with the retirement condition that you like once a year or once every three years have a look at this particular customization to understand is it still needed and otherwise to remove it. Right. And I just realized that we are talking about this now for, I don't know, 10, 15, 20 minutes. And it always sounded like we need these extensions. I have done some episodes with Martin and have had lots of conversation with customers who say, hey, we want to move actually to IAM as a service or IAM provided from the cloud because it makes us stick with standards.

So we do not do extensions. We do not do these extensions, these custom built nitty-gritty small things that make things nicer for a small peer group within the organization.

Of course, the one with the money. So isn't the cheapest extension the one that we never built? So shouldn't we really look at the very initial part of this process, the requirements definition and the moment that people come up to us and ask, can you do that?

Yeah, totally. So the thing is building it or customizing it inside the platform is the last step you undertake kind of. And there are, in my advisory note, I propose seven steps where you have actually questions that you should ask yourself before you're implementing. Not to make it like an over sophisticated process. But if someone arrives at your desk and says, I need this custom form or something, you should ask some questions before you rush to the implementation or rush to give it to cloud to implement it or whatever you have behind it to actually implement it.

So I would start first with adjusting the requirement. The first step that we have is adjusting the requirement. So what is this really needed? Do I already find the information that I need in the platform? Is it already available, for example? So sometimes someone needs just during the approval, a particular information to be shown. And sometimes the people just lack the knowledge that it is already there. So that you might have to just change to a particular tab or something to show the opportunities that you have already in your solution.

It's, I think, self-explaining, but you have to consider maybe the user has not found already the information. It's like also thinking too complex at this point. Then second step, configure it with the standard. Do you have an opportunity to just configure, put the proper configuration without creating any code or something or any calculation, for example? So if it's, for example, like two fields that need to be shown instead of now creating a new string that is calculated, needs to be updated and so on.

Is it maybe enough to show during the approval, like the two or three fields separately besides each other? The next step is relocated to the originating function. Because if you have not solved it until these steps, because that would be very easy steps. And then you have to ask yourself, is it, I am really the right place to solve it? Sometimes the steps come also a bit upfront. Sometimes you can also put this as a first step, but sometimes you just say, okay, I want to accomplish it, but this step needs to be somehow there.

The steps can also be interchanged in your organization and also of course depend on the organizational context, I would say. So relocated to the source where it actually belongs, where it can be solved cheaper, for example. The thing is you mentioned HR would be a great example, for example, maintaining data, cleaning up data and so on. Another thing is obtain it externally. Maybe for your platform, you can buy an already existing connector from a third-party vendor or something like this, instead of building it on your own. You can get it from the market or maybe there's something on Git.

So also evaluate if there's something already. Another thing is submit to the vendor roadmap and wait until it's implemented. So do not build a custom solution, but see if it's an opportunity to hand it in and is it also something the solution could profit from. We see a lot of vendors which are happily taking the advice or requests from their customers and implement it. So use this channel and ask if this could be implemented in the standard. And then now six and seven, which really includes developing or doing something.

Step six is, is it worth to have it as an external service within the identity API layer? So really bringing up the idea of the identity fabric. I have a separate microservice, for example, which is just there, for example, for this particular calculation and so on. Instead of building a complex logic into your solution. And the last point is then, of course, to build it inside the platform. And the thing is, of course, with the higher steps or the latest steps I have named now, these are the ones with the highest life cycle costs, but the lowest organizational costs kind of.

So because on the earlier steps, you need to negotiate with the person requesting, you have to understand what is there, what is not there. And this is, of course, taking also resources and sometimes, or a lot of organizations tend to then just say, okay, it's easier to just build it.

And yeah, I kind of then, and that's the reason why they're hesitating to, to really lead this discussion. So I can just encourage you because if you see the life cycle costs that are created by such extensions, then it is worth to see the earlier steps or the lower steps. Right. That sounds like a lot of bureaucracy, but you and I, I think we get why it's needed because it pays off downstreams and it sounds logical. So simple questions.

So again, and that would be a takeaway for those who are waiting for the takeaways, but why do teams skip these first steps anyway? Why, why don't they ask? Why don't they talk? Why don't they communicate? Why don't they look at the market? Yeah. And I think that is really the thing because it requires the discussions. Yeah. Of course there's an organization has also their political side. Yeah. You are forced to do something. Yeah.

Some, some management might get into discussion and forces you to do something and yeah, it needs kind of the agreement outside of the IAM organization. Yeah. So you need to really talk to other stakeholders too. And then of course, if you're like, there's a problem with data quality and have to say, okay, this needs to be solved within HR. You are creating work at their side. Yeah. And they need to implement or change their process.

And I think a lot of organizations are kind of, yeah, not ready to take these discussions because I would also say in a lot of organizations, they have not thought about their strategy. Yeah. And if for example, something we can, we have an ERP for years. Yeah. It's called fit to standard. If this is my strategy and I say, really, I want to do standardization, then I have to beat these discussions upfront. Yeah. But if I do not have this declared as my standard, as my strategy, then yeah, every discussion becomes an individual decision. Right. Let's approach this from a different angle.

When I talked with Martin, I think we talked about the replacement of SAP IDM because it has been sundown. So, and he said, okay, if you choose a solution now, it will have to live for 15 to 20 years. And if we think we are now with another product just at the end of the 20 years, and we're building an extension of an extension, and we've built lots of these extensions because we need to add functionality that was not originally within the solution that we've chosen.

Isn't there a point where this is no longer about individual requests, but it is more, yeah, a set of symptoms of understanding that there might be a different disease that the platform itself is the one that we should look at? Yeah.

I think, I think this is a very, very good thing because if you have the steps that I've talked before, we've talked before, applied in your organizations and in your organization at ending up a lot of times at six and seven, then you have to really ask yourself, am I doing the right thing with the right tool at the moment? So one cause could be I'm doing a lot of stuff here that is actually not IAM. Yeah. So if I need to customize a lot in a quite good and mature solution to put a lot of logic inside, which does not belong there at the end. Yeah.

So then I have to really think, okay, am I doing the right thing? Or the other thing is with SAP IDM, it could be now the case that you, if you have put a lot of custom logic inside that you would expect now from a modern IGA solution, for example, then you have to ask yourself, is this still the right tool? Then think about your requirements, have a look at the market and understand at the end, do I need maybe another tool? Yeah. So do I need maybe to replace the existing tool or to place another one which complements the existing tool so that I can just reduce the customizing within it?

Right. Yeah. That sounds really straightforward to really also have some kind of gate to say, okay, if I always end up with six and seven and a half tons of additional solutions and today they work and I don't work tomorrow. So then that might be something that I need to take care of. Right. And the thing is, yes, you're totally right. And the thing is there now the loop closes because there helps your customization registry. You see what have I built over the years? Because the thing is, if you just always look, what have I developed?

I don't know, within the last 12 months or something, you are just looking at a particular spot of your solution. And the thing is, if you have the registry and see what have I built there, what is all custom code, what I need to maintain and so on. And the thing is, if there's a lot of times I am as the owner, because it's just basic IAM functionality, then I have to really ask myself, is it still the right solution? There you have the registry, you look at it regularly.

And if you end up a lot of times, six and seven, you see this in the customization registry and can take an informed decision towards your management, for example, that you need, for example, to look for another solution. Right. We've promised results at the end. So we come to exactly this section, the closing. I usually do not like this. What will you do next Monday? But this time I ask that because you've mentioned the registry. If there's a registry, then you can do the assessment. The question is, what do you do if there's no registry?

Maybe that could be a starting point for action items for next Monday. I would say create the registry if it's not there. What else? Yes. I think if you're owning IAM, start with this one. Then use the assessment with the next extension that arrives. Look if these steps are working for you and look if you have maybe also other steps that you have in between and so on. Build your pyramid or your workflow for creating such customizations or before you create such customizations that you have an organized, documented process. That's another thing.

I think for security and risk leaders or security and risk people who are listening to us, they should really look, is their IAM organization using the same secure development pipeline that the rest of the organization is using? Are they agreeing to the principles? Is it really using the standards that the organization gives? I think Marty mentioned this also in the last podcast that you do when you have a system integrated that you really give them your guidelines at the beginning. Think about this. Is the IAM organization really following it?

I think for business and application owners, talk about your needs. Understand what you want to solve and not talk directly about the solution within the platform. Start with your requirement and then give the IAM team to serve you with a good solution and not just fulfilling what you think would be the appropriate solution.

Also, be aware about the ownership that comes at the end with all of this. We are at the end and we've promised results and here they are. First of all, AI makes code cheap. That was our first section that we looked at, but the bottleneck in IAM was never, in brackets, creating the code. It was really defining it, describing the requirements, testing it and embedding it into an overall solution.

Second, you said once you do it, every IAM extension, be it whatever we talked about, it needs to have a life cycle, an owner, a place in the register, and also a retirement date, a retirement trigger. That would be important.

Third, before you build, apply your seven-step approach to say, okay, isn't the standard enough? Do we really need it? Can't we configure it? Do we need to build it or can we buy it? Where do we build it? I think all of these are the questions that are the right steps to approach this potential of over-customizing, over-extending your IGA solution. I hope I summarized that properly. These three steps are really good approaches and they are also results of your advisory note. Final words from your side before we close out. Did I misinterpret you?

No, it was all great. Thanks for the summary. I don't have to do it. I would say the thing is, if you're now selecting a new tool and doing things again, start right. Even if you're in the middle of operating your IAM, it's never too late to start with this. Create transparency and stop the customization hell, I would say, and that we don't end up with Lotus Nodes 2.0 and so on or SAP IDM 2.0. Take action and become really a business enabler by delivering good solutions that not only work on the go live, but have a life cycle and continue to work.

Right, which also brings me a bit closer back to my advisory note, Identity at the Speed of Business, which provides the right solutions in the right place at the speed of the business, but also retire that as well. Your advisory note will be published on the Cookbaker Coal website and most probably it is already. If people are looking out for that, of course, they can look for you, Patrick Teichmann, but they can also look for the title. The title is Governance for IAM Customization, so that will be at least somehow in the title.

Look out for this and the keywords and if you don't find it, just reach out to me. Right, and that would also be my final sentence. If you have any questions around this topic, around this podcast, to Patrick for the results of his research beyond what is published in the document, although there is a lot, just reach out to Patrick, to myself. We are happy to reply. We are looking forward to your feedback and if there are any questions, suggestions, how to look at this immense problem that will be raised or challenged, that will be just growing over the next months and years, just let us know.

We are happy to discuss this here or somewhere else. Thank you very much, Patrick, for being my guest today. Looking forward to having you soon and thank you very much for that research that you did. Thank you. It was a pleasure. My pleasure. See you. Bye-bye. Bye-bye.