Zero Trust Platforms: One Policy Layer for Everything

Hello and welcome to another KuppingerCole webinar. My name is Alexei Balaganski. I am the lead analyst here at KuppingerCole Analysts and my guest today is Chris Webber of Teleport.

Welcome, Chris. Thank you. Good to be here. Great. The topic for today is Zero Trust Platforms, One Policy Layer for Everything. But before we dive into the topic, we have to go through the usual housekeeping motions. So first of all, everybody except us two is muted, so we don't have to worry about that.

Actually, the entire second part of this webinar will be devoted to questions and answers, but feel free to submit your questions in advance using the appropriate tool. And finally, we are recording this and we will make the recording along with the slide deck available for all the participants, even those who could not attend live. The agenda is very simple. The first part would be run by me, where I will be talking about the recently published Leadership Compass Report covering this interesting new market.

And the entire second part would be me talking to Chris, kind of trying to reconcile theoretical high-level views with the actual practitioner's point of view and giving you some kind of a mix of best practices, recommendations, risks, and challenges. So, Chris, I'm happy to have you through the entire hour. We will be probably communicating we will be probably communicating along the entire hour as well, but kind of you will shine after the first 30 minutes. And without further ado, let's dive into the subject.

So Zero Trust has been a thing for quite some time, but definitely more than 10 years. I don't even remember anymore how long. And throughout the entire hype life cycle, if you will, one of the things we kept repeating is that Zero Trust is a principle, it's not a product. You cannot just buy it, turn it on. You have to go through a journey to a long-term goal and kind of the entire fun is in the process of the journey and the friends you've been making along.

And yes, this is still true, this is still relevant, but of course, a lot of people are not very happy with that response and say, well, but where do I start the journey? Like, where can I be looking for the right solutions? And what are actually the issues, the risks that a Zero Trust solution platform can address? So first of all, again, Zero Trust has emerged as a reaction for the idea that your internal network is trusted. So everything that happens inside is allowed by default.

Obviously, this is no longer the case. You probably don't even have a local network anymore if you are working from home or in a large industrial data center or in the cloud. Second is that, well, obviously you cannot trust anybody or anything. So you have to do the explicit verification of anything that's going to happen. You have to enforce least privileges on everything and you have to continuously check that everything is running accordingly.

And again, you cannot buy it, you cannot switch it on, but you can simplify your own journey by opting for a platform. And the platform in that case is basically a way to operationalize a strategy. So instead of building everything on your own as a Lego set, you just buy probably even more than one tool and you combine them with your existing tools. And what you get in the end will be your Zero Trust platform, if you will. So Zero Trust, again, it's not a product, it is first and foremost, a strategy.

Chris, would you agree with that statement? I definitely agree with the statement. And I was trying to remember back when I first was thinking of Zero Trust as well. I think it's 15 years, 10 years ago now, for sure. And in my own experience, when I was early in IT security, before these concepts existed, we had the same ideas, but not tying them together in a way that was cohesive, that let us have a prescriptive way to look across the tools, the processes, the people that we had. So I see it as that. It is all tools, it is people, it is process, it is not a product at all.

It never is just one thing, but it is a way to look at all of what we have to make sure that we're doing the best we can. Great.

Well, but then, of course, our listeners would ask, well, what's the point of this entire webinar, if we're talking about quote-unquote platforms? Well, just listen on, we have a few answers to that question.

Again, the whole idea is that our network security isn't even relevant anymore, it's not new. The network is no longer your primary security battleground, it is the identity. This is what we've been hearing, again, for a few years already, identity is the new perimeter, because the perimeter just doesn't exist anymore. It spans clouds, SaaS applications, edge deployments, partner networks, some unmanaged devices. So with such a long and very permeable border, you cannot just think about it as a safe perimeter anymore.

And of course, we know that attackers increasingly just, they don't have to break in, they log in normally with your stolen credentials or tokens or API keys and do whatever they want to completely legitimately, because they do not raise any alarm, because everything they do is legitimate. They have valid access, and they are away with your data before you even notice that something really is happening.

So yeah, identity is the new perimeter. Well, I would say access is the new identity, because as we will learn soon, I just kind of checking your identity once when you log in is also no longer enough, because your identity can be stolen, it can be abused. There are so many new attack scenarios for, again, kind of having a completely valid identity, but still abusing your access policies. So how do we address that?

The biggest problem of, quote-unquote, adopting zero trust is, again, not just finding a tool, because there is no single tool, but solving the fragmentation, because you probably already have more than one tool which came with the label zero trust on the package.

