Elevate Infrastructure Resiliency and Engineering Velocity with Infrastructure Identity

Elevate Infrastructure Resiliency and Engineering Velocity with Infrastructure Identity

The Identity Attack Era: Is Your Infrastructure Secure? Cyberattacks are evolving, and identity compromise is now the primary tactic used by adversaries to infiltrate organizations. With credential theft, phishing, and social engineering driving most breaches, traditional security measures struggle to keep up. At the same time, the complexity and scale of modern infrastructure—spanning distributed systems, multi-cloud access, and AI-driven operations—have vastly expanded the attack surface.

Join Jack Poller, Principal Analyst, and Ev Kontsevoy, CEO of Teleport, as they explore a groundbreaking approach to securing infrastructure at scale: Infrastructure Identity. This new security paradigm is designed for the scale and ephemeral nature of modern infrastructure, incorporating cryptographic identities, short-lived privileges, and dynamic access controls to eliminate secrets, prevent credential theft, and enable trusted, scalable operations.

Key Takeaways:

✅ Why identity attacks have become the dominant threat vector and how they exploit infrastructure weaknesses.

✅ The adoption of Infrastructure Identity—a unified, scalable approach to securing modern computing environments.

✅ How cryptographic identities and ephemeral access eliminate static credentials and standing privileges and significantly reduce attack surfaces.

Transcript

Introduction

Lexi: Okay. Well, I think we can get started. Hi again, everybody. Thank you for joining today's session. As a reminder, I'm Lexi. I am our Marketing Coordinator here at Teleport, and I'm going to be moderating today's session for you all. I want to cover a couple of housekeeping things just before we get started. Please note — there is a purple box on the right-hand side of your screen that you can use for chatting. Feel free to post any comments and engage with us there throughout today's conversation. We're going to be keeping an eye on this throughout, and we'd like to address things as they come up. We want today to be super conversational, so if you have any thoughts, let us know. If you have any questions, please feel free to use the Q&A tab at the top of that same chat box. We'll address your questions as they come up live as well. If we don't get to them live, we will have dedicated time for Q&A at the end of today's session. So don't worry about that. And also in that same box is a docs tab. You can find today's resource, which is a white paper written by Jack Poller himself. So feel free to download your copy there. And we will also send you a recording of the webinar within 24 hours of today's session wrapping up. So don't worry about any furious note-taking. But with that, let's get started. Ev and Jack, you have the floor, and I'm excited to learn about today's topic.

Ev: Well, thank you, Lexi. Thank you for organizing everything. So first, let me introduce myself and have Jack introduce himself. Jack, who are you and what are you doing here?

Jack: Well, thanks. It's a pleasure to join. I'm Jack Poller. I am a Principal Analyst with Paradigm Technica. I am an industry analyst focusing on cybersecurity and identity security. And in my old life, before I became an analyst, I was an engineer developing chips and systems and then became a marketer and then an analyst. So I'm happy to join you today talking about infrastructure identity.

The importance of infrastructure identity

Ev: Well, it's great to have you here. And for those of you who are not familiar with me, I'm Ev Kontsevoy, CEO and Co-founder of a company called Teleport. So we are hosting this webinar today, and just a little bit about what we do — we are on a mission to make computing trustworthy. And there is a formal definition of trust when it comes to computation. Your laptops, for example — there are fully trusted environments. And for this reason, applications that are running on your laptop, they're not anonymous. They have IDs, and all the users have IDs, and interactions with users and applications — they're fully trusted because everyone's identity is always known. But the interesting thing is that this property trust is not present in computing environments. Our data centers, our AWS and GCP and Azure accounts, are not trustworthy. And that's what we're trying to fix. But the topic of today's conversation is different. It is about elevating infrastructure resiliency and improving engineering velocity with infrastructure identity. So why are we talking about this? What is infrastructure identity? I hope you will find answers to these questions in the next 25 minutes or so. But first, let me make a few observations about why infrastructure identity is about to become an extremely important topic everywhere.

