Identity centric ZTNA is reshaping access control for hybrid work

At a glance

What this is: Identity centric ZTNA is an access model that uses identity, device health, and context to decide access continuously rather than relying on static perimeter trust.

Why it matters: It matters because IAM teams need controls that can govern hybrid work, third-party access, and device posture without assuming a session stays trusted after login.

Context

Identity centric ZTNA is a way of granting application access by checking who the user is, what device they are on, and whether the request still matches policy. It replaces the old assumption that a successful login can be trusted for the rest of the session.

For IAM and security teams, the governance problem is not only remote access. It is the mismatch between static access models and a hybrid environment where users, contractors, cloud workloads, and endpoints change context continuously. When access must be re-evaluated in real time, password-centric and network-centric controls become too coarse to carry the policy load.

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 VPNs create governance problems in hybrid infrastructure?

A: VPNs were designed to extend network trust, not to enforce modern privilege boundaries. In hybrid environments, that creates an access model where contractors, admins, and automation can all inherit too much reach after one connection event. The result is poor least privilege, weak accountability, and limited evidence when something goes wrong.

Q: What breaks when access decisions rely only on passwords and login time?

A: The control fails when a session stays trusted long after the user, device, or context has changed. Passwords can prove an initial identity event, but they do not prove that the access is still appropriate for the current risk or device state.

Q: What is the difference between ZTNA and a traditional VPN for IAM governance?

A: ZTNA is identity and context driven, so it narrows access to specific applications and can change permissions during the session. A traditional VPN focuses on network connectivity first and usually trusts the user more broadly after authentication, which makes it harder to enforce least privilege.

Technical breakdown

Continuous verification replaces trust at session start

Identity centric ZTNA treats access as a sequence of checks rather than a one-time authentication event. Identity, device posture, and contextual signals are re-evaluated so that access can change when risk changes. In practice, this is closer to an ongoing authorization decision than a traditional VPN session. That matters because a valid login no longer implies enduring trust, which reduces the value of stolen credentials and limits the usefulness of lateral movement through a trusted network path.

Practical implication: enforce re-checks on identity, device health, and context at the point of access, not only at sign-in.

Least privilege becomes application-specific access control

ZTNA narrows access to the specific applications or resources a user needs rather than opening broad network reach. That is the operational difference between network access and application access. For hybrid work, this reduces blast radius because a contractor, employee, or vendor only receives the minimum reachable scope needed for the task. It also aligns better with modern IAM governance because entitlements can be reasoned about per app, per user, and per context instead of as an all-or-nothing network route.

Practical implication: map access policies to applications and roles, then remove network-wide access paths wherever possible.

Device trust and third-party access need the same policy lens

The article places device health, cloud access, and third-party vendor access under the same identity centric model. That is important because the risk is not just user identity, but the trustworthiness of the endpoint and the context in which access is requested. In hybrid environments, a contractor on an unmanaged device or a partner connecting from an unexpected context can create the same governance challenge as an employee on a compromised laptop. ZTNA makes those cases policy decisions rather than implicit exceptions.

Practical implication: extend access policy to device posture and third-party context instead of treating them as separate exception processes.

NHI Mgmt Group analysis

Identity centric ZTNA is really a governance model for trust decay. The core shift is not simply better remote access, but the move from static trust to continuously reassessed trust across identity, device, and context. That matters because hybrid work breaks the assumption that access conditions remain stable after authentication. Practitioners should treat ZTNA as a control model for shrinking the period in which access can be abused.

The hybrid workspace has made broad network access too expensive to govern. Once contractors, employees, and partners all connect from different devices and locations, perimeter-era controls become difficult to reason about. Granular application access is more auditable than network reach, especially when compliance and incident response depend on knowing exactly what was reachable. The practitioner conclusion is that network adjacency is no longer a safe proxy for authorization.

Least privilege now has to include device trustworthiness, not just user role. The article correctly ties access decisions to device health, which is where many programmes still underweight risk. A user with the right role on the wrong endpoint is still a governance failure. The implication is that identity programmes cannot stop at authentication factors and role assignment; they must incorporate the endpoint into the entitlement decision.

Zero-standing access thinking is becoming more relevant even where the article does not name it. The more access is tied to momentary context, the less value persistent broad access has in hybrid environments. That does not remove the need for IAM governance, but it changes the boundary of control from account possession to access condition. Practitioners should re-evaluate where standing access still exists in remote, cloud, and vendor workflows.

Identity centric ZTNA is a bridge concept between human IAM and machine access governance. The article focuses on people, vendors, devices, and cloud resources, but the same control logic applies when non-human identities are in the path. If access must be validated continuously, then the programme design should not stop at human login journeys. The broader conclusion is that access governance is converging across human, device, and workload contexts.

What this signals

Hybrid access is becoming an authorization problem, not just a connectivity problem. Once workers and third parties connect from mixed environments, the programme has to decide whether the current identity, endpoint, and context still deserve access. That pushes security teams toward policy that can be enforced continuously rather than once at login.

Identity centric ZTNA also exposes where legacy IAM programmes are over-trusting the session. If a user keeps access simply because authentication succeeded earlier, the control is already behind the risk. The practical signal is clear: review where your remote access stack still assumes stable trust after the first decision.

Application-scoped access is the more governable boundary for hybrid work. It gives IAM, PAM, and security architects a smaller unit to certify, monitor, and revoke than broad network access. That shift becomes especially important when contractors, cloud systems, and endpoint posture all influence the same entitlement decision.

For practitioners

• Rebuild access policy around context-aware authorization Define rules that evaluate identity, device posture, location, and application sensitivity at the point of access rather than at login alone.
• Reduce network-wide access paths Replace broad VPN-style reach with application-specific access so each user or third party can only reach the resources required for the task.
• Extend device posture checks to vendors and contractors Apply the same device trust requirements to third parties that you apply to employees, including compliance status and health validation.
• Review standing access in hybrid workflows Identify places where users retain persistent access to cloud, remote, or partner systems after the initial business need has passed.

Key takeaways

• Identity centric ZTNA is about continuously governing trust across identity, device, and context rather than assuming a login remains valid.
• The main operational change is narrower, application-specific access that reduces the blast radius of remote and third-party connectivity.
• For practitioners, the priority is to rework access policies so that network reach, device posture, and standing access are all subject to the same governance logic.

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 Zero Trust practice that re-evaluates trust during the session instead of relying on a single successful login. The control is stronger when context signals are available in real time and when the identity programme can act on those signals without creating excessive exceptions.
• Adaptive Access: A risk-based access model that changes authentication requirements based on context such as device trust, location, behaviour, and session risk. It is most useful where users move between environments quickly, because the policy can stay strict without making every login equally heavy.
• Least-Privilege Access: Least-privilege access means granting only the permissions required for a specific task and removing them when the task ends. In infrastructure environments, that control depends on policy, lifecycle automation, and evidence, because broad entitlements and delayed revocation quickly turn least privilege into a statement rather than a condition.

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 building or maturing an IAM programme, it is worth exploring.