Cloudflare Zero Trust cheat sheet

Access model: Cloudflare Access authorizes each request per identity, device posture, and context; no implicit network-level trust is granted once a user is on the corporate LAN or VPN.

Core components: an Access application (self-hosted, SaaS, or non-HTTP), one or more policies, an identity provider, and optionally a Gateway DNS/network policy for the same hostname.

Policy evaluation order: Access evaluates policies top-to-bottom and applies the first matching Allow/Block/Service Auth decision; a request matching no policy is denied by default.

Identity requirement: every Access policy needs at least one Include rule (email, group, IdP group, SAML attribute, IP, or service token); Require rules add conditions but cannot admit a user alone.

Common Access rule types: Include, Require, Exclude, and Bypass. Exclude overrides Include; Bypass skips identity checks entirely and is typically limited to public or health-check paths.

Service Auth: non-interactive clients (CI jobs, APIs, MCP servers) authenticate with Access service tokens via the CF-Access-Client-Id and CF-Access-Client-Secret headers instead of an IdP login.

Device posture: Access can require WARP client checks (OS version, disk encryption, running processes, corporate device certificate) before issuing the Access JWT cookie.

Private network access: WARP-to-Tunnel routing publishes internal CIDR ranges through cloudflared; the user's device must be enrolled and connected to WARP for the route to resolve.

Session controls: Access issues a signed JWT cookie per application; session duration, re-authentication frequency, and 'revoke existing sessions' determine how long a compromised session remains valid.

Gateway inspects DNS, network (L4), and HTTP (L7) traffic from enrolled devices via the WARP client or from network locations via dedicated egress IPs and DoH subdomain.

DNS filtering resolves names against Gateway's resolver; a Blocked DNS response returns 0.0.0.0 (or the configured block page IP) and prevents the connection before any TCP handshake.

Policy precedence: Gateway evaluates DNS, then network, then HTTP policies; within a category, the first matching rule wins, and a request with no match falls through to the default Allow.

Policy selectors include host, domain, URL, URL category, application, content category, source IP, user identity, device posture, and HTTP method/version.

Cloudflare Gateway Categories are Cloudflare-curated intelligence feeds (for example, 'Security Risks', 'Gambling'); Application categories map to specific SaaS apps by domain set rather than by content classification.

TLS inspection: Gateway decrypts HTTPS only when a TLS decryption policy matches and the device trusts the Cloudflare root certificate; without the certificate, users see certificate errors.

Do Not Inspect (DNI) lists exempt hostnames and categories from TLS inspection, typically for privacy, legal, or breakage reasons; DNI traffic is still subject to DNS and network policies.

Isolation: Gateway can route matching sites through Remote Browser Isolation so the endpoint receives only a pixel stream; file downloads and clipboard are governed by separate isolation settings.

Logging: Gateway logs DNS, network, and HTTP events to Logpush or the dashboard; unmatched traffic is logged as allowed and should be monitored for policy gaps.

DEX uses the WARP client on enrolled devices to collect passive and active telemetry: device health, network path, Wi-Fi quality, and application reachability.

Live and historical views: the dashboard shows real-time device and user experience plus historical trends; fleet-wide scores aggregate device, network, and application signals.

Synthetic tests: administrators define HTTP, TCP, and traceroute tests with target URLs, intervals, and device cohorts; results show latency, status codes, and hop-by-hop path data.

Device signals include CPU, memory, disk, battery, OS version, WARP connection state, and installed applications; these feed posture checks and troubleshooting views.

Network path analysis identifies the last-mile ISP, gateway, and Cloudflare colo a device reaches, which distinguishes local Wi-Fi or ISP problems from Cloudflare-side issues.

Application tests measure reachability of internal apps (private network via Tunnel) and SaaS apps; failures correlate with Gateway policies, Tunnel health, or IdP outages.

Troubleshooting workflow: start from a user or device, review the experience score, then inspect synthetic test results and network path before opening a support case.

DEX data is scoped by device enrollment; unenrolled devices produce no telemetry, so coverage gaps usually indicate WARP not deployed or not connected.

API CASB connects to SaaS tenants (Microsoft 365, Google Workspace, Salesforce, and similar) via OAuth to scan at-rest data, detect misconfigurations, and remediate without inline traffic.

Inline CASB operates through Gateway HTTP policies on SaaS traffic, applying controls such as block upload, block download, or require justification on matched applications.

Shadow IT discovery surfaces unsanctioned SaaS use from Gateway logs; each app gets a risk score based on category, security posture, and usage volume.

DLP profiles define detection entries (predefined patterns such as credit cards or SSNs, custom regex, keywords, and document fingerprints) plus confidence thresholds.

DLP policies attach a profile to a scope (inline HTTP, API CASB, or email) and an action: Allow, Block, or Block with override (user justification logged).

Matching logic: DLP inspects content only when a policy's scope matches the request; encrypted or uninspected TLS traffic is not scanned, so DLP depends on TLS decryption.

Predefined detection entries cover common data types (PII, financial, credentials); custom entries support regex with validation and proximity keywords to reduce false positives.

API CASB findings include publicly shared files, unapproved third-party app grants, and stale accounts; remediation can revoke sharing or remove app access directly from Cloudflare.

Logging and incidents: DLP matches generate Gateway or CASB logs and optional email notifications; overrides are recorded with the user's stated reason for audit.