Conditional Access vs ZTNA: Where Sign-In Policy Ends and Network Access Begins

Conditional access and zero trust network access (ZTNA) both claim to enforce zero trust, but they check different things at different moments, and the gap between them is where attackers walk through. Conditional access is a policy decision made by the identity provider when it is asked for a token. ZTNA is a policy decision made by a broker when a device asks for a network path to an application. One controls what a sign-in can obtain; the other controls what a device can reach. This guide sets out exactly where each control ends, which applications and protocols fall between them, how session lifetimes and bypass paths differ, and how to layer the two so each covers the other's blind spots. It is for identity engineers and network and security architects. Microsoft Entra and Google are used as documented examples of both layers; platforms are listed alphabetically and the order is not a ranking.

Key takeaways

• Conditional access gates token issuance, ZTNA gates connections. Conditional access runs when an identity provider is asked for a token; ZTNA runs when a client asks a broker for a path to a specific host and port. Neither sees the other's event by default.
• Anything that never asks the identity provider escapes conditional access. Kerberos and NTLM to file shares, RDP with directory passwords, database logins and SSH keys never reach a cloud sign-in page, so only a network control can put policy in front of them.
• A valid token or cookie defeats both if sessions are long. Conditional access is not re-checked until the token is refreshed unless continuous evaluation is in place, and a ZTNA session admitted once may outlive the device posture that justified it.
• ZTNA without an identity provider policy is a weak gate. The broker's own sign-in usually federates to the identity provider, so conditional access on the broker's enterprise application is what makes ZTNA phishing-resistant and device-aware.
• Layer them deliberately. Use conditional access as the single policy engine for authentication strength, device and risk; use ZTNA to make private applications reachable only through a broker; then require a compliant network or broker-sourced traffic for cloud applications so stolen tokens replayed elsewhere fail.

The short answer

You need both if you run any private applications, and you need conditional access first. For a pure SaaS estate where every application uses modern federated sign-in, conditional access plus device management covers most of what ZTNA would add. As soon as there are on-premises or VPC-hosted applications, legacy protocols, administrative ports or third parties who need narrow access, ZTNA becomes the control that removes the network path, and conditional access becomes the control that makes the ZTNA sign-in trustworthy.

See the Conditional Access Guide and the ZTNA Guide for each control on its own; this page covers the boundary.

What each one actually enforces

NIST SP 800-207 describes a policy engine that makes "the ultimate decision to grant access to a resource for a given subject" and a policy enforcement point "responsible for enabling, monitoring, and eventually terminating connections". Both controls implement that pattern, but the enforcement point sits in a different place.

Conditional access: the identity provider as enforcement point

• Trigger: a request for a token or assertion. Microsoft states that Entra policies "are enforced after first-factor authentication is completed", so they decide what a proven identity may obtain, not whether the password was right.
• Inputs: user, group or agent, IP location, device platform and state, target application, and calculated risk. Google Workspace context-aware access uses access levels built from IP range, device policy, geographic origin and custom attributes.
• Outcome: block, grant, or grant with conditions such as an authentication strength, a compliant device or an app protection policy. The output is a token the application trusts for its lifetime.
• What it never sees: traffic after the token is issued.

ZTNA: the broker as enforcement point

• Trigger: a client or browser asking the broker for a path to a named FQDN or IP and port. NIST's tenet that access "is granted on a per-session basis" is applied to connections, not tokens.
• Inputs: the user identity asserted by the identity provider, device posture from an agent or management system, the application segment requested, and time or location constraints.
• Outcome: a brokered connection through a connector, or nothing; unpublished hosts have no route.
• What it never sees: whether the application itself then accepts a weak local password, and anything that reaches the application without going through the broker.

Threat model for each layer

Conditional access

• Token replay: a session cookie or access token stolen by an adversary-in-the-middle proxy or infostealer is used from another device. The identity provider is not asked again, so the policy is not re-run. ATT&CK tracks this as T1539 Steal Web Session Cookie and T1550.004 Web Session Cookie. See the Infostealer Logs and Session Token Abuse Guide.
• Protocols outside the identity provider: an attacker with a valid directory password connects over SMB, RDP or LDAP to an on-premises host. No cloud sign-in occurs, so there is nothing for conditional access to evaluate.
• Exclusions and default allow: in Entra, tokens are issued when no policy condition triggers a control, so every exclusion and every application outside policy scope is a gap. See How to Find Accounts Excluded From MFA and Conditional Access.
• Non-human identities: Microsoft notes that "calls made by service principals aren't blocked by Conditional Access policies scoped to users", and Google states that context-aware access controls end-user accounts, not Google API access from service accounts.

