Zero trust access network

The old model: 'Connect to the network, get the keys to the castle.' If an attacker gets in, they get everything. This is why ransomware spreads.

The new model (Zero Trust): 'Earn access to one door at a time.' You don't connect to a network. You just access an app. It's safer because a compromised device can't attack other systems. It's faster because you don't backhaul traffic through a slow VPN.

The old security model assumed a clear perimeter. Remote work + cloud erased it. VPNs grant network-level access after a single login, increasing lateral movement risk and expanding attack surface.

Zero Trust makes access app-scoped and decisioned per request using explicit context + policy. This reduces blast radius while improving control and user experience.

Perimeter-based security assumed stable network boundaries. Modern enterprises have remote endpoints, SaaS sprawl, multi-cloud infrastructure, and third-party contractor access.

VPNs solve reachability by extending layer-3 connectivity. This creates implicit trust domains with broad routing access and lateral movement paths (RFC1918 space, split tunneling, or full tunneling with routing policies).

Zero Trust reframes access as a request-time authorization problem: bind identity assertions (OIDC/SAML claims), device signals (posture, certificates, MDM state), and request metadata (IP, time, method) to explicit policy evaluation per destination.

Design goals: eliminate implicit trust, minimize reachable attack surface, make authorization decisions auditable and reversible, and decouple authentication from network connectivity.

Instead of connecting to a network, you request access to specific applications. Each request is evaluated independently. When you access an app, Cloudflare validates your identity (who you are), checks your device posture (is it compliant), and evaluates policy rules (are you allowed). Only if all checks pass do you get access to that specific resource. The next request goes through the same process. The key difference: you never get blanket network access. Every request earns authorization individually.

Cloudflare Zero Trust is a contract: every request is evaluated and only the requested resource is authorized. Users don't gain broad network access; applications don't need to be directly exposed to the Internet.

A typical decision shape: User → Identity → Device context → Policy → Transport → Application. Keep this mental model fixed; everything else is implementation detail.

Cloudflare ZT is an authorization and connectivity fabric: evaluate requests with identity + device context, then proxy authorized traffic to specific resources without granting network membership. Core invariants: explicit policy evaluation per request, default-deny posture, app-scoped authorization (not subnet-scoped reachability).

Request flow: client initiates connection → identity assertion validated (JWT, session cookie) → device posture evaluated (WARP client signals, certificate auth) → policy rules matched → authorized requests routed through Cloudflare edge → backend receives proxied connection. For private apps: origins connect outbound via cloudflared tunnels, eliminating inbound firewall rules and public IP exposure. For SaaS/web: inline proxy with same identity + policy enforcement.

Zero Trust decisions are built from four components: Identity, Device, Policy, and Transport. Identity: who you are (verified through your IdP like Okta or Azure AD). Device: what you're using and its security state. Policy: the rules that determine access. Transport: the secure path to the application.

Each component can independently block access. A valid user on a non-compliant device gets blocked. A compliant device with invalid credentials gets blocked. Understanding these four primitives helps you debug access issues and design policies effectively.

Cloudflare Zero Trust is the composition of four primitives: Identity, Device, Policy, and Transport. Identity provides WHO (from your IdP). Device provides WHAT (posture signals). Policy provides the allow/deny logic. Transport provides the controlled path to the destination.

They're separable: you can adopt them incrementally, and you can debug them independently. Most failures map cleanly to one primitive: identity assertion, device signal, policy match, or transport reachability.

Model the system as four independent concerns with distinct sources of truth and failure modes.

Identity: externalized to IdPs via OIDC/SAML. Cloudflare validates tokens and extracts claims (groups, email, custom attributes). MFA context available via IdP assertion. Cloudflare never stores passwords — it consumes identity, doesn't originate it.

Device: posture signals from WARP client (OS version, disk encryption, firewall state) + MDM/EDR integrations (Intune, Jamf, CrowdStrike, SentinelOne). Also certificate-based device identity. Signals evaluated continuously, not just at initial auth.

Policy: ordered rule engine with first-match semantics. Rules combine identity claims (email, groups), device signals (posture checks), request context (IP, method, path), and destination. Default-deny means missing rules block access.

Transport: WARP client routes traffic via Cloudflare edge. Private apps connect via cloudflared tunnels (outbound-only connections using HTTP/2 or QUIC). DNS resolution controlled by Gateway. No direct client-to-origin connectivity for private resources.