Ev: Identity is not new. We all use products like Okta and Active Directory and SailPoint. There are many other wonderful solutions to manage identities and to make sure that people have access only to resources they're supposed to have access to. But computing is much, much, much more complex in 2025 than it was in 2005 or 1995. So back when companies like Facebook were starting, back then, all you needed to build a multi-billion-dollar company was the LAMP stack. Remember? Or Java for Enterprise. Just four layers of technology; Linux, Apache, PHP, MySQL, and off you go. So setting up and securing four pieces of technology was not that hard. But today, and Jack knows this really, really well, you talk to a smaller company with maybe 50 to 100 engineers, and they have hundreds of different layers of technology deployed in their data center or in their AWS account or whatever. So scale and complexity are crushing our security posture. It's becoming increasingly impossible to think and reason about security. And that is because there is basically so many different infrastructure form factors out there because laptops need identity. Engineers need identity. Servers need identity. Workloads running on the servers, all of these things, they need identities. And traditional solutions to manage identities — they're usually fragmented and focused on one of those identity form factors.

The need for a new approach to securing infrastructure

Ev: And what this leads to — and this is why organizations are looking for a new approach. What it leads to — it leads to increased exposure to human error because complexity leads to mistakes. And mistakes are the foundation of a breach. Most breaches, if not all breaches today, when you follow the news, they're mostly identity breaches. Someone stole some kind of secret, some kind of credential, impersonated someone else and got access to one thing, stole more secrets from that one thing, and went sideways. So Jack, from your perspective, where you sit, how are companies dealing today with this kind of proliferation of different identities and complexities and scale?

Jack: Well, I think most companies are marching down the path that we've been marching on for a very long time. And you talked about the LAMP stack and history, and we can go all the way back to the very beginning of the computing days, and we had a single user on a single computer, and then we finally figured out how to do multiple users accessing a single computer and said, "Okay, we need that to separate those two users. Now we need an identity." And as we've marched along, we've gotten more and more complex. So we went from user identities to system administrator identities to customer identities. And now we bring in automation and machines. Now we have machine identities and we have API identities and we have secrets, and it just keeps steamrolling over and over and over. And every time we come up with a new identity, we come up with a new solution to securing that very specific identity. So if you have user access, we have the broad category of IAM, identity and access management, which is really focused on your body of users in the environment and authorizing them to get access to specific services. If we have customers, we then have a separate version of identity and access management for customers. And now in the last year, we've had this big explosion in solutions for what we call generically non-human identities, which are identities of anything that's not associated with a human in one form or another.

Jack: And this is a really big problem because, as you mentioned, we're getting very complex environments. And when you look at people who have on-premises environments, they may have 5 or 10 times as many non-human identities as they have human identities. When you look at people who are into — you laugh at 5 to 10 times, but then you start looking at cloud environments where people have SaaS, IaaS, and PaaS environments, and they may have anywhere from 45 to 100 times as many identities as they do human people, so non-human identities. The number of human identities is 100 to 1, right? So you have 1,000 employees, you may have 100,000 non-human identities. You have 100,000 employees, a large corporation, and now you're talking about millions of identities. And so then I'm going to think about it now. You flip that around and you say, "Okay, you have all these things. And how do we manage it? And more importantly, how do we secure it?" And today, we think about security, and everything we do is based on the concept of having a shared secret somewhere or another. And that's a password that's shared. The password is shared between the service you're trying to access and the person trying to access it. When it comes to non-human identities, having a non-human entity enter a password to access a service is very hard. So we've come up with these things called secrets, which are really just another form of passwords. [crosstalk] —

Ev: Kind of like the API key, right?

Jack: Right. The API key, right?

Ev: Yeah, [crosstalk].

How organizations are attacked and breached

