Why Static Credentials Are Your Fastest-Growing Attack Surface

Welcome to our KuppingerCole Analysts webinar, Why Static Credentials Are Your Fastest-Growing Attack Surface, or why should we go away from long-lived credentials or ideally more or less C++. This webinar is supported by Akeyless, and the speakers today will be Oded Hareven, who is CEO and co-founder of Akeyless, and me, Martin Kuppinger. I'm the principal KuppingerCole Analysts, and during this webinar, we basically will do two things.

We will have short presentations by me and Oded, in that order, and in the second phase of the webinar, then, we will go into more sort of a fireside chat between the two of us, where we will share our perspectives on this market and what we expect or what we must change, and how should we deal with the complexity of credentials and secrets in today's world. Before we do that, I want to do a little bit of housekeeping. Audio control, nothing to do here.

Pulse, we will run two pulse during the webinar, one right after that slide, and one at the end of my part of the presentation. There will be a Q&A session, plus there will be the fireside chat. In this case, it means if you have questions, enter them whenever they come to your mind, and we will pick up the questions, potentially also during the fireside chat, if they fit into the flow of our conversation or otherwise handle them towards the end of the webinar.

Then, there's the recording. We are soon after the webinar. Before we look at the agenda, a quick poll, and that is one which I believe is very simple to answer, and I would dare to say we should end up with a 100% and 0% results. You can make up your mind in which order that will be. Do you have comprehensive, so really comprehensive insight into where in your organization secrets and which so do you feel you really know where the secrets are and which secrets you have to handle?

We leave that poll open for a bit, so you have a bit of time to respond to the poll, and I'm curious whether I'm right as my guess about the results. Where I'd like to look at it when we look at this entire topic is fix the cause, not the symptom. Looking a bit at what is really the thing we should look at. The second part of my audit will be a quick presentation around a phrase that the need for going secretless. Before we jump in our fireside chat and the Q&A, as I've said, when there are questions, feel free to enter the questions at any time.

In the questions area, the lower right of the webinar screen, the more questions we have, as I've said, the more interesting it will be, so don't be shy, bring up your questions. When we talk about this entire scene and secrets and credentials, we end up with quite a number of different things to look at. We have passwords, we have API keys, we have encryption keys, the private keys of certificates, FIDO2 tokens, SSH keys, pass keys right now. We see also there are new things like what came up with FIDO2, what came up with pass keys, and more.

One thing they have in common, they are adding to your attack surface. Every secret is something that is of interest to attackers. Pretty simple. Be it old school passwords, be it new school pass keys, attackers love secrets. That is a point where we need to think about. I think that the point is we have a situation nowadays where we have a sprawl of types of we're living in an age where we are facing sort of an ever-increasing number of cyber attacks. So we have the pressure from both ends, we need to get a crib on.

When we look at this entire domain, then we have usually a life cycle, there might be some more, some less stages, depending on the type of credential. But at the end of the day, there's a creation that might be just a creation basically of the secret itself. It might be the creation of an identity, which then is sort of related to the creation of a secret. So you create a user account as a password, or you create an API token. In both cases, there's a creation. Unfortunately, a lot of this tends to happen nowadays in the wild. So some of that is clearly under control.

We have defined lifecycle management processes where we look at our workforce, our employees, then we tend to have defined workflows where we get a crib from the very beginning. And we have other areas where we don't have, where these things pop up, where they might be done partly automatically, but be done in one of these as a code approaches. We need to understand where they are. We need to inventory. This is the common way we look at it. And this is Ross Complex, as you can see, classified. And what is it?

Put them into a wall, which still means we're just trying to bring them into a better place. Question is, is this enough? We need to understand the ownership, which is a huge challenge. So who is really the owner, which not necessarily is the creator. And when we look at ownership discussions, we could spend hours probably in a webinar on just this theme. So what is with a human account? When it's an employee versus when it's a customer, or when it's a traditional shared account, every shared account clearly must have a human owner. And every other secret, in a sense, should also have.

