Extending SPIFFE beyond Kubernetes to VMs and off-cluster workloads

At a glance

What this is: This is a practical analysis of extending SPIFFE-based workload identity beyond Kubernetes so VMs can consume short-lived identities without copying private keys onto disk.

Why it matters: It matters because IAM teams need one governance model for Kubernetes, VMs, and legacy workloads, or they end up with inconsistent trust, secret sprawl, and weaker zero trust enforcement.

By the numbers:

• Only 5.7% of organisations have full visibility into their service accounts.
• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
• 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time.

👉 Read Teleport's guide to extending SPIFFE identity beyond Kubernetes

Context

SPIFFE workload identity gives software workloads a verifiable cryptographic identity, but the control model gets harder when calls originate outside Kubernetes. The governance gap is not the protocol itself, but the delivery and lifecycle of identities for VMs, edge gateways, and legacy services that still need to participate in zero trust policy.

The article’s core point is that off-cluster workloads should request and consume short-lived identities locally instead of receiving copied certificates. That matters for NHI governance because the trust boundary must extend beyond the cluster without turning every VM into a manual certificate-management exercise.

Key questions

Q: How should security teams extend workload identity to VMs without creating secret sprawl?

A: Security teams should deliver short-lived workload identities through a local consumption path rather than copying certificates onto the VM. That keeps private keys off disk, makes rotation more automatic, and lets the same identity model work across Kubernetes and non-Kubernetes environments without turning every VM into a manual certificate project.

Q: Why do VMs complicate SPIFFE-based zero trust architectures?

A: VMs complicate SPIFFE-based zero trust because they do not inherit Kubernetes control plane identity lifecycle by default. Teams then need a separate way to issue, rotate, and revoke short-lived identities while preserving a common trust domain. Without that, policy fragments and callers outside the cluster become harder to govern consistently.

Q: What breaks when workload identity is delivered as copied certificates?

A: Copied certificates create long-lived credentials that often outlast the workload that needed them. Rotation becomes manual, revocation slows down, and identity gets confused with network placement or shared certificates. That makes access harder to audit and increases the chance that old credentials remain usable after the original use case has changed.

Q: How do zero trust teams decide whether their trust anchor is too cluster-bound?

A: A trust anchor is too cluster-bound when upgrades, re-installs, or control plane events can disrupt identity for callers outside the cluster. Teams should test whether identity policy can still be enforced consistently across clusters and VMs. If not, the programme still depends on topology instead of identity.

Technical breakdown

How SPIFFE identity delivery changes outside Kubernetes

SPIFFE defines a workload identity model built around SVIDs, trust bundles, and verified attestation. Inside Kubernetes, platforms often assume the control plane can distribute identity natively, but VMs do not share that lifecycle machinery. The challenge is not authenticating a workload once. The challenge is delivering a short-lived identity in a way that does not require the workload to store private keys as files or rely on a copied certificate that outlives the task that requested it. That is where local consumption APIs and trust-chain delegation matter.

Practical implication: Treat identity delivery as a runtime service, not a file distribution problem.

Why separating identity issuance from identity consumption matters

When issuance is separated from consumption, the workload requests identity from a trusted authority and then consumes it through a local API such as SDS or a workload socket. That design keeps certificates off disk, reduces manual rotation, and makes revocation more workable because the identity is ephemeral by construction. It also avoids a common anti-pattern in VM governance, where one static credential is shared across too many services and environments. For identity teams, the architectural gain is consistency across platforms without collapsing everything into cluster-local assumptions.

Practical implication: Use local identity consumption paths so VMs can inherit short-lived identity without persistent secrets.

Why cluster-local trust anchors become a scaling problem

A cluster-local CA works when identity stays inside Kubernetes, but the trust anchor becomes an operational boundary when callers live elsewhere. Each cluster then becomes an isolated trust island, and upgrades or control plane changes can affect identity for off-cluster callers. The issue is not merely inconvenience. It is that identity policy becomes harder to standardise across workloads because the trust fabric is fragmented. In zero trust terms, the policy boundary no longer matches the actual service boundary.

Practical implication: Model trust anchors as organisation-wide primitives when workloads span clusters and VMs.

Threat narrative

Attacker objective: The objective is to preserve usable access to in-cluster services through long-lived workload credentials that bypass short-lived identity controls.

1. Entry occurs when a VM or legacy workload is forced to use copied client certificates or other long-lived credentials to reach in-cluster services.
2. Escalation follows when manual rotation is missed, the credential remains valid after the original workload need has changed, or revocation lags behind operational reality.
3. Impact is unauthorized use of workload identity across environments, with broader access and harder containment because the credential was never tied to a short-lived runtime boundary.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• Schneider Electric credentials breach — exposed credentials gave attackers access to Schneider Electric Jira, exfiltrating 40GB.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

SPIFFE-only thinking breaks down when workloads leave Kubernetes. Identity programmes often assume that the cluster is the natural issuance and enforcement boundary. Once VMs, edge systems, or legacy services join the flow, that assumption no longer holds because the workload lifecycle continues outside the cluster control plane. Practitioners should treat cross-environment identity as a governance boundary, not just a transport problem.