Jack: But all we do is we store this somewhere on a file that the computer has access — that the service has access to — to identify itself to another service. And that's easily grabbable by an attacker, just like a password is easily grabbable by an attacker in one form or another. And the big problem here is — identities by far are the largest way organizations are attacked and breached. And part of that is because attackers are lazy and people make mistakes, as you noticed. And more importantly, people are easily able to be conned out of their passwords, right, out of their shared secrets. So it's very easy for an attacker to go and convince you to give up your password. It's also just as easy for an attacker to go and look at your source code or your applications and find out where it stores its password, i.e., its API key or its secrets and go and get that as well. And there are lots of companies, lots of attackers that go out and scan, for instance, GitHub repositories trying to find secrets. So now there's actually other companies whose only job it is to go and scan your source code to hide those secrets from the attackers that are looking for them, rather than saying, "This is unmanageable and untenable way to secure identities."

Ev: Exactly. Yep. Right. [crosstalk] —

Jack: Now, if you think about — I'm sorry, go ahead.

Ev: Essentially, too many people are confusing the definition of what identity is and what is credential or account. Yeah. Because when people say like, "Oh, there is an identity theft," that technically should not be possible because the whole idea of identity, it's something that you are. It's not some kind of file that could be uploaded and downloaded, "Oh, look, I just stole his identity because I got into his laptop and found that file in his home directory," or something like that.

The security implications of today’s infrastructure environments

Jack: The other thing that's important here to think about and you started to talk about it — was we're talking about infrastructure identity. So if we think mostly just in terms of the infrastructure, the problems that we have for user access in a SaaS application are relatively simple. It's a constrained environment with a constrained set of permissions or attributes that somebody can go ahead and access and to do something with [inaudible]. When you look inside the infrastructure environment, almost everything that either a person or a non-human identity is trying to do is having to do with the configuration, changes configurations, and what we would call privileged operations, they're very sensitive operations that can bring down services, change permissions, access data that's very sensitive. And unfortunately, you need to have those types of permissions to build your infrastructure. We also have automation that comes into play that now with DevOps — we're now doing a whole bunch of automation, right?

Jack: So everybody I talked to is well down on the path of DevOps and automation, and nobody configures their systems by hand anymore. They say, "Here's a program. I want a whole bunch of machines to look like this." And then the program goes out and does it — the infrastructure as code, right? But that program that's doing all that stuff has to have super user privileges everywhere in the environment to make all the changes to configure it. So now if a bad guy somehow gets a hold of that identity or credential of that automation tool, they can do whatever that automation tool can do, which is create systems, destroy systems, change configurations. So there's a very big difference in what people can do in the infrastructure environment and what the security implications are, and therefore, how valuable it is to attackers. And that's really why this is very important today, right?

Three problems with the traditional approach to identity

Ev: Exactly. Exactly. So to sum up, I would say that there may be three fundamental problems with the traditional approach to identity that no longer work for infrastructure because infrastructure complexity is really the driving force here. So problem number one is fragmentation of identities. That in a traditional IT — let's call it IT world, we have human identities, non-human identities. Then you have identities for endpoints. And if you look at non-human identities, they fragment them also. There's machine identity industry. Then there's workload identity. And now people are creating products for managing identities of LLMs, for AI agent as a separate thing, which is absolutely a path to nowhere. So that's the first problem. Fragmentation of identities causes enormous operational overhead, enormous complexity, and high costs of integrating all of the solutions. Second problem is that the identity is weak. Oftentimes, people talk about identity. They just basically talk about an API key or private key or a database entry with username and password. MFA only makes them slightly more secure, but at the end of the day, that's just the records that could be stolen and impersonated. So weak identity is the second problem. And the third problem is that traditional IT-based solutions, identity solutions — they are not compatible with the DevOps, cloud-native way of doing things where everything is provisioned as code. Because people need to realize that engineers who write code — they essentially have root privileges to everything because the person who wrote Terraform script that provisions your AWS could have added anything they wanted to that script, including mistakes. So those are three overarching problems that are now being recognized.