Every access request is evaluated against an ordered list of policy rules. The first matching rule determines the outcome. If a rule matches and allows access, the request proceeds. If it matches and blocks, access is denied. If no rules match at all, access is denied by default.

This default-deny behavior is intentional. It prevents accidental access from misconfigured or missing rules. When debugging access issues: verify identity claims are correct, check device posture passes requirements, confirm a policy rule matches the request, and ensure transport connectivity works.

Authorization is deterministic: policies evaluate in order, first match wins. If no rule matches, deny is the default (fail-closed). This makes outcomes predictable and debuggable — rule order and scope matter.

Debug flow: confirm identity assertion → confirm device posture → confirm policy match → confirm transport reachability.

The policy engine behaves like a routing table for authorization: ordered rules with scoped predicates and deterministic first-match resolution.

Evaluation: extract identity claims from JWT/session, fetch device posture signals, evaluate request context (source IP, destination, method, path) against rule predicates in order. First satisfied rule returns Allow or Block. No match = implicit Deny.

Fail-closed prevents accidental exposure from misconfigurations, missing predicates, or IdP/posture provider failures. If upstream signals are unavailable, requests fail.

Best practices: avoid overlapping predicates to keep rule order predictable. Use explicit Deny rules when you want to document blocked patterns. Version and test policy changes with canary users/devices before rollout.

Troubleshooting path: (1) verify identity claims in JWT (groups, email match expected values), (2) check device posture evaluation logs (which checks failed), (3) validate rule predicate match and order (use policy preview/dry-run), (4) confirm transport health (tunnel status, DNS resolution, edge routing).

VPNs grant network-level access. Once authenticated, you can reach any system on that network (unless additional segmentation is configured). If your VPN-connected device gets compromised, an attacker can access everything reachable on that network. The VPN doesn't re-check authorization for each internal connection.

Zero Trust grants app-scoped access. Every connection requires authorization. A compromised device only gets access to resources that device and user are explicitly authorized for. This reduces blast radius significantly. An attacker would need to compromise credentials AND device posture AND pass policy checks for each target application.

VPNs grant network-level access after a single authentication, increasing lateral movement risk. ZTNA grants app-scoped access, enforcing policy per request and per destination.

With outbound-only connectivity (tunnels), private apps can avoid inbound exposure and direct Internet reachability. This is an architectural shift: membership vs authorization.

VPNs extend layer-3 connectivity to remote endpoints. Clients get routing access to RFC1918 space (full tunnel) or split-tunnel to specific subnets. Segmentation relies on firewall rules, VLANs, or ACLs downstream.

Attack surface expansion: compromised endpoint can scan reachable IP ranges, exploit lateral movement paths, and pivot to other systems without re-authentication. VPN concentrator sees one authenticated session, not per-app authorization.

ZTNA inverts this: authorize at request-time per destination. Client never gets layer-3 routing to private networks. Access is proxied through Cloudflare edge after policy evaluation. Each connection is a distinct authorization event.

For private apps using cloudflared: origin connects outbound to Cloudflare edge via long-lived HTTP/2 or QUIC tunnel. No inbound ports listening on public IPs. Firewall rules can block all inbound. Attackers can't directly reach origin even with valid credentials unless authorized request flows through edge.

Key difference: VPNs solve connectivity first, authorization second. ZTNA solves authorization first, provides connectivity only for authorized flows. This decouples network reachability from security posture.

You don't have to replace everything at once. Start with one internal tool (like a wiki or admin panel). Put it behind Cloudflare Zero Trust. It takes 15 minutes. Then add one team. Then another. It's a gradual upgrade, not a scary switch.

This is a 'parallel adoption'. Your old VPN stays running while you move apps over one by one. Users won't even notice the difference, except that things get faster.

Parallel adoption strategy: Keep your VPN running. Pick one non-critical internal app. Configure cloudflared tunnel to point to localhost:8080 (or your internal IP). Set policy to 'Email ends with @company.com'. Test. No firewall changes needed initially.

Route by route migration: Use Split Tunnels to exclude ZT protected IPs from VPN, or just allow them to route through ZTNA. You control the pace.

Side-by-side deployment: Route specific DNS domains to Cloudflare Tunnel (CNAME to UUID.cfargotunnel.com). Keep existing VPN for legacy routes. Over time, migrate more internal DNS records to Cloudflare.

Users install WARP client. It co-exists with most VPN clients (split tunnel configuration). Eventually, when all apps are migrated, decommission the VPN concentrator. Zero downtime migration path.