You have multi-factor authentication solutions, you have zero trust network access, you maybe even have a micro-segmentation tool, you have security posture validation tool, you have API security, hopefully, you might even have identity governance and administration, all great and useful tools, but alone they do not make a zero trust platform, because they are deployed in silos, they are operated by different teams, they have different owners, and they almost never share any risk signals.

And, of course, there is no way, there is no single place to define a policy which can be enforced regardless whether it's in the cloud, whether it's protecting your identity, or cloud tools, or local data, or anything else, or APIs, what not. There is no way to enforce a single policy consistently across all those landscapes. This is the gap that a zero trust platform, the new kind of solution or product, is emerging to resolve. So a bundle of tools is not an architecture, a bundle of tools is not a platform, so what is it?

Well, when we started last year, just thinking about doing a leadership compass report on the subject, we had the same question, what exactly is a zero trust platform, and, more importantly, what it is not. And we came up, after a few internal and external discussions with our own customers, with some vendors, that we believe that a platform has to address at least four of these key requirements. First of all, again, it has to be able to enforce the same policy across different environments, entities, workloads, devices, what not.

Second, it has to be able to provide continuous trust evaluation, meaning that not just once you are verified that it is actually you, or an agent working on your behalf, or an API serving your data, it should happen in real time at every access attempt. The third part is intelligent segmentation. This is probably the least discussed part, but as soon as you start thinking big, as soon as you start experiencing growth problems at a data center level, at a large global public cloud level, you will understand that you are limited by a physical network typology.

You cannot keep up with all those fragmentation and heterogeneity of your networks. You have to be able to treat parts of your network on the logical segments, like segments of a submarine, so if one is flooded, the entire submarine doesn't sink. And there are tools which support exactly that, and I believe this is also a very important part of the Zero Trust platform. And finally, it has to give you that notorious single pane of glass. You have to be able to understand what's going on across your entire environment, and give you actionable recommendations how to fix the issues.

So the test is both breadth of coverage and depth of enforcement, and a platform has to provide both. Chris, have you ever considered these four things as the foundational pillars, if you will, or do you see some others as well? It's interesting. I think that I have considered these four, but some of them with a slightly different lens, at least in my way of thinking, but it does line up here. So universal enforcement, of course, I think is the one that we all could agree on for sure.

But when I see intelligent segmentation, for example, and unified analytics, I think also of being able to have the platform make sure that it is keeping up with that growth as well, right? I don't want my team or users to have to remember, oh yeah, we brought up this new cluster, or set of clusters, or node, or data center entirely, let's go to machine by machine, that will never work. It's not like the old days when I had it easy.

I had a new employee, I had to go through, HR told me, and then I could set up all the systems for them, and they'd be ready and waiting, and when they were gone, I could take it away. These things, as we know, come up and down very quickly. So it's not just about the identity-aware nature, and the topology, and figuring it out, but it's also about keeping up, I think for me a lot of times, in a way that doesn't put a burden too much on engineers or the rest of the team. But other than that, and that's just a subset, but everything else makes perfect sense. All right.

Again, I think different people can just use different terminology, and this is probably one of the biggest issues for us analysts, is to first establish the single language to speak with both vendors and customers. And well, it is difficult, but we are working on that. Right.

So, again, the Zero Trust platform is not something which you buy, deploy, replace existing tools, turn on, and you're done. It's still not just kind of technically impossible, it doesn't actually make a lot of strategic sense as well.

Again, you probably already have tons of existing tools, be it identity-focused, or endpoint security-focused, cloud, serverless, and so on. Cloud security, or just security analytics and telemetry. There are existing tools which work great separately, but not together. And this is kind of the entire missing piece.

And yes, some vendors are large enough and sophisticated enough already to kind of offer you an entire blank coverage of all of these things. But as we will find out later, you don't have to look for a solution from a single vendor, simply because it might end up too expensive or too complex, and doing way too much for your specific requirements.

So, when looking for, again, a proper platform, there is another term which we like to use a lot at Coupang.co, a fabric. Again, kind of a fabric is kind of the same thing, in a way, but from a logical perspective. You do not treat it as a single product, a single SKU, or a suite of tools. You just kind of, you decide, you buy it, or you build it, or you combine different solutions. Most important thing is how it operates in the end.

So, it can require some assembly or tuning, or it can be really a turnkey solution for your specific use cases. You are to decide what is your most important use case. One thing we have to kind of warn in advance is that you cannot just deploy an architecture which works one way. All of those existing tools just kind of send in security information to a single place, like a scene, and call it a Zero Trust Platform, because without enforcement, without the other way, if you will, integration, the whole thing just doesn't make a lot of sense.

Again, it will be probably a decent scene, but it won't be a Zero Trust Platform. So, connect what you have. No need to rip and replace.

Again, kind of focus on this kind of logical fabric approach. Know what you need to cover, and cover those areas.