Jack: There's actually the fourth one, which you talked about early on, but I think I really want to emphasize, which is the scale problem. Almost all of the existing identity solutions, regardless of which varied type of identity, whether it's non-human, whether it's a machine or an API or whatever, they all assume that there's a human behind the keyboard, which means you're operating at a scale of thousands or maybe tens of thousands. But when you get to the scale of millions, it's just impossible for humans, right? You can't have a person behind a keyboard managing or securing the scale that we're talking about. And it's not only as a scale, but it's very dynamic. So it's not that you create a million identities and then that's a static environment and you can just set it and forget it, right? With things like Kubernetes and infrastructure as code, these things are ephemeral. They come and go all the time. And so we have to have a solution that can be just as automated to manage the security of the identities as it is automated to create these things in the first place.

Ev: Exactly. Exactly. So I think we spent plenty of time, I would argue maybe too much, on articulating what the problems are in front of us. So now let's talk about the solutions. And the interesting thing about the solution is that it's not exactly new. So for a very long time, we knew how to build secure and trusted computing environments or computing systems. Even in 1985, the Department of Defense published a wonderful book called Criteria for Evaluating Trustworthiness of Computing Systems, so all of the fundamental ideas of how to fix this problem have been outlined even back then. So the proposed architecture — let me share a slide here for all of us to see what we want to discuss here. It's called infrastructure identity. So infrastructure identity is essentially an architecture that we are proposing to upgrade your computing environment into a trusted state. So let me walk you through this slide so everyone understands what we're talking about. So at the bottom of your architecture, you have to consolidate all forms of identities in one place. When I say all forms of identities, let me just give you the most common ones, but it's not a full exhaustive list. So all the humans who need to access computing environments need identities. Environments themselves — they need identities because staging and production are not the same thing. And if you're managing staging and production just by looking at some inventory files, that's not really a good identity. Because again, someone accidentally can add a removed machine to the wrong inventory file, or someone maliciously can plant a rogue machine onto your production inventory file. So environments, they need identities. Then machines or servers inside of those environments, they need identities. Then workloads that you run, databases, Kubernetes clusters, they need identities as well. And then obviously identities for the code you write. Identities for LLMs or AI agents that you deploy in these environments — they need identities as well.

Infrastructure identity architecture

Ev: So the key idea here is to have that identity layer being shared across all of these different identity types. First of all, it makes the entire architecture much, much, much simpler and easier to manage and cheaper or cost-effective, should they say. But also, it allows you to do all these other wonderful things on top that I will talk about. But before we move up, I do want to make a comment about how those identities need to be implemented. There are no secrets on usernames or API keys or anything like that. Identities need to be implemented in a strong way. Right now, in 2025, we have a TPM chip on every laptop and HSM on every motherboard, on every server. And all the cloud providers supply strong identity for their cloud resources in those accounts. That is what we mean by identity. It's a cryptographically derived identity from a physical world. So to give you an example, identity of a person is their fingerprint paired with the TPM on their laptop. That is identity. It's not data. It's stored in a physical world. It's a physical person and a physical microchip. So then if you need to transfer that identity for access purposes, you should use a cryptographic derivative like a certificate to do it. And then certificate needs to be revoked after it's done. That's what we call strong identity. So you have to implement strong identity for everyone and everything you have. That's step number one.

Ev: Step number two, once you have full visibility into what you have, you can now implement Zero Trust networking. And over here we say it's Zero Trust Plus because most of the time when people hear Zero Trust, they assume, "Oh, it's just a person accessing some kind of web resource in the browser." Well, but that web resource is an application consisting of 15 microservices running on a Kubernetes cluster, talking to seven different databases. All of those things — how do they talk to each other? Are those connections all encrypted and authenticated frequently? No. But this architecture allows you to have all of them, all of those connections inside of your environments encrypted and authenticated at all times. And then on top of this, you could do short-lived privileges, meaning that you can issue privileges only when there is something to do for that particular identity or group of identities. For example, to run a deployment, you issue certificates to your Jenkins, to an engineer who will drive Jenkins to the machines that all of this runs on. So deployment is run, and then privileges are revoked. And then on top of this, you could do the usual stuff that you want to pass compliance audit, like all the governance — excuse me — and audit capabilities. But what it gives you — let me give you a simplified view on the exact same architecture — is that the first two layers, if you think about it, strong cryptographic identity for everything and everyone, paired with Zero Trust. Those two eliminate anonymous computing completely. Once you have that in place, you will always know in your computing environment, what do you have, who is talking to whom, and what are they doing?

