Topic starter
06/11/2026 6:35 pm
TL;DR: Many enterprises already own MFA, ZTNA, posture and segmentation controls, but those tools still lack a shared policy model, leaving humans and workloads governed by separate engines with inconsistent decisions, according to NetFoundry's commissioned KuppingerCole Analysts Buyer’s Compass. The deeper issue is not missing features but fragmented identity policy that cannot coordinate access across human, NHI and AI agent use cases.
Editorial analysis by NHI Mgmt Group, based on content published by NetFoundry: “New Analyst Report: Choosing a Zero Trust platform? Start with the traffic it has to carry.”.
Key questions
Q: How should teams unify zero trust policy across humans and workloads?
A: Teams should unify zero trust policy by using a single policy model for both human access and workload access, while separating the identity signals, controls and enforcement points.
Q: Why do workload connections need different zero trust controls than human sessions?
A: Workload connections need different zero trust controls because they are usually non-interactive, machine-to-machine sessions that cannot use human factors such as passwords, MFA prompts or browser-based step-up.
Q: What frameworks help govern AI agent access to tools and data?
A: Teams should combine agentic AI risk guidance with zero trust and NHI controls.
Practitioner guidance
- Define one policy owner for each identity class Separate the governance for human sessions, workload-to-workload flows and agent-mediated access so each class has a clear decision authority and revocation path.
- Test zero trust decisions across mixed enforcement points Validate whether MFA, posture, segmentation and ZTNA make the same decision when a session changes context or crosses from human to workload execution.
- Treat machine connectivity as a distinct design pattern Document where mutual authentication, latency sensitivity and end-to-end trust make a brokered human access model unsuitable for services and workloads.
Bottom line: Zero trust programmes can fail even when the right tools are already deployed, because separate engines do not create a shared access decision model.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
06/11/2026 6:41 pm
Zero trust is becoming a policy-integration problem, not a control-availability problem. Enterprises already own many of the right components, but separate enforcement engines do not create a governed system. When access decisions are fragmented across ownership silos, the architecture can look mature while still failing to make consistent decisions. Practitioners should treat policy unification as the core zero trust design task.
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 do bearer tokens fail as proof of machine identity?
A: Bearer tokens fail as proof of machine identity because possession alone is enough to use them, so any stolen or replayed token can impersonate the workload. They do not cryptographically prove that the sender is the intended workload unless they are bound to a client certificate, signed key, device attestation or other sender-constraining control.
👉 Read our full editorial: Zero trust stalls when policy models do not span humans and machines