TL;DR: Teleport's guide argues that microservices secured with long-lived secrets, static certificates and network trust remain exposed to sprawl, rotation pain and weak identity proof, while SPIFFE-based short-lived credentials let services prove who they are and enforce explicit allow rules. The operating assumption shifts from trusted network location to cryptographic workload identity, which changes how NHI programmes should think about proof, policy and rotation.
At a glance
What this is: This guide shows how SPIFFE, Istio and Teleport replace static secrets with cryptographic workload identities for microservices, reducing trust in network location and tightening service-to-service access.
Why it matters: IAM and platform teams need this pattern because service accounts, certificates and workload identity controls become the gatekeeper for east-west traffic, blast radius and auditability in cloud-native environments.
👉 Read Teleport's guide on securing microservices with SPIFFE identities and Istio
Context
Microservices security breaks when teams assume a service can be trusted because of where it runs. In Kubernetes and other ephemeral platforms, IP addresses change, workloads scale dynamically, and long-lived secrets become a poor proxy for identity. The result is a governance gap: policy is still written as if the network were stable, but the workload estate is not.
This article is about replacing that assumption with cryptographic workload identity. SPIFFE gives each service a standardised identity, Istio enforces service-to-service policy in the mesh, and Teleport acts as the issuing and audit layer. For IAM and NHI programmes, the important shift is that access is now governed at issuance and verification time, not after a static secret has already been distributed.
Key questions
Q: How should teams replace static secrets with workload identity in microservices?
A: Start by issuing short-lived workload identities at runtime instead of storing long-lived certificates or API keys in secrets. Tie each credential to the service's attested identity, then enforce service-to-service policy at the mesh or gateway layer so the credential proves who the workload is, not just what it possesses.
Q: Why do long-lived certificates create risk in service-to-service environments?
A: They combine rotation burden, leakage risk and weak proof of identity. In fast-changing environments, a certificate may still be valid long after the workload has changed, which means the credential can outlive the trust context it was meant to represent.
Q: What breaks when microservices rely on network trust instead of cryptographic identity?
A: The trust boundary collapses to IPs, labels or cluster location, all of which are poor signals once workloads scale and move. That opens the door to lateral movement because the policy does not actually verify which service is making the call.
Q: How can security teams audit workload identity decisions in a zero trust mesh?
A: Log each credential issuance, the attested workload identity behind it, and the service relationships that were permitted. That gives you a defensible record of who was allowed to talk to whom and makes identity drift visible before it becomes an incident.
Technical breakdown
Why static certificates fail in ephemeral microservices
Long-lived certificates stored as secrets do not scale cleanly across short-lived, auto-scaling workloads. They are difficult to rotate everywhere at once, easy to leak into repositories or environment variables, and weak as proof because a secret can prove possession without proving which workload is actually running. In a microservices estate, that creates a false sense of identity: the credential is present, but the caller may not be the intended service. The operational problem is not just secret hygiene. It is that network-native trust models still depend on stable endpoints in an environment built on churn.
Practical implication: Treat long-lived certificates as a trust liability in dynamic service environments and move identity checks to runtime issuance and verification.
How SPIFFE and SVIDs establish workload identity
SPIFFE defines a standard identifier for software, while an SVID is the cryptographic document that proves the workload owns that identity. In practice, the workload contacts a local API, the system attests to the process or pod identity, and then issues a short-lived credential for mTLS. That structure matters because the identity is no longer inferred from IP address, namespace alone, or a stored secret. It is asserted, verified and time-bound. For microservices, this turns service-to-service trust into a cryptographic decision rather than a network convenience.
Practical implication: Use SPIFFE-based identity when you need services to prove who they are before any east-west traffic is allowed.
Why default-deny plus explicit allow rules matter
A default-deny policy changes the security model from permissive connectivity to declared trust. Every service relationship must be expressed explicitly, usually by matching the caller's SPIFFE ID and constraining the method and path that are allowed. That is a material governance improvement because it prevents broad lateral movement if a container is compromised. It also makes the policy model auditable: teams can see which workload is permitted to reach which backend and why. This is the service-mesh version of least privilege, but it only works when identity is stable enough to be machine-readable and enforced consistently.
Practical implication: Build service policies around explicit caller identity and narrowly scoped operations instead of IP-based trust or open east-west access.
Threat narrative
Attacker objective: The attacker wants to pivot from one compromised workload to sensitive backend services by abusing weak service identity or broad network trust.
- Entry occurs when a compromised frontend or other workload tries to reach backend services through ordinary east-west traffic rather than a dedicated exploit path.
- Credential access is replaced by identity issuance and attestation, so the critical control point becomes whether the workload can obtain a valid short-lived SVID for the target service.
- Escalation would happen if a service could reuse a static secret or overly broad mesh permission to reach databases or other backends beyond its intended scope.
- Impact is lateral movement into sensitive backend data or service abuse, prevented here by cryptographic identity and default-deny policy.
Breaches seen in the wild
- Azure Key Vault Contributor escalation 2024: Datadog found Azure Key Vault Contributor could add itself to access policies and read every secret, key and certificate in a vault.
- Hugging Face Spaces breach 2024: Unauthorised access to Hugging Face Spaces may have exposed secrets users stored for AI apps; tokens were revoked and org tokens removed.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Static secrets are the wrong trust primitive for ephemeral services: This article reinforces a core NHI governance failure mode. A certificate or secret can prove possession, but it does not prove that the workload presenting it is the intended service, running in the intended context. Once workloads scale and recycle quickly, the governance model that depends on durable credentials no longer matches the runtime reality. Practitioners should stop treating stored secrets as identity evidence in microservices.
SPIFFE creates a named identity layer for software: That matters because identity governance only works when the subject can be stated consistently across environments. The combination of SPIFFE IDs and short-lived SVIDs gives services a standard, verifiable name that can be checked at the mesh boundary and logged centrally. For IAM teams, this is the difference between policy written around infrastructure state and policy written around the workload itself.
Default-deny microservice policy is only credible when identity is cryptographically bound: The article shows that zero trust for services is not simply about blocking traffic. It is about defining which caller identity may invoke which operation, and doing so at runtime. That shifts the center of control from network segmentation to service authentication and authorisation, which is where workload governance belongs.
Identity silos remain the hidden failure point in service-mesh projects: The guide's comparison with isolated mesh CAs is important because many teams solve service-to-service trust inside one platform while leaving the rest of the estate outside the model. If identity stops at the cluster boundary, governance breaks at the first integration point with VMs, CI jobs or external services. The practical conclusion is that workload identity strategy has to outgrow the mesh.
Secret sprawl is not just an operational nuisance, it is a governance signal: When services depend on static credentials, teams are carrying a hidden inventory problem, a rotation problem and an audit problem at the same time. That is why workload identity should be treated as part of the identity lifecycle, not as a point security control. The practitioner takeaway is to align issuance, rotation and revocation around the workload lifecycle, not around the storage location of the secret.
From our research library:
- The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to the State of Secrets in AppSec.
- Read next: Guide to the Secret Sprawl Challenge
What this signals
Static secret dependence is now a governance smell: When services still rely on long-lived credentials, the programme is carrying an invisible inventory of identities that must be rotated, revoked and audited separately. NIST SP 800-207 Zero Trust Architecture is relevant here because the trust decision has to move from network location to continuous verification.
Ephemeral credential trust debt: The average of 6 distinct secrets manager instances is a fragmentation problem, not just a tooling problem. Each additional store adds another rotation path, another audit trail and another place where service identity can drift away from policy.
SPIFFE-based identity gives teams a cleaner control point: Once a service has a standard identity, teams can govern east-west access by workload rather than by infrastructure artefact. That is the point where zero trust becomes operational instead of aspirational.
For practitioners
- Replace static service credentials with workload identity Move microservices off long-lived certificates and API keys stored in secrets, and issue short-lived identities that are bound to the workload at runtime.
- Enforce default-deny between services Start from blocked east-west traffic, then allow only the specific service identity, method and path combinations each workload requires.
- Bind service policy to SPIFFE IDs Use cryptographic service identities as the policy subject instead of IP addresses, labels or namespace trust alone.
- Audit certificate issuance and service access Log who requested each workload credential, which identity was issued, and which services used it so you can trace service-to-service trust decisions.
Key takeaways
- Static credentials are a poor fit for microservices because they do not prove which workload is actually calling a backend service.
- The article shows that zero trust for services depends on runtime identity issuance, not on storing secrets and hoping they stay controlled.
- The practical control shift is from network-based trust to explicit allow rules tied to cryptographic workload identity.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-53 Rev 5 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | The article centres on how services prove identity with SPIFFE instead of static secrets. |
| NHI-07 — Long-Lived Secrets | It contrasts short-lived SVIDs with static certificates and secrets stored for reuse. | |
| NHI-05 — Overprivileged NHI | Default-deny policies and explicit allow rules are used to limit service-to-service access. | |
| Recommendation — Adopt runtime workload authentication so service identity is attested before access is granted. Replace long-lived service credentials with short-lived, automatically rotated identities. Scope each workload's permissions to the exact services and operations it needs. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The guide focuses on explicit service authorisation based on verified identity. |
| Recommendation — Bind permissions to verified workload identities and review entitlements for east-west traffic. | ||
| NIST SP 800-53 Rev 5 | IA-9 — Service Identification and Authentication | Microservices authenticate to one another using SPIFFE-backed workload credentials. |
| Recommendation — Use service authentication controls to verify workload identity before any backend access is allowed. | ||
| NIST Zero Trust (SP 800-207) | Zero Trust Architecture — Zero Trust Architecture | The article is explicitly about moving microservices from network trust to zero trust. |
| Recommendation — Apply zero trust principles so every service call is authorised from identity rather than location. | ||
| MITRE ATT&CK | TA0008 — Lateral Movement | The guide addresses stopping a compromised service from pivoting to back-end systems. |
| Recommendation — Harden east-west controls to reduce attacker lateral movement between services. | ||
Key terms
- SPIFFE ID: A SPIFFE ID is a unique, cryptographically verifiable identity for a workload or service. In the SPIFFE framework, it is expressed as a URI, such as spiffe://trust-domain/path, and is used to authenticate software entities across systems without relying on static secrets, enabling workload identity and policy enforcement.
- SVID: An SVID is a SPIFFE Verifiable Identity Document, usually an X.509 certificate or JWT that represents a workload identity. It is short-lived and meant to replace static secrets, but its security depends on accurate attestation, secure distribution, and timely revocation when the workload changes or disappears.
- Default deny: Default deny is an authorization pattern where no traffic is allowed until a policy explicitly permits it. For microservices, it exposes hidden service dependencies and prevents accidental trust between workloads that should only communicate through named, reviewable paths.
- 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.
What's in the full article
Teleport's full guide covers the operational detail this post intentionally leaves for the source:
- Step-by-step Istio policy configuration for default-deny and explicit allow rules
- The Sock Shop implementation flow showing how Teleport, Istio and SPIFFE interact in practice
- The comparison between reference SPIFFE implementations and a broader identity control plane
- Examples of how Teleport logs workload certificate issuance and service access events
👉 Teleport's full guide covers the implementation flow, policy examples and workload identity details
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 programme, it is worth exploring.
Published by the NHIMG editorial team on June 7, 2026.
Updated on October 7, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org