Chris, what's your stance on this? I know that kind of you are not actually focused on building the one-size-fits-all tool as well. How do you approach this? I think you're exactly right on all accounts. We hear from our customers that they have specific problems that need specific solutions, right? We want to focus there, but what we also know is that this idea of a fabric, we often think about it as a layer. I'm from the days when the OSI networking layer had seven multiple layers, right? It started with a physical and data link, and then you went up from there.

So, you could make sure that you thought about each of those as building blocks that stretched across your entire topology. Now, I think more of a cloud layer, right? There's a networking layer. There's storage, right? I think about an identity layer as well that has to be universal enough to work across everything that you have, both from a tooling perspective, like we're talking about here.

So, it needs to bidirectionally understand something from one piece. For example, there's no need to replace your entire IDP just because you want to have a different way of doing authorization across your environment, let's say. They can work very well together, as a matter of fact, as you well know.

So, I think that idea of a layer that extends, it both is for the tooling, but also for all the resources that are there. It should extend across everything that's in your environment to make it as easy as possible, A, to deploy, and B, to get the value that you want in the way each person wants.

And I think that's what I hear you saying here, is each company, each team, each deployment is going to be different enough to be that this needs to support folks who really have a focus on the IDP side and the cloud security side and a SIEM, but others may have different priorities and needs to work well for them to tie in. Right, right.

Well, I totally agree with your kind of idea of layers. Like, augers have layers, like onions. The difference, I guess, is that there is more than one way to layer this because network layers is probably somewhat a misleading idea because, again, you can layer, for example, you can slice into layers across different teams and siloed systems and clouds and whatnot. And the whole point of having this platform is to kind of cut across the layers to make sure that they all connect. I see that makes sense, too, yeah. Right.

So, we started looking at the market about eight to six months ago, kind of by the end of last year, and we found that it's a very new and emerging market in the sense that kind of not a lot of companies back then told us, yes, this is exactly what we do, we do a Zero Trust platform. But what we found was that actually quite a lot of companies do offer at least some of those capabilities, and they are, of course, very much interested in delivering them in a way that cuts through the layers, kind of connects everything together.

Because, again, Zero Trust, as a buzzword, is probably a little bit per se already, but the problem is still there, and it's only becoming more important in the age of AI and agents and multi-clouds and data sovereignty, if you will. It's all extremely important. And we started looking at what the platforms can actually do and do not. And what I can show you on this slide is kind of somewhat a little bit too early, because I have not told you yet which companies we covered, but at least the ones we have analyzed profoundly, we can give you some statistics.

So most of them already federate with existing identity providers, so this is kind of an easy thing. You will probably never struggle with it when you deploy a Zero Trust platform. And three quarters can actually continuously re-evaluate active sessions, which kind of brings in the question, if the other quarter, can they even be considered a Zero Trust platform if they are not fulfilling the one of the four key pillars we just defined?

Well, again, it's a difficult question. It all depends very much on your specific requirements, but let's kind of follow the entire story to the end.

Pass keys, for example, it's an extremely important thing. So it's kind of phishing-resistant secure authentication, which is already mandated by quite a lot of regulatory frameworks. Only 60% are doing this natively. You can probably get around it somehow by delegating it to that federated identity provider, but still something to think about.

Unfortunately, less than half kind of do it, kind of treat non-human identities as first-class citizens already, in the sense that they can give them the same kind of identity, the workload identity level, short-term certificate instead of an API key or a long-term kind of hard-coded one. Again, this is something where we should definitely see more growth in the future, and I think Chris will probably tell about this later in detail.

And again, there are some areas where, for example, in the whole cloud security posture and area, because again, at least here in Europe, cloud sovereignty is a huge topic. Obviously, this is something where vendors have to improve a lot, but at least kind of a seam integration and basically that kind of universal visibility and analytics is another almost solved problem. This is where you can start using those tools almost immediately. In the end, I would say there is broad progress, but unfortunately still very uneven maturity in this market.

There are gaps where you should be asking hard questions to vendors, before buying anything, but again, this is something which we cover extensively in our writing and reports, and you can refer to our website for more information on that. Continuous authorization. We already kind of mentioned it. This is the key. This is the foundation of the entire Zero Trust platform concept. You have to be able to watch as many risk and security signals from a lot of different sources, not just from devices, not just from identities. Some of those signals are behavioral.

Some of those signals are very specific to a certain environment. Some are just attributes from any custom thing that you have running, a workload-related thing. All those signals somehow have to be normalized, brought into a single evaluation engine, and the decisions that the platform is making every time something is about to happen have to rely on those signals and have to be able to take all those signals into account and then make the right choice. Should we allow it? Is it too suspicious to just kind of let it continue without a step-up authentication?

