Teams often assume that changing the access technology automatically changes the trust model. In practice, a ZTNA deployment can still preserve static rules, broad exceptions, or weak session governance if policy design is not tightened. The real test is whether access is scoped to the minimum resource and can change as risk changes.
Why This Matters for Security Teams
Replacing VPNs with ZTNA is not just a network refresh. It changes how access is brokered, how trust is evaluated, and how much blast radius a single session can create. If the policy layer still grants broad app groups, long-lived sessions, or weak exception handling, the organisation has changed the front door without changing the keys. That is why NIST’s zero trust guidance emphasises continuous evaluation rather than a one-time gateway decision in NIST SP 800-207 Zero Trust Architecture.
This matters even more when ZTNA is used to reach workloads, APIs, or service accounts that are part of an NHI-heavy environment. NHIMG research shows that Ultimate Guide to NHIs — Standards identifies 90% of IT leaders saying proper NHI management is essential for successful zero trust, which reflects a common gap: access tooling gets upgraded before identity governance does. In practice, many security teams discover the weakness only after a user, contractor, or compromised device has already used a “modern” ZTNA path to reach more than was intended.
How It Works in Practice
ZTNA is strongest when it enforces per-application access, device and posture checks, and policy decisions that can change during the session. The practical shift is from “can this user get onto the network?” to “should this identity, device, and context be allowed to reach this resource right now?” That requires tighter policy design, logging, revocation, and exception management. NIST’s control guidance in NIST SP 800-53 Rev 5 Security and Privacy Controls supports this by treating access as a control objective, not just a transport mechanism.
Teams typically get better results when they design ZTNA around concrete use cases:
- limit each policy to a single application or service path rather than a broad subnet;
- bind access to identity, device health, and session risk signals;
- set short session lifetimes and force re-evaluation on risk changes;
- log decisions, denied attempts, and exception usage for detection and audit;
- remove standing broad access and replace it with just-in-time elevation where possible.
This is especially important where humans and NHIs interact. Service accounts, API keys, and machine-to-machine paths often sit behind the same application surfaces as users, so a ZTNA policy that only considers human login risk can miss the real exposure. NHIMG’s Guide to SPIFFE and SPIRE is relevant here because workload identity needs its own trust model, separate from user access. These controls tend to break down in legacy environments with flat application architectures, shared jump hosts, or vendor portals that cannot express per-resource policy cleanly.
Common Variations and Edge Cases
Tighter ZTNA often increases operational overhead, requiring organisations to balance stronger segmentation against user friction, policy maintenance, and integration effort. That tradeoff becomes sharper when the environment still depends on legacy protocols, thick-client applications, or third-party remote support tools that were built for network-level trust, not application-level authorization. Current guidance suggests that these cases should be handled as exceptions, not as proof that zero trust has failed.
Another edge case is the hybrid estate. A team may replace VPN access for employees but leave administrators, vendors, or automation on older paths, creating inconsistent trust assumptions. That inconsistency is where risk accumulates. Security leaders should also be cautious about over-relying on claims that ZTNA alone solves credential theft. If the policy engine trusts a stolen session, a compromised device, or an over-privileged service account, the control may still fail in the same way a VPN did. The breach pattern described in SonicWall VPN Mass Breach via Stolen Credentials is a reminder that access technology does not neutralise weak identity hygiene.
For NHI-heavy environments, the practical question is whether ZTNA is aligned to the identity layer behind the app, not just the user at the edge. If it is not, the deployment may look modern while preserving the same exposure. There is no universal standard for this yet across every workload type, so security teams should validate each access path individually rather than assume a single ZTNA rollout fixes all remote access risk.
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 CSF 2.0, NIST Zero Trust (SP 800-207) and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AA-01 | ZTNA depends on knowing and authenticating every access request before granting entry. |
| NIST Zero Trust (SP 800-207) | Policy Decision Point | The question hinges on whether access is re-evaluated continuously instead of trusted once. |
| OWASP Non-Human Identity Top 10 | NHI privilege and lifecycle governance | ZTNA often exposes service accounts and API paths that need tighter non-human identity control. |
| NIST SP 800-53 Rev 5 | AC-6 | Least privilege is the core control gap when VPN-style broad access is kept in ZTNA. |
Use centralized policy decisions with continuous evaluation of identity, device, and risk signals.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on July 10, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