Ev: But most importantly, if you add short-lived privileges on top of it, it allows you to implement no access in steady state, which is an extremely powerful concept, which basically means that when your infrastructure is working, it's processing transactions and making you money. Nothing is happening. You're not deploying anything new. You're not doing any backups, which is 99.999% of the time. When nothing is happening, you should know with 100% certainty that no one has access to anything, not a single employee. Even if someone tries to bribe them with a trillion dollars, they will not be able to touch anything because all the servers, all of your workloads, there are no users, no passwords, no accounts, nothing. Access will be granted only when there is something to do. So that's what infrastructure identity brings you. And by the way, again, it's not just from us, from Teleport. It's not just from DOD in 1985. If you look at how Apple builds their data centers to run their intelligence workloads, they documented all of it. It's called Apple PCC, Apple Private Computer, if I believe. So that's basically exact same ideas. This is how you run native cloud workloads at scale in the simplest and most secure way possible. And if you look at — let me share this slide. I think it would be useful as well. If you look at how does this map against existing solutions in the market and how does it compare against just kind of general kind of cybersecurity industry? I think this two-dimensional picture might be helpful.

Infrastructure identity landscape

Ev: So on x-axis over here, so we have identity strength. So meaning that on this dimension, we're evaluating how strong is implementation of identity of a particular solution. If it's just an account and a database with a secret, that's really, really low. It's weak identity. But if it's a TPM with a certificate, that's a high cryptographic identity. And on the vertical axis, we have infrastructure use cases, or you can think about it as kind of scale, like how many different identity types this particular solution covers. And as you see, the classic privileged access management vendors, they usually implement low strength identity. That's only good for humans over here. So you see it's kind of low in both dimensions. But some startups, by the way, they would pick an identity type — let's just say it's an LLM — and they do implement just that identity, and they do it really, really well with strong crypto. So they would, for example, be here. But you see — because they only work for LLMs and for nothing else. So that's a siloed solution that will lead to all the same problems that we've identified, which brings me to this DIY box over here. I've always found it interesting that all of the hyperscalers — it's always like Googles and Netflixes and Apples in the world. They almost always have a homegrown solution that implements this. This is why I mentioned Apple PCC earlier, and this is what Teleport provides. So as an open-source solution, we also have some enterprise capabilities that you can leverage.

Ev: So this is where everyone wants to be. And essentially, because everyone wants to become a hyperscaler, and this is what hyperscalers are doing. This is the right way of doing it. And it's actually simpler than combining a bunch of these solutions. So speaking about simpler or harder, let's talk about the initiatives that are actually happening at organizations that infrastructure identity can help with. Jack, what have you heard from your clients or from your connections in the industry? What are the typical use cases or situations where organizations face this unpleasant reality or awakening by looking at this [inaudible] of identities they have created?

Infrastructure identity initiatives

Jack: So I would say there's sort of two different paths organizations take. There are organizations that are proactive that understand they have issues that need to be addressed. And those organizations are typically ones that are growing quickly and would be all in on an automation DevOps journey, all in on a cloud environment, and are growing fast enough that they're struggling with scale issues, right? And they just can't manage what they have today. They're losing track of things. And so they're looking for solutions. The other group of companies that are looking at this type of solution are, unfortunately, reacting to breaches and attacks that they have recently suffered. And the scary part is that there's a lot of organizations that have always taken the head-in-the-sand approach, right? And yeah, there's a problem out there somewhere, but we'll deal with it when we have to deal with it. And having to deal with it is sometime after a credential of a superuser account gets stolen and their entire infrastructure is compromised in one way or another. And as an example, a little while ago, I was talking to a bank that had an entirely — this was a couple of years ago. They were entirely virtualization-based. So it was all VMware-based. And they had almost 1,000 VMware administrators.

