Kernel-first zero trust raises the bar for workload identity

At a glance

What this is: This is an analysis of kernel-first zero trust for workload identity, arguing that attestation and SPIFFE-based identities should replace implicit trust in userspace and host boundaries.

Why it matters: It matters because IAM, PAM, and NHI teams need identity controls that can survive lateral movement, ephemeral workload execution, and cross-cloud trust decisions.

By the numbers:

• 80% of identity breaches involved compromised non-human identities such as service accounts and API keys.

👉 Read Riptides' analysis of kernel-first zero trust and workload identity

Context

Kernel-first zero trust starts from a simple premise: trust should not begin at the network edge or even at the node boundary. In this model, workload identity depends on attestation first, then issuance of a cryptographic identity, then policy-controlled communication. For NHI programmes, that shifts the conversation from who has a secret to what has been verified at runtime.

The governance problem is that many infrastructure models still assume a trusted host or trusted runtime once a workload is inside the environment. Riptides argues that this is exactly where implicit trust lingers, especially in cloud-native and hybrid estates. For identity teams, the question is whether existing workload identity, secrets, and Zero Trust controls can actually constrain behaviour after execution begins.

Key questions

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. Require attestation before issuing identity, bind policy to the workload itself, and remove dependence on static credentials or trusted network zones. The goal is to make every trust decision conditional on verified state, so compromise of one node does not automatically extend trust to everything running on it.

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. If a compromised process can inherit identity or reuse credentials after execution starts, lateral movement becomes easier even when permissions look narrow on paper. The control problem is trust inheritance, not just entitlement size.

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. They also create a hidden dependency on secrets handling rather than identity proof. In practice, static federation weakens least privilege because the credential can outlive the workload state it was meant to represent.

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.

Technical breakdown

Why attestation comes before workload identity

Attestation is the proof step that checks code origin, integrity, and execution environment before a workload is treated as trusted. In kernel-first designs, the system does not assign a usable identity until the process or workload passes those checks. That matters because workload identity is only as strong as the confidence behind issuance. If a compromised binary, injected process, or unverified userspace runtime can obtain the same identity path as a legitimate workload, then the identity layer becomes a wrapper around compromise instead of a control against it.

Practical implication: require runtime attestation as a gating control before any workload identity or credential issuance.

How SPIFFE and kTLS bind communication to identity

SPIFFE gives workloads portable cryptographic identities, usually expressed as SPIFFE IDs and delivered as SVIDs, while kTLS binds transport security closer to the kernel. Together, they reduce reliance on static secrets and make service-to-service trust policy-driven rather than network-driven. The important shift is not encryption alone. It is that communication is authenticated as a function of verified workload identity, which lets policy engines decide whether one workload can speak to another under least privilege.

Practical implication: map service-to-service policy to workload identity, not to IP ranges or host membership.

Where kernel-first zero trust changes the blast radius model

Traditional zero trust often stops at the perimeter, node, or application layer, which still leaves room for implicit trust inside a host. Kernel-first thinking narrows that gap by treating userspace as untrusted until proven otherwise and by continuously re-evaluating the workload. That changes the blast radius model because lateral movement depends less on finding a trusted network path and more on defeating identity issuance, policy, and attestation together. In practice, the attack surface becomes per-process and per-workload rather than per-subnet.

Practical implication: segment policy at the workload layer and treat host trust as an insufficient security boundary.

NHI Mgmt Group analysis

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.

SPIFFE IDs are only meaningful when identity issuance is conditioned on proof, not convenience. Kernel-level attestation changes SPIFFE from a portable identity format into a control that depends on runtime evidence. Without that condition, the same identity model can be attached to unverified code, which weakens least privilege and undermines policy enforcement. Practitioners should treat identity issuance as a governed event, not an automatic byproduct of deployment.

Least privilege for workloads is no longer just about permission scope, but about trust scope. A workload can be tightly permissioned and still be dangerous if the environment assumes it is trustworthy before attestation. That is the specific control gap kernel-first zero trust is trying to close: permissions alone do not solve identity provenance. The conclusion for identity teams is that entitlement design and trust establishment must be evaluated together.

Cross-cloud federation becomes defensible only when static credentials are replaced with verifiable identity and policy. The post’s federation model is really a rejection of long-lived secrets as the basis for inter-environment trust. Once workloads move across clouds or partners, the old assumptions about fixed network perimeters break down. Practitioners should re-evaluate whether their federation model can survive compromise without falling back to shared secrets or broad trust zones.

Zero trust at the kernel sharpens the identity blast radius concept for modern infrastructure. The real issue is not simply whether an attacker gets in, but how far a verified workload can move once identity is granted. Kernel-first controls try to compress that movement window by making trust conditional, local, and revocable. For NHI and IAM teams, the practical takeaway is that blast radius now has to be measured at workload granularity.

From our research:

• 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.
• For a broader baseline, see Ultimate Guide to NHIs , Key Challenges and Risks for the visibility, over-privilege, and sprawl patterns that make kernel-first controls necessary.

What this signals

Kernel-first programmes will force identity teams to separate trusted placement from trusted state. That distinction matters because many current controls still assume a workload is safe once it runs inside approved infrastructure. Teams that cannot verify runtime state will struggle to make least privilege meaningful across hybrid and multi-cloud estates.

With 97% of NHIs carrying excessive privileges, according to Ultimate Guide to NHIs, identity scope remains too broad even before runtime trust is considered. Kernel-level attestation does not replace entitlement hygiene, but it does expose where entitlement governance has been built on assumptions rather than proof.

For practitioners

• 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. Replace that shortcut with attestation and explicit policy checks before trust is extended.
• 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. The control objective is to make communication decisions depend on the verified workload, not the place it runs.
• 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. This reduces the chance that trust outlives the workload session.
• Re-test blast radius at process level Run tabletop and red-team scenarios that assume a legitimate workload is compromised after launch and then try to move laterally through policy gaps. Use the results to decide whether segmentation is being enforced at the process level or only at the network layer.

Key takeaways

• Kernel-first zero trust reframes workload security around proof of execution state, not trust in the host or network.
• Identity controls that depend on static secrets or inherited trust will struggle to contain lateral movement in cloud-native environments.
• Practitioners should evaluate whether attestation, workload identity, and policy enforcement are aligned at runtime rather than only at provisioning.

Key terms

• Attestation: Attestation is the proof step that verifies code origin, integrity, or execution environment before trust is granted. In workload security, it determines whether a process, container, or service is allowed to receive identity or credentials.
• SPIFFE ID: A SPIFFE ID is a portable cryptographic identity assigned to a workload under the SPIFFE standard. It gives security teams a consistent way to reference workloads in policy, but only works well when identity issuance is tied to strong verification.
• Blast Radius: Blast radius is the amount of environment an attacker or compromised workload can reach after initial compromise. In identity governance, it measures how far trust, access, and lateral movement can spread before controls stop it.
• On-demand Credential Injection: On-demand credential injection delivers credentials only when a workload needs them and removes them when the task is complete. It reduces long-lived secret exposure, but it still depends on accurate identity proof and lifecycle control to avoid extending trust past the intended session.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or lifecycle governance, it is worth exploring.

This post draws on content published by Riptides: Vision Zero Trust: From Perimeter to Kernel. Read the original.