But is it developer? Is it the owner of the business application when we look at the workload side of things that, what some call machine identities? We need to understand this. We need to look at it. What is the posture? So which risks do they carry? You need to monitor what happens with them. Are they under attack? Did they leak?

Rotation, or do some things pop up in us in the Slack channel, or still happening secrets? Like we did decades ago already, putting passwords into a script, putting passwords into code. Some bad practices seem to never die. Putting right now stuff, sometimes even passwords, but also other stuff into Slack channels. We still have them visible. We need to rotate because, and that's one of the things, the longer secret lives, the bigger the risk.

And I think this is, every now and then on LinkedIn, for instance, that pops up one of these metrics is saying, this is the time it needs to crack a password of this strength. The complexity of passwords goes up, the time goes down, but it also demonstrates it's an unsolved problem. So we can use longer passphrases, but it doesn't really solve the thing. We need also to decommission. So when the things tend to live where they shouldn't live anymore, we have a problem. And that leads me to something I call my what, how, and ouch metrics. I use for a couple of scenarios.

Usually I bring up this what, how, ouch metrics when we are looking at challenges that we never have, or that we haven't solved well. So passwords, so we look at changing the password length, the strengths, faster rotation, putting them into a wall. But even when we not look at the quantum cryptography aspects, even the best passwords aren't secure because they are knowledge and people tend to fall trap to phishing attempts, et cetera, or blackmailing or whatever. API tokens.

Yeah, we try to make them very short-lived. Developers complain, we had this AWS bedrock.

Oh, we extend the allowed lifespan. It's totally counterproductive here. And as I said, there are slack channels. We have TLS certificates, which is an ongoing race against the attackers. Bring them the lifetime to down to 47% doesn't solve the problem at all. It shifts the problem, it doesn't solve it. And also the business models don't tend to adapt to the change, the cost potentially increase. Ephemeral SSH certificates to bring up another example, short-lived, fast rotation, fully automated lifecycle. But then you have long running sessions.

It's something for a bit more focused use cases, limited use cases. So it's really not a solution for everything and things must work. And I think the cause is at the end of the day, secrets are living too long. And longer than attackers need to utilize or to weaponize them. So if we reduce lifetime, it's a patch, but it's not the solution. It's not addressing the root cause. And so what I strongly believe is that the entire industry must spend way more time about thinking, how can we go secret-less? How can we go ephemeral?

Which are two a bit different things, but heading in the same direction. And that also means we need even to rethink security protocols, so that we have a sort of a constant exchange or handling or use of different types of cryptographic approaches. So that we go in that sense, ephemeral or secret-less by design and not trying always to patch the challenge. Because this, I think what we have proven is the ouch part. At the end, it still is not solved. It goes wrong. That brings me to my second poll line.

That is, do you have a plan for enterprise secrets management? Which I define as something that covers all types of secrets consistently. So you have a consistent governance and insight into what's happening with secrets across all the types. Do you have a plan for that? Solution in place, project running, early planning stage, or no plans at all.

Again, we leave that poll running for a bit. And with that, I already go back to the agenda. And we look at the need for going secret-less.

And Oded, the stage right now is yours. Thank you so much, Martin. Very happy to be here with you.

I'm Oded, the CEO and co-founder of Akeyless Security, a leading identity security for the AI era. Let's click one more to the next slide. And briefly, I'll talk about Akeyless. So we secured today more than 220 billion transactions for 2025. We've seen a growth of more than 500% for annual growth with a number of machine identity interactions.

When I say interactions, I mean machine-to-machine communication with providing either static credentials, or in further cases, just like Martin has started to discuss, in which we will discuss today even more, is with secret-less approach, meaning providing tokens and dynamic identities that we provide. So generally speaking, it's either static secrets holding, a vaulting solution, the ability to automatically rotate for many types of endpoints to include also certificate flotation, as well as keys rotation. And then with dynamic identities. I'll talk about that even further.