Should we practically identify that something has too many privileges and reduce those? Should we just terminate the activity, or should we do something else?

So again, all of this should be able to happen at any time, and not just at login. This is the most important part. And of course, yes, as I mentioned, 75% of the platforms we covered already do that to an extent, but they don't give in the details. The way how they do it and where this applies can be very different.

So Chris, where do you see the biggest challenges here? I think what we hear from the market is that these goals are actually pretty clear and common amongst the folks we talk about, making sure that the context is present to make the right choices when any two systems need to communicate or folks need to access those resources. I think a challenge that comes through is those signals can come from many places.

So we're thinking about security-related places here, device posture management, or another identity entity giving some, here's a new challenge, here's a new role that's been created, whatever it may be, or behavioral anomaly. But I hear a lot of people asking, oh, we're heavily invested in GitHub. I want to see when certain repositories access there, or visibility changes, or someone does secret scanning, or maybe it's specific things in Okta or AWS where they say, I want to see something as granular as a database snapshot. Is it being turned public? Is it getting something seen?

Whatever these little, again, I think it gets to your earlier point where each team that's looking for a solution is looking for a unique solution. I guess that's the other way to say it. And it's not just about the security tooling that they have in place and the fabric or the layer that makes those work together, but it's also about their specific topology and deployment and the different tools all can do, communicate, and have available API or other things to say, here's what's happening inside.

So being able to tie that together in a way that's meaningful for a given team does take a flexible layer, a platform or a fabric that can talk across all of those cross-platform things to do that detection and the context to make decisions. Right.

Yeah, that's exactly the point, I guess. Everybody thinks they have their unique requirements, but in the end, they don't really.

I mean, they broadly share similarities, at least within their industries and geographies and sizes and whatnot. The problem is almost nobody knows in advance what they will actually be facing tomorrow or next year or whatnot. And kind of being able to anticipate to that future growth is probably the biggest challenge of choosing the right solution that will grow with you. And this is what we are, again, kind of talking about today. Let's kind of switch gears a little bit. And of course, we have to at least mention AI once, because if we would not, it would be bad.

So yes, we've probably heard that mantra a thousand times already that machine identities already outnumber humans by a huge number, which is kind of pointless because, well, the whole idea of doing identity management properly is to treat every identity the same way, right? Well, the problem is not them kind of outnumbering humans. The problem is how do you deal with that scale? Can you actually address that scale?

Can you address it flexibly enough to be able to not just know that this, yeah, this is actually a non-human workload doing something, but it's actually an agent doing something on behalf of somebody else. And it will also instantiate a different agent with a different set of privileges. And how do you track the entire chain? And how do you apply those policies properly? How do you know who is doing what on whose behalf? And of course, there is a lot of words being thrown around like intent analysis and whatnot.

This is a huge and really growing kind of segment of the entire identity and cybersecurity as a field. But is there like, is it a solved problem?

No, it definitely isn't. And there is so much to address. So as you can see, when you're talking about workload, secrets, API keys and stuff, most solutions already do that, but they've done it before AI, obviously. But only 40% can at least offer you something that would make a non-human identity at least remotely similar in coverage and treatment as a human. And intent awareness is mostly on roadmaps. So watch this space. Maybe check our next edition of the Zero Trust Platform Solution Complex next year. But this is definitely a hugely important area. It's not just about securing AI.

Again, for the non-human identity governance, it's much more than that. And as we are sometimes joking internally, should we replace our HR departments with human and AI resources management, the hair department? Probably something to think about next year.

Chris, have you thought about hair yet? As I get older, I'm thinking about hair all the time. I try to figure that, but not in the way you mentioned. But I do think about, and we in general, you're right, we all know that this is a huge trend.

Of course, AI is a big trend. Non-human identity growth has been a trend for some time. And I think the thing that's interesting here is that conversation you were having about intent.

And yes, a lot of folks know that that is an ideal way to start saying, okay, for these for these agents or this tooling that is going to go find a way to accomplish a goal on its own, we need some sort of bounding there to figure it out. But what I think here is interesting and maybe a little will keep me from going too far.

But a few years back, 10 years ago, when cloud native and containerization and sort of Kubernetes started really, really maturing and becoming available to us at scale, I saw the beginning of a trend that I think AI is also helping us in this in this state and security, which is governance, moving closer to security. And that is because instead of just policy about what people should and shouldn't do, that's written down and documented, and we all have to agree to it. Now the enforcement and the policy are coming closer and closer together.