Ev: Oh, my God.

Jack: Every single one of those VMware administrators had super user access to the entire infrastructure. So they actually had problems where people were logging into the wrong host and turning off services they thought were staging a development services — they were production. And they lost significant funds because they took down part of their system, right? And that's when they realized that they had a problem. I mean, that was just simply — and again, that was isolated simply to humans accessing and managing the infrastructure. And then they look outside of that and they say, on top of all the virtualization infrastructure we have, we have Kubernetes, we have automation, we have all these other things, we've got a lot of people who have access. And they did things that were sort of short-term solutions to some problems, like they put in a secondary permission or a secondary approval process. So before you could ever do a shutdown on a virtual initiation machine, somebody else had to approve the process so that you could make sure you didn't shut down the wrong machine, which is great, but it's a very [inaudible] and bad way, and of course, doesn't scale, right? So we have these two different types of groups. And then there's the third group, which is hopefully the people we're talking to today that say, "Hey, we've got a problem, but we don't know how to solve it," right? And so here's a way to solve it, to say, "We understand that we need to secure our infrastructure." There's 40 different vendors yelling at us saying, "Non-human identity, human identity, LLM security, this security, that security," and not one single one of those addresses the infrastructure as a whole.

Ev: Exactly.

Jack: And I was going to say, when you look at the architecture and what people are doing, I think one of the keys, the eye-opener that I've seen when people talk about this is the elimination of anonymous computing, right? There is no way for somebody to do something in the environment without an identity, right?

Ev: Or something, yes, yes.

Jack: Something, right? Some person, something, somewhere, right? And that's a key because when you look at people's infrastructure overall, there's a lot of things that are moving and doing things in the environment without an identity, without a human, without a system attached to it. It just magically happens. And I think that people sort of look at them. When you expose them to that, that's an eye-opening moment, right?

Ev: Yep. I was at a dinner once with a bunch of CTOs and CISOs from pretty well-known companies. And someone asked a question, "What is the typical bottlenecks you guys see when you try to move faster?" Because you have to stay competitive. You constantly need to be deploying new technologies. It used to be — cloud migration used to be a big thing, like jump on the cloud or you're going to be left behind. So then there was kind of containers, microservices, Kubernetes. There was another big push. Now everyone is trying to jump on the GenAI bandwagon. So someone asked, "What is the typical kind of biggest kind of obstacle for you to move with enough velocity?" And they said security because every time you bring a new disruptive technology into your environment, you need to scratch your head and figure out how to secure it. So you add Kubernetes, for example, to an environment, which didn't have one before. Kubernetes represents a completely alternative way to accessing all of your resources that are within the cluster. It itself actually needs an identity. So essentially, every time you bring new technology, you start shopping for a security solution for that technology. And that is always just a huge burden. And then your complexity increases. All of your engineers are complaining because they have 15 different credentials and files for every environment, every cloud, every workload.

Jack: And let me talk about that for just a second because on the slide we talk here, and you sort of look at engineering and security, and they are two separate roles and two separate domains within organizations. And as you said, very often security is viewed as a roadblock, as a gate that people have. We need this tool, but security comes in and says, "You can't use that tool," or "We need this new function of Kubernetes. How do we secure it?" And that makes security a bolt-on afterthought. And with infrastructure identity as an architecture and as an approach, we talk about Zero — Zero Trust is not a product, right? It's not a feature. Zero Trust is a — sorry, Zero Trust is a strategy. Infrastructure identity is really a strategy. It's a way to ensure that it doesn't matter what new technology you bring into your environment, you can bring it into the environment in a secure method, right? And your environment stays secure when you add new stuff. So if you have an existing environment and now you say we're going to go do agentic AI, we don't need a new security thing.