And how do we do that? One click, please. And generally speaking, the company is serving global Fortune 500 and 2000, Fortune 10 as well. We are serving the biggest US retailers, as well as the global financials, as well as great names in the technology space, the largest pharmaceutical companies, providing a multi-cloud and a multi-region operation. Everything is a SaaS hybrid approach, easily to maintain, easily to consume our service from the cloud, and basically infinitely scale within it, much faster to deploy, and so on and so forth.

Prominent investors, great list of partners, and we've been covered by several analysts and endorsed during the years. One click, please. So I want to focus straight to the point with regards to exactly what Martin has mentioned with how not to patch just with secrets management. And the patch of secrets management is basically just to store them and centralize them. Even rotation today, as far as what we are hearing and what we are seeing in the industry, is that even rotation today is something that is just not Why?

Because when you have a certain account, certain identity, and you decide that you wish to rotate it, or you have to rotate it, then unfortunately, number one, in many cases, we see that the rotation is not in a short period of time. So sometimes rotation can be once in 30 days, 90 days a year, or not at all, which is not good enough, because as we know today, the sophistication of attacks are becoming higher and higher with time. And the time span that is used in order to actually attack this particular secret or identity is very short.

So even 30 days rotation today is not necessarily would be a best practice. We see also the push for even shortening the time of certificates of their timeframe to be valid to 47 days.

Again, our opinion as practitioners, as professionals in the market, that it's not enough, and you need to go down. Now, what does it mean? It means that even when you do operate the rotation, there is an identity. And so going back to what I said, the second concern is that the identity itself is there to be and waiting to be attacked. So it can be brute force, even if the So the third generation that we are approaching, the way that we look at the development and the way to go secretless and to reduce the number of secrets, is to go for dynamic identities.

That's the third generation that we help our customers a lot. And actually, I've seen it in my eyes how it can be done. It requires, within Kubernetes environment, containerized environment, ephemeral environment, it's much easier. Within the more static environment, it's a bit harder, but it requires some change.

Today, with the AI and Gen AI era that we're entering into, then code can be opened and can be altered more easily.

But generally speaking, dynamic identities in the notion of whenever a certain workload requires access to a different workload, let's say a backend server that requires access to a database server, then instead of providing it with an identity of that database that will be rotated once in a while, the identity provider, in that sense, the keyless or the advanced secrets management solution, is able to create that particular account on the database and to provide it to the backend server, and then after the use, to delete it.

So a new identity is being created, the specific least privilege entitlements are being provided. This is provided to the actual application server, and whenever it is finalizing its own particular query or particular action or transaction that he's been running, then the identity itself is being deleted. The same goes with secretless. Secretless, complete secretless approach goes even one step further for the fourth generation, where you don't even need a dynamic identity to be created and provisioned on a database or whatever the source is that performs this two-party authentication.

Then the secretless approach basically means no provisioning of an identity rather than issuing a token that eventually the database or whoever will respect.

So that means that, again, if there's a backend a temporary token, and this is why we call that secretless, allegedly there is no secret in that manner, although the token itself obviously is a secret, but when we say as an industry that there is a secretless, we say that the token itself represents an identity without provisioning an identity, so there is no bootfalls attack that can happen versus that particular account because it was never been created.

So that's a small nuance between dynamic identities and secretless, but in general, the third generation and the fourth generation represent a just-in-time approach where credentials, where access is being created on the fly, only when being used, and it is expired and deleted once it is not used.

This kind of approach, the third generation, the fourth generation with the secretless manner, this helps us as an industry to evolve exactly as Martin has mentioned, given that obviously we're protecting, we're not just patching, we're not just adding another secret rather than really solving the manner itself and also reducing the need to vault the secrets.

