Notifications
Clear all
Topic starter
11/06/2026 11:19 pm
TL;DR: SPIFFE defines workload identity cleanly, but SPIRE still leaves certificates, renewal, and enforcement too close to user space, creating a gap between identity issuance and real-time control, according to Riptides. That gap matters because identity governance for workloads is only as strong as the layer that can actually enforce it.
NHIMG editorial — based on content published by Riptides: Why Riptides Embraces SPIFFE But Not SPIRE
By the numbers:
- Only 38% have automated certificate lifecycle management in place.
- 69% of organisations now have more machine identities than human ones.
Questions worth separating out
Q: How should security teams govern workload identity when certificates are handled in user space?
A: Teams should treat user-space certificate handling as a control dependency, not a complete governance model.
Q: Why do service meshes and sidecars complicate workload identity governance?
A: They insert extra components between the workload and the control point, which increases operational complexity and can shift the certificate relationship from the process to the proxy.
Q: When does a workload identity standard stop being enough on its own?
A: A standard stops being enough when identity is defined clearly but enforcement depends on external components that teams cannot verify consistently.
Practitioner guidance
- Separate identity issuance from enforcement Map where workload identities are created, where certificates are loaded, and where policy is enforced.
- Reduce direct credential handling in applications Identify workloads that still request, store, or renew certificates in code or sidecars, then prioritise designs that remove direct handling from the application path.
- Test enforcement at the runtime boundary Validate whether policy decisions can be enforced at the workload boundary rather than only through proxy or mesh logic.
What's in the full article
Riptides' full post covers the operational detail this post intentionally leaves for the source:
- How the kernel-level identity flow is implemented across workload startup, certificate handling, and trust establishment
- The specific differences between user-space, proxy-based, and kernel-based enforcement paths
- How on-the-wire credential injection works for third-party services that do not speak SPIFFE
- The federation model used to extend workload identity across multiple cloud environments
👉 Read Riptides' analysis of SPIFFE versus SPIRE for kernel-based workload identity →
SPIFFE workload identity in the kernel: what changes for teams?
Explore further
12/06/2026 7:56 am
Identity issuance without runtime enforcement is a governance gap, not a completed control. The article’s core claim is that a workload can be known and still not be controlled where it matters. SPIFFE-style identity gives structure, but if enforcement depends on application participation or proxy coordination, the governance boundary remains porous. For practitioners, the implication is that issuance, renewal, and enforcement must be treated as distinct trust decisions.
A few things that frame the scale:
- 88.5% of organisations acknowledge that their non-human IAM practices lag behind or are merely on par with their human identity and access management efforts, according to The 2024 Non-Human Identity Security Report.
- Only 19.6% of security professionals express strong confidence in their organisation's ability to securely manage non-human workload identities.
A question worth separating out:
Q: How can teams tell whether workload identity is actually reducing risk?
A: Look for fewer places where keys are exposed, fewer code changes required for credential lifecycle, and a shorter path between identity proof and policy enforcement. If the control still relies on manual proxy logic or application coordination, risk has been moved rather than reduced. The best signal is simpler enforcement with less credential surface.
👉 Read our full editorial: Kernel-based workload identity raises the bar for SPIFFE governance
