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.
At a glance
What this is: This analysis examines kernel-first zero trust for workload identity and concludes that verified attestation, SPIFFE-based identity, and identity-bound transport tighten trust boundaries beyond host-level controls.
Why it matters: It matters because IAM, NHI, and platform teams need to understand where workload identity controls still rely on implicit trust and how that affects segmentation, credential scope, and blast radius.
Context
Zero trust for workloads only works when the trust decision follows the workload, not just the host or network zone. The article argues that identity-based controls need to reach the kernel because node-level trust still assumes too much about the code running above it.
For identity programmes, the important shift is from trusting an addressable machine to verifying the process or workload behind each request. That changes how teams think about NHI issuance, transport security, and policy enforcement across hybrid and multi-cloud environments.
The article’s central claim is that implicit trust lingers in userspace and host-based models even when organisations believe they have adopted zero trust. In that sense, the starting position is typical of modern infrastructure stacks, where controls often stop one layer too high.
Key questions
Q: What breaks when zero trust stops at the node instead of the kernel?
A: When zero trust stops at the node, every process on a trusted host can inherit more trust than it should. That creates a gap between machine trust and execution trust, which attackers can exploit through code injection, privilege reuse, or lateral movement inside the host. Kernel-level controls narrow that gap by verifying the workload itself before identity is issued.
Q: Why do workload identity controls reduce lateral movement risk?
A: They reduce lateral movement because policy is tied to a verified workload identity rather than to a shared network boundary or static secret. If an attacker compromises one process, they do not automatically gain the same communication rights as every other process on that host. That makes east-west access far less ambient and much easier to contain.
Q: What are the signs that host-based zero trust is not enough?
A: Common signs include services trusting anything inside a cluster, credentials that live longer than the workload session, and policies written around nodes instead of processes. If access decisions still assume a trusted host is a trusted workload, the architecture is preserving implicit trust rather than removing it. That is where compromise can spread faster than expected.
Q: How should teams compare workload identity federation and static credentials?
A: Federation is the better fit when workloads need portable trust across cloud boundaries without long-lived shared secrets. Static credentials are simpler to start with, but they expand blast radius and make offboarding harder. The decision usually turns on whether the team needs identity to follow the workload or just needs a fixed secret for a single environment.
Technical breakdown
Why kernel-level attestation changes workload trust
Kernel-level attestation moves trust establishment closer to execution, where code origin, runtime state, and environment can be checked before identity is issued. In this model, a workload does not inherit trust from the node. It earns a cryptographic identity after proving it is the expected workload in the expected state. That is materially different from host-based admission controls because the security question shifts from "is this machine allowed?" to "is this process legitimate right now?"
Practical implication: tie workload identity issuance to attestation rather than to host membership alone.
SPIFFE and SPIRE-style workload identity as the policy anchor
SPIFFE provides a portable identity format for workloads, while SPIRE is the reference implementation that issues and verifies those identities after attestation. Once a workload has an identity, policy can be written against that identity instead of against static network location or embedded secrets. That gives operators a common control plane for workload-to-workload trust across clusters and cloud boundaries. The key mechanism is that identity is derived, not assumed, and access decisions are made on that derivation.
Practical implication: build service authorization around workload identities, not IP addresses or shared credentials.
kTLS and identity-bound communication reduce ambient trust
kTLS pushes encrypted transport handling into the kernel, which matters when identity is already anchored there. Combined with workload identity, it lets communication be bound to a verified identity rather than to a socket path that any process on the host might reuse. This closes a common gap in east-west traffic: even if the host is compromised, every process should not automatically gain the same communication rights. The architectural payoff is tighter blast-radius control and less dependence on static secrets.
Practical implication: pair transport protection with identity enforcement so process-level trust does not collapse into host-level trust.
Threat narrative
Attacker objective: The attacker’s objective is to turn one compromised execution environment into broader east-west access and durable persistence across workloads.
- Entry occurs when an attacker gains a foothold on a trusted host or workload boundary, but the real weakness is the assumption that host presence equals trust.
- Escalation follows when userspace processes inherit trust without fresh attestation, letting malicious code or injected processes act as if they were approved workloads.
- Impact comes from lateral movement and persistence across services because trust decisions are still anchored to static node or network assumptions rather than to verified workload identity.
Breaches seen in the wild
- Salt Typhoon telecom intrusions 2025: Salt Typhoon breached US telecoms mainly with stolen logins, then harvested SNMP strings and TACACS/RADIUS keys to spread and persist for years.
- Storm-2949 Azure Breach: Storm-2949 social engineering attack turns one cloud identity compromise into full Azure tenant breach.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Kernel-first trust is an identity model, not a transport upgrade: Once workload identity is issued only after attestation, the control point moves from the perimeter and node to the execution layer itself. That matters because host-level trust still assumes too much about what is running on the machine. Practitioners should read kernel-first designs as a change in trust model, not as a narrower version of zero trust.
Static trust in userspace is the real governance gap: The assumption that a trusted host equals trusted processes was designed for environments where execution was simpler and more centralised. That assumption fails when attackers can inject code, pivot inside the host, or reuse ambient permissions across workloads. The implication is that workload governance has to distinguish the machine from the process and the process from the identity it presents.
SPIFFE-style identity becomes the control surface for cross-cloud policy: When identity is portable and cryptographically bound to attested workloads, policy can follow the workload across clusters and clouds without falling back to long-lived shared secrets. That aligns with NIST Zero Trust Architecture principles and with NHI governance patterns that separate identity from location. Practitioners should treat portable workload identity as the foundation for segmentation, federation, and least privilege.
Kernel-level control exposes identity blast radius as the decisive metric: The article shows that reducing compromise impact is less about where a workload runs and more about how far its identity can reach. If a process can only communicate after fresh verification, the blast radius shrinks materially. For security architecture teams, blast-radius control becomes a stronger design objective than perimeter hardening alone.
Workload identity governance now spans attestation, issuance, and revocation: The most useful concept here is identity continuity under runtime scrutiny. An identity that was valid at startup but is never re-checked does not fit the threat model described in the article. The practitioner takeaway is to govern workload identity as a lifecycle, not as a one-time enrollment event.
From our research library:
- 90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation, according to the Ultimate Guide to NHIs.
- Read next: Zero Trust Identity Guide
What this signals
Kernel-first trust forces workload identity teams to rethink the control boundary: Policies that begin at the host still leave a gap between execution and authorization. As more environments adopt hybrid and multi-cloud patterns, the practical question becomes whether identity decisions are still being made at the right layer for the threat model.
Identity blast radius is now a first-class design variable: The more precisely a workload identity is bound to attestation, transport, and policy, the less one compromise can spread across services. That makes lifecycle governance for workloads, not just credentials, a core Zero Trust discipline.
Zero Trust for workloads becomes more defensible when trust is issued, not assumed. Teams should expect stronger separation between platform trust, process trust, and communication trust, because each of those layers fails differently under attack.
For practitioners
- Audit where host trust still substitutes for workload trust Map services that rely on node membership, subnet trust, or shared runtime assumptions instead of verifying the process that is actually sending the request.
- Bind service authorization to workload identity Use cryptographic workload identities for east-west policy so service access follows the attested workload rather than the machine it happens to run on.
- Separate attestation from network admission Require attestation before identity issuance, then enforce identity-bound communication so a trusted host does not automatically grant trusted process behaviour.
- Review where long-lived secrets still carry trust Identify workloads that still depend on embedded credentials or static tokens and replace them with identity-bound issuance and revocation paths.
Key takeaways
- Kernel-first zero trust treats the workload, not the host, as the unit of trust, which changes how segmentation and authorization are enforced.
- The article’s model reduces ambient trust by binding identity to attestation and verified communication, making lateral movement harder to scale.
- For practitioners, the practical lesson is to stop assuming node trust is enough and to design for process-level verification, portable identity, and tighter blast-radius control.
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 Zero Trust (SP 800-207) and NIST CSF 2.0 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 verified workload identity before communication is allowed. |
| NHI-05 — Overprivileged NHI | Kernel-first policy is about shrinking the rights a workload can exercise once trusted. | |
| NHI-07 — Long-Lived Secrets | The article explicitly contrasts identity-bound issuance with static credentials and embedded secrets. | |
| Recommendation — Require attestation before issuing workload identities and reject unauthenticated process traffic. Scope workload permissions to the smallest identity-bound policy set possible. Replace embedded secrets with short-lived, identity-bound credential issuance and revocation. | ||
| NIST Zero Trust (SP 800-207) | Zero Trust Architecture — Zero Trust Architecture | The article extends zero trust principles to the workload and kernel layers. |
| Recommendation — Apply zero trust policy at the workload layer rather than relying on node trust. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Identity-based authorization is the core control logic in the article. |
| Recommendation — Align workload permissions to verified identities and continuously review authorization scope. | ||
| MITRE ATT&CK | TA0008;TA0004 — Lateral Movement; Privilege Escalation | The article’s threat model is built around preventing post-compromise movement inside trusted hosts. |
| Recommendation — Map host-trust gaps to lateral movement and privilege escalation paths in your detections. | ||
Key terms
- Kernel-First Zero Trust: A zero trust model that places verification and policy enforcement as close as possible to execution in the operating system kernel. It assumes no inherent trust in userspace or the host boundary and requires identity to be established from runtime proof, not location or network membership.
- 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.
- Attestation: Attestation is verifiable evidence about a workload’s execution context, such as where it is running, who started it, and whether it matches policy. In agent governance, attestation can be used to bootstrap enrollment and to justify access decisions that need to change as the workload behaves differently.
- Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.
Deepen your knowledge
NHI governance, workload identity security, and identity lifecycle management 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 or NHI programme, it is worth exploring.
Published by the NHIMG editorial team on June 11, 2026.
Updated on October 10, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org