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. In this guide I will share the patterns from our migration of a 4,200-employee organization off a legacy SSL VPN, including the device posture pipeline, the per-application authorization model, and the parallel-run strategy that prevented a single outage 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. We started with ZTNA and added 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.
We evaluated Google IAP, Cloudflare Access, Tailscale, and Pomerium. Cloudflare Access won for our externally-hosted SaaS and customer-facing internal tools because of its global anycast network. Additionally, Tailscale won for engineering infrastructure because its WireGuard-based mesh handled 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.
We integrated Jamf and Intune as posture providers, exporting compliance state to the IAP every five minutes. Subsequently, the policy engine could enforce rules like “finance applications require encrypted disks and OS patches less than 30 days old.” This caught roughly 200 non-compliant devices per week 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. We deployed 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 gave us per-workload identity that survives pod rescheduling and IP reuse. For deeper Kubernetes-specific patterns, our 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. We use 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. We 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 our 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. We implemented JIT via ConductorOne for SaaS applications and a custom Slack bot integrated with our 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, average standing privileges across the organization dropped by 87% in the first quarter, dramatically reducing blast radius for compromised accounts.
Migration Phases and Parallel Run
We migrated 280 applications off the SSL VPN over 14 months in five waves. Wave 1 covered low-risk SaaS-adjacent internal tools (wiki, ticketing, CI dashboards). Wave 2 added engineering infrastructure. Wave 3 covered HR and finance applications. Wave 4 tackled production database access. Finally, Wave 5 covered the long tail of legacy applications, some requiring application-layer changes to consume header-based identity.
Critically, the VPN remained available throughout the migration as a fallback. Each application was published behind the IAP first, validated for two weeks, then removed from VPN-accessible network ranges. This parallel-run approach prevented user-visible outages and allowed us to roll 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 14 months of migration and another 18 of operational refinement, we shut down the legacy VPN entirely. Zero outages during cutover, an 87% reduction in standing privileges, and a security posture that finally matches the threat environment of 2026.