Zero trust is a security model that assumes breach and requires continuous verification of identity, device, and context. It is not a single product you can buy and switch on. Teams should treat it as an architecture and operating approach, then map controls, telemetry, and policy enforcement to that model.
Strategy defines the model, not the merchandise
zero trust as a strategy is an operating model: assume no implicit trust, verify every request, and make access decisions from identity, device posture, location, sensitivity, and policy. Zero trust as a product claim is narrower and often misleading, because a single tool rarely delivers the full model on its own. The important distinction is between an architecture you design and a feature you may use to support it.
That distinction matters because the strategy spans policy, enforcement points, telemetry, segmentation, and governance across many systems. A product can contribute one layer, such as access brokering, device checks, or policy enforcement, but it does not by itself establish continuous verification or least privilege across the environment. Teams should therefore ask what control objective the product actually satisfies, not whether it uses the zero trust label.
For architecture-level grounding, the NIST model is still the clearest reference point: NIST SP 800-207 Zero Trust Architecture frames zero trust around policy decisions and enforcement rather than a single technology purchase.
How product claims are usually overstated
Vendors commonly compress a broader architecture into one capability, such as secure access, conditional access, network segmentation, or identity-aware proxying. Those are useful controls, but they are only parts of the strategy. If the rest of the stack still allows broad standing access, weak telemetry, unmanaged devices, or uncontrolled service access, the organisation has bought a feature set, not implemented zero trust.
A good way to test the claim is to map it to the actual control plane. Does the product enforce policy at the point of access? Does it consume trusted signals? Can it reduce privilege over time? Can it support device, workload, and user contexts consistently? If the answer is no, the product may be adjacent to zero trust without being zero trust in operational terms.
This is why identity and access governance often become the practical boundary of the strategy. NHIMG’s Ultimate Guide to NHIs shows how visibility, lifecycle, rotation, and excessive privilege shape whether zero trust is actually enforceable in day-to-day operations. The same principle is echoed by the wider workload identity model in Guide to SPIFFE and SPIRE, where identity, attestation, and trust bundles are treated as part of the architecture rather than a product switch.
What practitioners should evaluate before accepting the label
When a product claims zero trust, practitioners should separate marketing language from control reality. The question is not whether the product is “zero trust enabled,” but whether it measurably reduces implicit trust, constrains lateral movement, and supports continuous authorization decisions across the relevant assets and identities.
- Verify whether access is evaluated continuously or only at login.
- Check whether policy is enforced centrally or only within one tool boundary.
- Confirm that device, user, and workload signals are actually consumed.
- Look for proof of least privilege, short-lived access, and revocation.
- Test whether telemetry is sufficient to detect policy bypass or drift.
Independent research supports why this matters. In NHIMG’s The 2026 Infrastructure Identity Survey, 70% of organisations granted AI systems more access than a human employee would receive for the same job, and 67% still relied heavily on static credentials. That is a reminder that “zero trust” fails quickly when access, privilege, and credential handling are still broad or static.
Practitioner takeaway: Treat zero trust as a design and control assurance problem, not a procurement label, and only accept a product claim when you can show it enforces real policy, real signals, and real least privilege across the scope you care about.
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 address the attack and risk surface, while NIST SP 800-63, NIST Zero Trust (SP 800-207), CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | AAL — Authentication Assurance Levels | Zero trust depends on strong, context-aware authentication decisions. |
| Recommendation — Use appropriate authentication assurance before granting access in zero trust flows. | ||
| NIST Zero Trust (SP 800-207) | ZA-1 — Zero Trust Architecture | Directly governs zero trust as an architecture rather than a product feature. |
| Recommendation — Design policy decisions and enforcement points around zero trust architecture. | ||
| CIS Controls v8 | 6 — Access Control Management | Zero trust requires least privilege, access review, and revocation discipline. |
| Recommendation — Reduce standing access and validate permissions continuously. | ||
| NIST CSF 2.0 | PR.AC — Access Control | Zero trust strategy is implemented through enforced access control outcomes. |
| Recommendation — Apply access control policies that verify and limit every request. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Inventory and Visibility | Zero trust fails when non-human access paths are unseen or unmanaged. |
| Recommendation — Inventory non-human identities and remove unknown access paths. | ||
Related resources from NHI Mgmt Group
- What is the difference between zero trust for users and zero trust for NHIs?
- What is the difference between JIT access and Zero Trust for NHIs?
- What is the difference between shared logins and a centralized zero trust access model?
- What is the difference between using zero trust to protect internal operations and using it as a product capability?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 18, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