I'll pause here and maybe just one last slide before, Martin, we go to our discussion, so just one click, just to conclude everything, that I've now described, if you can just one click on the slideshow, everything that I've now described is provided within the identity security platform of Akeyless that, by the way, today we are releasing the keynote that goes over all of that, so this is basically a scoop here within the Coping a Goal webinar today.

We are providing a full keynote with regards to all of those capabilities within machine identity security, AI agent identity security, and human identity security. We'll be happy to see you later there. That's it on my end, Martin, back to you.

Okay, great, that was super informative, very helpful, and so as I said, we will go into the fireside chat directly and look at some of the things you brought up, and I think what I found interesting, and again, maybe to the audience, if you have questions, enter them into the questions area so that we pick them up. I think let's start with one point, which I find very interesting.

So, you basically said your third generation, your slide, your fourth generation, they stand a bit side by side, so they are, in that sense, the innovation away from our traditional approaches where we sort of left secrets and tried to just get a bit of grip on them towards we work differently. So, would you say that these live side by side?

So, when I look at it, I would say they probably will live side by side when we look at different types of use cases, so not everything works everywhere. When you look at the legacy world, et cetera, then we are probably a little bit less flexible, and I think you also have, maybe that's something you can elaborate a bit, you also had, for instance, the zero standing privileges also mentioned around SPIFI in your Gen 4.

Yeah, so you've mentioned, just to make sure that I fully grasp your question, you've mentioned the certificates, right, and whether they live in parallel to secrets and different secret types, right? Yeah, I would more say whether the third generation you've brought up, so zero standing privileges is probably something which lives, I think we will still, you know, we will have passwords or Gen 0 even in decades from now, but when we look at the modern part, it's probably even also there a combination of the third generation approach, you called it in the fourth generation approach.

Yes, by all means, and you nailed it exactly, Martin, as we see it as well, and as I see it, there is no complete shift between generations, right? There is no place where we can stop consume static secrets at all, because in a way, there are places where static secrets are required, and the best you can do is to rotate them, okay? So let's say that the move to the second generation is something that ideally we can go to with the existing technologies that are there, okay?

The third generation and the fourth generation, which is using, start using dynamic identities, dynamic secrets, and tokens with secretless approaches, et cetera, those are the things that we as an identity practitioners within organizations for that sense, okay? The industry itself must advocate more and to be able to educate the developer teams, the platform teams, the architecture teams. This will require what I call a phenomenon of shift identity lift.

We need, just like we've done very successfully within the cybersecurity industry, we've been able to take more and more of capabilities of application security, being able to secure the code, to scan codes and code vulnerabilities. In the last five, six, seven years, we've seen a great move in which there is a better connection between the developers and the security.

Nowadays, our next challenge as an identity practitioners and professionals is to do the same, but for identity, to shift identity lift and to get those different, let's call it newer authentication schemes, authentication and authorization schemes, to get them sooner within the development process, where it will eventually bring us with a new era or allow us to mature with greater generations of start using the methods of basically asking for a temporary credential and asking for a token, okay? Because it does require a different approach of how you authenticate and how you write the code.

I think it's, when I look at the identity space, for instance, and we take another area, which is OPA, open policy agent, or in more general speaking, externalizing authorizations, it's also, we need to make changes. So it's rather difficult to implement something like that. And always a bit of a workaround to implement it in an existing environment. It's significantly simpler if we embed it into the code.

And so what you're basically saying is we must at all levels, from cloud services to commercial software of any other type to all the bespoke software developed in organizations, we must shift to an approach where developers go away from using any type of sort of static credentials, long living secrets. What I feel about it, I'm looking at it, you know, let's go back to policy-based, so externalizing authorization, it's not an entirely new concept. So back in 1976, IBM released RACF, which basically does that. We call it a constraint environment. So probably easier to do there.

