ZTNA vs VPN for remote staff and contractors

Remote access usually gets framed as a product swap: retire the VPN gateway, buy a ZTNA (zero-trust network access) subscription. The swap is the easy part. Whether you end up with less implicit trust depends on the policy you bring to it.

ZTNA is a product category, not a standard

NIST SP 800-207, the reference definition of zero trust architecture, never uses the term ZTNA. It frames zero trust as minimizing uncertainty in “least privilege per-request access decisions” on “a network viewed as compromised”, and describes deployment models — a device agent with a gateway, a gateway in front of an enclave, a resource portal — that map directly onto what ZTNA products sell. NIST’s later implementation guide, SP 1800-35, files ZTNA as one component of SASE, next to the secure web gateway and the CASB. Read vendor claims with that in mind: the product is an enforcement point. Zero trust is the policy it enforces.

The CISA Zero Trust Maturity Model (version 2.0) scores the same shift. Applications reachable only over private networks or a VPN sit at its Traditional stage; each stage above it puts more applications in direct reach of authorized users.

What ZTNA actually changes

• Per-application access instead of network reach. Under SP 800-207’s third tenet, authentication and authorization to one resource “will not automatically grant access to a different resource.” A VPN does the opposite by design: it makes you a host on the network.
• Identity and device, evaluated per decision. The inputs are the user, the device’s posture (managed, patched, encrypted) and the application’s sensitivity, not the source subnet. Rich posture needs software on the device; NIST notes that an agentless portal only sees a device while it is connected.
• No inbound listener, for connector designs. A connector inside your network dials out to the broker, and vendors document it as outbound-only, with no inbound firewall rules. That matters because internet-facing VPN gateways are targets: in January 2024, CISA’s Emergency Directive 24-01 responded to widespread, active exploitation of an SSL VPN product line and later ordered federal civilian agencies to disconnect it. The exposed edge doesn’t vanish. It moves to the vendor’s service, which you now depend on.

What it doesn’t fix by itself

No access-policy model, no improvement. If your first rule is “all employees → all private apps”, you have rebuilt the VPN in a new console. Under-specify in the other direction and you get lockouts: NIST warns that incomplete knowledge of assets, users and processes “will most often lead to a business process failure.” SP 1800-35 adds that rules can end up scattered across identity, endpoint and network products, and says to track where each rule is configured. Both problems have one fix: write the model down as code before you configure any product.

# access-policy.yaml — reviewed in pull requests, applied by CI
- app: payroll
  sensitivity: high
  allow: { groups: [finance], device: managed-compliant }
  enforced_at: ztna-connector
- app: crm-saas
  sensitivity: medium
  allow: { groups: [sales, sales-contractors], device: registered }
  enforced_at: idp-sign-in-policy
- app: legacy-erp
  sensitivity: high
  allow: { groups: [ops], device: managed-compliant }
  enforced_at: enclave-gateway

Legacy and non-HTTP applications. Agentless, browser-based access is built for web apps; thick clients, file shares and database protocols generally need the agent. Check server-initiated traffic — VoIP callbacks, software pushed to laptops, directory updates — product by product: some outbound-only connectors don’t carry it at all. NIST’s enclave model, one gateway in front of a legacy segment, works, but it protects the segment as a whole and may let users see resources they can’t open.

SaaS. A private-access connector never sees SaaS traffic, and NIST says a remote user should not have to tunnel back through the enterprise network to reach cloud-hosted services such as email. For SaaS, the enforcement point is your identity provider’s sign-in policy, which in mainstream providers can require a compliant or managed device. SASE suites add a web gateway or CASB for that traffic: another policy, which the model has to cover too.

Break-glass. After cutover, the broker and your identity provider are the front door. NIST notes that an operational error could stop an entire enterprise from functioning if the policy engine or policy administrator becomes unreachable. Build an emergency path that doesn’t depend on the components it exists to bypass, keep its credentials offline, alert on every use, and test it on a schedule.

When a VPN is still reasonable

• Site-to-site links. Joining networks is a different problem from user access, and IPsec still solves it.
• Traffic your ZTNA product can’t carry yet, such as bidirectional or long-lived connections.
• The migration residue. NIST says zero trust and perimeter workflows may coexist for “an indefinite period”, and CISA calls the path an incremental process that “may take years to implement.”

The test is whether the VPN is scoped and shrinking — named people, named subnets — or still the default way in.

A migration that doesn’t lock people out

1. Inventory first: applications, the people who use them (contractors included) and their devices. NIST treats this survey as the prerequisite for any deployment.
2. Write the policy model as code, reviewed like any other change.
3. Observe before enforcing. SP 1800-35 suggests starting from a full-device tunnel, observing traffic, then enabling only what each user profile needs. SP 800-207 describes a reporting-only phase in which basics, such as denying failed MFA, are still enforced.
4. Cut over by cohort, lowest risk first, with the VPN still available as rollback for that cohort.
5. Remove VPN routes as each application moves, so the VPN shrinks instead of running in parallel forever.
6. Test break-glass before the first cohort, not after the first outage.

A Secure Access Build is that sequence, delivered: the access-policy model as policy-as-code in your repo, the enforcement points in Terraform, and a phased, reversible cutover with break-glass tested first. Whichever ZTNA product you choose, the policy stays yours.