ZTNA

• Direct path left open: Google's IAP documentation warns that users who can reach the application-serving port of a VM can bypass IAP, and tells customers to block traffic that does not come through the load balancer. The same applies to every broker: if the old VPN, a site-to-site tunnel or a public IP still reaches the application, the broker is optional.
• Compromised broker or connector: NIST SP 800-207 warns that "a compromised PA could allow access to resources that would otherwise not be approved".

Edge gateways that terminate remote access are a repeated target in their own right. In the CitrixBleed 2023 incident, session cookies leaked from the gateway were replayed to bypass passwords and MFA, and in the Ivanti Connect Secure exploitation attackers harvested credentials and service account secrets from the appliance. The lesson for any broker: revocable, context-bound sessions and a hardened broker. See Securing the ZTNA broker and remote access VPN itself.

Coverage of legacy and private applications

The clearest line between the two controls is the application's authentication protocol. Conditional access can only act where the application hands sign-in to the identity provider. Microsoft lists on-premises applications among the resources a policy can consider; in practice that means applications whose sign-in is handed to Entra by a publishing component.

Microsoft describes Universal Conditional Access as a way to protect "apps that don't support modern authentication" by applying conditional access to network traffic, and Entra Private Access lets policies target individual Quick Access or per-app enterprise applications. Note the documented boundary: "Universal Conditional Access applies to the Internet Access and Microsoft traffic tunnels. There isn't support to target the Private Access tunnel", so private resources are governed per application, not as one tunnel. On Google Cloud, context-aware access applies to IAP-protected web applications and to administrative SSH and RDP to VMs. In both, the identity provider decides and the broker carries that decision to protocols that cannot ask for themselves. Retiring legacy protocols is the long-term fix; see the Legacy Authentication and ROPC Retirement Guide.

Session controls and how long a decision lasts

Both controls make a decision and then trust it for a period. The length of that period is the real exposure window.

• Token lifetime: Microsoft states that without continuous access evaluation (CAE) access tokens are valid for one hour by default, and that in CAE-capable sessions token lifetime increases to up to 28 hours, with revocation driven by events instead.
• Event-driven revocation: CAE acts on account disablement, password reset, MFA enablement, administrator token revocation and high user risk, with latency of up to 15 minutes; IP location enforcement is instant. Only IP-based named locations are enforced in real time: country locations are not visible to CAE.
• Application sessions: Google states that SAML apps under context-aware access "are evaluated only at sign-in", with no recheck on location change until the session ends, while core Workspace services are evaluated continuously. Most federated applications behave like this: their own cookie outlives the identity provider's decision.
• Broker sessions: a ZTNA session is admitted at connection time. Whether posture is re-checked mid-session, and how quickly a disabled user loses an open RDP or SMB connection, depends on the product and must be tested, not assumed.
• Policy change latency: Microsoft notes that policy and group changes can take up to one day to reach CAE sessions; revoke sessions to apply them at once. See How to Revoke All Sessions for a Compromised User.

Bypass paths and how the layers close them

Microsoft's compliant network check is a worked example of the two layers closing a gap together. It is a named location, "All Compliant Network locations", satisfied only when the user's traffic arrives through the tenant's Global Secure Access service. If a stolen refresh token is used from a device outside that network, Entra ID denies the request. At the data plane, only CAE-integrated services such as Microsoft Graph reject replayed access tokens in near real time; elsewhere a stolen access token stays valid for its lifetime, which Microsoft gives as between 60 and 90 minutes by default. Google's equivalent pattern is context-aware access with IP or device access levels, combined with IAP and firewall rules that only admit traffic from the load balancer. In both, the network layer creates a signal the identity layer can require, and the identity layer makes the network layer's sign-in strong.

A combined architecture

1. One policy engine for identity decisions. Keep authentication strength, device compliance and risk rules in the identity provider's conditional access, and federate the ZTNA broker's sign-in to it. Avoid a second, weaker set of device and MFA rules inside the broker.
2. Treat the broker as a high-value application. Give its enterprise application a dedicated policy: phishing-resistant authentication strength, managed device, block high sign-in risk.
3. Publish applications, not networks. Build per-application segments with named groups; avoid broad Quick Access style ranges except as a temporary migration step.
4. Remove every other path. Firewall private applications so they accept connections only from connector addresses, retire the VPN pool for migrated applications and close public endpoints that were left for convenience.
5. Feed the network signal back to identity. Where the platform supports it, require a compliant network or broker-sourced egress for high-value cloud applications, so tokens are useless off the managed path.
6. Shorten and bind sessions. Use continuous evaluation where offered, sign-in frequency for sensitive apps, token protection or device-bound sessions, and test how quickly each layer drops a disabled user.
7. Handle machines separately. Neither user conditional access nor user ZTNA policies govern service principals or service accounts. Use workload identity policies and machine-to-machine segments. See Conditional Access for Workload Identities.

