They end up verifying too much and constraining too little. The programme may look mature because access is checked continuously, but the identities themselves still hold broad entitlements. That leaves residual risk in place even when the authentication story appears strong.
Why zero trust still needs access scoping
Zero trust changes how trust is granted, not how much authority an identity should have. If teams use it as a substitute for access scoping, they can end up checking every request while leaving broad entitlements intact. The control looks stronger because access is continuously evaluated, but the blast radius is still determined by the permissions already attached to the identity.
That matters because zero trust is strongest when it reduces implicit trust and limits what a verified identity can do. It is not a replacement for entitlement design, role scoping, or periodic access review. A system can authenticate well and still be overexposed if the account behind the request can reach too many resources.
For the architectural baseline, NIST SP 800-207 Zero Trust Architecture frames the model as continuous verification with policy enforcement, but that policy still has to express least privilege and segmentation. The question is not whether the caller is checked, it is whether the checked caller should have that level of reach in the first place.
What actually breaks in the access model
When scoping is weak, zero trust becomes a gate around an oversized keyring. Teams may add conditional access, device posture checks, and request-time policy, yet the underlying identity still carries dormant entitlements, cross-environment access, or permissions that were never narrowed after provisioning. The result is a mature authentication story paired with an immature authorization model.
This is where the distinction between authentication and authorization becomes operational, not academic. Verification answers who or what is making the request; scoping answers what that caller should be allowed to do. If the second question is left broad, zero trust can only slow misuse, not meaningfully contain it.
Identity governance work such as IAM and IGA Basics helps separate those layers by tying provisioning, entitlements, access reviews, and least privilege to the actual job or workload need. That separation is what prevents continuous verification from becoming a false substitute for authorization design.
For workload and machine access, Guide to SPIFFE and SPIRE shows the same principle at the service layer: strong workload identity only helps when the workload is also constrained to the specific services and actions it genuinely needs.
Why the residual risk remains even when authentication looks strong
Residual risk remains because broad entitlements are still usable after the zero-trust check passes. A verified identity with excessive privilege can still exfiltrate data, invoke sensitive functions, or move across environments if the policy is not narrowed to a defensible scope. Zero trust reduces implicit trust at the perimeter of each request, but it does not automatically remove standing privilege.
That weakness is especially visible in service-to-service and machine-to-machine access, where a valid token or certificate may prove identity but says nothing about whether the scope is minimal. A well-implemented trust check can confirm the caller, yet still leave the caller able to do too much once inside the policy boundary.
For identity-heavy environments, Ultimate Guide to NHIs is useful because it ties zero trust to lifecycle controls, offboarding, visibility, and excessive permissions rather than treating trust checks as the finish line. The same principle applies to human and non-human access: the control is only complete when the scope is small enough to survive compromise.
Risk and Threat Considerations
The main risk is control illusion. Teams can report progress on zero trust adoption while leaving overprivileged identities in place, which preserves the attacker’s payoff if a token, session, or account is abused. In practice, that means the environment may resist unauthorised access at the edge but still fail to contain authorised misuse after authentication succeeds.
Failure mechanism: Continuous verification is layered on top of broad entitlements, so the policy checks the caller repeatedly while still allowing access that should never have been granted. The weakness is not the trust model itself, but the assumption that verifying more often is equivalent to scoping better.
Impact: Excess privilege remains the blast-radius driver, so compromise of one verified identity can still expose sensitive systems, data, or cross-environment paths. At scale, this creates persistent exposure even in organisations that appear mature on paper.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, NIST Zero Trust (SP 800-207) and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Broad entitlements are the core weakness in this question. |
| IA-2 — Identification and Authentication (Organizational Users) | Zero trust still depends on strong user authentication at each access decision. | |
| IA-9 — Service Identification and Authentication | Workload and service access is central when zero trust is applied to machine-to-machine paths. | |
| Recommendation — Enforce least privilege so verification does not sit atop excessive access. Authenticate organizational users strongly before applying authorization policy. Use service authentication only with tightly scoped access permissions. | ||
| NIST Zero Trust (SP 800-207) | N/A — Zero Trust Architecture | The subject is about correctly applying zero trust as a control model. |
| Recommendation — Implement zero trust with policy enforcement plus least-privilege access boundaries. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | Access scoping and entitlement review are the practical failure points here. |
| Recommendation — Review and reduce access rights so verified users and services cannot overreach. | ||
Practitioner Guidance
What to prioritise: Review whether your zero-trust policy is narrowing decisions, or only rechecking them. If the same identity can still reach multiple high-value resources after passing the control, you have added assurance without reducing exposure.
What to verify: Confirm that every major identity type, especially service accounts and other non-human actors, has an explicit scope boundary, a current owner, and a reviewable reason for each entitlement. Continuous verification should sit on top of that baseline, not replace it.
Common mistake: Treating conditional access, MFA, or device posture as if they solve overprovisioning. Those controls reduce misuse opportunity, but they do not fix role design, entitlement sprawl, or stale access.
Practitioner takeaway: Zero trust should shrink trust assumptions at decision time, while access scoping shrinks the damage possible after the decision is granted. If one is present without the other, the programme is more observable, not more secure.
Related resources from NHI Mgmt Group
- Should security teams treat Zero Trust and JIT access as the same control?
- How should security teams run access reviews for non-human identities?
- How should security teams govern non-human identities that have persistent access?
- How should security teams govern API keys used for generative AI access?