TL;DR: Zero trust should move from perimeter and node controls down to the kernel, combining strong attestation, SPIFFE identities, and kTLS to bind workload communication to verified identity rather than implicit host trust, according to Riptides. That framing matters because it exposes where current workload identity models still rely on static assumptions that modern attackers can bypass.
NHIMG editorial — based on content published by Riptides: Vision Zero Trust: From Perimeter to Kernel
By the numbers:
- 80% of identity breaches involved compromised non-human identities such as service accounts and API keys.
Questions worth separating out
Q: How should security teams govern workload identity in zero trust architectures?
A: Start by treating workload identity as a runtime control, not a deployment label.
Q: Why do service accounts and workloads still create lateral movement risk in cloud environments?
A: Because many environments still trust the host, namespace, or cloud boundary more than the workload's actual state.
Q: What breaks when teams rely on static credentials for workload federation?
A: Static credentials extend trust beyond the moment they were issued, which makes revocation, provenance, and scope harder to govern.
Practitioner guidance
- Audit where host trust still acts as a shortcut Identify any control path where workloads receive identity, access, or credential injection simply because they run on an approved node or in an approved namespace.
- Bind service policy to workload identity Map east-west authorization to SPIFFE IDs or an equivalent workload identity standard, then remove IP-based or subnet-based assumptions wherever practical.
- Minimise static secrets in workload paths Review which workloads still depend on long-lived credentials for federation, service calls, or cloud access, and replace them with on-demand credential issuance where identity can be verified at runtime.
What's in the full article
Riptides' full article covers the implementation detail this post intentionally leaves for the source:
- The kernel-first enforcement model and how attestation gates identity issuance in practice
- SPIFFE, SVID, and kTLS implementation details for workload-to-workload communication
- Federation and on-demand credential injection patterns across hybrid and multi-cloud environments
- The article's own layered zero trust stack from process attestation through cross-partner identity
👉 Read Riptides' analysis of kernel-first zero trust and workload identity →
Kernel-first zero trust and workload identity: are controls keeping up?
Explore further
Kernel-first zero trust exposes the fact that host trust is still a hidden governance assumption. Many programmes say they have moved beyond the perimeter, but they still treat a trusted node as a sufficiently safe place to issue or reuse identity. That assumption fails when userspace can be compromised after the host is considered healthy. The implication is that workload governance must be built around verification at execution time, not trust inherited from infrastructure placement.
A few things that frame the scale:
- 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures, according to Ultimate Guide to NHIs.
- Only 5.7% of organisations have full visibility into their service accounts, which means many teams cannot confidently verify where workload trust begins or ends.
A question worth separating out:
Q: When should organisations move from node-level controls to kernel-level enforcement?
A: When host-based trust no longer matches the threat model. If attackers can reach workloads through injected code, compromised processes, or cross-cloud trust paths, node-level controls are too coarse. Kernel-level enforcement becomes relevant when the programme needs per-process trust decisions, stronger attestation, and tighter control over how identities are issued and used.
👉 Read our full editorial: Kernel-first zero trust raises the bar for workload identity