But I think it demonstrates the idea for itself is not new. And what I think is very important to make this a success is to make it super, super simple for developers. It must be simpler for developers to call for that to a service than it is to do it themselves. I think it's the only way to make it work, make it super easy, make it deliver a service. And for me, I'm very curious about your opinion. There's also something where we must rethink the way we do identity management, because currently, the typical attitude is a bit, oh, sorry for the identity people in the room.

Yes, interesting problem. We will look at it and think about a solution. And maybe six months later, there might be a first pilot we can run. Developers won't wait six months. We must take a service delivery attitude, which means we have to service when it's needed and it's done in a way that works for the developers without breaking our identity and security. Exactly.

Look, I'm so happy that you brought this example. In general, as you know, as I, in general, the history repeats itself in terms of the patterns of design, right? Even containerization have been implemented back in the mainframe back in the days, right? So I've seen it in my own eyes as well, back serving in the Israeli defense forces, looking at that change, you know, mainframe to distributed world, to the Windows and Linux, et cetera. And eventually, virtualization that came was presented, companies and solutions like VWare, et cetera.

And then nowadays, again, containerization is another type of virtualization, but a higher pace. Look, there's a good news here of what we're now talking, which is how to have identity folks to react faster, to be able to react faster, to be able to bond better with the developers in order to really solve the issues, to really solve the identity challenge, right? Given that breaches, more and more breaches are being operated using some kind of taking advantage of a certain identity and using it.

Now, the good news here is that we might have missed on one end, we might have missed the containerization trend, because this is where identity could have injected itself and say, while you containerize, while you have multi-service, multi-function, you're changing the architecture of your application. While you do so, please also add, let's discuss a newer authentication methods, a newer way to do it better. So we might, in some cases, we might have missed that opportunity. We have a call that will solve it for you.

Yes, yes. I think there's a way to say, I had this conversation around XAML or XACML many years ago, where I said, no one wants to see or write XAML. The developer wants, back in the days, it was Java, and so it was just to have a method call that returns yes or no or something in between. Nothing else.

Yeah, the tokens were very complex back in the days. I fully hear you, and I remember that exactly, and it was more difficult to explain and exchange information with the developers. But these days, and here, where I go, there are two things here that now are happening.

One, the AI era brings a Gen AI approach, meaning that code can be touched much better, right, and easier and quicker. So that's a good news that we can leverage during the next few years, so that there is no saying that someone will tell you anymore, I can't touch this code, right, because it will take me years to refactor and when we will start changing the authentication methods and the schemes that we're leveraging. So that's number one, that's good for the industry. The notion of changing code and updating code will be faster.

Number two is the shift from the terminology around secrets management or managing your secrets or vaulting your secrets to the identity provider scheme, okay, and that's a different approach. Instead of reactively, as an identity profession, okay, let's call it now, we are very reactive because we need to discover the identities of someone else is doing, right, you called it also the mess that is happening, we are reactively trying, looking at API keys that are being created in the cyberspace, and we need to discover them and then to take ownership, right, this is a very reactive approach.

The future is a proactive approach by going out and say, we as an identity people, we provide identity provider to the organization, it is very easy to call it, it's a very clear service within the organization, and I'm in contact with some organizations that start to implement it, and this is providing an authentication, dynamic identities, dynamic tokens, and that's the future.

And it's interesting that you bring this up because when we brought up the idea of the identity fabric a couple of years ago, which right now has been widely recognized, one of the things I have on my slide is the top of this, I don't have it on hand here, a slide, but basically there's one layer where we manage, for instance, that service cloud or legacy application, and there's another layer, which is, I call it the identity API layer, which is for me an essential part of a modern identity architecture, call it an identity fabric, and that is where we have a paradigm shift because our traditional identity management thinking is, so to speak, inside out, we as identity managements, so usually we manage the other systems, we create the accounts, we manage the secrets, whatever else, but in a world where we have a very fast delivery of digital services, we must offer the outside-in service via an identity API layer where the services can consume the identity services, like I do that and the secret is provided or create an account for me or whatever else.

