Why Zero Trust Network Access Replaces the VPN
Zero trust network access rejects the assumption that anything inside the corporate network perimeter is trustworthy. Instead, every request to every application is authenticated, authorized, and inspected based on identity, device posture, and contextual signals, regardless of whether the request originates from a coffee shop or a corporate office. This model originated at Google with the BeyondCorp paper in 2014 and has since been productized by Cloudflare, Tailscale, Google IAP, and a dozen other vendors.
However, ZTNA is not a product purchase; it is an architecture migration. This guide shares the patterns common to migrating a multi-thousand-employee organization off a legacy SSL VPN, including the device posture pipeline, the per-application authorization model, and the parallel-run strategy that prevents outages during cutover.
ZTNA vs SASE vs VPN: Drawing the Lines
VPNs grant network-level access: once authenticated, the user has L3 reachability to whatever the network ACLs permit, which historically meant “everything.” ZTNA grants application-level access through an identity-aware proxy: each request is evaluated independently against policy, and the user never receives a network route to the underlying infrastructure. SASE bundles ZTNA, SWG, CASB, and FWaaS into a single cloud-delivered platform.
For most enterprises, ZTNA is the foundational shift; SASE is an operational consolidation strategy on top. Furthermore, ZTNA can be deployed incrementally per application, while SASE typically requires a larger commitment to a single vendor’s stack. A common sequence is to start with ZTNA and add SASE components opportunistically over the following 18 months.
Identity-Aware Proxy: The Core Primitive
The identity-aware proxy (IAP) sits in front of every application and enforces policy on each request. Concretely, the IAP terminates TLS, authenticates the user via OAuth/OIDC, evaluates device posture and contextual signals, and then forwards approved requests to the backend with signed headers identifying the user. The backend trusts the headers because the IAP is the only ingress path.
Common options worth evaluating include Google IAP, Cloudflare Access, Tailscale, and Pomerium. Cloudflare Access is a strong fit for externally-hosted SaaS and customer-facing internal tools because of its global anycast network. Additionally, Tailscale fits engineering infrastructure well because its WireGuard-based mesh handles lab environments and ephemeral workloads more gracefully than HTTP-only proxies.
# Pomerium policy for a per-application access decision
apiVersion: pomerium.io/v1
kind: Policy
metadata:
name: finance-reports
spec:
routes:
- from: https://reports.example.com
to: http://reports-internal.svc.cluster.local:8080
policy:
- allow:
and:
- email:
is: '@example.com'
- groups:
has: 'finance-analysts'
- device:
posture:
compliant: true
osPatchLevel:
gte: '2026-04-01'
diskEncryption:
is: true
- claim/aud:
is: 'pomerium-finance'
- deny:
and:
- geo:
country:
not_in: ['US', 'CA', 'IN', 'GB', 'DE']
pass_identity_headers: true
set_request_headers:
X-Forwarded-User: '{user.email}'
X-Forwarded-Groups: '{user.groups}'
Device Posture: The Signal That Changes Everything
Identity alone is insufficient because credentials get phished. Device posture closes that gap by requiring requests to originate from a managed, compliant endpoint. Posture signals include disk encryption status, OS patch level, EDR agent presence, MDM enrollment, and certificate-bound device identity. The IAP evaluates posture on every request and denies access from non-compliant devices.
A typical integration uses Jamf and Intune as posture providers, exporting compliance state to the IAP every five minutes. Subsequently, the policy engine can enforce rules like “finance applications require encrypted disks and OS patches less than 30 days old.” This routinely catches non-compliant devices that VPN-based access had been silently allowing for years.
Micro-Segmentation Between Services
ZTNA at the user-facing edge is only half the story. East-west traffic between services must also follow zero-trust principles, which is where service-to-service authentication via mTLS and SPIFFE/SPIRE comes in. A common approach deploys Istio with strict mTLS mode across all production namespaces, with workload identities issued by SPIRE and authorization policies enforced via AuthorizationPolicy resources.
Compared to flat network access controlled only by IP-based ACLs, this gives per-workload identity that survives pod rescheduling and IP reuse. For deeper Kubernetes-specific patterns, this Kubernetes network policies zero trust guide covers the L3/L4 layer that complements service mesh L7 policies.
OAuth/OIDC Integration and MFA Enforcement
The IAP integrates with your IdP via OIDC. Every request without a valid session redirects to the IdP, which authenticates the user (typically with SSO + MFA) and returns an ID token. The IAP validates the token, establishes a session cookie, and enforces session lifetime policies. A common configuration uses 8-hour sessions for most applications and 1-hour sessions for high-risk applications like cloud consoles and database admin tools.
Additionally, MFA enforcement happens at the IdP, not the IAP. Best practice is to require phishing-resistant MFA (FIDO2/passkeys) for all employees, with TOTP as a fallback only for legacy edge cases. Refer to the Google BeyondCorp documentation for the canonical reference architecture and this passkeys and WebAuthn guide for the IdP-side MFA implementation.
#!/bin/bash
# Tailscale ACL for ZTNA-style internal application access
cat > /etc/tailscale/acl.json <<'EOF'
{
"groups": {
"group:platform": ["alice@example.com", "bob@example.com"],
"group:finance": ["carol@example.com", "dave@example.com"],
"group:contractors": ["ext-eve@example.com"]
},
"tagOwners": {
"tag:prod-db": ["group:platform"],
"tag:finance-app": ["group:platform"],
"tag:dev-server": ["group:platform", "group:contractors"]
},
"acls": [
{ "action": "accept", "src": ["group:platform"], "dst": ["tag:prod-db:5432"] },
{ "action": "accept", "src": ["group:finance"], "dst": ["tag:finance-app:443"] },
{ "action": "accept", "src": ["group:contractors"], "dst": ["tag:dev-server:22,443"] }
],
"ssh": [
{
"action": "check",
"src": ["group:platform"],
"dst": ["tag:prod-db", "tag:finance-app"],
"users": ["root", "admin"],
"checkPeriod": "12h"
}
],
"postureChecks": {
"defaultSourcePosture": ["posture:compliant"]
}
}
EOF
tailscale set --advertise-tags=tag:finance-app
Just-in-Time Access Patterns
Standing access to production databases and admin consoles is a primary breach vector. Just-in-time (JIT) access flips the model: users have no standing access, request elevation through a workflow, and receive time-bound permissions tied to a specific change ticket. JIT is commonly implemented via ConductorOne for SaaS applications and a custom Slack bot integrated with the IdP for infrastructure access.
The audit trail this generates is invaluable for incident response and compliance. Every privileged operation maps to a request, an approval, and a ticket. Furthermore, organizations that adopt JIT often see average standing privileges drop dramatically within the first quarter, dramatically reducing blast radius for compromised accounts.
Migration Phases and Parallel Run
A migration of hundreds of applications off an SSL VPN typically proceeds over many months in waves. Wave 1 covers low-risk SaaS-adjacent internal tools (wiki, ticketing, CI dashboards). Wave 2 adds engineering infrastructure. Wave 3 covers HR and finance applications. Wave 4 tackles production database access. Finally, Wave 5 covers the long tail of legacy applications, some requiring application-layer changes to consume header-based identity.
Critically, the VPN should remain available throughout the migration as a fallback. Each application is published behind the IAP first, validated for two weeks, then removed from VPN-accessible network ranges. This parallel-run approach prevents user-visible outages and allows rolling back individual applications without affecting others.
In conclusion, zero trust network access is the most consequential security architecture shift since the introduction of TLS. It eliminates an entire class of lateral movement attacks, dramatically tightens the audit trail, and pairs naturally with modern identity providers and MDM tooling. After many months of migration and continued operational refinement, organizations can shut down the legacy VPN entirely. Done well, cutover is achievable with zero outages, a large reduction in standing privileges, and a security posture that finally matches the threat environment of 2026.