Worked scenario: a mid-sized firm with hybrid applications

A 3,000-person firm runs Microsoft 365 and a dozen SaaS tools with SAML, an internal HR portal using OIDC hosted in a cloud VPC, a finance application using Windows integrated authentication, SMB file servers and SQL databases on-premises. Remote staff use a full-tunnel VPN.

• Starting point: conditional access requires MFA for all users and blocks legacy authentication, but the finance application, file shares and SQL never ask the identity provider anything, so a phished VPN user reaches all of them.
• Step 1, identity: move administrators and then all users to a phishing-resistant authentication strength; require a compliant device for the VPN or broker application; add a sign-in frequency to the HR portal.
• Step 2, ZTNA: publish the finance application, file servers and SQL listener as separate segments for named groups; publish RDP to servers only for the server administrators group; leave the HR portal published by FQDN only.
• Step 3, remove paths: firewall the finance servers and SQL hosts to accept connections only from the connector subnet; shrink and then remove the VPN pool.
• Step 4, close token replay: require the compliant network or named egress for Microsoft 365 and the most sensitive SaaS apps; enable continuous evaluation where clients support it.
• Result: a phished cookie fails from the attacker's machine for cloud apps on the managed path, and a stolen password no longer reaches the file shares, because no connection exists without a compliant device and phishing-resistant sign-in.

A small SaaS-only organisation can stop at steps 1 and 4; a large one with many sites needs per-site connector groups and the broker treated as tier zero infrastructure.

Decision criteria

Trade-offs to plan for: conditional access is cheap to extend but leaves network reach unchanged; ZTNA removes reach but adds a broker, connectors and clients to run, patch and keep available. Tying cloud application access to a network signal also creates a dependency: Microsoft warns that blocking Internet Access tunnels for non-compliant devices can stop users reaching the endpoints they need to become compliant, and recommends a bypass for device management endpoints.

Detection and measurement

• Correlate the two logs: join identity provider sign-in logs and broker connection logs on user and device. A connection with no matching recent sign-in, or a token use from an IP that is not the broker's egress, is worth investigating.
• Watch for direct access and gaps: alert on connections to private ports from anything but connector addresses, and list applications and accounts outside conditional access scope.

Framework mapping

Common failure patterns

• Assuming conditional access protects on-premises apps. Teams see "all users, all resources, require MFA" and stop, while file shares and Kerberos apps stay reachable over the VPN with a password.
• ZTNA broker signing users in on its own. A broker with local accounts or plain MFA becomes the weakest door to every published application.
• Leaving the old path open. The VPN pool, a public IP or a cloud service's default URL still reaches the application, so the broker is optional for an attacker.
• Trusting a long session. A posture check at connection time or a sign-in check at token issuance is treated as continuous when it is not, so a device that falls out of compliance keeps access for hours.
• Applying user policies to machines. Service accounts excluded from conditional access and given network-wide broker access become the easiest path in. See the Zero Trust Identity Guide.

Practitioner checklist

• Inventory applications by authentication protocol and mark which ones never call the identity provider.
• Federate the ZTNA broker's sign-in to the identity provider and apply a dedicated conditional access policy with a phishing-resistant authentication strength and a device requirement.
• Publish private applications as individual segments for named groups; retire broad ranges after migration.
• Restrict every private application to accept connections only from connector addresses, and close leftover VPN and public paths.
• Require a compliant network or named egress for the most sensitive cloud applications, with exclusions for device management endpoints.
• Test and record time to revoke access for a disabled user in each layer.

Standards and references

• NIST: SP 800-207 Zero Trust Architecture
• NCSC: Zero trust architecture design principles
• Google Cloud: Identity-Aware Proxy overview
• Google Workspace: Protect your business with context-aware access
• Microsoft Learn: What is Conditional Access
• Microsoft Learn: Continuous access evaluation
• Microsoft Learn: Universal Conditional Access through Global Secure Access
• Microsoft Learn: Enable compliant network check with Conditional Access

Related NHI Mgmt Group resources: Conditional Access Guide · ZTNA Guide · ZTNA Buyer's Guide · Identity-Aware Proxy Guide · Device Trust and Posture Guide