This is what we really need to do here. So I think this is a very important paradigm shift and it's exactly what you're saying.

This is, and we can distinct now between, by the way, why what we're now talking has a very good potential to succeed and we should differentiate between several approaches. The approach that we are now discussing is where the identity or the account or the password, whatever you want to call it, is being provided to a certain workload whenever it requires access to database, to an API service, whatever. So creating short-lived credentials, short-lived tokens with a certain permission to do a certain thing, this has a very good potential to succeed.

There's another notion which we require even further depth. It is important, but I'm not sure that it will be that easy to implement, which is the whole authorization mechanism, which is the role making that is specific to the application itself, who can do what, etc. This is something that CIAM mechanisms, we try to do that as an industry. Some of it succeeded with a great push of multi-channel approach for humans, etc. I'm not that convinced that we will be able to take this exact concept of CIAM to machine and AI agents.

We should focus first on the authentication part with some sorts of authorization, with the basic entitlements that we can provide to the token itself, to the temporary identities, and that will be the quicker win for us as an industry. The first, make sure that the identities are well protected.

Yeah, so I think we are very much on the same page here. And I think we directly sort of interest a bit the Q&A part here as well, because I think there's the first question coming up, and it's an interesting one. Is it right or correct to understand that third-generation temporary dynamic identity requires a high-privileged static identity or process or service which will utilize second-generation credential rotation?

So, at the end of the day, is it that you need to make third-generation work to issue the identities? It's still somewhere a highly privileged account that is very traditional.

Yeah, so this kind of differentiates between the secretless approach and the dynamic identities generation, right? Those two concepts that eventually will reach, will get the same bottom line of saving identities from being breached, but those are two different nuances.

OAuth, Ife, Inspire, and others can be considered as more of a secretless approach. Dynamic identities, dynamic secrets, this concept of just-in-time creation of credentials, this is an approach that does leverage, exactly as was asked, a privileged user that would be to create those dynamic identities. There are ways to automatically rotate that particular dynamic privilege, but at the end of the day, there is some sort of trust that is needed to provide to the identity provider itself.

Think of it that something eventually needs to approve, either a public certificate, either something to validate that the action is actually valid, right? So yes, within dynamic identities, there is a need to leverage either a privileged user or a privileged token in order to create a short-lived identity. In the realm of token creation, eventually, there is a level of trust in parallel, right? There is also a trust in which if the identity provider, if the application itself that receives the token trusts the identity provider, by definition, has some kind of privileged approach.

So there is no way to go to avoid this. Eventually, your identity provider must have some sort of privileged authorization. How it is being implemented, it differs between the techniques, but there is no other way.

Yeah, but I think that's something we may be able to address a bit when we look at modern authentication approaches where there's a lot of context and other things. So I think when we evolve there so that we have enough context signals around and put them into the context of what we are doing, then we also can minimize the risk of privileged activity. So I think there are ways also in the identity space where we are thinking about where we can do probably a much more dynamic and fine-grained authorization approach, which is not the open or whatever.

But it depends on really what exactly are you doing that is handled. I think there are some smart things going on as well, which may help us to address this.

Yeah, but just to conclude on Anu's question, it does not necessarily mean that you need to adopt the privileged access to happen with Avotation and Gen2. You can practically leverage in privileged access using a dynamic token that is being created. So even the access to that particular data store or user store that requires you to open up new dynamic secrets, then you can do that also with other types of what we call secret zero approaches. So the authentication there does not necessarily have to be with Gen2 credentialed Avotation.

Okay, and by the way, quickly hinting, we don't need to display it, but hinting on the poll results. So I expected for the first question, do you have comprehensive insight into where in your organization's secrets reside that the response will be 100% no and 0% yes. But interestingly, it's 50-50.

