Identity is becoming the control plane for secure infrastructure

At a glance

What this is: This analysis argues that secure cloud-native infrastructure now depends on identity governance across humans, service accounts, workloads, and AI-driven infrastructure actions.

Why it matters: IAM, PAM, and NHI teams need to treat infrastructure identity as a first-class control plane because static secrets, standing access, and weak audit context no longer match modern deployment speed.

By the numbers:

• 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job.
• Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security.
• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.

👉 Read Teleport's analysis of identity as the backbone of secure infrastructure

Context

Identity is the mechanism that determines who or what can act in a cloud-native environment. In the article's framing, the real gap is not Kubernetes scale or platform engineering maturity, but the lack of reliable governance over access for humans, workloads, pipelines, and AI-driven automation.

That matters because static credentials, broad SSH access, and unverified workload identity do not fit ephemeral infrastructure. As platforms fragment across clusters, clouds, and CI/CD systems, identity becomes the only practical way to preserve accountability without slowing delivery.

For teams building NHI programmes, the article aligns closely with the governance problems covered in the Ultimate Guide to NHIs and the broader challenge of proving origin, intent, and scope for every non-human actor.

Key questions

Q: How should security teams replace shared secrets for workloads that span multiple clouds?

A: Use federated workload identity so the workload proves who it is with a signed token or attestation instead of a shared static secret. Then scope the resulting credential tightly to the request and make the trust relationship revocable when the workload, supplier, or environment changes.

Q: Why do service accounts and workloads need the same authentication governance as people?

A: Because attackers do not care whether the identity is human or non-human if the access path is replayable or poorly scoped. Service accounts and workloads often carry persistent secrets that can be copied, reused, or pivoted across systems. Treating them outside the main authentication governance model leaves a second, weaker assurance plane in place.

Q: What breaks when observability tools lack identity correlation?

A: You lose the ability to tell whether an action was legitimate, over-privileged, or suspicious even when the event itself is visible. That creates noisy alerts, weak investigations, and uncertain accountability. Identity correlation turns raw telemetry into evidence that supports both detection and governance decisions.

Q: How do JIT access and workload identity work together in cloud environments?

A: Workload identity establishes who or what the actor is, while JIT access limits what it can do and for how long. Used together, they reduce standing privilege without forcing teams back to shared secrets or permanent permissions. The result is tighter control with less operational friction.

Technical breakdown

Why static credentials fail in ephemeral infrastructure

Cloud-native workloads are created, replaced, and scaled faster than traditional access models can track. Static secrets and hardcoded API keys assume a stable trust relationship, but ephemeral pods, CI jobs, and AI workloads often need access only briefly and in tightly scoped contexts. When those credentials persist, the environment inherits standing privilege and a large blast radius. The technical issue is not just storage but lifecycle mismatch: credentials outlive the workload, the pipeline run, or the task they were meant to serve.

Practical implication: replace reusable secrets with short-lived, identity-bound credentials tied to workload lifecycle.

How certificate-based access changes the control model

Certificate-based access shifts authentication from secret reuse to time-limited proof of identity. Rather than distributing a shared token into scripts or jobs, the system issues ephemeral credentials at request time and records the resulting session. That changes both access control and auditability. In practice, it reduces the value of leaked material because the credential is scoped, short-lived, and easier to revoke or expire. It also creates a clearer trust boundary for infrastructure, where the identity provider becomes the source of authority for access decisions.

Practical implication: centralise issuance and expiry policy so workloads inherit controlled, auditable access by default.

Why identity context is essential for observability

Observability tools can show that a command ran or a resource changed, but they do not explain whether the actor was authorised. Identity context adds that missing layer by linking sessions to a human, service account, or workload identity and by preserving the access path behind each action. Without that linkage, logs tell you what happened but not whether the event was legitimate. In cloud-native operations, that distinction matters as much as the event itself because it determines whether the response is remediation, investigation, or both.

Practical implication: enrich logs and detections with identity attribution so audit trails answer who acted and under what authority.

NHI Mgmt Group analysis

Identity is now the control plane for cloud-native governance. The article reflects a broader shift in which infrastructure access can no longer be treated as an implementation detail. When workloads, pipelines, and operators all act through ephemeral infrastructure, the governance question becomes who or what can act, for how long, and with what traceability. That is an identity problem first and a platform problem second, and practitioners should organise controls accordingly.

