Topic starter
11/06/2026 11:27 pm
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.
Editorial analysis by NHI Mgmt Group, based on content published by Riptides: “Zero Trust: From Perimeter to Kernel — How Riptides Pushes the Boundary”.
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.
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.
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.
Practitioner guidance
- 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.
Bottom line: Kernel-first zero trust treats the workload, not the host, as the unit of trust, which changes how segmentation and authorization are enforced.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 2 days ago by NHI Mgmt Group
12/06/2026 8:06 am
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.
A few things that frame the scale:
- 90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation, according to the Ultimate Guide to NHIs.
A question worth separating out:
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.
👉 Read our full editorial: Kernel-first zero trust raises the bar for workload identity
This post was modified 2 days ago by NHI Mgmt Group