Yeah, I can provide... I'm a little reluctant here. So let me provide you with maybe an explanation for why is it 50-50, Martin, because we see it quite a lot. When you think of it, the majority or let's call it 50%. Where are those secrets today? They are within the Cloud Vaults, AWS Secret Manager, GCP Secret Manager, Key Vault by Azure. They are within the scripts. The infrastructure is called scripts within the CICD pipeline scripts. So it's not really unknown completely. And I agree with you that they can be within the configuration files in many other places. You're right, under control.

You're completely right because, and this is part, by the way, part of the Akila solution is the governance on the Cloud Vaults, right? Because even when you have a secret that is being managed, it doesn't mean that it is being controlled, governed, and rotated. Just as an example, the cloud service providers, secrets managers do not rotate, and they do not provide dynamic identity for non-managed technologies, which is majority of technology that we all have on cloud. So it is right. Your question was about whether we know where they are, and I think that in many cases we can know.

Honestly, I would dare to say, if you say, yes, I know, then it means that you either have no shadow IT, which no one has, or you just say, okay, or it's in the shadow IT. Because at the end of the day, you always have shadow IT, and there's something which is not under control, which is not known. Yeah. So I think you should read it as a collective answer, which means 50% I know, and 50% I don't know. In that sense, I would fully agree, and I think this is a nice take on that. So maybe going a bit back to some of these things.

So when we think about things like third generation, fourth generation, and we're moving into way more sort of dynamic short-lived approaches. You brought up, you spent time in the defense services. What about all the disconnected use cases, which is sometimes defense, which is OT, partially defense at least, OT, IIOT, and clearly some other use cases. Yeah. How do we handle it in these areas? Yeah. So in that area requires, and it depends on the level of disconnectivity, right?

Also OT in general, even if it's connected, there are other, right, more other challenges there with older device and older protocols, et cetera. So every use case has its own answer. Let's call it the maximum level of disconnectivity, let's call it this way, would require more use of signed, let's call it signed tokens, signed certificates, the offline approaches in a way that can sometimes handle it without an identity provider, okay? So that we are leveraging PKI as we should have done for a long time.

Today we're very much using it for TLS, right, and for network encryption, et cetera, but we can leverage that much more for identity purposes. Spiffy Inspire is doing that also, which is kind of a mix. In a very different kind of what a traditional CA and PKI have done. Yeah. This is why, by the way, thank you for bringing this, Martin. This is why we claim that every strong identity posture sits on top of a very, very strong cryptography understanding.

And speaking of convergence, by the way, within identity management, I think as you can see today that IGA players are saying we do also PAM and we do also access management, the access management player saying we are doing also PAM, we're doing also IGA. Something is definitely converging within our market, within identity and access management. And going back to what you said, it is practically the same when we look at the future, what's going to happen next.

There are some principles and components within data protection world based on cryptography that has been always adjacent to identity, almost adjacent to identity, but we're going to see more and more of those type of components and features going into identity security within tokenization, within multi-cloud, within key management capabilities and so on and so forth. Yeah. You brought up Spiffy in your slide. I think it's something that everyone is so familiar with. Could you explain Spiffy in a nutshell?

Well, definitely an area in which it's a newer way to provide identity that covers also different types of levels. It's also with a network level and provides and was created specifically for machines on that space. It is based on PKI, but we'll settle with that. Okay. But at the end of the day, it's something which helps on the fly delivering basically what you need. Yes. Based on just-in-time principles, based on this privileges approach, all of that. Exactly. And I think it sees quite some traction. Rising.

Yeah, definitely. Definitely rising traction. There's a debate whether OAuth can provide a better solution for that. Debate with Spiffy Inspire covers other aspects, in some cases can go into parallel. The thing is that, and I think that everyone understands it, because sometimes I hear all kinds of approaches that says, we should go only this, we should go only that.