Ev: Exactly. Exactly.

Jack: It's into infrastructure identity. And that way, engineering and security can be cooperating rather than fighting with each other.

Ev: That's why I always like mentioning this analogy between computing environments that we have in data centers and our actually personal computers. Our personal computers are trustworthy. So they do implement infrastructure identity only within one machine. This is what allows us to download and install and run all kinds of technologies on our laptops without having to purchase a separate security solution. All security we need is already built into the operating system. So macOS or Windows, they manage identities. They manage privileges. They maintain an audit log. There is a single login screen for everything. So that's ultimately what we all want. This level of simplicity and this level of productivity — we want that for the cloud. That's really what infrastructure identity is about. So before we wrap up, let me again summarize what this is all about — three big central ideas. First of all, unification of all identities, of all forms of identities in one system. It's extremely important for implementing Zero Trust fully and completely and for setting policy in one place. Idea number two, move away from weak identities towards strong identities backed by physical world attributes like biometrics and secure enclaves and cryptography. And idea number three is issue privileges and access only when they're needed, not all the time. So those are three most important, I think, tenets of infrastructure identity because the benefit is amazing. The benefit is a trustworthy computing environment.

Ev: Now, to proactively answer a question where you guys can learn about it. So there is a white paper written by Jack himself that you can find on our website. I believe I'm sharing the right thing on my screen right now. And I do believe this webinar itself will be available to listen later, download, and share it with your friends and colleagues. And now I think we do have some time for Q&A, so Lexi.

Q&A

exi: Yes. All right. Yeah. We also do have that white paper available in the docs tab of the webinar platform as an easy download spot there as well. But for some questions, I do see a couple that came in. One of them is — how do you get started with infrastructure identity?

Ev: So aside from downloading all of these resources, I would also recommend for folks — because I don't want to sound like a commercial for Teleport because it's really easy for me to say, "Hey, Teleport is open source. Go download. Start playing with it. Start kind of understanding how all of this works." So that's a practical kind of hands-on way to very quickly get your hands dirty or your feet wet, playing with this kind of concept of creating a trusted environment. Because the way it works in Teleport, we're first asking, or the product asks you, to define a cluster. And cluster by default is just like a — it's an environment, essentially. So it's empty. So then you start enrolling your servers, right, because you need hardware first. So they get real cryptographic identities issued to them. So they join your environment. They become staging or production, whatever. So then you start enrolling your workloads, things like databases and Kubernetes clusters. Then you can enroll yourself, right? You can add a user, and it will ask you to register your fingerprint and TPM on your laptop. Then you can enroll your laptop, actually, also. That's another thing. So all of that forms a cluster. So that becomes your analogy of a laptop in the sky. So this is your computing environment where everyone and everything inside of that environment, they all know each other. But if you do want to kind of think about how it's going to be rolled out in a much, much more complex way in your organization, I would recommend looking at projects that are new because it's much easier to implement new technology for a new initiative as opposed to touching something that's not broken yet. That's usually how Teleport customers start getting into this kind of trusted computing game by implementing this paradigm for new projects and initiatives. And then gradually, you expand the footprint of your trusted compute kind of further and further in your organization.

Lexi: Great. There is another question here. You talked a lot about big ideas. Is infrastructure identity difficult to implement?

Ev: Well, it's actually trivial to implement when you're doing it from scratch, right? So if you're creating an environment to run a new project, I would even say it's much simpler than traditional approach, that's for sure, because there is only one piece of software that you need that manages everything that you need to get done that normally you would have had to kind of stitch together multiple solutions. You would probably use some kind of vault for certificate issuing and for storing keys, and you'd need some kind of VPN, and you'd need some kind of identity platform. Then you need some — anyway, so it's actually simpler if you're starting from scratch. But if you're bringing it into a kind of mature organization, I would probably sort your projects by priority, where priority would be defined by kind of how sensitive it is to regulation and security concerns and how important engineering productivity is or velocity. So those are really kind of two primary benefits of this approach. So using those two, I would sort the projects you have in flight to determine where to get started with — what to get started with.