And in the case of intent, it is definitely the case that you can start looking at an LLM, let's say or an agent and say, well, the intent is very clear, it's being described in real time, you know, here are the prompts of what people want. But also there's there can be as part of the layer, a set of universal governance that are applied automatically, because we're talking to a machine. And we don't have to trust that the machine is going to understand the rules and follow them, we have to enforce that the machine is going to do it different from a person.

So I hear you on the watch this space, right? We are at the beginning of all of this as an industry. But also there are opportunities to do something now, because when everything is codified as data, whether that's declarative policy for a container, or the prompting and the responses for AI, it's all viewable, it's all understandable by systems and by humans. So we can I like I like bringing those together. So they're not, you know, governance over on one side and security on the other, just doing the enforcement.

Right, right. Well, I totally agree with you on the declarative part, because this is exactly the thing which I'm sort of arguing a lot with other people. What exactly is a policy, I would say a policy has to be declarative to be even considered one.

Like, for example, you'll remember probably talks recently that or that AI agent dropped our production database. How could we have prevented that you should have had a policy in place?

Well, no, not really. The only policy you need to have in place is nobody drops our production database. This is it. This declaration alone is the policy, regardless whether it's an agent or a script or a human or a hacker. The question is, how do you actually translate this declarative policy into a multitude of different languages and APIs and rules and whatnot? This is where a platform approach is most important, right? This is where exactly that universal enforcement comes into play. Right. Moving on. So one kind of important consideration was what do we even, like, where do we stop?

Because there are so many vendors out there that say, yeah, definitely have a platform. Some vendors basically build their entire marketing stories about offering a platform for everything. But when you actually start digging deeper, you realize they actually have, like, five different platforms or ten, and they are completely separate. They do not even speak to each other. How can you expect that you will deploy them in a single pane of glass or a single layer of enforcement? This doesn't happen.

And, of course, there are many legitimate reasons for buying a zero trust network access or a security edge platform, but it's not what we are talking about today, right? So we have defined a few kind of rules, but the most important rule is do not trust any label. Zero trust for labels. This is our motto. Never take any word that a vendor's marketing material uses for granted. Always look for capabilities. Always ask hard questions and ask them to explain what is it exactly that they are, what do they mean by that label? And there are very kind of simple tests.

Again, kind of the simplest one is, like, can it actually enforce a single policy across all types of environments? Can it actually protect my database from being dropped, regardless whether it's on-prem, in the cloud, or on a local machine or somewhere else? If it doesn't, sorry, it's not a zero trust platform. Moving on.

Chris, as a representative of a vendor yourself, what's your way of addressing this? I think there's, I mean, I'm chuckling because I think applying zero trust to marketing is a great idea. I could imagine a lot of blogs that we could write about that very thing. And I see a couple of trends in the market that I think are important. One is just your point there. Making sure, you know, you said ask questions, validate.

Also, when you can, use it. Whatever tool it is that you're looking for, there should be some way to actually deploy as a proof of concept, if nothing else. But if there's an open source version, deploy the open source version and test and believe it, right? Get familiar. And frankly, as a vendor, I'm happy to see more and more folks just living that life anyway, right? People are getting intelligent and taking their own word for it in a lot of ways.

And I think that's great because then everybody can just be honest and talk about what's the strengths and talk about where maybe it's not the right solution. And it's very clear. I think the other pieces that AI right now is, well, it's a little bit like a few years ago, zero trust in general, zero trust, the term started just being used by companies just to mean do security, right? It kind of lost some of the specificity of what it was really about. I'm happy to see that we've come back to talking about zero trust as a tenant that is a little different. But same with AI.

AI washing can just mean, well, it's somewhere in the product, in the logs, the AI takes a look and it writes a paragraph for you. And it says, here's what these logs might mean, which is useful. But it's not the same as using inference to go through and help your SOC team find specifically where in a given session, something may have happened that maps to MITRE that says, this is a real threat, you should go figure it out. Or the other way, actually being a tool like we were talking about before, where we're watching prompts or helping to put some containment or boundaries around AI.

And so just people like want to put that stamp, I think, because it's 2026 and AI is at the center of the conversation. But it's very different to just have the stamp on it than it is to actually have a solution that is meaningfully changing both how the product is used from an internally deploying AI, but also where the product can be used and what tools for agents and LLMs and things that may be deployed. It's not as easy.

I have a lot of empathy for someone who's doing evaluation these days, because you do have to peel back, we talked about the onion, you got to peel back to really understand, but where you can find, get your hands on the tool and make sure that it works the way you want. This is exactly where we as independent analysts are coming to help both vendors and customers to find each other in the most sensible and fitting way.

