TL;DR: Identity centric ZTNA shifts access decisions from static passwords and perimeter trust to continuous verification, adaptive policies, and least privilege across remote work, cloud, third-party, and device contexts, according to Whiteswan Security. The security model matters because traditional IAM assumptions break down when access must be re-evaluated in real time across users, devices, and applications.
At a glance
What this is: This is an analysis of identity centric ZTNA and its case for replacing password-heavy, perimeter-based access with continuous verification and least-privilege controls.
Why it matters: It matters because IAM, NHI, and human access programmes increasingly need the same access model to handle remote users, third parties, cloud apps, and device posture without overextending trust.
By the numbers:
- The escalating frequency of data compromises, breaches, leaks, and exposures in 2022 affected over 422 million individuals in the United States alone.
- The same year saw 1,802 data compromises in the United States.
- Only 5.7% of organisations have full visibility into their service accounts.
👉 Read Whiteswan Security's analysis of identity centric ZTNA for hybrid access
Context
Identity centric ZTNA is a model for deciding access by identity, device posture, and context instead of assuming trust after a successful login. The IAM problem it addresses is familiar: passwords, broad network access, and one-time authentication do not hold up well when users, contractors, cloud services, and endpoints move constantly across environments.
The article frames ZTNA as a response to rising compromises and to the limits of traditional VPN-style access. That is directionally sound, but the deeper issue is governance. Enterprises now need access controls that can keep pace with hybrid work, third-party connectivity, and device risk without turning every session into a standing trust grant. That is standard territory for modern IAM and ZTA programmes, not an edge case.
The article's starting position is typical for organisations trying to move from perimeter security to identity-led access control, but it blends human access, device trust, and service connectivity into one model that practitioners must separate before implementation.
Key questions
Q: How should security teams implement identity centric ZTNA in hybrid environments?
A: Start by defining the resources that should be app-scoped, then tie access to identity, device posture, and session context. Keep broad network reach out of the design. ZTNA works best when IAM, PAM, and device governance are already coordinated, because the access layer can only enforce the policy you have actually modelled.
Q: Why do traditional VPN and perimeter models fail for modern access control?
A: They assume that once a user is inside the network, trust can be broad and durable. That assumption no longer fits hybrid work, third-party access, or changing device risk. ZTNA reduces that gap by making access conditional on identity and context, but it still depends on strong governance behind the policy.
Q: When should organisations prioritise ZTNA over broader network access models?
A: Prioritise it when remote work, third-party connectivity, or cloud application use makes broad network access too risky to sustain. The key trigger is not technology preference but governance strain: if a login grants far more reach than the task requires, the access model is already too permissive.
Q: What is the difference between ZTNA and zero standing privilege?
A: ZTNA controls how access is granted and routed during a session, while zero standing privilege removes persistent access that would otherwise exist before the session starts. They are complementary, not interchangeable. ZTNA can narrow exposure, but ZSP removes standing entitlement that ZTNA alone cannot eliminate.
Technical breakdown
Continuous verification in zero trust access
Continuous verification means access is not treated as a one-time event. The system keeps checking identity, device health, and context as the session proceeds, which reduces the chance that an authenticated user retains access after risk changes. In practice, this is a ZTNA pattern rather than a pure authentication pattern. It works best when policy decisions can be re-evaluated against current posture, not just initial login state. That distinction matters for IAM teams because session trust must be dynamic if access is to remain proportional to risk.
Practical implication: design policy engines that can re-check session context instead of relying on login-time approval.
Least privilege and micro-segmentation for application access
Least privilege in ZTNA means the user or device receives access only to the application or resource required for the task, not the surrounding network. Micro-segmentation supports that by narrowing lateral movement paths and reducing the blast radius of a compromised account or endpoint. This is where ZTNA differs from broad remote access models. Rather than handing out network reach and hoping application controls compensate later, the access decision is attached to a specific resource and a specific policy. That makes authorization cleaner and easier to audit.
Practical implication: map remote access paths to specific applications and remove broad network-level entitlements.
Identity, device trust, and third-party access
The article's strongest operational point is that access control must account for more than the user. Identity centric ZTNA ties user identity to device health and contextual risk, which is especially relevant for third parties, cloud work, and distributed teams. That said, device trust is not a substitute for identity governance. If contractor accounts, service access, or privileged paths are not lifecycle-managed, ZTNA can still become a thin layer over bad entitlement hygiene. The architecture is stronger when human access, NHI access, and device trust are governed as related but distinct control sets.
Practical implication: treat device posture as one control input and keep identity lifecycle governance separate from network access decisions.
Threat narrative
Attacker objective: The objective is to turn a single login or remote connection into access across more systems, data, or applications than the user should have.
- entry: An attacker or unauthorized user gains initial access through weak password-based authentication or an overbroad remote access path.
- escalation: Broad network access and static trust assumptions allow the session to reach more applications or internal resources than necessary.
- impact: The result is unauthorized access, data exposure, or a wider compromise path than an identity centric ZTNA model would permit.
Breaches seen in the wild
- Azure Key Vault privilege escalation exposure — Azure Key Vault Contributor role misconfiguration enabled privilege escalation.
- Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Identity centric ZTNA is an access-control model, not a complete identity programme. It can reduce trust in the network path, but it does not automatically solve entitlement sprawl, contractor offboarding, or privileged access governance. The practical lesson is that ZTNA strengthens enforcement only when IAM, PAM, and lifecycle controls are already coherent.
Zero standing privilege is the more demanding control objective behind the ZTNA story. Continuous verification narrows the window of trust, but standing access still creates residual risk if permissions persist beyond the task that justified them. Practitioners should read ZTNA as an enforcement layer, not a substitute for removing persistent access.
Identity and device context must be governed separately to avoid false confidence. A compliant device does not make a broad entitlement safe, and a known user does not make an unmanaged endpoint trustworthy. The field-level implication is that access policy, device posture, and identity lifecycle need distinct owners and audit trails.
The real shift is from perimeter trust to session-scoped accountability. Traditional remote access assumes that a successful login authorises a broader trust relationship. ZTNA narrows that relationship to specific resources and contexts, which is the right direction for hybrid work, but it raises the bar for policy design and telemetry quality.
Identity centric ZTNA reflects a broader convergence across human, machine, and privileged access governance. The same access logic is increasingly being applied across employees, contractors, workloads, and service paths. That convergence is useful, but only if organisations stop treating access control as a network issue and start treating it as an identity governance problem.
From our research:
- Only 5.7% of organisations have full visibility into their service accounts, according to Ultimate Guide to NHIs.
- 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time, according to Ultimate Guide to NHIs.
- For the broader lifecycle picture, see NHI Lifecycle Management Guide, which shows how visibility, offboarding, and rotation need to work together.
What this signals
Identity centric access will keep expanding beyond humans. Once organisations accept that access decisions must be tied to identity, posture, and context, the same logic starts to shape workload, contractor, and privileged access programmes. That makes lifecycle governance the real control plane, not the network edge.
Session-scoped trust is becoming the practical floor for modern access governance. The old model of broad post-login trust is increasingly hard to justify when remote work and cloud access are normal. Teams should expect more pressure to prove that every access path can be narrowed, recertified, and revoked without breaking operations.
The governance gap is not just about stronger authentication. It is about whether identity programmes can keep pace with changing context across users, devices, and services while preserving auditability and offboarding discipline.
For practitioners
- Separate user identity from device trust decisions Define which signals are required for session approval, then validate whether device posture can be re-checked during the session rather than only at sign-in.
- Limit remote access to specific applications Replace broad network-level access with app-scoped entitlements so that a successful login does not expose adjacent internal resources.
- Review third-party and contractor access lifecycles Make sure external users are offboarded promptly, recertified on schedule, and removed from stale access paths that ZTNA would otherwise continue to permit.
- Align ZTNA policy with PAM and IAM controls Treat ZTNA as the enforcement layer for access decisions, while PAM handles privileged elevation and IAM handles identity lifecycle and recertification.
Key takeaways
- Identity centric ZTNA narrows trust at the session level, but it does not replace lifecycle governance or privileged access controls.
- The operational risk is broad access after login, especially when hybrid work, third parties, and device context all change faster than static policies.
- Practitioners should treat ZTNA as an enforcement layer and align it with IAM, PAM, and device governance before scaling it across the enterprise.
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 Zero Trust (SP 800-207) and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST Zero Trust (SP 800-207) | The article centres on zero trust access and continuous verification. | |
| NIST CSF 2.0 | PR.AC-1 | Access control and identity verification are the article's core governance themes. |
| OWASP Non-Human Identity Top 10 | NHI-03 | Third-party and service access sprawl makes NHI lifecycle control relevant. |
Use ZTA principles to limit trust, re-evaluate context, and scope access to specific resources.
Key terms
- Identity Centric ZTNA: An access model that uses identity, device posture, and context to decide whether a session should reach a specific resource. It replaces broad network trust with narrower, policy-driven access decisions and is commonly used to support hybrid work and distributed applications.
- Continuous Verification: A control pattern where access is reassessed during the session, not only at login. The goal is to catch changes in identity risk or device state quickly enough to reduce the chance that a previously approved session continues unchecked.
- Zero Standing Privilege: A governance approach in which access is not left active by default. Privileges are granted when needed and removed when the task is complete, which reduces the exposure created by persistent accounts, dormant entitlements, and broad standing access.
- Session-Scoped Accountability: The idea that access should be traceable and bounded to the actual session, resource, and context rather than to a general network location. It supports more precise auditing and makes it easier to see whether a user or service had more access than necessary.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.
This post draws on content published by Whiteswan Security: Identity centric ZTNA and the evolution of endpoint security. Read the original.
Published by the NHIMG editorial team on 2023-11-28.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org