Lexi: Gotcha. And how do you justify the budget for something like this to your upper management?

Ev: I would maybe pass this one to Jack because he's much more involved in those conversations.

Jack: Well, like every other tool and every other cybersecurity strategy, it's a risk evaluation, right, and how much do you spend to protect the valuables you have and how much are those valuables worth? And we can simplify that by saying you're not going to go and take a nickel and put it in $1 million safe in your safe deposit in the bank, right? But you are going to go and take your $10 million worth of gold bars and put it in Fort Knox. So you want to think about — and that's part of the priority — is thinking about what's the most important thing you want to protect. The cost of not protecting this stuff is absolutely astronomically huge. If you look at the IBM cost of a breach study, it has gone over the last four or five years from a couple million dollars to about 4 to 5 million dollars per breach. But those are sort of weird numbers because nobody really wants to talk about what the cost of a breach is.

Jack: If we look at a recent identity breach a couple of years ago, MGM Grand in Las Vegas had an identity breach, and their identity and access system was pretty much taken down. And their casino and hotels were down for days, and they lost tens of millions to hundreds of millions of dollars. And I'm sure they're still suffering reputational damage from it, right? And you say, "Well, that's this big casino and they're a big target." The reality is every organization is a target because identities are so easy to compromise. In fact, they are the largest attack path by far, by like three times over the next attack path that people use. I can't remember the numbers offhand. I do talk about it a little bit in the white paper —that about 70% of all breaches and attacks are identity-based. And a huge portion of the attacks are targeting your infrastructure, not your users because infrastructure identities are more valuable because as we talked about earlier, they're a super user's identity that can do just about anything, right? So the cost of not protecting this is high. The cost of implementing it with existing other types of strategies means, as Ev mentioned, you have to deal with separate tools and therefore separate charges for human identities, for server identities, for certificate key management, for API key management, for LLM identities. It just goes on and on and on, where there's a separate solution for every single type of identity rather than one solution that covers your entire infrastructure environment and provides security regardless of what new technology you bring in.

Ev: Yeah. That actually reminds me of another very simple way to justify budget. The budget actually will probably shrink because once you put an infrastructure identity solution like Teleport in place, you no longer have the need for a bunch of other stuff. So you could get rid of your VPN vendors because it's already included. So your trust networking layer gives you secure and encrypted and authenticated connectivity to anything you want, anywhere in the world. You could also get rid of privileged access management kind of legacy PAM vendor simply because PAM just doesn't work for infrastructure, period. It's just not a good fit. You might also be able to shrink the usage so you need fewer licenses for kind of human identity platforms like Okta. Plus, there are all these other non-human identity vendors that say they sell these siloed point solutions that you also will no longer have any need for. So yeah, the overall budget may actually be much smaller than what used to be in place. It's a simple [crosstalk], that's what we're offering.

Jack: Yeah, I was going to say just real quickly — one of the other things that you don't need is you don't need IGA identity governance, right?

Ev: Yeah, that's another layer.

Jack: There's no standing privileges, therefore no privileges to audit to say, "Does this system administrator have access to only the right things?" Because standing privileges don't exist.

Ev: Yep, yep. Any other questions? Let me check the tab. No other questions. And we are right with maybe one minute left. Well, thank you, Jack, for joining us today. Thank you, everyone, on this call. I hope you've enjoyed it, and we are very easy to find. I believe I am sharing the right slide with the white paper and documentation where you can go and try things for free. But also, hey, you could always reach out to us and talk to us directly. I'm [email protected]. Thank you for joining us today. This webinar was about the importance of this new emerging technology called Infrastructure Identity. Thank you.