Notifications
Clear all
Topic starter
12/06/2026 12:32 am
TL;DR: SPIFFE deployments still rely on app libraries, sidecars, or proxies that add complexity, weaken process binding, and make workload identity harder to operate at scale, according to Riptides. Moving enforcement into the Linux kernel reframes NHI as a native control plane issue, not an add-on plumbing layer.
NHIMG editorial — based on content published by Riptides: Kernel Rethinking Workload Identity at the Kernel Level
By the numbers:
- 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time.
- 69% of organisations now have more machine identities than human ones.
- Only 5.7% of organisations have full visibility into their service accounts.
Questions worth separating out
Q: How should security teams evaluate kernel-level workload identity for production use?
A: They should test whether the design improves process binding, removes helper-layer trust, and enforces identity at connection time across the environments they actually run.
Q: Why do sidecars and proxies create workload identity governance risk?
A: They create an extra identity layer between the workload and the communication event, which can weaken process fidelity and make troubleshooting or policy verification harder.
Q: When is SPIFFE alone not enough for NHI governance?
A: SPIFFE alone is not enough when identity is issued correctly but enforced inconsistently, or when secrets and policy still depend on helper processes.
Practitioner guidance
- Map identity enforcement to the runtime boundary Inventory where workload identity is actually enforced today, then separate policy definition from runtime enforcement.
- Test process binding explicitly Validate whether certificates and trust material are attached to the executing process or merely to the surrounding workload envelope.
- Reduce dependency on helper-layer identity Treat proxies and sidecars as transitional controls unless they are the only feasible path.
What's in the full article
Riptides' full post covers the operational detail this post intentionally leaves for the source:
- Kernel module packaging and compatibility work across Linux distributions and cloud provider ecosystems
- Implementation details for kTLS-based identity injection at the record layer
- Observability and tracepoint design used to debug kernel-level identity enforcement
- Installation and upgrade behaviour across existing provisioning workflows
👉 Read Riptides' analysis of kernel-level workload identity for SPIFFE environments →
Kernel-level workload identity: what it changes for IAM teams?
Explore further
12/06/2026 9:48 am
Kernel-level workload identity exposes the operational gap between identity issuance and identity enforcement. The article’s central point is that SPIFFE can solve workload identity abstraction while still leaving enforcement fragmented across application code, proxies, and sidecars. That is a governance problem, not just an architecture preference. The implication is that NHI programmes should judge controls by where identity is enforced in runtime, not by where it is defined in policy.
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.
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
A question worth separating out:
Q: What should teams prioritise first in workload identity modernisation?
A: They should prioritise where identity is enforced before they optimise how identity is represented. A runtime-bound model that works across Kubernetes, VMs, and bare metal is more durable than a model that depends on one orchestration pattern.
👉 Read our full editorial: Kernel-level workload identity changes how NHI is enforced
