WEBVTT 00:00:00.000 --> 00:00:04.800 Most enterprises can tell you the number of employees they have, but I think very few 00:00:04.800 --> 00:00:08.600 can tell you the number of machine identities they have in their environment. 00:00:09.300 --> 00:00:14.400 And that becomes dangerous because NHIs often accumulate privilege silently over time, 00:00:14.700 --> 00:00:17.107 and eventually you end up with machine 00:00:17.107 --> 00:00:20.400 identities holding persistent access across multiple 00:00:20.400 --> 00:00:20.900 systems. 00:00:21.500 --> 00:00:30.000 So considering PAM being a key component for solving the overall area of NHI challenges, 00:00:30.300 --> 00:00:36.600 I think that is fair to say that PAM will play an important role, not the only role, 00:00:36.700 --> 00:00:41.900 but without a proper PAM solution, you might not get a grip on your NHI challenges. 00:00:42.000 --> 00:00:44.524 I believe that the organizations struggling 00:00:44.524 --> 00:00:47.400 most are usually the ones that are still treating 00:00:47.400 --> 00:00:52.900 PAM as a vault deployment owned by a small infrastructure team, security team. 00:00:53.300 --> 00:00:58.700 And I believe that the organizations making progress are the ones that are shifting that 00:00:59.200 --> 00:01:01.144 mindset and treating privilege as a 00:01:01.144 --> 00:01:04.200 continuously governed operational capability across the 00:01:04.800 --> 00:01:05.800 entire identity ecosystem. 00:01:20.500 --> 00:01:22.800 Welcome to the Kupinger Coal Analyst Chat. 00:01:23.100 --> 00:01:23.500 I'm your host. 00:01:23.800 --> 00:01:24.900 My name is Matthias Einblatt. 00:01:25.000 --> 00:01:28.600 I'm an analyst and advisor with Kupinger Coal Analysts. 00:01:28.700 --> 00:01:35.700 Today we want to pick up on a topic that we covered a few years ago already, way back 00:01:35.700 --> 00:01:37.300 then with my colleague Paul Fisher. 00:01:38.200 --> 00:01:44.600 The topic has changed, the analyst has changed, everything has changed when we talk about 00:01:44.600 --> 00:01:47.800 the topic of privileged access management. 00:01:48.100 --> 00:01:50.700 And for this, I welcome Alejandro Leal. 00:01:50.900 --> 00:01:54.700 He is the author of the new research on privileged access management. 00:01:56.200 --> 00:01:56.700 Hi Matthias. 00:01:57.000 --> 00:01:57.800 Thank you for having me. 00:01:58.000 --> 00:01:58.600 Great to have you. 00:01:58.800 --> 00:02:01.472 And when I say you have picked up the 00:02:01.472 --> 00:02:05.300 research in the PAM area, you've published quite some 00:02:05.300 --> 00:02:07.100 documents around this right now. 00:02:07.400 --> 00:02:13.900 So these documents are just out, they have been published along with the EIC conference 00:02:13.900 --> 00:02:18.100 because it is identity management, it's cybersecurity, it's privileged access. 00:02:20.000 --> 00:02:26.200 So first of all, before we go into the details, how did the topic evolve for you? 00:02:26.300 --> 00:02:28.000 How did you approach it? 00:02:28.600 --> 00:02:32.108 What has been your approach as an analyst 00:02:32.108 --> 00:02:36.300 towards the changing market segment of privileged 00:02:36.300 --> 00:02:37.000 access management? 00:02:38.100 --> 00:02:40.600 Well, I think a lot of things changed. 00:02:41.500 --> 00:02:46.900 For example, you mentioned the report that I just published, so the leadership compass 00:02:47.100 --> 00:02:47.900 on PAM. 00:02:48.600 --> 00:02:51.773 In this version, we had 36 participants, I 00:02:51.773 --> 00:02:55.400 believe around 10 more than the previous report. 00:02:56.000 --> 00:03:04.500 And I saw new entrants and new, let's say, well-established vendors that recently made 00:03:04.500 --> 00:03:07.600 acquisitions to enter the PAM space. 00:03:08.200 --> 00:03:09.300 So there's a lot of momentum. 00:03:09.700 --> 00:03:12.600 And I also covered vendors from all over the world. 00:03:14.100 --> 00:03:18.800 I've done, I don't know how many you'll see so far, but I think this one was perhaps the 00:03:19.500 --> 00:03:22.700 most diverse in terms of geographical location. 00:03:22.900 --> 00:03:28.500 So we had PAM vendors from China, from the Middle East, from South America, from North 00:03:28.300 --> 00:03:29.900 America, Europe. 00:03:30.900 --> 00:03:39.100 So one of the, let's say, main challenges I had at the very beginning was to define 00:03:39.000 --> 00:03:48.200 privilege, because as you mentioned, the old, let's say, PAM model assumed that privilege 00:03:48.200 --> 00:03:53.200 was tied to a small number of non-admin accounts. 00:03:53.200 --> 00:03:56.714 So you had a domain admin account, root 00:03:56.714 --> 00:04:01.400 account, and the problem was mostly about protecting 00:04:01.400 --> 00:04:02.300 those credentials. 00:04:03.000 --> 00:04:08.700 So vaulted the password, rotated, monitored the session, recorded the activity. 00:04:09.800 --> 00:04:18.400 That model made sense when infrastructure was, let's say, relatively static and most 00:04:18.400 --> 00:04:21.200 privilege operations were performed by humans. 00:04:21.900 --> 00:04:28.700 Of course, those capabilities still matter, but that assumption no longer holds because 00:04:28.800 --> 00:04:33.396 today, privilege is distributed across APIs, 00:04:33.396 --> 00:04:38.200 cloud roles, service accounts, CICD pipelines, 00:04:39.200 --> 00:04:42.500 Kubernetes workloads, et cetera, et cetera. 00:04:42.500 --> 00:04:47.290 So the question is no longer, is this account 00:04:47.290 --> 00:04:52.400 privilege, but more about what can this identity 00:04:52.500 --> 00:04:55.000 do right now in this context? 00:04:55.800 --> 00:05:05.800 So the way I defined privilege was more about, let's say, less about who holds an identity 00:05:05.800 --> 00:05:15.000 and more about the ability of an identity to perform actions that affect systems, security 00:05:14.800 --> 00:05:18.100 controls, infrastructure, or other identities. 00:05:18.400 --> 00:05:24.500 So in this sense, privilege is less defined by who holds a specific account and more by 00:05:24.500 --> 00:05:26.400 what an identity is capable of doing. 00:05:26.600 --> 00:05:31.200 Right, but when you say that, and we've seen that in earlier editions already, but this 00:05:31.200 --> 00:05:34.200 really has been exploding more or less. 00:05:34.900 --> 00:05:36.807 There's also changes where privileged access 00:05:36.807 --> 00:05:38.800 management actually is located, where it needs 00:05:38.800 --> 00:05:40.100 to sit, where it has to run. 00:05:40.600 --> 00:05:43.716 So we are no longer on-premises and with 00:05:43.716 --> 00:05:48.000 traditional software systems that had changed before as 00:05:48.100 --> 00:05:51.400 So we included key capabilities or something like that. 00:05:51.400 --> 00:05:59.300 But right now, it's much more about monitoring identities and the processes they represent 00:05:59.300 --> 00:06:01.500 at runtime, wherever they are. 00:06:01.700 --> 00:06:03.300 And that is everywhere. 00:06:03.500 --> 00:06:07.400 It's in the cloud, it's in, as you said, in all these virtualization platforms. 00:06:07.900 --> 00:06:12.000 So you need to have PAM components everywhere. 00:06:12.200 --> 00:06:16.300 So we are moving towards a more hybrid PAM already? 00:06:17.100 --> 00:06:23.800 Yes, and before I get into that, there were also two interesting insights, let's say, 00:06:24.000 --> 00:06:26.000 that I found out during my research. 00:06:26.000 --> 00:06:30.738 So one is that for organizations that build, 00:06:30.738 --> 00:06:35.800 let's say, PAM around the traditional features, 00:06:36.400 --> 00:06:42.600 in a way that creates a visibility problem, because most of them do not really know where 00:06:42.600 --> 00:06:45.500 privilege exists anymore as they continue to scale. 00:06:45.800 --> 00:06:47.600 So they know where the vault is. 00:06:47.800 --> 00:06:52.400 They know, let's say, which human accounts are on-border, but they lack the visibility 00:06:52.400 --> 00:06:56.600 into delegated cloud permissions or inherited entitlements. 00:06:56.900 --> 00:07:01.700 But something that was interesting from this is that in the leadership compass, there were 00:07:02.300 --> 00:07:08.300 three to five vendors that just focus on small, medium enterprises. 00:07:09.100 --> 00:07:22.400 And what they told me is that a lot of the SMBs here in Europe or in other parts of the 00:07:23.500 --> 00:07:26.500 agentic AI, but many of them just want the vault. 00:07:26.900 --> 00:07:32.800 Many of them don't have large IT teams, identity teams. 00:07:33.000 --> 00:07:35.500 So they just want to get the basics right. 00:07:35.700 --> 00:07:38.000 They want to get the foundations right. 00:07:38.600 --> 00:07:45.300 So for many of these small, medium enterprises, all these talk about NHIs and AI agents, 00:07:45.700 --> 00:07:47.600 in a way, it's a little bit of a background noise. 00:07:47.600 --> 00:07:53.000 Of course, they have that in mind, but they just want to get the basics right. 00:07:53.800 --> 00:07:57.900 And the second trend is a change in, let's say, architecture. 00:07:58.500 --> 00:08:04.400 So a lot of these vendors now understand that there is a deeper convergence with 00:08:05.800 --> 00:08:08.500 the broader identity and security ecosystem. 00:08:09.000 --> 00:08:15.400 So BAM is now less isolated and it's more integrated with IGA. 00:08:16.000 --> 00:08:22.100 In a way, there's some convergence going on there with Keem, ITDR, SIEM, SOAR, etc. 00:08:22.800 --> 00:08:24.700 So we're already seeing this in the market. 00:08:25.500 --> 00:08:30.600 Vendors are adding cloud entitlement management, secret management, ITDR. 00:08:32.800 --> 00:08:38.800 So I think that BAM is becoming less of a standalone admin security product 00:08:39.300 --> 00:08:42.500 and organizations are adapting quickly. 00:08:43.500 --> 00:08:53.100 But going back to your question about hybrid, I'm interested also in what you think here, 00:08:53.200 --> 00:08:56.400 because you recently told me that you're doing some work around advisory. 00:08:56.700 --> 00:08:57.000 Right. 00:08:57.100 --> 00:08:57.900 Yeah, absolutely. 00:08:58.100 --> 00:09:01.200 And I think this is really a changing market. 00:09:01.700 --> 00:09:05.814 So even customers or prospects that we are 00:09:05.814 --> 00:09:11.300 talking to, they are not in the first generation of BAM. 00:09:11.900 --> 00:09:14.424 They need to adapt to a changing 00:09:14.424 --> 00:09:19.000 infrastructure world and they need to have the right tools 00:09:19.000 --> 00:09:21.700 where privileged access actually happens. 00:09:21.900 --> 00:09:23.800 And that is in AWS. 00:09:24.200 --> 00:09:25.200 That is in Azure. 00:09:26.000 --> 00:09:29.100 That is privileged accounts towards a SaaS environment. 00:09:29.300 --> 00:09:33.600 So it's really no longer just the traditional BAM that we know, 00:09:33.600 --> 00:09:35.100 session management, vaulting, etc. 00:09:35.300 --> 00:09:36.600 That is foundational. 00:09:37.000 --> 00:09:38.100 Absolutely, they need that. 00:09:38.900 --> 00:09:45.100 But they need the same type of functionality, but translated into a cloud world. 00:09:45.600 --> 00:09:50.000 And that often needs, even on the vendor side, as far as I can see it, 00:09:50.200 --> 00:09:54.800 adding capabilities that have not been there because it's implemented differently. 00:09:55.000 --> 00:09:56.100 It's controlled differently. 00:09:56.300 --> 00:09:58.706 It cannot go through one single session 00:09:58.706 --> 00:10:02.100 management tool because the sessions happen everywhere. 00:10:02.100 --> 00:10:08.700 So it's really an expanding universe of privileged access management capabilities. 00:10:09.000 --> 00:10:12.300 And the second thing that you've mentioned holds true as well. 00:10:12.600 --> 00:10:16.344 So the deep integration into an overall security 00:10:16.344 --> 00:10:20.400 infrastructure and in an overall IAM infrastructure, 00:10:20.700 --> 00:10:24.760 what we call identity fabric, is essential 00:10:24.760 --> 00:10:29.400 because ideally BAM focuses on what it does best 00:10:29.400 --> 00:10:33.800 and it consumes everything that other platforms do well. 00:10:34.900 --> 00:10:37.650 So human lifecycle management for humans using 00:10:37.650 --> 00:10:40.400 privileged accounts can be inherited from IGA. 00:10:41.900 --> 00:10:45.100 And reporting can be delegated to Seam, SOAR, 00:10:45.200 --> 00:10:49.000 or I've talked to our colleague Matthew about the AI SOC. 00:10:49.600 --> 00:10:51.800 There is a deep integration for that as well. 00:10:51.900 --> 00:10:58.200 So it's really like a spider in the web that consumes and provides capabilities 00:10:58.800 --> 00:11:00.100 from an overall fabric. 00:11:00.200 --> 00:11:02.500 And I think that is really interesting. 00:11:02.700 --> 00:11:05.200 And the same holds true for the BAM itself, 00:11:05.700 --> 00:11:09.400 adding these new capabilities that need to be provided and consumed as well. 00:11:09.600 --> 00:11:12.800 So to have an overall hybrid BAM. 00:11:13.500 --> 00:11:14.800 But now I've been talking a lot. 00:11:15.000 --> 00:11:20.600 That is what we see from the requirements that we see in any type of organization. 00:11:20.800 --> 00:11:22.900 And it's interesting that you've mentioned the smaller ones 00:11:23.500 --> 00:11:27.300 that just want to make sure that they do the basics well. 00:11:27.300 --> 00:11:29.600 So that's really interesting. 00:11:30.700 --> 00:11:32.300 And before you jump into the next question, 00:11:32.400 --> 00:11:35.600 I think that from what I hear, the challenge is that many organizations 00:11:36.200 --> 00:11:38.200 hear the phrase identity fabric, 00:11:38.600 --> 00:11:41.622 and they assume they need a fully mature 00:11:41.622 --> 00:11:45.400 identity architecture before integrating anything. 00:11:45.600 --> 00:11:47.800 And I think that's not realistic. 00:11:47.900 --> 00:11:51.900 It's not how we discuss this concept of identity fabric. 00:11:51.900 --> 00:11:55.800 So you don't need to have a perfect maturity to gain value from integration. 00:11:55.800 --> 00:11:59.600 But you need a reasonable, stable identity foundation. 00:12:00.300 --> 00:12:02.800 So you don't need, as we've been talking in previous, 00:12:02.900 --> 00:12:04.800 or you've been talking in previous podcast recordings, 00:12:05.000 --> 00:12:09.600 that you don't need to add the latest technology to your existing infrastructure. 00:12:09.800 --> 00:12:12.900 You just need to be able to connect all the dots, 00:12:13.100 --> 00:12:16.600 to orchestrate them, to have a more signals-driven approach. 00:12:16.700 --> 00:12:20.300 So you have a strong identity foundation from the very beginning. 00:12:20.900 --> 00:12:21.200 Exactly. 00:12:21.000 --> 00:12:23.200 That also means that you can, 00:12:23.200 --> 00:12:26.100 and you typically will start with a lower level of maturity, 00:12:26.400 --> 00:12:27.500 which is perfectly fine. 00:12:28.400 --> 00:12:32.500 And such a fabric helps you in taking the right next step. 00:12:32.600 --> 00:12:35.800 You won't move from maturity two to maturity five, 00:12:35.900 --> 00:12:37.200 all automated, all well. 00:12:37.400 --> 00:12:38.800 Nope, that won't happen. 00:12:39.200 --> 00:12:43.300 So it's really a continuous improvement process. 00:12:43.400 --> 00:12:47.000 And if you have a proper lifecycle management in your IGA, 00:12:47.200 --> 00:12:48.300 and you can inherit that, 00:12:48.700 --> 00:12:51.400 that really helps you in admin processes for PAM. 00:12:51.400 --> 00:12:54.300 So if a person is no longer with the organization, 00:12:54.900 --> 00:12:58.000 maybe there shouldn't be account for that person in the PAM system. 00:12:58.200 --> 00:13:00.000 So that is what I mean by integration. 00:13:01.400 --> 00:13:06.000 So yeah, that's really clearly reflecting what we see also in the market. 00:13:07.300 --> 00:13:11.100 It's more cloud, it's more modern technologies. 00:13:11.300 --> 00:13:12.700 We'll get to that later. 00:13:13.700 --> 00:13:17.500 And yeah, it's really an evolution of a security platform 00:13:17.500 --> 00:13:21.700 that was a bit boring five or eight years ago. 00:13:21.900 --> 00:13:25.600 And it is key and center for security infrastructure just right now. 00:13:26.000 --> 00:13:29.600 But back to your research, what was striking for you? 00:13:30.000 --> 00:13:31.000 What was added? 00:13:31.100 --> 00:13:35.400 What has been added to the set of capabilities that PAM now serves? 00:13:36.800 --> 00:13:42.800 Well, a lot of vendors are starting to integrate some of the Keen features. 00:13:43.300 --> 00:13:46.700 But there was a lot of talk on agentic AI. 00:13:46.700 --> 00:13:48.200 And NHIs. 00:13:49.700 --> 00:13:56.700 And from what I get is that the biggest mistake organizations do 00:13:56.700 --> 00:14:01.000 is that they still treat NHIs as, let's say, technical artifacts 00:14:01.000 --> 00:14:04.800 rather than identities with operational authority. 00:14:05.100 --> 00:14:08.900 So service accounts, API keys, workload identities. 00:14:09.200 --> 00:14:15.900 They're often created quickly to solve, let's say, instant operational problems. 00:14:15.900 --> 00:14:18.100 But then they're forgotten entirely. 00:14:18.800 --> 00:14:22.600 And most enterprises can tell you the number of employees they have. 00:14:23.100 --> 00:14:26.500 But I think very few can tell you the number of machine identities 00:14:26.500 --> 00:14:28.000 they have in their environment. 00:14:28.200 --> 00:14:33.800 And that becomes dangerous because NHIs often accumulate privilege silently over time. 00:14:34.500 --> 00:14:36.800 And eventually, you end up with machine identities 00:14:37.000 --> 00:14:40.300 holding persistent access across multiple systems. 00:14:40.400 --> 00:14:42.700 And that's one of the challenges that I mentioned earlier. 00:14:42.900 --> 00:14:44.600 So this visibility issue. 00:14:45.600 --> 00:14:48.600 And agentic AI, well, it's amplifying this problem 00:14:48.600 --> 00:14:54.100 because these systems are not only executing predefined tasks, 00:14:54.100 --> 00:14:56.600 but they can also make conditional decisions. 00:14:57.500 --> 00:14:59.100 They can invoke APIs dynamically. 00:14:59.500 --> 00:15:02.300 They can operate semi-autonomously. 00:15:03.500 --> 00:15:07.700 And many organizations approach this in the wrong way, from my perspective, 00:15:07.700 --> 00:15:12.200 by focusing almost entirely on authenticating the AI agent itself. 00:15:12.200 --> 00:15:17.700 Of course, authentication matters, but it's not the central problem. 00:15:18.000 --> 00:15:22.000 I think that the critical issue is authorization, 00:15:22.600 --> 00:15:25.400 granularity, and runtime constraints. 00:15:25.700 --> 00:15:27.900 So what actions can the agent perform? 00:15:28.300 --> 00:15:29.400 What's the intention behind? 00:15:29.800 --> 00:15:30.600 Under what conditions? 00:15:30.900 --> 00:15:31.600 Et cetera, et cetera. 00:15:31.700 --> 00:15:38.600 So we see a lot of these vendors trying to address these agentic AI challenges. 00:15:39.300 --> 00:15:44.500 And also, there's a lifecycle problem, like you mentioned not long ago. 00:15:45.400 --> 00:15:49.000 And that creates another issue. 00:15:49.100 --> 00:15:52.200 And that's why we also see this convergence between IGA and PAM. 00:15:52.900 --> 00:15:55.600 So if I can say with AI agents, 00:15:55.700 --> 00:15:59.200 I think that the industry is only beginning to understand 00:16:00.300 --> 00:16:01.700 the operational implications. 00:16:02.200 --> 00:16:07.900 And most enterprises are still thinking about AI risk at the model layer. 00:16:08.600 --> 00:16:12.200 The more immediate issue from, let's say, a PAM perspective 00:16:12.500 --> 00:16:15.200 is the privilege execution authority. 00:16:16.300 --> 00:16:21.500 So how are we going to manage privilege over time with these new systems? 00:16:21.700 --> 00:16:25.100 I think whenever I talk to our advisory customers 00:16:25.200 --> 00:16:31.900 and how we can categorize or assess these NHI and even agentic AI, 00:16:32.600 --> 00:16:35.600 consider them as privileged, because most probably they are. 00:16:36.100 --> 00:16:40.600 So they hold more access rights than the typical user, 00:16:41.000 --> 00:16:42.700 more access rights than they typically should. 00:16:43.400 --> 00:16:47.200 Or they have to have more because the actual decision 00:16:47.200 --> 00:16:49.700 which access will be needed is done at runtime. 00:16:49.900 --> 00:16:54.500 And then they are only limited by more or less rough guidelines 00:16:54.500 --> 00:16:56.100 or guardrails, and that's it. 00:16:57.000 --> 00:17:00.600 So considering PAM being a key component 00:17:00.600 --> 00:17:05.600 for solving the overall area of NHI challenges, 00:17:05.900 --> 00:17:10.900 I think that is fair to say that PAM will play an important role, 00:17:11.200 --> 00:17:14.400 not the only role, as you said, well integrated into an architecture. 00:17:15.600 --> 00:17:17.700 But without a proper PAM solution, 00:17:17.700 --> 00:17:21.000 you might not get a grip on your NHI challenges. 00:17:21.200 --> 00:17:22.800 That's what I'm convinced. 00:17:23.100 --> 00:17:25.100 So it's good to see that it's in the market out there. 00:17:26.300 --> 00:17:29.000 And one solution that we often say is, 00:17:30.000 --> 00:17:32.400 we need to have short-lived credentials, 00:17:32.700 --> 00:17:34.900 ephemeral credentials, just-in-time access. 00:17:36.100 --> 00:17:37.000 How has that evolved? 00:17:37.400 --> 00:17:41.600 Just-in-time comes or stems from privileged access management. 00:17:42.300 --> 00:17:45.500 Is this now capable of doing that at scale, 00:17:45.700 --> 00:17:48.400 at volume, and also at machine speed 00:17:48.400 --> 00:17:50.900 when we're talking about NHI and just-in-time access? 00:17:51.500 --> 00:17:52.500 Well, yeah, that's the challenge. 00:17:52.600 --> 00:17:54.500 If I'm not mistaken, in my report, 00:17:54.500 --> 00:17:57.700 as I mentioned, there were 36 vendors participating 00:17:58.200 --> 00:18:03.800 and only one of them did not provide just-in-time features. 00:18:04.400 --> 00:18:05.200 It was on the roadmap. 00:18:05.500 --> 00:18:08.900 So let's just say that all of them are covering this. 00:18:09.100 --> 00:18:12.300 So conceptually, just-in-time is easy to agree with. 00:18:14.000 --> 00:18:17.600 Very few security leaders argue, of course, 00:18:17.700 --> 00:18:22.100 in favor of admin access, on persistent admin access. 00:18:22.100 --> 00:18:25.900 So although these vendors claim to, 00:18:27.700 --> 00:18:30.000 they're trying to get rid of standing privilege, 00:18:30.700 --> 00:18:33.500 they still exist and it's still a problem. 00:18:34.500 --> 00:18:37.400 And just-in-time access is supposed to reduce this friction, 00:18:37.600 --> 00:18:38.700 supposed to solve this issue. 00:18:39.000 --> 00:18:42.800 But many organizations struggle with implementing it right. 00:18:43.400 --> 00:18:46.200 So the first challenge that I see is that, 00:18:47.800 --> 00:18:50.900 again, is this identity and entitlement visibility. 00:18:50.900 --> 00:18:53.500 So you cannot implement just-in-time effectively 00:18:53.500 --> 00:18:56.800 if you do not have an overall picture 00:18:56.800 --> 00:18:59.600 and you don't understand who currently has access, 00:18:59.900 --> 00:19:01.600 who has privilege, why they have it, 00:19:01.900 --> 00:19:04.200 and which systems are impacted by that. 00:19:04.900 --> 00:19:07.300 The second issue is operational integration. 00:19:07.600 --> 00:19:10.100 So just-in-time is not just a single feature. 00:19:10.300 --> 00:19:14.000 It also depends on orchestration between identity providers, 00:19:15.100 --> 00:19:18.600 between platforms, ticket systems, policy engines. 00:19:18.600 --> 00:19:21.100 So in heterogeneous environments, 00:19:21.400 --> 00:19:22.500 this can be very complicated. 00:19:23.100 --> 00:19:26.200 And the third issue is, in a way, 00:19:26.600 --> 00:19:29.500 you can understand it as maybe cultural resistance. 00:19:30.100 --> 00:19:33.600 So security teams often underestimate 00:19:33.600 --> 00:19:35.500 how much organizational behavior 00:19:35.500 --> 00:19:37.300 depends on persistent privilege. 00:19:38.000 --> 00:19:41.800 So developers want deployment velocity, 00:19:42.700 --> 00:19:46.100 infrastructure teams want rapid troubleshooting capabilities. 00:19:46.900 --> 00:19:50.600 So if just-in-time is introduced as a security mandate 00:19:50.600 --> 00:19:53.600 without any operational redesign, 00:19:54.500 --> 00:19:56.700 it could be challenging for those teams. 00:19:57.200 --> 00:19:59.800 So in a way, a realistic transition 00:19:59.800 --> 00:20:05.000 usually starts with a higher privilege reduction 00:20:05.000 --> 00:20:08.000 rather than a universal just-in-time 00:20:08.100 --> 00:20:09.600 everywhere on day one. 00:20:10.400 --> 00:20:13.200 So focusing first on high-risk admin access 00:20:13.200 --> 00:20:15.100 is typically maybe the first target. 00:20:16.200 --> 00:20:20.300 Then organizations expand toward cloud privilege elevation, 00:20:21.400 --> 00:20:24.700 developer workflows, and ephemeral infrastructure access. 00:20:25.000 --> 00:20:27.400 So it's like step-by-step, right? 00:20:27.400 --> 00:20:28.500 It's not something that can be done 00:20:28.500 --> 00:20:29.600 from one day to the next. 00:20:30.000 --> 00:20:34.000 All vendors are attempting to implement just-in-time 00:20:34.000 --> 00:20:35.400 and get rid of standing privileges. 00:20:35.600 --> 00:20:37.900 But I believe that the operational reality 00:20:37.900 --> 00:20:41.600 for a lot of their customers and a lot of enterprises, 00:20:41.800 --> 00:20:44.300 it's much harder than it sounds. 00:20:44.300 --> 00:20:45.800 Right, and I think, yeah, 00:20:45.900 --> 00:20:50.100 once you introduce just-in-time access as a mandate 00:20:50.100 --> 00:20:52.600 and this is not done properly, 00:20:52.700 --> 00:20:54.200 people will find a way to evade it. 00:20:55.400 --> 00:20:58.400 So when we think of PAM having started 00:20:58.400 --> 00:21:00.800 out of more or less managing shared accounts, 00:21:00.900 --> 00:21:05.000 so the typical root DB admin, domain admin accounts, 00:21:05.800 --> 00:21:07.200 they are still around. 00:21:08.000 --> 00:21:11.800 So I think this is also at least a part 00:21:11.800 --> 00:21:14.200 of the responsibility of the vendors 00:21:14.200 --> 00:21:16.800 to make this as easy as possible. 00:21:17.200 --> 00:21:19.900 So the most secure solution 00:21:19.900 --> 00:21:25.000 should also be the most easy option to choose. 00:21:25.500 --> 00:21:27.700 And I think that's something 00:21:27.700 --> 00:21:30.300 where these highly technological solutions 00:21:30.300 --> 00:21:33.300 sometimes struggle, but this is just my perception 00:21:35.000 --> 00:21:38.200 because everything that is more secure sounds 00:21:38.200 --> 00:21:40.500 more complicated, let's avoid it. 00:21:41.400 --> 00:21:43.400 That's not the way to move forward. 00:21:45.400 --> 00:21:48.000 Yeah, so, but at least as you say, 00:21:49.200 --> 00:21:52.200 practically every vendor provides just-in-time access. 00:21:52.500 --> 00:21:54.400 So there is the way to move away 00:21:54.400 --> 00:22:00.900 from standing privileges and go to more least privileged, 00:22:01.500 --> 00:22:05.600 more time-bound and ephemeral access 00:22:05.600 --> 00:22:06.800 only when it's needed. 00:22:07.000 --> 00:22:10.100 Otherwise it's not even assigned to the account. 00:22:11.600 --> 00:22:13.600 A question that is close to my heart 00:22:13.600 --> 00:22:15.300 that I see in my practice 00:22:15.600 --> 00:22:17.900 at several customer sites already. 00:22:18.000 --> 00:22:19.200 This is the question about, 00:22:20.600 --> 00:22:22.000 where does the system actually run 00:22:22.000 --> 00:22:23.000 when it comes to ownership? 00:22:23.200 --> 00:22:26.600 Not only which platform it runs on, 00:22:27.100 --> 00:22:31.400 cloud, on-prem, private cloud, software as a service. 00:22:31.500 --> 00:22:34.900 It's really about who owns it, who runs it, 00:22:35.000 --> 00:22:36.200 who has access to the system, 00:22:36.700 --> 00:22:39.600 who has in the end final access 00:22:39.600 --> 00:22:41.100 to the keys to the kingdom, 00:22:41.500 --> 00:22:43.200 or can I run it on my own? 00:22:43.900 --> 00:22:48.100 So the other extreme is complete deployment sovereignty. 00:22:49.400 --> 00:22:51.500 This is trend that you also see with the vendors 00:22:51.500 --> 00:22:55.100 that they allow to run this where you want. 00:22:55.300 --> 00:22:59.000 Yeah, so the decision has become much more strategic 00:22:59.000 --> 00:23:01.000 than it was, let's say five years ago. 00:23:01.300 --> 00:23:05.200 So historically the question was mostly operational. 00:23:05.400 --> 00:23:08.800 So do we want to manage the infrastructure ourselves 00:23:08.800 --> 00:23:10.900 or outsource that burden to the vendor? 00:23:12.200 --> 00:23:15.400 And now the conversation is increasingly moving 00:23:15.400 --> 00:23:18.300 into topics such as sovereignty, jurisdiction, 00:23:20.100 --> 00:23:22.500 auditability, regulatory exposure, 00:23:23.100 --> 00:23:25.200 especially among the European vendors. 00:23:25.900 --> 00:23:28.100 So something interesting is that 00:23:28.100 --> 00:23:30.200 the first two to three slides 00:23:30.200 --> 00:23:31.300 when I was talking to them, 00:23:31.300 --> 00:23:36.900 they would show me a slide on how we are gonna take Europe 00:23:36.900 --> 00:23:39.800 on this digital sovereignty journey. 00:23:40.800 --> 00:23:42.400 So that was an interesting, let's say, 00:23:42.600 --> 00:23:44.900 change from previous reports. 00:23:46.300 --> 00:23:49.100 So PAM platform sit close to the core 00:23:49.100 --> 00:23:51.400 of enterprise control infrastructure. 00:23:51.500 --> 00:23:52.800 So they manage, as we know, 00:23:53.000 --> 00:23:54.200 privileged credentials, secrets, 00:23:54.600 --> 00:23:56.900 session telemetry, policy decisions, et cetera. 00:23:57.400 --> 00:23:58.700 So in many organizations, 00:24:01.800 --> 00:24:05.200 PAM becomes one of the most sensitive security systems 00:24:05.200 --> 00:24:06.100 in their environment. 00:24:06.900 --> 00:24:09.300 On the one hand, if we look at SAS, 00:24:09.600 --> 00:24:12.100 so SAS delivery has advantages. 00:24:12.400 --> 00:24:15.700 So it's faster deployment, lower operational overhead, 00:24:16.200 --> 00:24:19.000 quicker feature delivery, easier scalability. 00:24:19.600 --> 00:24:21.500 But for many organizations 00:24:21.500 --> 00:24:25.000 that are in highly regulated industries, 00:24:25.200 --> 00:24:27.500 that's becoming interesting to think about. 00:24:28.000 --> 00:24:30.000 So the key issue is not simply, 00:24:30.500 --> 00:24:34.300 let's say where the data is stored, 00:24:34.300 --> 00:24:37.400 but it's where the operational authority resides. 00:24:38.200 --> 00:24:39.500 So if privileged access, 00:24:41.200 --> 00:24:43.300 telemetry or session recordings or secrets, 00:24:44.200 --> 00:24:45.100 and they are controlled 00:24:45.300 --> 00:24:47.500 through externally hosted infrastructure 00:24:47.500 --> 00:24:49.400 subject to foreign jurisdiction, 00:24:50.300 --> 00:24:51.900 subject to foreign laws, 00:24:52.800 --> 00:24:54.400 some organizations will view that 00:24:54.400 --> 00:24:58.100 as an unacceptable dependency vulnerability. 00:24:58.500 --> 00:25:00.800 That does not mean that SAS is insecure. 00:25:01.000 --> 00:25:04.200 It means that organizations need to evaluate deployment 00:25:04.300 --> 00:25:06.100 through a risk governance lens 00:25:06.100 --> 00:25:08.600 rather than purely a convenience lens. 00:25:09.100 --> 00:25:13.700 So what wasn't before efficient for some organizations, 00:25:14.000 --> 00:25:19.400 it could become now a vulnerability or a dependency. 00:25:20.100 --> 00:25:21.900 And the question is not really, 00:25:22.200 --> 00:25:24.200 so which deployment model is modern? 00:25:24.400 --> 00:25:26.700 I think the right question should be 00:25:26.700 --> 00:25:28.800 which deployment model aligns 00:25:28.800 --> 00:25:31.000 with our operational risk tolerance, 00:25:31.400 --> 00:25:34.200 with our own regulatory obligations. 00:25:34.200 --> 00:25:35.600 Sovereignty requirements 00:25:35.600 --> 00:25:37.900 or internal capability maturity. 00:25:39.100 --> 00:25:41.900 So hybrid models are becoming increasingly common 00:25:41.900 --> 00:25:43.300 precisely because organizations 00:25:43.300 --> 00:25:45.100 want some sort of flexibility 00:25:45.100 --> 00:25:47.300 and control over sensitive components. 00:25:49.600 --> 00:25:53.500 And what I see is that European organizations 00:25:53.500 --> 00:25:56.000 and European vendors increasingly view identity 00:25:56.000 --> 00:25:59.300 and access control as a strategic infrastructure. 00:25:59.400 --> 00:26:01.800 So not just purely technical. 00:26:02.400 --> 00:26:05.500 So it's not about is this spam solution secure, 00:26:05.900 --> 00:26:07.800 but about who controls the platform? 00:26:08.200 --> 00:26:08.900 Where is it operated? 00:26:09.700 --> 00:26:11.200 What legal exposure exists? 00:26:11.900 --> 00:26:13.600 Can we avoid vendor locking? 00:26:14.200 --> 00:26:17.000 And I think that reflects a broader European concern 00:26:17.000 --> 00:26:20.000 about reliance on non-EU providers. 00:26:20.700 --> 00:26:25.300 It doesn't mean that Europe should pursue sovereignty 00:26:25.300 --> 00:26:28.400 in a purely ideological or isolationist way, 00:26:28.400 --> 00:26:31.300 but from a more practical perspective. 00:26:31.300 --> 00:26:35.200 So where does dependency create real risk for me? 00:26:36.000 --> 00:26:37.200 And just to conclude, 00:26:37.600 --> 00:26:39.900 I think that's also an opportunity for European vendors 00:26:39.900 --> 00:26:42.400 to try to address and close these gaps 00:26:42.700 --> 00:26:46.400 that European organizations are starting to talk about, 00:26:46.600 --> 00:26:48.900 but also non-EU providers 00:26:49.000 --> 00:26:51.500 and let's say North American vendors, 00:26:52.200 --> 00:26:56.200 they should focus more on the scalability, 00:26:56.600 --> 00:26:59.000 on the components, on execution, 00:26:59.600 --> 00:27:02.900 and maybe be more careful with marketing claims 00:27:02.900 --> 00:27:05.100 because marketing claims are not enough. 00:27:06.000 --> 00:27:08.400 Buyers increasingly want structural safeguards 00:27:08.400 --> 00:27:11.700 of clear governance, transparent operations, 00:27:12.200 --> 00:27:14.900 contractual protections, and all of these things. 00:27:15.000 --> 00:27:16.900 But in an ideal world, that also would mean 00:27:16.900 --> 00:27:18.900 that I can really choose a vendor 00:27:18.900 --> 00:27:21.000 based on the capabilities they provide 00:27:21.000 --> 00:27:23.700 and then choose the adequate deployment model to say, 00:27:23.800 --> 00:27:26.300 okay, yeah, I take this from vendor XY 00:27:26.300 --> 00:27:30.300 who is from the EU or is not because it doesn't matter 00:27:30.300 --> 00:27:33.000 because I run it on my own private cloud 00:27:33.300 --> 00:27:36.200 and I have the full control over the platform 00:27:36.200 --> 00:27:40.000 independent of the way that they decide 00:27:40.000 --> 00:27:41.000 to provide the service. 00:27:41.100 --> 00:27:43.800 So if I have full choice in the full spectrum 00:27:44.000 --> 00:27:46.600 between SaaS and self-hosted, 00:27:47.800 --> 00:27:50.200 so then I can really look at the capabilities 00:27:50.200 --> 00:27:52.500 and even can change deployment over time 00:27:52.500 --> 00:27:53.700 with the same product. 00:27:53.700 --> 00:27:57.700 That would be in an ideal world, a good approach. 00:27:58.500 --> 00:28:01.400 And you can always readjust your risk assessment 00:28:01.400 --> 00:28:03.900 when it comes to I entrust this product 00:28:03.900 --> 00:28:08.100 with my most secret details of the organization. 00:28:08.700 --> 00:28:11.300 So that might change over time. 00:28:11.400 --> 00:28:11.900 Yes. 00:28:12.200 --> 00:28:14.300 Or it's changed by somebody else. 00:28:14.400 --> 00:28:17.200 I'm looking at you, Dora, or at you, Nis2 00:28:17.200 --> 00:28:18.400 or something like that. 00:28:18.600 --> 00:28:21.800 So that might also be an issue 00:28:21.800 --> 00:28:24.100 when it comes to third-party risk management, etc. 00:28:24.700 --> 00:28:26.900 And then the third-party risk is something 00:28:26.900 --> 00:28:29.600 to address with your PAM provider. 00:28:31.700 --> 00:28:32.100 Okay. 00:28:33.800 --> 00:28:35.600 I have to ask this question 00:28:35.600 --> 00:28:37.500 because we are in 2026. 00:28:38.200 --> 00:28:40.700 AI and machine learning in PAM, is it a thing? 00:28:40.700 --> 00:28:41.600 I think yes. 00:28:41.700 --> 00:28:44.600 But how do you see it from the research perspective? 00:28:45.200 --> 00:28:46.400 Yes, of course it is. 00:28:46.600 --> 00:28:49.700 But there's an enormous amount of marketing inflation 00:28:49.700 --> 00:28:51.400 around AI capabilities. 00:28:51.800 --> 00:28:54.600 Many vendors describe, let's say, 00:28:55.200 --> 00:28:59.700 basic statical thresholding or rule-based correlation 00:28:59.700 --> 00:29:03.200 or risk-based assessment 00:29:03.200 --> 00:29:05.800 as AI-driven behavioral analytics. 00:29:07.600 --> 00:29:09.700 Buyers need to test whether the platform 00:29:09.700 --> 00:29:13.000 is actually producing meaningful detection improvements 00:29:13.000 --> 00:29:17.300 or it's simply relabeling existing analytical functions. 00:29:17.500 --> 00:29:20.600 And I know that buyers are skeptical 00:29:20.600 --> 00:29:22.300 around all these marketing claims. 00:29:23.000 --> 00:29:26.800 They don't really want AI 00:29:26.800 --> 00:29:28.800 if it's just going to be fancy 00:29:28.800 --> 00:29:30.900 or because the competition is doing it. 00:29:31.000 --> 00:29:34.300 They just want you to solve their problems. 00:29:34.600 --> 00:29:37.500 And if AI is going to be able to do that, 00:29:37.600 --> 00:29:38.900 then that's great for them. 00:29:39.200 --> 00:29:42.700 But I think that there's a lot of marketing around that. 00:29:42.800 --> 00:29:47.800 I also think that the other issue 00:29:47.800 --> 00:29:50.100 is false positives. 00:29:50.800 --> 00:29:55.600 For example, when I published my report on ITDR in October, 00:29:55.800 --> 00:29:58.700 there were a large number of PAM vendors 00:29:59.800 --> 00:30:03.400 that are also incorporating ITDR capabilities. 00:30:03.600 --> 00:30:10.500 So that's an area where PAM can leverage some AI features 00:30:10.500 --> 00:30:14.600 to be able to not only detect threats, 00:30:14.800 --> 00:30:17.000 but also be able to respond to them. 00:30:18.300 --> 00:30:20.300 But ultimately, as I said, 00:30:20.400 --> 00:30:25.200 buyers, they want answers to their problems. 00:30:25.400 --> 00:30:26.600 They don't want more AI 00:30:26.600 --> 00:30:28.100 just because it's going to be fancy. 00:30:28.300 --> 00:30:30.600 And I think when we combine the last two topics 00:30:30.600 --> 00:30:32.700 that we have, AI and sovereignty, 00:30:33.000 --> 00:30:35.800 the question is, where is the AI provided from? 00:30:36.000 --> 00:30:39.100 So you have a highly secure PAM solution run on-prem, 00:30:39.500 --> 00:30:41.000 but if you want to use AI features, 00:30:41.100 --> 00:30:42.900 you need to go back to a SaaS service. 00:30:42.900 --> 00:30:46.200 I think that is not necessarily where you want 00:30:46.200 --> 00:30:48.800 to provide the distilled essence 00:30:49.000 --> 00:30:52.900 of your privileged access management telemetry 00:30:53.100 --> 00:30:54.100 to the cloud. 00:30:54.400 --> 00:30:56.200 So I think this is not nothing that... 00:30:56.200 --> 00:31:00.200 So the question is, can you run even the AI for yourself? 00:31:00.400 --> 00:31:01.800 I think that's... 00:31:01.800 --> 00:31:03.200 Or in the self-hosted cloud 00:31:03.200 --> 00:31:06.000 with the proper power behind that 00:31:06.000 --> 00:31:08.800 to actually have the information available 00:31:09.000 --> 00:31:12.800 and the right velocity at the right scale. 00:31:13.200 --> 00:31:15.100 But I think for many organizations, 00:31:15.100 --> 00:31:18.000 using AI as a SaaS service 00:31:18.000 --> 00:31:20.900 provided by a shared platform somewhere 00:31:21.000 --> 00:31:22.500 is not an option either. 00:31:23.200 --> 00:31:25.800 So that might be difficult as well. 00:31:26.800 --> 00:31:28.000 If you sum it up, 00:31:28.500 --> 00:31:31.100 if you look back on the research that you do, 00:31:31.300 --> 00:31:33.600 have we come to a point where it has consolidated 00:31:33.600 --> 00:31:38.200 or is this still a quickly evolving market? 00:31:38.300 --> 00:31:39.500 It has matured, of course, 00:31:39.500 --> 00:31:41.100 because they've been around for years. 00:31:41.900 --> 00:31:43.700 But is the cloud part mature? 00:31:43.700 --> 00:31:45.100 Is it changing? 00:31:45.300 --> 00:31:46.400 What does NHI do? 00:31:47.200 --> 00:31:49.100 There's more to do in the next years, right? 00:31:49.800 --> 00:31:51.200 Of course, yeah, it's mature. 00:31:51.700 --> 00:31:53.500 But since the definition of privilege 00:31:53.700 --> 00:31:55.400 has not only changed, 00:31:55.500 --> 00:31:56.900 but it continues to evolve 00:31:56.900 --> 00:31:59.100 based on what we see in the industry, 00:31:59.300 --> 00:32:00.600 I expect more momentum. 00:32:01.700 --> 00:32:03.600 There are new vendors, new entrants. 00:32:04.000 --> 00:32:06.100 And even after completing my research, 00:32:06.200 --> 00:32:10.300 I spoke to two or three new European PAM vendors. 00:32:10.300 --> 00:32:13.300 So there's for sure room 00:32:13.500 --> 00:32:16.700 for more dynamics around the market. 00:32:17.100 --> 00:32:19.000 But if I can conclude with something, 00:32:19.300 --> 00:32:20.900 it would be, as we discussed, 00:32:21.300 --> 00:32:22.900 PAM should not be thought about 00:32:22.900 --> 00:32:24.800 as an admin security product, 00:32:24.900 --> 00:32:26.500 as a standalone solution. 00:32:28.500 --> 00:32:30.000 We need to change our mindset 00:32:30.000 --> 00:32:35.200 and view PAM as an enterprise authorization layer 00:32:35.200 --> 00:32:38.900 that is part of this identity fabric, 00:32:39.500 --> 00:32:41.500 because it's governing the execution 00:32:41.500 --> 00:32:43.200 of high impact actions, 00:32:43.700 --> 00:32:45.700 not only of humans, but of machines, 00:32:46.200 --> 00:32:49.200 of workloads, AI agents, et cetera. 00:32:50.200 --> 00:32:52.200 And I believe that the organizations 00:32:52.200 --> 00:32:54.500 struggling most are usually the ones 00:32:55.200 --> 00:32:56.600 that are still treating PAM 00:32:56.600 --> 00:32:58.500 as a vault deployment 00:32:59.300 --> 00:33:02.100 owned by a small infrastructure team, 00:33:02.400 --> 00:33:02.800 security team. 00:33:03.100 --> 00:33:05.000 And I believe that the organizations 00:33:05.200 --> 00:33:07.100 making progress are the ones 00:33:07.100 --> 00:33:09.100 that are shifting that mindset 00:33:09.100 --> 00:33:10.300 and treating privilege 00:33:10.300 --> 00:33:13.600 as a continuously governed operational capability 00:33:13.600 --> 00:33:15.700 across the entire identity ecosystem. 00:33:16.500 --> 00:33:18.800 And I expect to see more convergence 00:33:18.800 --> 00:33:20.400 moving forward with IGA 00:33:20.400 --> 00:33:22.000 and other areas of identity. 00:33:22.600 --> 00:33:25.100 So I'm not sure where the market will be 00:33:25.100 --> 00:33:26.600 in the coming years, 00:33:26.700 --> 00:33:28.500 but I expect that there will be 00:33:29.300 --> 00:33:30.900 some interesting and exciting developments. 00:33:31.500 --> 00:33:31.800 Great summary. 00:33:31.900 --> 00:33:33.300 I don't ask any other questions. 00:33:33.300 --> 00:33:35.700 I just highlight that your research is out there. 00:33:35.700 --> 00:33:39.400 So if you are interested in reading more 00:33:39.400 --> 00:33:42.700 of what Alejandro has provided as research, 00:33:42.800 --> 00:33:44.800 so have a look at the Leadership Compass PAM 00:33:44.800 --> 00:33:47.400 that just has been released a few weeks ago. 00:33:47.600 --> 00:33:49.400 So please do so. 00:33:49.700 --> 00:33:50.800 If you have any questions 00:33:50.800 --> 00:33:52.600 regarding this podcast episode, 00:33:52.800 --> 00:33:54.400 regarding what we could cover, 00:33:54.700 --> 00:33:55.800 what Alejandro and I could cover 00:33:55.800 --> 00:33:56.900 in an upcoming episode 00:33:56.900 --> 00:33:58.400 on more details about PAM, 00:33:58.800 --> 00:34:01.100 let us know, reach out to Alejandro, 00:34:01.400 --> 00:34:02.200 reach out to me. 00:34:02.200 --> 00:34:04.100 We are easy to find on LinkedIn. 00:34:04.100 --> 00:34:05.900 The mail address is easy to find. 00:34:06.500 --> 00:34:08.100 And if you have an immediate question 00:34:08.100 --> 00:34:10.700 regarding this video or this podcast, 00:34:10.800 --> 00:34:12.800 just leave a message, a question 00:34:12.800 --> 00:34:14.300 on the platform that you're using 00:34:14.400 --> 00:34:16.000 on YouTube in the comment section. 00:34:16.500 --> 00:34:20.100 We do reply and we take your feedback serious. 00:34:20.800 --> 00:34:23.300 And you can influence the next episode 00:34:23.300 --> 00:34:25.400 on PAM by your questions. 00:34:25.900 --> 00:34:27.900 So having said that, Alejandro, 00:34:28.100 --> 00:34:29.800 thank you very much for being my guest today. 00:34:29.900 --> 00:34:33.100 Thank you very much for this great research, 00:34:33.100 --> 00:34:35.200 because I use it as an advisor 00:34:35.300 --> 00:34:36.500 in my daily work. 00:34:36.800 --> 00:34:37.900 So this is really something 00:34:37.900 --> 00:34:40.400 that is also fruitful for our work 00:34:40.400 --> 00:34:41.900 in the advisory business. 00:34:42.400 --> 00:34:44.200 So thank you very much for being here today. 00:34:44.700 --> 00:34:45.000 Thank you, Matthias. 00:34:45.100 --> 00:34:45.500 I appreciate it. 00:34:46.800 --> 00:34:47.800 Thank you and bye-bye.