Notifications
Clear all
Topic starter
03/06/2026 11:01 am
TL;DR: SPIFFE defines how workloads prove who they are without shared secrets, but it stops short of authorization, delegation, proof-of-possession, and registration policy, according to Teleport. That gap matters because mature workload identity now has to cover cross-system trust, CI/CD, and AI agent use cases, not just service-to-service mTLS.
NHIMG editorial — based on content published by Teleport: What SPIFFE Answers for Workload Identity and What It Doesn’t
By the numbers:
- 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.
- Only 5.7% of organisations have full visibility into their service accounts.
- 61% rely on spreadsheets or manual tracking for machine identity management.
Questions worth separating out
Q: How should security teams govern workload identity beyond SPIFFE?
A: Treat SPIFFE as the attestation and bootstrap layer, then add explicit governance for authorisation, registration policy, delegation, and audit evidence.
Q: Why do workload identity programmes still need authorisation controls if SPIFFE is in place?
A: Because SPIFFE verifies identity, not permission.
Q: What do security teams get wrong about workload identity in cloud and CI/CD environments?
A: They often assume short-lived credentials automatically create good governance.
Practitioner guidance
- Separate bootstrap from governance Document which team owns workload attestation, which team owns authorisation, and which team owns audit evidence for each workload class.
- Unify registration with access policy Avoid maintaining workload identity registrations in a separate system of record from human and machine access decisions, because drift quickly undermines auditability.
- Require possession-bound credentials Prioritise proof-of-possession or equivalent token binding for workloads that cross trust domains or act in distributed environments.
Teams that do not unify those records will struggle to maintain trustworthy governance?
👉 Read Teleport's analysis of what SPIFFE covers for workload identity →
Explore further
View Full Forum → | NHI Foundation Course → | Our Services →
03/06/2026 11:04 am
SPIFFE is a workload identity foundation, not an identity governance end state. The spec solves a real bootstrap problem by replacing shared secrets with verifiable workload identity. But workload identity programmes fail when teams mistake bootstrapping for governance and assume the specification also covers authorisation, policy, and lifecycle control. The implication is that architects must separate identity proof from access decisioning before they design the rest of the stack.
A few things that frame the scale:
- 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time, according to the Ultimate Guide to NHIs.
- Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
A question worth separating out:
Q: How can organisations decide whether SPIFFE is enough for their environment?
A: SPIFFE is enough when the problem is basic service-to-service authentication inside a known boundary. It is not enough when workloads must act across trust domains, carry user attribution, or prove possession of a credential. Those cases need additional identity and authorisation design above the spec.
👉 Read our full editorial: SPIFFE solves workload identity bootstrapping, not authorization