Right, so where do you start that Zero Trust journey, if you will? I guess the biggest hint is don't try to boil the ocean. You will never be able to deploy a platform today, turn it on tomorrow and kind of throw away all the existing infrastructure the next day, simply because it will fail inevitably and it will kind of bring your entire IT to a grinding halt, which you obviously do not want. You do not want to DDoS your entire digital business, if you will.

So it all starts with a strategy, obviously, and the strategy is you have to understand your risks, you have to understand your priorities, you have to map your dependencies and, of course, you have to deploy all those tools in a way that you can test before, do some simulation dry running. Again, it depends, it varies very dramatically across solutions and, of course, you have to be the judge of your own risks, because, unfortunately, security has too long been seen as an obstacle and it's up to you to turn this into some kind of a business enabler.

And one mistake in deploying too much security, if you will, on the wrong system can destroy all the trust. But again, the goal should be continuous authorization, because without it there is no zero trust and, of course, there is no platform behind it. So where do you start, kind of, for real today?

Well, we are presenting the Leadership Compass, the paper we just published recently, which is a result of about six months' work. We started reaching out to vendors, we started identifying what they basically can or cannot do, we started filtering out marketing from substance.

So, unfortunately, or fortunately, the way it depends on how you look at it, some of the very popular names are not even on our list at all, because we decided, well, this is not how we at Kubernetes Code define a zero trust platform. So, thank you, moving on, maybe next year. When we reached out to each vendor, we asked them to fill in a questionnaire to show us the solution in an interactive demo. And then we started crunching numbers, doing write-ups, doing comparisons.

Well, unfortunately, I cannot show you the internals of the process, but trust me, we have a very thorough and formalized methodology with tons of formulas and stuff. And the result is a paper which covers the vendors we were able to directly analyze, along with some mentions of vendors we knew were interesting, but for some reason they could not participate properly, we call them vendors to watch. And the resulting paper, of course, was fact-checked by every individual company for some small mistakes or misunderstandings or whatnot.

And finally, it's now available for reading at kubernetescode.com. Feel free to sign up and have a look. Every rating, every number in that report, again, is a product of six months of work.

So, I'm kind of proud of those results. Let's have a quick look at what are those results.

So, we have identified eight valuation criteria, eight kind of important functional areas where we were looking for capabilities. Secure connectivity enforcement, obviously, it's kind of the bread and butter of Zero Trust. Access management policy, again, like how you do that security enforcement. Context and posture, how thoroughly can you evaluate all those real-time signals. Number four, segmentation and lateral movement.

Again, this is about segmenting your entire access layer across the company into logical blocks, because you cannot do it on a single device level. You will need too many policies for that. Monitoring analytics, obviously. Threat prevention is a kind of nice icing on the cake. For example, if you prevent lateral movement, you automatically block most of ransomware attacks. That's kind of important.

Data-centric security is another icing on the cake, because, again, if you ensure that only the right people can access the right data, this is the solution for the entire data leak and data-centric security problem. And finally, of course, we had to mention AI, so we specifically looked for AI and machine identity protection capabilities. We have ended up with a mixture of 20 different companies, and I definitely anticipated the question, like, surely these are very different companies.

Some are large, like Microsoft, some are pretty small, some are like really European-based or smallish companies, and they definitely all have very substantially different areas of coverage. Yes, this is true. As I mentioned earlier, the Zero Trust platform at the market segment is very much an emergent and evolving space, and different vendors approach it from different perspectives. Some have started as pain solutions, others are specifically addressing, like, application layer connectivity, others still maybe even done some endpoint security at one point.

Regardless, kind of what they can offer you now is a solution which covers at least some of those foundational capabilities. And this is why it's so important to emphasize even the leaders we have recognized as the best Zero Trust platforms are not interchangeable. You have to first decide what is it exactly that you are trying to solve, and then you can use our paper to identify the best fitting solution for you. So it is a crowded market.

As I mentioned, we have, like, 19 other vendors we have identified as at least relevant and interesting and worth your consideration, but unfortunately we don't have yet the full depth of analysis, maybe next year. But the real question is how to choose the right tool. And these are our leaders. And I guess, Chris, you probably have your own kind of idea, but I have to address the elephant in the market.

Again, kind of the mixture of leaders is very different. I would say that probably Microsoft is the only company which would truly be named a real Zero Trust platform, simply because it has offerings in every of those areas, and also has a substantial market presence in all those areas.

But still, you know, the solution requires some assembly. All the other leaders, large or smaller, are more kind of specialized and more sophisticated in certain areas.

Again, they are not interchangeable. This chart is not where your evaluation should end. You cannot just take the right most vendor and say, this is our tool. This is where you should start. And obviously, Teleport is one of those leaders.

So, Chris, maybe you just give me a few words, like what is it your focus area here? Oh, sure. I think Teleport has been focused on what we've been talking about here since the beginning of our existence, right? We are a platform uniquely dedicated to creating trust between systems in the right context, Zero Trust platform, right?