Long-lived credential delivery is the wrong design centre for off-cluster identity. The article correctly shows that copying certificates onto VMs creates rotation debt, revocation lag, and confusion between workload identity and network location. That is a classic NHI governance failure pattern. The implication is that teams must stop treating VM identity as an exception and bring it into the same lifecycle model they expect for other non-human identities.

Trust anchor fragmentation is a zero trust problem, not a Kubernetes problem. When every cluster becomes its own island, policy standardisation becomes brittle and federation complexity rises. This is where NIST SP 800-207 Zero Trust Architecture is the right reference point: policy should follow identity, not topology. Teams that cannot express the same control intent across cluster and VM boundaries do not yet have a unified identity fabric.

Identity blast radius is the right concept for cross-platform workload governance. A separate trust chain can reduce the number of places where credentials are copied, but only if the organisation understands where identity is issued, where it is consumed, and how far its trust domain reaches. That is the operational question practitioners should ask before expanding SPIFFE beyond Kubernetes: how large is the blast radius if the trust anchor is compromised or mis-scoped?

Off-cluster workload identity is becoming a baseline governance requirement. As enterprises mix Kubernetes, VMs, and edge services, workload identity can no longer be managed as a cluster-native special case. The practical conclusion is that identity architecture must support the same policy language and rotation expectations across all runtime environments, or zero trust remains partial by design.

From our research:

• Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
• 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time.
• For a broader standards view, see Ultimate Guide to NHIs, Standards for the control stack that underpins workload identity governance.

What this signals

Identity blast radius: as workloads move across Kubernetes, VMs, and edge systems, the question shifts from whether SPIFFE is supported to how far a trust domain actually extends. Teams should expect more pressure to document issuer ownership, trust-anchor scope, and rotation behaviour across every runtime, not just inside the cluster.

A workload identity programme that stops at the cluster boundary will increasingly misalign with real service topology. The next governance step is to treat off-cluster identity as a normal part of NHI lifecycle management, with the same scrutiny applied to issuance, consumption, and revocation paths.

With only 5.7% of organisations reporting full visibility into their service accounts, cross-environment identity standardisation is not a nice-to-have. It is the difference between a policy model that can be governed and one that fragments as soon as workloads leave Kubernetes.

For practitioners

• Map every off-cluster credential path Identify where VM and legacy services still depend on copied certificates, shared secrets, or IP-based allow rules, then classify each path by rotation burden and revocation difficulty.
• Separate identity issuance from consumption Move workloads toward local consumption of short-lived identities through a workload API or proxy so private keys are never stored as files on the target system.
• Standardise policy on workload identity Write access rules against SPIFFE principals instead of network location so Kubernetes services and VM callers are governed by the same identity semantics.
• Review trust-anchor scope Document which cluster, platform, or organisation owns the trust anchor, then test whether upgrades or re-installs would disrupt off-cluster callers.

Key takeaways

• Off-cluster workload identity fails when teams fall back to copied certificates, because long-lived credentials do not fit zero trust or modern NHI lifecycle controls.
• SPIFFE can extend beyond Kubernetes, but only if identity issuance, consumption, and trust-anchor scope are governed as one architecture.
• VMs, edge services, and legacy workloads need the same identity discipline as containers, or policy consistency breaks at the first boundary crossing.

Key terms

• Spiffe Svid: A SPIFFE Verifiable Identity Document is the short-lived cryptographic credential a workload uses to prove who it is. In this context, it matters because the identity must be issued and consumed without forcing the workload to store a private key as a file or depend on a long-lived certificate.
• Workload Identity: Workload identity is the machine or service equivalent of a human identity, used to authenticate software rather than a person. For VMs and containers, it needs lifecycle controls for issuance, rotation, and revocation so policy follows the workload rather than the host or network location.
• Trust Anchor: A trust anchor is the root authority that other identities rely on when proving legitimacy. When workload identity spans clusters and VMs, the trust anchor becomes a governance boundary because its scope determines who can issue identities and how consistently policy can be enforced.
• Secret Sprawl: Secret sprawl is the uncontrolled spread of credentials across files, systems, and environments. In workload identity programmes, it usually appears when teams copy certificates or keys to make access work quickly, then inherit rotation debt, revocation lag, and audit blind spots.

What's in the full article

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

• Step-by-step architecture for issuing SPIFFE identities to VMs through a local workload API
• Envoy and SDS configuration detail for consuming short-lived identities without storing private keys on disk
• Istio AuthorizationPolicy examples that bind access to a specific SPIFFE principal
• Discussion of how Teleport maintains the trust chain across Kubernetes and non-Kubernetes environments

👉 The full Teleport post shows the VM identity flow, trust-chain handling, and mesh policy example.

Deepen your knowledge

SPIFFE workload identity beyond Kubernetes is covered in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building a cross-environment governance model for VMs and clusters, it is worth exploring.