Look, identity and access management is a complex world. It has to support all of those different protocols. Not everyone is suitable for everything. We touched mainframes, we touched OTI IoT, which touched workforce, we touched consumers already in this conversation. And trying to say there's the one standard, the holy grail, I don't really believe in that because there are different use cases. I think what is more important is to say, we understand certain principles we must follow. Yes. Yes. As I tend to say, I think it's the same with static entitlement.

When you look at IGA and the traditional workforce identity management, the root cause of all that there is static entitlements, standing privileges. This is why we have roles, that is why we have recertification and all the other stuff, which is challenging. So if we get away from that, and this is going back to the developers of cloud service applications, et cetera, we see quite some improvement there. Then we can improve very fundamentally here. And I think this is really the way we should think about it. Looking at things like Spiffy, so we have a lot of our standards, et cetera.

When you think about these, what would be... If you look at standards in the realm of our conversation, which standards should we reinvent first, from your perspective? Is it TLS? Something else?

Wow, this is a strong, strong question. And I need to... This is a great quote that if I had this answer of what should be altered, whether TLS would be...

Look, I think that generally it is quite understandable that with time, it took time. Every problem needs to be break into smaller pieces in order for us to really answer it. As an industry, it took us, even as humanity, it took us a few years to understand how to build big buildings.

Today, it is almost considered to be... Of course, yes, there are high buildings, but look, 200 years ago, it was not that clear, or 300 or 400 years ago that we could build that high and this big. The same works with technology. We should accept that and understand it. So I think that in that sense, I'm not sure that TLS would be the one that should be into identity. There will continue to be in parallel creation of protocols to answer it. And I believe that the current tools that we have today should surprise the one that we've reminded today.

And it's more about paradigm shifts or shift-left thinking, however we'd like to phrase it, where we think more about going from inside-out identity management to outside-in, delivering as a service, where we go from standing to dynamic to front-lift, zero-standing approaches to... So it's really more shift and thinking. And I think you brought up infrastructures code.

I think, and you also basically said we had a chance when containers came up to ingest identity there. I think it's just true, because I think for infrastructures code, it's very clear the security piece should be just automated and triggered, because identity people usually are, or most identity people are not super good developers. We need to change that, Martin. We need to, that's the whole thing. Shift-identity-left is making sure that identity and developers to get closer. But most developers are not good identity people.

I think that's totally fair, because you're, usually people are specializing. The point is we need to get better at intersection.

So we, as identity, need to deliver the service the developers need in the way the developers need the service. And that's the point. And I think we have proof for things that are easy to use. They will be adapted, because then it makes sense. And this is really what we should look at in this entire evolution. And I think that this is really, and going back to what I said at the beginning, I think we must think more in what is the symptom and what is the cause? And sometimes we probably spend a little too much time in trying to cure the symptoms, fix the symptoms and not fixing the cause.

That is probably the main takeaway, which will also bring us closer to the end of our webinar. I think this was a very interesting conversation with a lot of insights also for me. And I like to see how this space is moving. So maybe you have a closing remark you'd like to? Yeah. I just want to thank you, Martin, for this wonderful session. I believe that as an Akeyless, we have two challenges to focus on for 2026. One is the shift identity left, which is getting closer, as we said, exactly. And number two is to advocate for just-in-time approach, dynamic credential creation.

There are so great mechanisms to do so. Obviously, within Akeyless, we'd be happy to provide you all of that and more details with regards to how to really mitigate and how to really solve the problem and not just to, how do you call it, to a stitch and to provide a temporary solution. Exactly. And there is definitely no need today anymore for any developer of any digital service to use passwords, maybe for user authentication or any type of static accounts anymore. We can do it better. The things are here. It was a pleasure having you here. Thank you to Akeyless for supporting this webinar.

Thank you to everyone listening to this webinar. Especially, thank you to all your insights. These were extremely interesting.

So, thank you. Thank you. Talk to you soon again. Bye. Bye-bye.