And that, from day one, has been about that fabric, that layer, focused both on the tooling beneath it, but also all the resources, all the infrastructure above it. And that infrastructure includes, of course, your Kubernetes clusters, or a database, or a server, or whatever it may be that need to communicate, an app that has to talk to a database, should have that same level of Zero Trust, all of the eight things that you've talked about, just like when I need to get to a production cluster in order to make a change. We have considered those things from day one.

It has not had to evolve or have pieces put into it, partially because of that vision all along. And you've done a great job. We worked closely with you to make sure that all of this was accurate, but to bring it all together. And I think that's your point of, like, there are some things that are just massive and broad across the scope, and there are some more focused areas. Our focus has been that Zero Trust platform since day one. Right.

So, as an illustration, I wanted to show you that kind of for each vendors we have covered, we have identified, we're not just providing a full kind of write-up of what the solution can or cannot do. We also have strengths and challenges and capabilities kind of arranged across those eight functional areas I mentioned earlier, along with some standard criteria we are ranking like security, deployment, interoperability, which is hugely important in this market.

And, of course, usability in the day-to-day usage. Good job, Teleport, and some other vendors we have identified.

Again, I recommend you look at the report for more details. Reach out to us for more context.

Again, it does not automatically mean that this or some other solution is the right choice for you. You have to understand what it is that you are specifically looking for.

And, of course, this was my kind of last slide for the actual presentation. We still have some time left for Q&A. And the first short question I wanted to address before our analysis, why is AWS missing from this chart?

Again, some vendors we have considered, if only for their large presence and capabilities we offer as separate services, but that alone is not enough. We have identified that the platform has to be a platform. It has to offer unified policy management. It has to support a hybrid multi-cloud and heterogeneous deployments.

And, again, it has to give you kind of the single pane of glass in management. Well, I would argue that AWS is not there, not even yet. That's just kind of, that's not their focus. That's not what they would rather prefer kind of offering their infrastructure for partner solutions to deploy on. And this is probably where you should be looking for your best fit. Right. We have some other questions. Let me quickly open the list.

Ah, that's an interesting one. Where do you start when credentials are sprawling and tools are fragmented?

Well, obviously, you start looking for a Zero Trust platform, but then where do you start doing that? Chris, what's your?

Yeah, well, it's interesting because that is the state of things. Credentials are sprawling and tools are fragmented, and you talked about it well up front. I think we see, I see customers starting in a few different places.

You can, like you said, starting everywhere is a DOS against the business. That, that is a good way to think about it, right?

If you, if you try to carve off too much, it can be overwhelming and a big challenge, but I do think it's possible to move. And there's, there's different ways of slicing it. What we see often is people thinking about specific resources. So where are kind of my crown jewels? Where's that live? And then let's peel back.

Let's, let's remove the standing access pass, the standing privilege from that subset of things and sort of work important out to, or, you know, high concern to lower concern. We also see that same idea sometimes applied the opposite way from a privilege perspective. So what are the, what are the roles whether it's for humans or whether it's for the machines that are in there that really have high access or high privilege that maybe don't need it?

That's a really sometimes scary one for people because at least back in my day, I had roles that existed that I never created that my predecessor didn't create, that my boss didn't create. They were, they were 10 years old by the time I got there.

And I, you know, turning it off was always sometimes a scary thing to do because I didn't know what might break. But I think today you don't have to just shut it off. You can have a, you can move to something that's going to work in a different method. So I think the basic easy answer that maybe everybody knows is start small, but choose something meaningful. And before you pick the highest privilege or the most sensitive, run a low sensitivity deployment, right?

Pick your team or some folks that are willing to have some changes made or some lab solution where it doesn't matter if the app database thing doesn't work today and tuned it out there, and then just pick little groups and move around. We see that it seems intimidating up front sometimes for people, but after the first couple of shifts, starts getting a lot easier and actually starts getting automated in a lot of ways to make this just smooth across your environment.

Again, it's the beauty of cloud native and a lot of the systems, right? The policy can be built in, the systems can identify themselves and say, hey, I'm going to go enroll. And you can make that a lot easier on your teams. Right.

To that, I can only add, like, there has to be someone in your company responsible for that kind of driving this, because the biggest problem is there are multiple teams who are digging their own holes and they're not talking to each other. And that might be your development team or DevOps or security or identity management team or somebody else, which can be that champion to start the journey, to start small. But sooner or later, they will have to grow and they will have to collaborate with the others. I guess this is probably the biggest obstacle and it's non-technical at all.

