Conditional access still anchors ZTNA policy
Zero Trust Network Access can look clean on a diagram and still behave like an old perimeter design in practice. The usual failure mode is simple: identity providers make the real decision, while the rest of the stack just passes traffic through. If access still follows network location as the main trust signal, the model has drifted back towards the thing it was meant to replace.
Why conditional access keeps doing the heavy lifting
Conditional access sits in the middle because it already knows about authentication state, device context, and policy decisions tied to identity. ZTNA products often hang off that decision point rather than replacing it. That is fine if the policy is tight, and messy if the identity layer is carrying all the weight while the network layer keeps its old habits.
Where this goes wrong is when access looks private but behaves broadly. A user signs in, passes a check, and then gets more reach than the application actually needs. The policy may look modern. The trust model does not.
Where identity providers still make the decision
Identity providers usually end up deciding whether a session starts at all, whether it can continue, and whether the device or user state still qualifies. That makes them part of the access path, not just an upstream login service. If they fail, the policy fails with them.
That dependence matters because ZTNA is often sold as if it removes the central role of authentication. It does not. It moves the decision closer to the application, but the identity layer still controls the gate. If the identity provider is down, degraded, misconfigured, or bypassed, the access policy has nothing solid underneath it.
The point at which network segmentation stops being the control
Network segmentation helps, but it is not the policy. Once segmentation becomes the reason access is allowed, the design has drifted back towards subnet trust. That is the old problem in a new coat.
ZTNA should stop at the application boundary, not at a broad internal network boundary. If a user can move from one private service to another just because both sit behind the same segment, the control is too wide. The segment is a containment measure, not a decision-maker.
What a ZTNA policy looks like when it is actually tied to the app
A ZTNA policy tied to the app has a narrow target and a narrow outcome. It opens access to one private application, not to a general network slice. It cares about who is asking, from where, under what authentication state, and with which device posture, then it stops.
That sounds boring because it is. Boring is good here. The policy either maps to the application request or it maps to a chunk of network. Only one of those matches the zero trust idea.
Private application access, not broad subnet reach
Private application access should feel like a direct path to one service, not a wandering route into an internal address range. Broad subnet reach creates room for lateral movement, accidental discovery, and policy creep. Once that happens, the ZTNA label starts to mean very little.
A tighter design keeps the scope obvious. One app, one policy set, one controlled path. If a second service needs access, it gets its own rule. That is the part many deployments skip because it takes longer than opening a whole range and calling it done.
Authentication signals that should survive the jump from VPN to ZTNA
Authentication details should remain part of the decision after the move away from VPN. Session freshness, user identity, device state, and conditional access results still matter. If those signals disappear once the tunnel changes, the policy has lost the only part that made it trustworthy.
Old VPN habits creep back in when access is tied to a successful connection rather than a continuing set of checks. A connection can be up while the trust conditions have changed. The policy should notice. If it does not, the jump from VPN to ZTNA has changed the packaging, not the behaviour.
The controls that stop old trust assumptions creeping back in
The main control is blunt: stop treating network location as a trust signal. A private address, an internal segment, or a corporate path does not prove identity or intent. It only proves the traffic arrived from somewhere that looks familiar.
Use access policies that bind the session to the application, not the subnet. Keep authentication and conditional access checks in the path. Recheck device state where that is part of the design. Limit lateral reach so one granted session does not become a general-purpose badge for the rest of the environment.
A good rule is that a policy failure should deny one app, not expose a wider slice of the network. If a control failure opens more than the intended service, the boundary is too loose. That is exactly how legacy trust creeps back in.
Test the policy against the failure modes that matter
ZTNA tests that only check whether the client connects miss most of the useful failure cases. A session opening is not the same thing as the right application being protected in the right way. The ugly cases are the ones that show whether identity, access policies, and segmentation are still doing separate jobs.
Break the auth path, not just the client
A sensible test is to break the authentication path and see what survives. If the identity provider is unavailable, the access decision should fail closed. If a token expires, the session should not keep drifting along as if nothing happened. If conditional access no longer applies, the connection should stop carrying trust.
Client tests alone are too neat. They tell you the software starts. They do not tell you whether the policy still depends on a live identity decision.
Check that access policies still hold when location changes
Location changes expose lazy designs fast. A user on one network should not gain a different class of access just because the source address changed. If access policies shift from one location to another without a real reason, network trust is still running the show.
That kind of test catches the awkward middle ground where ZTNA exists, but the old perimeter rules still decide too much. The access path should stay tied to identity and application scope, not to where the connection happened to begin.