Static credential trust debt is the named failure mode this environment exposes. Hardcoded secrets, long-lived API keys, and manually rotated SSH material all assume access will remain stable long enough to be managed later. In cloud-native operations that assumption keeps compounding exposure, because the access path moves faster than the review cycle. The practitioner conclusion is that persistent credentials are no longer a tolerable default for dynamic infrastructure.

Workload identity must be governed as a lifecycle, not a deployment convenience. The article's strongest technical point is that infrastructure identity only works when issuance, expiry, audit, and revocation are treated as one process. That maps directly to NHI governance, where lifecycle discipline matters as much as authentication strength. Practitioners should treat every machine or pipeline identity as a governed asset with an owner, a purpose, and a termination point.

Observability without identity attribution creates false confidence. Teams can see activity across clusters and clouds, but they still cannot answer whether the actor was expected, authorised, or over-privileged without identity correlation. That makes audit and detection incomplete, especially where service accounts and automated jobs can mimic normal operations. Practitioners need identity-aware telemetry if they want reliable accountability in multi-cloud environments.

From our research:

• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, according to Ultimate Guide to NHIs.
• Only 5.7% of organisations have full visibility into their service accounts, which means many teams still cannot verify who holds non-human access across the estate.
• For a broader governance baseline, Ultimate Guide to NHIs shows why lifecycle control, rotation, and offboarding have to be treated as one discipline.

What this signals

Identity sprawl in infrastructure will keep widening until teams treat machine access as a governed lifecycle. The practical priority is not just replacing secrets, but knowing which identities exist, who owns them, and how they are retired. That is where lifecycle control stops being an IAM admin function and becomes a resilience issue.

With 70% of organisations granting AI systems more access than they would give a human employee performing the same job, the direction of travel is clear: access policy is already drifting faster than oversight. Teams that do not close the gap now will inherit a larger review burden later, not a simpler one.

For practitioners

• Replace embedded secrets with short-lived workload credentials Remove API keys and static tokens from CI/CD jobs, scripts, and deployment manifests. Issue short-lived certificates or tokens at run time so access expires with the task instead of persisting across pipelines or environments.
• Map every infrastructure identity to an owner and expiry Maintain an inventory of service accounts, pipeline identities, and workload credentials with clear ownership, intended use, and revocation criteria. A lifecycle record makes it possible to review whether access still matches operational need.
• Correlate logs with identity context Ensure audit trails record both the action and the actor identity, including whether access came from a human, service account, or workload. This lets security teams separate legitimate automation from suspicious use of valid credentials.
• Reduce standing privilege in multi-cloud access paths Use just-in-time access for SSH, cluster administration, and database access where standing permissions are no longer justified. Short duration access reduces the blast radius of compromised credentials and forces explicit authorization at the point of need.

Key takeaways

• Cloud-native security now depends on governing identity for humans, workloads, pipelines, and AI-driven actions in one model.
• Static secrets and standing access create lifecycle debt that does not fit ephemeral infrastructure or fast-moving delivery pipelines.
• Practitioners should move toward short-lived credentials, identity-aware telemetry, and explicit lifecycle ownership for every non-human actor.

Key terms

• Workload Identity: The identity assigned to a software workload — such as a containerised application, serverless function, or microservice — enabling it to authenticate to other services without storing static credentials.
• Standing Privilege: Standing privilege is access that remains active even when no immediate task requires it. For NHI programmes, it is a common failure mode because long-lived credentials and persistent roles create unnecessary exposure. Reducing standing privilege usually means tighter expiry, on-demand access, and clearer review of who or what still needs access.
• Identity correlation: Identity correlation is the process of linking multiple account records to one governed subject. It lets IAM and IGA teams understand that separate usernames, principals, or emails may belong to the same employee or workload, which is essential for access review, offboarding, and entitlement analysis.

What's in the full article

Teleport's full blog post covers the operational detail this analysis intentionally leaves for the source:

• Concrete examples of how Teleport issues short-lived certificates for infrastructure access across SSH, Kubernetes, and databases
• The operational friction points teams hit when replacing SSH keys, API keys, and static secrets in platform workflows
• Practical examples of just-in-time access requests through Slack or CLI and how they expire automatically
• How Teleport correlates access sessions with identity for audit trails across multi-cloud environments

👉 The full Teleport post expands the platform engineering, workload identity, and JIT access examples in more operational detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM, PAM, or NHI governance programme, it is worth exploring.