It's purely organizational. Driving all this. Really good advice. Yeah. Right. By the way, just kind of shameless plug to some related research on our website. And the next question is, how can zero trust be enforced for ephemeral workloads, non-human identities and agents in the activity cannot be effectively monitored or detected?

Yeah, I think, at least from my point of view, we talked about declarative policy up front, right? That's one of the beauties of an ephemeral workload is that they are instantiated and taken down by a set of policy. And it's most simple terms. Maybe we think about Kubernetes as the orchestrator. There is admission control. There is declarative policy. We have places to think about that. But we also have policy for communication between systems. And I think that, A, that declarative piece such that nothing exists without policy that precedes it.

And when it is alive, that's how it's going to enroll and use. It gets taken away based on other policy. I think that's key. But I do think there's, I understand the question, right? These things are fast. They exist. They're maybe outside of what we think of a traditional role. And in fact, I think maybe that's kind of part of this, at least from my perspective. We need to move away from the standing role or the service account that lives forever that may or may not be moved here. We need to change the way we think about the detection and monitoring. Things should self-enroll.

They should never have standing access. They should never have a level of privilege. They should never have a credential that could be lost or stolen or shared across systems. And I know that we all think about ephemeral or just in time as the right place to get. But it isn't as impossible as it used to be 10 years ago.

In fact, it's very possible. The data centers all give us good ways to do, you know, HSMs or TPMs on our laptops. There's hardware root of trust available to all of us.

And so, we can make that move. And in that way, have identity waiting automatically deployed to everything that's there, whether it is an agent or an ephemeral workload or GitHub actions can immediately get, you know, it only has to go deploy when it deploys, Terraform, same thing. But as it's instantiated, it has a unique identity. That identity can define the workload, the time it exists, what it can access, what environments. And when it's done, it should be torn down and gone as though it never happened. That new way of thinking, the declarative way, I think, is a change.

So, to put it more shortly, the identity angle of this is being solved already, partially for some areas. And the access angle is basically exactly what the autospectrums are all about, right?

So, when you combine those two, you have at least some kind of a solution, which is definitely way better than nothing at all. And of course, it's evolving. It will be better next year, definitely. And in that regard, I'm actually pretty optimistic. Right. Next question. What separates platforms built to govern non-human identity from those that just bolted on AI features? That's a provocative one, I would say.

Yeah, I think that it's a great question. And it's something that I challenge folks to push, to talk to analysts, to really ask, like, how does this work? Is it just three different tools bolted on together with a UI on top? But I think what should separate is that fundamentally, at least in what we're seeing from the market, what people want, is to not have to think about the difference in a way, right?

Now, certainly, there is a difference. I, as a human, going to try to get to a cluster, there's a different approval process that may need to happen if I'm just like a junior admin, and there's no reason I should get there. A human should be in the loop, figure out whether this is right. But I should have an identity that is exactly the same.

Again, I keep doing this, because there's that layer idea or the fabric. Everything should have an identity that works the same way. We shouldn't have roles over here for humans and others for service accounts, and yet others for workloads or AI. That's the problem that we have thus far. That's what's gotten us here. And it's what makes it so difficult. And it's what leads to all the credentials or shared secrets or keys being out in our environment that attackers can make use of.

And so I think looking for something where it isn't different, looking for a platform where literally the same identity type is given everywhere, and the same, therefore, policy layer is available everywhere. And then, of course, we use it as appropriate for the type of actor.

But when you move to an ephemeral method, let's say, where no two things can communicate except under very specific circumstances for a limited amount of time, and it's defined in a certain what can and can't happen, what privilege layer is there, all of a sudden, the way I work is very similar to the way an application may access a database, or the way an AI agent may access three different APIs. We can define the time frame, the privilege level, the scope of work that needs to happen. And then when that's done, we tear it down.

And we don't leave anything behind for an attacker to move laterally across, or in the industry for people to steal and start, or an AI agent to like, hey, look, I found all these API keys, maybe I'll use them later. And they become a target themself or a bad actor. If we remove those concepts, suddenly, we're left with something that looks very similar across all the humans, workloads, automation, or it should be one policy layer. Right. It's kind of funny.

I mean, the whole idea AI has emerged is to combine the best things from both human minds and computer automation. Why is it we are struggling to find the worst half of those things? That's an interesting point. Right. So that's a nice kind of segue to promote our next upcoming event in Cologne in September, where we will be discussing exactly this whole thing, how to expand identity coverage across all the types of identities. And we have just reached the top of the hour. Thank you to all of our attendees, live and future watching the recording.

Thank you, Chris, for offering your insights. Thank you. And looking forward to connecting to everybody in the future. Feel free to reach out to Kuping and Co. or to me personally. Thank you very much and have a nice day.