Platform engineering has transformed how organizations deliver software. You've modernized compute with Kubernetes, automated deployment with CI/CD, and made observability a first-class capability. Yet access to infrastructure, servers, clusters, databases, pipelines, still relies on VPNs, static secrets, and fragmented Identity and Access Management (IAM) systems that belong to a different era. That gap is not a security team problem. It's a platform problem.
Infrastructure identity is a Zero Trust approach that assigns cryptographic identities to every entity, human, machine, workload, and AI agent, and replaces network-based trust with short-lived, just-in-time, identity-based access. But infrastructure identity doesn't just secure the front door. It secures every room in the building, for every type of visitor, using credentials that expire automatically.
Three forces make infrastructure identity crucial to your platform engineering initiative. Breach costs now average $4.4M globally, making static credentials a financial liability. Machine identities now outnumber human identities by up to 100:1 in modern enterprises, demanding automated identity management at a scale no human process can sustain. And AI agents are emerging as a new class of platform user requiring fine-grained authorization, human-in-the-loop approvals, and auditable actions, a challenge that existing IAM tools are not designed to handle.
This guide will give you the mental model, cost framework, and implementation principles to embed infrastructure identity into your Internal Developer Platform (IDP) and make zero trust the default developer experience.
“Infrastructure identity means every actor in your system holds a unique, cryptographically verified identity, whether that actor is an engineer pushing code, a workload serving traffic, a CI job cutting a release, or an AI agent calling an MCP server. Static credentials and shared secrets compound as liabilities in the form of leaked API keys, forgotten SSH keys, or MCP tokens shared across a dozen agents. Assigning cryptographic identities to every human and non-human actor means each one becomes known, verified, and accountable. The blast radius of a compromise shrinks from your entire environment to a single identity you can revoke on the spot.”- Chris De La Garza, Senior Solutions Engineer at Teleport
Key takeaways
- Infrastructure identity is a platform capability rather than a security bolt-on: You own the developer interface and must operationalize identity as part of the IDP.
- Legacy access models create three measurable costs: Productivity loss to access friction, ops toil from manual provisioning, and risk exposure from static credentials that can be stolen or leaked.
- Mean Time to Access (MTTA) is the key metric: Measure time from access request to active session, implement infrastructure identity, and measure again. The delta is your ROI.
- A unified identity layer replaces fragmented access paths: IAM, Kubernetes RBAC, and database users with unified identity and secure access for humans, machines, services, and AI agents.
- AI agents are a new class of platform users: Enforce the same identity rigor as humans and services: authentication, scoped API access, human-in-the-loop approvals, and auditable actions.
What is infrastructure identity for platform engineers?
Infrastructure identity is a Zero Trust security approach that assigns, manages, and cryptographically verifies unique identities for every entity within a computing environment, such as humans, machines, software, and AI workloads. Put simply, infrastructure identity means giving every piece of infrastructure a clear, verifiable identity so systems can know who or what is making a request, not just where the request comes from. Infrastructure identity is often conflated with IAM, secrets management, or Zero Trust Network Access (ZTNA).
While these concepts overlap in many areas, understanding the distinctions between them is important for effective platform design. For example, instead of granting access based on IP addresses, VPN connections, or network location, infrastructure identity grants access based on verified identity, short-lived certificates, and context-aware authorization policies.
However, the key distinction is where trust is enforced. Traditional access models secure the perimeter, the front door. Infrastructure identity secures resources themselves: the servers, clusters, databases, internal services, and so on. This bridges the gap between your identity provider and the infrastructure layer, bringing cryptographic trust to every login and every session.
Every static secret in your environment is a live vulnerability that rotating or encrypting only delays. Infrastructure identity eliminates static, long-lived secrets and credentials entirely, replacing them with short-lived certificates that expire automatically and are bound to an identity that can be verified in real time.
How identity is verified across infrastructure
Verified identity requires every actor in your infrastructure to present attestation evidence to a trusted authority for validation. After evidence is validated successfully, the actor is issued a short-lived cryptographic certificate that encodes the entity's identity, authorized roles, and an expiration time.
Infrastructure actors may verify their identity in different ways:
Humans typically authenticate through an identity provider with multi-factor authentication.
Devices may present posture data (OS version, encryption status, management enrollment) validated against policy before credentials are issued.
Machines (CI runners, automation scripts, scheduled jobs) may authenticate using platform-issued identities based on cloud metadata, hardware attestation, or enrollment tokens.
Workloads (containers, services, functions) may use identity documents based on runtime properties, such as namespace, service account, or container image.
Agents (AI assistants, autonomous workflow executors) may require verification for both the individual agent's own identity and the delegating user's identity.
How infrastructure identity differs from other security approaches
As is common in our industry, platform engineers encounter a number of different access-related acronyms. Here's where each of these approaches to security fit, and where infrastructure identity fills the gap they leave open.
- Identity and Access Management & Single Sign On (IAM/SSO) authenticates users at login and manages roles and permissions for applications. IAM and SSO secures application login, but not infrastructure sessions. These tools do not enforce just-in-time access to servers, Kubernetes, or databases, and are built for humans only.
- Zero Trust Network Access (ZTNA) brokers secure connections to internal networks and verifies device posture before access. ZTNA secures the network edge, not the resource itself, and does not eliminate standing privileges once a user is inside.
- Privileged Access Management (PAM) stores and manages high-privilege credentials and enforces approval workflows. PAM secures and manages credentials, but doesn't provide cryptographic identity for machines or workloads.
- Infrastructure identity secures the resource itself by issuing short-lived, cryptographic identities and enforcing policy at the server, cluster, and database layer, without relying on stored credentials.
While these approaches are complementary, they are not interchangeable.
Why infrastructure identity matters
Legacy access models impose costs that are often invisible until a breach occurs or developer velocity stalls. Making those costs visible (and measurable) is the first step toward building an effective internal case for change.
When we break down those costs, they fall into three categories:
- Productivity loss, which is the engineering time spent waiting for access instead of shipping i.e every "permission denied" error breaks flow state and delays incident response.
- Ops toil, which is the platform team hours spent manually provisioning credentials, rotating secrets, and managing disconnected access planes across IAM, Kubernetes RBAC, and database users.
- Risk exposure, which is the financial and reputational impact of static credentials that sit idle but active, ready to be stolen, leaked, or misconfigured.
These kinds of standing privileges are a core root vulnerability. Long-lived API keys, SSH keys, and tokens create permanent attack surfaces. And at the same time, though credential rotation delays the risk, it doesn't eliminate it. According to data from IBM, Verizon and Proofpoint, we are witnessing a 71% year-over-year surge in the use of stolen credentials to access valid accounts, while 95% of breached assets are cloud-based servers, and the human element is a component of 68% of breaches, including factors such as errors and social engineering.
Your perimeter is a myth. VPNs, most people and orgs' primary line of defence, grant only broad network access, not specific resource access. Once inside, lateral movement is trivially easy.
What is MTTA? And how to use it
Though the cost categories highlighted above seem incredibly clear, it can be challenging to perfectly map those costs to your efforts internally. Simultaneously, abstract security benefits are always hard to sell internally. Mean Time to Access (MTTA) gives you a concrete, measurable metric that connects infrastructure identity directly to developer velocity and platform ROI.
MTTA measures the time from access request to active session. Every minute spent waiting is a minute not shipping - and high MTTA compounds during incidents, when fast access to production resources is the difference between a 15-minute resolution and a 3-hour outage.
To establish your baseline: time 10 representative access requests across different resource types (production database, Kubernetes cluster, internal service). Record the full elapsed time from request to active session, including ticket submission, approval wait, credential delivery, and configuration. That number is your baseline MTTA. After implementing infrastructure identity with just-in-time access, measure again. The improvement, multiplied by average developer cost and frequency of access requests, is your ROI calculation.
Proof point to gather: Baseline MTTA in your organization using the methodology above. This single number will anchor every leadership conversation about infrastructure identity investment.
Scenario: The cost of fragmented access
A developer needs to debug a production database issue during an incident. They don't have standing access as least-privilege policies restrict production credentials. They submit a ticket, wait for security approval, receive temporary credentials via Slack, manually configure their database client, and finally connect. It has been 45 minutes since the incident began. The incident resolution is delayed, the developer's flow state is destroyed, and the temporary credentials shared via Slack now exist in a searchable chat history, creating a new attack vector. Fun.
Now, how might this look with a platform-enabled infrastructure identity approach? The developer clicks "Debug Prod DB" in the developer portal. The platform API checks PagerDuty for on-call status. A 1-hour cryptographic certificate is issued automatically. A secure terminal opens in the browser. Total time: 30 seconds.
An improved security posture. A radically different developer experience.
Example: CI pipeline identity transformation
The CI pipeline is one of the highest-risk standing privilege surfaces in most organizations. Here's the before and after.
Legacy model: The CI pipeline stores a long-lived Kubernetes admin token, shared across environments, stored in a vault or as a GitHub secret. If leaked, the attacker gets broad, persistent cluster access. Rotation is manual, painful, and often deferred.
Machine identity model: The CI job authenticates using platform-issued identity. The platform issues a short-lived X.509 certificate scoped to a specific cluster, namespace, and role. When the job finishes, access disappears automatically as the certificate expires in minutes.
The result? No standing privilege, no secret rotation overhead, blast radius limited to a single job session, and improved MTTA through automatic, policy-driven access. This pattern applies across every workload that currently uses a long-lived token. Total gamechanger.
The infrastructure access landscape
Infrastructure access spans four layers, each securing a different surface at a different point in the access flow.
SSO is necessary, but insufficient. It secures application login, not infrastructure sessions, machine-to-machine communication, or resource-level enforcement. The blind spot is not authentication at the front door, but standing privilege at the resource layer.
To make things even harder, machine identities massively compound this problem. Microservices, CI/CD pipelines, and automation scripts all need access to infrastructure resources, and they outnumber human identities by up to 100:1. Shared static credentials among workloads can create vulnerabilities. Every service that shares a root credential is a single point of compromise with a blast radius proportional to that credential's scope.
So what is the alternative?
The unified identity layer
Before we begin, it's important to understand that the unified identity layer is not a single product - it's an architectural pattern.
The identity layer integrates with your organization's SSO/IdP for human authentication and with workload identity standards (SPIFFE - Secure Production Identity Framework for Everyone) for machine authentication. It sits alongside policy and state as one of the three cross-cutting layers any enterprise-grade platform requires. Access requests flow through the platform API, which evaluates context, role, device posture, on-call status, and time of day against policy-as-code definitions stored in version control.
Upon approval, the identity layer issues short-lived cryptographic credentials (X.509 certificates, SSH certificates) scoped to specific resources, roles, and time-to-live (TTL).
The audit trail evolves accordingly. Not "IP 10.0.0.5 executed a command" but "Jane Doe (prod-db-admin, 1h TTL), verified via Okta on trusted Mac, ran SELECT query." Every action is assigned to an identity, time-bound, and forensically complete.
The transformation in practice:
- Separate IAM, RBAC, and database users are governed through a unified identity layer
- Static credentials and secrets are replaced by short-lived certificates issued dynamically at runtime
- Fragmented workflows per system consolidate into a single, policy-driven identity layer
- Instead of human vs. machine access all identities are enrolled, creating a unified identity layer for users, machines, devices, agents, and protected resources
Infrastructure identity makes an enterprise platform trustworthy at scale.
Why platform teams must own the access experience
Platform teams own the identity control plane, the developer interface (portal, CLI, API), and the golden paths that embed secure access into standard workflows. You operationalize identity as a platform capability - with SLOs, feedback loops, and continuous improvement. Security teams might still own policy definition, compliance requirements, audit review and define what access is allowed - but no matter what, you implement how access is granted and enforced.
The interface between teams is policy-as-code. Access policies are defined in declarative formats, and platform teams integrate those policies into CI/CD validation and runtime enforcement. This boundary is clean, auditable, and version-controlled, allowing both teams to move independently without creating gaps or conflicts.
Cadence matters massively here, too. Access policies are reviewed quarterly or upon compliance requirement changes. Platform teams iterate on developer experience continuously, using MTTA metrics and developer feedback as the signal. The operating model treats infrastructure identity as a living product, not a one-time security project.
Why platform engineers, not security teams, must own access
Platform teams own the developer contract. Though platform teams are expanding far beyond that original remit, almost certainly, the platform team still owns DevEx. Identity is one of the highest cognitive load creators in organizations, and you're perfectly positioned to reduce that load by embedding access into the tools developers already use. Identity also affects workload design: how services authenticate, how CI/CD pipelines access clusters, how AI agents call APIs. These are architectural decisions that the platform team should own.
At the end of the day, security mandates without usability result in bypassed controls. Friction inevitably breeds shadow IT, where shared team keys, locally stored credentials, and backdoors bypass zero-trust governance. When you make secure access the path of least resistance, adoption follows. When you don't, engineers route around it. Platform teams are uniquely positioned to align security with velocity. That's a mandate that will actually work.
AI agents as a new class of platform users
AI agents are not a future concern. And platform engineers have a unique ability to enable their success. AI agents are autonomous software systems that call APIs, access sensitive data, trigger asynchronous workflows, and act on behalf of humans. They require authentication and authorization that goes well beyond what traditional IAM provides. Four security requirements here are non-negotiable:
- User authentication: The agent must know who the user is, with verified identity, not assumed context.
- API calling on behalf of users: Agents connect to far more applications than typical software and need secure token management (token vaulting) to handle OAuth 2.0 tokens without exposing them.
- Asynchronous workflows: Agents may take hours or days to complete tasks, requiring human-in-the-loop approvals for actions taken while users are away.
- Authorization for RAG: Data fed to AI models must be data that the user has permission to access. Fine-grained authorization at the retrieval layer is essential to prevent sensitive data disclosure.
The same unified identity layer that secures engineers and services must now govern AI agents. Token vaulting, fine-grained authorization, and auditable actions are capabilities that build infrastructure resilience against identity-based attacks and maintain control over AI in production.
Implementation principles: From legacy to unified identity
Principle 1: Replace standing privileges with just-in-time access. Certificates are issued on demand, scoped to specific resources and roles, and expire automatically - minutes or hours, not months. Stolen expired certificates are useless. This single change eliminates the largest category of credential-based risk.
Principle 2: Treat identity as code. Access policies are defined declaratively, version-controlled alongside application code, validated through CI/CD, and enforced automatically at runtime. When a new microservice is spun up, the platform automatically provisions the workload identity and access rules. No manual provisioning. No ticket queue.
Principle 3: Unify human and machine identity. Workloads require dynamic, verifiable cryptographic identities (SPIFFE/SPIRE) with the same rigor as human authentication. CI pipelines must authenticate using platform-issued identity, not long-lived tokens. The 100:1 machine-to-human ratio means manual machine identity management doesn't scale - automation is the only viable path.
Principle 4: Extend identity to AI agents. With 82% of organizations expected to deploy AI agents by 2027 (Capgemini, 2024), the unified identity model must govern autonomous agents with the same rigor as humans and services.
Principle 5: Make audits traceable to an identity Every action is logged with verified identity, role, TTL, device posture, and authentication method. This enables forensic analysis, compliance reporting, and incident reconstruction beyond IP-level logging.
Conclusion: Infrastructure identity is a platform evolution
Infrastructure identity is the cryptographic foundation that gives every user, server, workload, script, and automation a unique, verifiable identity, consolidating them into a unified layer that enables policy enforcement across your entire infrastructure. It turns zero trust from a policy and security team theory into the default developer, workload, and agent experience.
Static credentials and fragmented access planes create measurable costs like productivity lost to access friction, ops toil from manual provisioning, and risk exposure that compounds with every new service, pipeline, and AI agent you deploy. A unified identity layer that is short-lived, cryptographically verified, and policy-enforced reduces those costs while improving the developer experience.
Fragmented access mechanisms like IAM roles, Kubernetes RBAC bindings, database user accounts, and pipeline credentials are replaced by a single identity layer that issues access on demand. Access becomes about which verified identity, under which policy, for which resource, for how long, and with what audit trail - a non-negotiable change for the agentic era.
Platform teams are uniquely positioned to own this. Security can define what is allowed, but platform teams define how access is granted, automated, and experienced. When secure access becomes the path of least resistance, security and velocity stop competing.
The key takeaway is that infrastructure identity is how platform engineering eliminates anonymous computing and makes every actor in your infrastructure known, verified, and operating under policy. Instead of adding approval queues, or security tooling, it embeds cryptographic identity into the workflows developers, services, pipelines, and AI agents already use. The result is a platform where every session is short-lived, policy-enforced, and auditable by default, accelerating engineering velocity and maintaining infrastructure resiliency.
This report was written in collaboration with Teleport. Visit Teleport to learn more about infrastructure identity and unified identity layer for platform engineering.
FAQs
How does infrastructure identity differ from IAM, ZTNA, and PAM?
Infrastructure identity works at the resource layer, replacing static secrets with short-lived cryptographic identities for servers, databases, and Kubernetes clusters. IAM authenticates human logins, ZTNA secures the network edge, and PAM vaults high-privilege credentials, but none of the three enforces identity-based access at the resource itself.
IAM and SSO manage roles and permissions for applications but don't enforce just-in-time access to infrastructure, and they're built for humans only. ZTNA verifies device posture before granting network access but doesn't eliminate standing privileges once a user is inside. PAM stores and manages high-privilege credentials and enforces approval workflows, but doesn't issue cryptographic identity to machines or workloads. These four approaches secure different points in the access flow (login, network boundary, resource session, and stored credentials) and are meant to be complementary rather than interchangeable.
How do you calculate Mean Time to Access (MTTA) to prove ROI?
MTTA measures the time elapsed from an access request to an active session. To calculate ROI, benchmark a baseline MTTA against post-implementation MTTA, then multiply the time saved by developer cost and request frequency.
To set the baseline, time 10 representative access requests across different resource types (a production database, a Kubernetes cluster, an internal service), recording the full elapsed time including ticket submission, approval wait, credential delivery, and configuration. After implementing infrastructure identity with just-in-time access, measure again. The article's own comparison illustrates the potential gap: a manual, ticket-and-Slack-based request taking around 45 minutes versus an automated, policy-checked request taking about 30 seconds.
How does infrastructure identity govern AI agents and non-human workloads?
Machine identities now outnumber human identities by up to 100:1, which is why manual identity management doesn't scale. Infrastructure identity issues dynamic, SPIFFE-style credentials to workloads and enforces token vaulting, delegated user context, and human-in-the-loop approvals for autonomous AI agents.
For AI agents specifically, four requirements apply: verified user authentication rather than assumed context, secure token vaulting for OAuth 2.0 tokens when an agent calls APIs on a user's behalf, human-in-the-loop approval for asynchronous workflows that may run while a user is away, and fine-grained authorization at the retrieval layer so an agent only surfaces data the requesting user is actually permitted to see.
Who should own infrastructure access: platform teams or security teams?
Security teams define what access is allowed, including policy, compliance, and audit review. Platform teams own how access is granted and enforced, through the developer interface, the identity control plane, and automated golden paths.
The interface between the two teams is policy-as-code: access policies are defined declaratively and integrated into CI/CD validation and runtime enforcement, which keeps the boundary auditable and lets both teams move independently. The stated rationale is practical rather than purely organisational: security mandates without usability tend to get bypassed, and friction breeds shadow IT such as shared keys and locally stored credentials. Platform teams are positioned to make secure access the path of least resistance, which is what drives adoption.
How does infrastructure identity eliminate static credentials?
Every actor (human, device, machine, workload, or agent) presents attestation evidence to a trusted authority, which then issues a short-lived cryptographic certificate encoding identity, roles, and an expiration time. This replaces standing SSH keys, passwords, and API tokens that would otherwise sit active indefinitely.
The article's CI pipeline example shows this in practice: instead of storing a long-lived Kubernetes admin token, a CI job authenticates using a platform-issued identity, and the platform issues a short-lived X.509 certificate scoped to a specific cluster, namespace, and role. When the job finishes, access disappears automatically as the certificate expires, typically within minutes. This is the article's first implementation principle: certificates are issued on demand, scoped to specific resources and roles, and expire automatically in minutes or hours rather than months, so a stolen expired certificate has no value to an attacker.
