🌐 Trang này chưa được dịch sang tiếng Việt — đang hiển thị nội dung tiếng Anh.

Cloudflare Zero Trust — Implementation & Best-Practice Onboarding Guide

A detailed, opinionated implementation playbook for deploying Cloudflare's Zero Trust (SASE) platform plus Cloudflare WAN. Every section gives exact dashboard paths, concrete configuration values, best-practice callouts, worked policy examples, validation steps, and the mistakes to avoid.

Naming note: The device client formerly called the WARP client is now the Cloudflare One Client in current docs and dashboard. This guide uses Cloudflare One Client but the behavior is identical to WARP. Dashboard menu labels also shift over time (policy areas are grouped under Access controls and Traffic policies); follow the nearest equivalent if a label has moved.

0. How to use this guide

This is sequenced as a real rollout. Each phase depends on the one before it, and each is built to be piloted first (5–25 users / one site), validated, then expanded.

1 Account/Org → 2 Identity → 3 Devices (Cloudflare One Client)
   → 4 ZTNA (Access) → 5 Gateway (DNS → Network → HTTP → TLS)
      → 6 DLP → 7 AI controls → 8 Cloudflare WAN

The 10 golden rules (read first)

1. Adopt progressively, never big-bang. Cloudflare's own SASE reference architecture recommends prioritizing one or two use cases (VPN replacement, then SWG) and layering the rest. Most failed rollouts try to flip everything at once.
2. Pilot → validate → expand at every phase. Never push a new enforcement policy to all users without a monitored pilot group and a rollback path.
3. Start in log/monitor mode, then enforce. This is the rule for Gateway, DLP, and AI controls especially. Baseline real traffic before you Block.
4. Build reusable components, not per-app snowflakes. Use Access Groups, Lists, and reusable posture checks so one change propagates everywhere. Have a naming convention from day one.
5. Identity is the foundation. Connect your corporate IdP with group claims and SCIM before writing any policy that references groups.
6. Least privilege + continuous verification. Default-deny, scope policies tightly, set short session durations for sensitive apps, and re-verify device posture on every request.
7. Keep a break-glass path. Always retain an admin login method (OTP / Cloudflare login) and a Super Admin who can't be locked out by your own policies.
8. Inspect deliberately. TLS decryption unlocks HTTP filtering, DLP, and AI prompt inspection — but plan Do Not Inspect exceptions (cert-pinned apps, Microsoft 365) and consider privacy/legal scope.
9. Log everything to your SIEM. Turn on Logpush for Access + Gateway from the start; you'll need it for tuning and audits.
10. Mind the entitlements. DLP (custom profiles), advanced posture, Browser Isolation at scale, and Cloudflare WAN require Enterprise. Confirm before scoping.

1. Platform overview & deployment models

Cloudflare Zero Trust (part of the Cloudflare One SASE platform) replaces legacy VPN + on-prem security stacks by enforcing identity- and context-aware policy at Cloudflare's global anycast edge. Because every service runs in every data center, traffic is connected, verified, filtered, and routed in a single pass close to the user — no backhaul, no service-chaining latency.

Building blocks

How traffic reaches Cloudflare (on-ramps) — choose per use case

Reference architecture (logical)

   Managed device ─Client─┐
   BYOD (Include split) ──┤        ┌──────────────────────────────────────────────┐
   Unmanaged (clientless)─┤        │            CLOUDFLARE GLOBAL EDGE             │   Internet
   Branch/DC ─Cloudflare WAN───┼──────► │  Identity ▸ Posture ▸ Access(ZTNA)            │ ─── & SaaS
   Cloud VPC ─MNC/IPsec───┘        │     ▸ Gateway(DNS/L4/HTTP) ▸ DLP ▸ AI controls│ ──►
                                   └───────────────┬──────────────────────────────┘
                                                   │ Cloudflare Tunnel / Access
                                                   ▼
                                       Private apps, servers, internal networks

Deployment-model decisions to make up front

• Managed vs. BYOD devices → drives WARP split-tunnel mode (Exclude for managed, Include for personal) and whether you can require strong posture.
• Client vs. clientless → clientless (Browser Isolation) gives no device posture; reserve for contractors/3rd parties.
• Internet security first (SWG/DLP) vs. private-access first (ZTNA) → most orgs start with VPN replacement (ZTNA), then add SWG/DLP. Pick your phase-1 use case explicitly.

Prerequisites

• A Cloudflare account. A registered zone is not required to begin, but is useful for self-hosted Access apps and custom hostnames.
• Plan awareness: Free / Pay-as-you-go / Enterprise. Enterprise is required for DLP custom profiles, advanced posture providers, and Cloudflare WAN.
• Admin role: Super Administrator (or scoped Zero Trust roles) for setup.
• For HTTP filtering / TLS inspection / DLP / AI prompt inspection: install the Cloudflare root CA on devices and run the client in Gateway with WARP mode.

2. Account creation & organization setup

Goal: Create the account, activate Zero Trust, and lock in your organization's team name.

Steps

1. Create / sign in at https://dash.cloudflare.com; verify the account email and enable account-level MFA for admins.
2. Open Zero Trust (left nav → Zero Trust, or https://one.dash.cloudflare.com). Choose a plan and add billing. (Start on Free/PAYG to evaluate; subscribe to Enterprise before DLP/Cloudflare WAN work.)
3. Choose your team name. This becomes your team domain: https://<team-name>.cloudflareaccess.com — the URL for the App Launcher, Access logins, and client enrollment. Set/verify under Settings → Custom Pages / General → Team name.
4. Set org defaults early:
   • Login methods / IdPs → §3.
   • Custom Pages — brand the login + block pages (builds user trust, reduces helpdesk tickets).
   • Account roles — assign least-privilege admin roles; keep ≥2 Super Admins.
   • Logpush — wire Access + Gateway logs to your SIEM/storage now, not later.
5. Walk the Get Started / setup flows — guided walkthroughs map to this guide (Replace your VPN, Secure web traffic, Secure DNS for networks, Clientless SSH/RDP, Network-to-network).

Best practice — team name is forever. It's embedded in user-facing URLs, enrollment configs, and policies. Pick a stable, recognizable value (usually your company short name). Renaming later breaks bookmarks, MDM configs, and muscle memory.

Validation: https://<team-name>.cloudflareaccess.com shows your org login; Settings → General shows the right plan + team name.

Pitfalls: throwaway team names; provisioning DLP/Isolation before the Enterprise entitlement is active (selectors stay greyed out); only one Super Admin (lock-out risk).

3. Identity provider (IdP) integration

Goal: Authenticate users with your corporate identity so every Access and Gateway policy can evaluate who the user is and which groups they belong to. Identity is the single most important foundation — get it right before writing policy.

Default changed (May 2026): Cloudflare is now the default IdP for newly created Zero Trust accounts, replacing One-time PIN. Users can sign in with their existing Cloudflare account (MFA-backed). For any production deployment you should still connect your corporate IdP so you inherit real users, groups, and lifecycle.

Supported login methods

• Enterprise SAML / OIDC: Microsoft Entra ID (Azure AD), Okta, Google Workspace, Ping, OneLogin, JumpCloud, ADFS, Centrify, generic SAML/OIDC.
• Consumer / social: Google, GitHub, LinkedIn, Facebook (B2B / partner use cases).
• Built-in fallbacks: Cloudflare login (account membership) and One-time PIN (OTP) for contractors/externals.

Steps

1. Settings → Authentication → Login methods → Add new → choose your provider.
2. Complete provider app registration:
   • OIDC: copy Client ID / Secret into Cloudflare.
   • SAML: exchange SSO URL + signing certificate / metadata.
   • Enable group/role claims (Entra ID "groups", Okta "groups", Google "Groups"). Grant the directory-read permissions Cloudflare requests.
3. Test with the built-in Test button — it runs a real login and shows the identity payload (email, groups, claims) Cloudflare receives. Confirm groups appear here before going further.
4. (Recommended) Configure SCIM (Entra ID / Okta) so user/group changes and deprovisioning propagate automatically — and importantly, can revoke active sessions when a user is disabled.
5. (Optional) Add multiple IdPs — e.g. Entra ID for employees + OTP for contractors. You can scope which IdPs apply to which apps later.

Independent / global MFA

Zero Trust → Access controls → Access settings:

• Allow MFA methods, set an Authentication duration, optionally Use identity provider MFA (honors the IdP amr claim to avoid double-prompting), and Apply global MFA settings by default. (The App Launcher is exempt so users can self-enroll authenticators.)

Best practices — identity

• SCIM is not optional for real deployments. Group-based policies drift and offboarding fails without it. SCIM also enables session revocation on disable.
• Verify group claims in the Test output — missing groups is the #1 reason "my group policy doesn't match."
• Keep a break-glass IdP (OTP or Cloudflare login mapped to an admin) so a misconfigured SAML connector can't lock you out.
• Prefer enterprise IdP over consumer for employees; reserve social/OTP for external collaborators and scope them per-app.

Validation: IdP Test returns expected email + groups; a pilot user logs in at the team domain via the corporate IdP; disabling a test user in the IdP revokes access (proves SCIM).

Pitfalls: missing group claims; no SCIM (stale groups, failed offboarding); no break-glass login; decommissioning OTP before SAML is proven.

4. Device enrollment — Cloudflare One Client (WARP)

Goal: Connect managed (and selected BYOD) devices to Cloudflare so traffic can be filtered (Gateway), tunneled to private apps (Access), and evaluated for device posture.

4.1 Key concepts

• Client modes: Gateway with WARP (full L3/L7 + DNS filtering — standard enterprise mode), Gateway with DoH (DNS-only), Secure Web Gateway without DNS filtering, Proxy mode, and Device Information Only (posture, no proxying).
• Device enrollment permissions: rules defining who/what may enroll a device (e.g. emails ending @yourco.com, authenticated by your IdP). No matching rule → "you are not allowed to enroll."
• Device profiles: per-group settings (mode, split tunnels, switch locks, captive-portal behavior). Matched by selectors so different device groups get different configs.
• Device posture: signals used in Access/Gateway policies — OS version, disk encryption, firewall, client certificate, serial-number list, plus third-party EDR.

4.2 Steps

1. Define enrollment permissions. Settings → WARP Client → Device enrollment permissions → Manage → add a rule, e.g. Include → Emails ending in → @yourco.com, and select the IdP(s). This is the gate for registration.

2. Configure device profiles. Settings → WARP Client → Device settings:

   • Set the default profile (mode = Gateway with WARP, allowed protocols, switch locks, auto-connect, captive-portal detection).
   • Add group-scoped profiles (e.g. servers vs. laptops vs. BYOD) selected by posture/identity.

3. Configure Split Tunnels (per profile):

   • Exclude mode (default, managed devices): everything routes through WARP except listed exceptions. The default list includes 100.64.0.0/10 (CGNAT used by Cloudflare One services). Best practice: add back any RFC-1918 / CGNAT ranges you genuinely use locally to avoid conflicts, but otherwise keep the tunnel broad.
   • Include mode (BYOD/personal devices): only listed IPs/domains route through WARP — so Gateway inspects only corporate traffic and personal traffic stays private. This is the recommended posture for BYOD and reduces privacy concerns.

4. Distribute the Cloudflare root CA (required for HTTP filtering, TLS decryption, DLP, AI prompt inspection). Push the Cloudflare-managed certificate (or your own) to the OS/browser trust stores via MDM.

5. Deploy the client:

   • Pilot (manual): download from the Cloudflare One downloads page; users Login with Cloudflare Zero Trust and enter the team name.
   • Production (MDM — Intune, Jamf, Kandji, Workspace ONE, SCCM): push with pre-set parameters for a silent, pre-authenticated install. Key MDM parameters:

   Parameter	Purpose / best-practice value
   organization	Your team name — required for managed enrollment
   auth_client_id + auth_client_secret	Service-token enrollment — enroll without interactive login (ideal for fleets/servers)
   service_mode	warp (Gateway with WARP) for standard enterprise
   onboarding	false → suppress the welcome screens for silent deploys
   auto_connect	0 to connect immediately (no idle timeout before connect)
   display_name / support_url	Branding + a helpdesk link users see in the client
   unique_client_id	Stable device identifier for posture/serial mapping
   enable_post_quantum	Enable post-quantum tunnel crypto where supported
   organization_configs / configs[]	Multi-org / config switching (newer clients)

6. Enable device posture checks. Settings → WARP Client → Device posture (or Reusable components → Posture checks). Posture comes in three categories:

   • Client checks (run by the Cloudflare One Client): OS version, disk encryption, firewall, client certificate, file/registry/application presence, serial-number list, domain-joined.
   • Service-to-service (third-party providers): CrowdStrike, SentinelOne, Microsoft Intune, Tanium, etc. — matched even on agentless devices via email mapping.
   • Access integrations (Access apps only, not usable in Gateway policies).

Best practices — devices

• Default to Exclude mode for managed devices, Include mode for BYOD. Don't run personal devices in full-tunnel Exclude mode — it captures personal traffic and creates privacy/legal exposure.
• Roll out the root CA before enabling TLS decryption. If you flip decryption first, HTTPS breaks fleet-wide.
• Use service-token (auth_client_id/secret) enrollment for servers and large fleets so devices enroll silently and consistently.
• Set posture to "latest stable" not "absolute latest." e.g. macOS ≥ 15.1 (a version you've qualified), so a same-day OS release doesn't lock everyone out.
• Tanium posture is not supported in Gateway policies — only in Access. Plan accordingly.
• Phase device profiles: start Device Information Only (posture, no proxy) to validate signals, then switch the pilot group to Gateway with WARP.

Validation: pilot device shows Connected, correct profile applied; registration appears under My Team → Devices; a posture check (e.g. disk encryption) reports correctly; WARP diagnostics confirm enrollment.

Pitfalls: forgetting the root CA (HTTPS breaks / DLP silently blind); overly broad Include-mode entries blackholing local traffic when switching Wi-Fi↔Ethernet; no enrollment-permission rule.

5. ZTNA — Access (applications & policies)

Goal: Replace VPN for application access. Publish internal and SaaS apps behind Access so every request is authenticated and authorized per app — least privilege, no implicit network trust.

5.1 Connect the application to Cloudflare (pick a connector)

• Cloudflare Tunnel (recommended for private apps): install cloudflared on a host that can reach the app → Networks → Tunnels → Create → map a public hostname (wiki.yourco.com → http://localhost:3000) or route a private CIDR. No inbound firewall ports. (Only cloudflared can proxy public hostnames to private origins.)
• SaaS apps: integrate via SAML/OIDC — Access becomes the identity layer in front of the SaaS app.
• Private network / infrastructure: route internal CIDRs through a tunnel; use Access for Infrastructure for SSH/RDP/VNC, optionally clientless (browser-rendered).

5.2 Add an Access application

1. Zero Trust → Access → Applications → Add an application.
2. Type: Self-hosted (web app), SaaS, Private Network, or Infrastructure.
3. For Self-hosted: set name, public hostname/path, the IdPs allowed, session duration, App Launcher visibility, CORS/cookie settings.

5.3 Write Access policies (the core of ZTNA)

Policies evaluate top-down; the first match wins. Each policy = an Action + rules.

• Actions: Allow · Block · Bypass (no auth — avoid for sensitive apps) · Service Auth (machine-to-machine via mTLS or service tokens, no login page).
• Rule types: Include (match ≥1), Require (match all), Exclude (must NOT match — Exclude overrides everything).
• Selectors: emails / email domains, IdP groups, country, IP/CIDR, device posture, gateway (came through Gateway), mTLS cert, Lists, auth method/MFA, Cloudflare Account Member.

Worked example — "Allow Engineering on a compliant device, require MFA":

5.4 Reusable building blocks (do this, not per-app rules)

• Access Groups (Access controls → Policies → Groups): named, reusable rule blocks (e.g. "Secure employees" = group membership + 3 posture checks). Reference the same group across many apps — change once, applies everywhere.
• Lists (Reusable components → Lists): import emails (contractors, high-risk users) or approved device serial numbers; update via UI or API for integration with HR/MDM systems.
• Reusable posture checks: define once, reference in both Access and Gateway.

5.5 Advanced patterns

• RBI fallback for unmanaged devices: keep the normal Access Allow for compliant employees, and add a Gateway HTTP Isolate policy so users hitting the same app URL from a non-compliant device get a remote-browser session instead of a block.
• App Launcher: single portal (<team-name>.cloudflareaccess.com) listing each user's permitted apps.
• Per-app MFA / short sessions: override global MFA and set immediate session expiry for crown-jewel apps.

Best practices — ZTNA

• Adopt a policy naming convention from day one (e.g. Allow — Full-time employees, Block — High-risk users). You'll reuse these names across dozens of apps; consistency makes audits trivial.
• Default-deny. End each app's policy list with a low-priority Block — everyone safety net; put Exclude/Block policies above broad Allows (order matters).
• Session duration = least privilege over time. 24h is typical; set immediate/short for sensitive apps so posture + identity are re-verified continuously.
• Use Require gateway to force traffic through Gateway (via client, Browser Isolation, or a Cloudflare WAN site) — more flexible than requiring the agent alone, and guarantees logging/filtering.
• Use Service Auth (tokens/mTLS) for automation/APIs — never a Bypass policy.
• Migrate VPN apps app-by-app, validate, then decommission the VPN concentrator (see the Replace your VPN learning path).

Validation: permitted user reaches the app after IdP login; non-member is blocked; Access → Logs / Logpush show allow/block with identity + posture context.

Pitfalls: Bypass on sensitive apps; broad Allow ordered above a needed Block; forgetting the default-deny; per-app rule sprawl instead of Access Groups.

6. Secure Web Gateway (Gateway)

Goal: Inspect and filter outbound DNS, network (L4), and HTTP (L7) traffic — block threats, enforce acceptable-use, and create the enforcement point DLP and AI controls plug into. Build policies in three layers, in this order (dashboard: Gateway → Firewall Policies, increasingly under Traffic policies).

6.1 DNS policies — start here (fastest, lowest-risk value)

1. Gateway → Firewall Policies → DNS → Add a policy.
2. Block by security categories (malware, phishing, C2, DGA, new domains) and content categories per your acceptable-use policy.
3. DNS Locations (Gateway → DNS Locations): for offices/networks without the client, create a location and point the resolver at the assigned IPv4/IPv6, DoH, or DoT endpoints — filtering all DNS from that site with no client install.

Best practice: Deploy DNS filtering org-wide first — it works with or without the client, can't break HTTPS, and immediately blocks the majority of malware/phishing by domain. It's your safest phase-1 enforcement.

6.2 Network policies (L4)

Gateway → Firewall Policies → Network. Control by IP, port, protocol, and application — e.g. block outbound SMTP from clients, restrict RDP/SSH egress, or allow-list specific destinations. Requires the client in proxy mode (or a Cloudflare WAN on-ramp).

6.3 TLS decryption + HTTP policies (L7)

1. Enable TLS decryption (Settings → Network → Firewall / TLS decryption). Requires the Cloudflare root CA on devices (§4). Without it, HTTP/DLP/AI inspection can't see HTTPS bodies.
2. Create your Do Not Inspect exceptions before broad enforcement:
   • Gateway maintains a built-in "Do Not Inspect" application type for apps incompatible with decryption — select the whole type in a Do Not Inspect policy and Cloudflare keeps it updated.
   • Turn on the one-click Microsoft 365 traffic integration to auto-bypass all M365 domains/IPs.
   • Some Google products use embedded certificates and need a Do Not Inspect rule (or configure the app to trust the Cloudflare cert to keep visibility).
   • Add certificate-pinned apps (banking, some native/mobile apps) to Do Not Inspect.
3. Gateway → Firewall Policies → HTTP → Add a policy. Filter by application / app type (granular app categories), domain, URL, content category, file type, request/response direction, DLP Profile, and identity/device selectors.
4. Actions: Allow, Block, Isolate (Browser Isolation), Do Not Inspect, Do Not Scan (skip DLP on trusted apps).
5. Application granular controls: permit an app but restrict specific actions — e.g. allow ChatGPT but block uploads, allow Google Drive viewing but block downloads to personal tenants. This is also the hook for AI controls (§7).

Best practices — Gateway

• Order: general → specific, with Do Not Inspect / Bypass exceptions near the top, broad Allow/Block below. Policies evaluate top-down.
• Stage TLS decryption: enable for the pilot group only, confirm HTTPS works + logs show decrypted detail, then expand. Have the Do Not Inspect list ready first.
• Scope privacy-sensitive categories (health, finance) — consider Do Not Inspect for them to meet privacy/legal obligations.
• Use the HTTP analytics dashboard to watch Allowed / Isolated / Do-Not-Inspect ratios and spot misconfig.

Validation: browse a known-blocked category → Cloudflare block page; Gateway → Logs show DNS/Network/HTTP decisions and decrypted HTTPS detail (proves CA + decryption).

Pitfalls: HTTP/Network policies do nothing for users without the client/on-ramp (DNS is the exception); decryption breaks cert-pinned apps if you skip Do Not Inspect; decrypting sensitive categories without a privacy review.

7. Data Loss Prevention (DLP)

Goal: Detect and control sensitive data (PII, credentials, financial, source code, custom patterns) moving through Gateway HTTP traffic. Requires Zero Trust Enterprise + admin permissions, and depends on TLS decryption (§6.3).

7.1 How DLP works

• Profiles define what to detect; detection entries are the patterns (predefined detectors, custom regex, dictionaries, Exact Data Match (EDM), Microsoft Purview (MIP) sensitivity labels). DLP scans the HTTP body (uploads/downloads/posts/chat) — not headers.

7.2 Steps

1. Pick or build a profile. Zero Trust → DLP → DLP Profiles.

   • Predefined profiles: e.g. Credentials and Secrets, Financial Information, PII. Toggle individual entries to tune scope. Note: most predefined profiles match when any enabled entry matches; the PII Record profile is special — it requires ≥3 unique entries in close proximity before it fires (built-in false-positive control).
   • Custom profiles: combine entries, add custom regex/dictionaries, EDM datasets, or MIP labels.

2. Tune detection sensitivity:

   • Match count — minimum number of matches before an action triggers (set 10 → needs 11+ matches). Cuts noise on documents with isolated patterns.
   • Confidence threshold (Low / Medium / High) — DLP scores detections using proximity keywords (e.g. the word "SSN" near a 9-digit number raises confidence). Higher threshold = fewer false positives.
   • AI context analysis — a pretrained model adjusts confidence from surrounding context (HTTP/HTTPS only). Enable in DLP settings.
   • OCR — detect sensitive text inside images (.jpg/.png, 4 KB–1 MB). Enable in DLP settings (profile-level OCR is deprecating).

3. Enforce via a Gateway HTTP policy using the DLP Profile selector. Worked example:

   Selector	Operator	Value	Logic	Action
   Destination Domain	in	dropbox.com, wetransfer.com	And	Block
   DLP Profile	in	Financial Information (High)	And
   User Group	in	Finance

Best practices — DLP

• Monitor first, enforce second. Start every profile with an Allow + log policy to baseline detections for 1–2 weeks, then add a Block for specific high-risk destinations/groups.
• The recommended confidence pattern = two HTTP policies: Policy 1 uses a Low-confidence profile with Allow (log) for visibility; Policy 2 uses a High-confidence profile with Block for enforcement. You get full telemetry without over-blocking.
• Always scope by destination, app, or group. A broad Credentials and Secrets profile applied to all traffic floods you with false positives (Google, Zoho, internal apps).
• Use "Do Not Scan" for trusted, noisy apps; use match count + confidence to dial in precision.
• No decryption = no DLP. Confirm TLS decryption + root CA before expecting detections.

Validation: upload a benign test pattern (fake SSN / test credit-card string) to a monitored destination → detection appears in Gateway → Logs / DLP with the matched profile; the DLP Profile selector is present (proves Enterprise + permissions).

Pitfalls: over-broad profiles; missing decryption (silent under-detection); enforcing Block before baselining; "DLP Profile selector missing" = non-Enterprise plan or insufficient role.

8. AI safety controls

Goal: Govern generative-AI usage — discover shadow AI, stop sensitive data leaking into prompts, and defend AI apps you build from LLM-specific threats. Cloudflare provides complementary layers; deploy them in the order below.

8.1 Discover shadow AI (visibility first)

• Gateway → analytics → Shadow IT Discovery: see which AI/SaaS apps users access, mark them approved/unapproved, and quantify usage. This is the evidence base for your AI acceptable-use policy.

8.2 Control AI app usage with Gateway (prevent leakage)

• In a Gateway HTTP policy, target AI apps (ChatGPT, Google Gemini, Claude, Perplexity, …) and use Application granular controls to allow the app but block risky actions (file uploads, prompt submission) instead of blocking outright.
• Add the DLP Profile selector to the same policy to scan prompts/uploads for sensitive data.

8.3 AI Prompt Protection (DLP for prompts)

DLP natively inspects user prompts to popular AI apps and classifies them:

• Prompt detection for Google Gemini, ChatGPT, Claude, Perplexity.
• Topic classification: Content topics (PII, Source Code, Credentials & Secrets, Financial Information, Customer Data) and Intent topics (jailbreak attempts, malicious-code requests, PII-extraction attempts).
• Predefined "AI Prompt" profiles (e.g. AI Prompt: AI Security, AI Prompt: PII) bundle these for quick rollout. Configure under DLP → Detection entries → AI prompt topics, then reference in a Gateway HTTP policy.

8.4 DLP for AI Gateway (protect your own AI apps' traffic)

• If you run AI through Cloudflare AI Gateway, enable DLP for AI Gateway (AI Gateway → your gateway → features → set up DLP). It scans the text of requests to AI providers and the responses for sensitive data — without requiring Gateway HTTP filtering or TLS decryption. Ideal for API-based / programmatic AI usage.

8.5 AI Security for Apps (WAF — for AI you expose)

• For AI apps you build and expose, AI Security for Apps (in WAF) detects LLM-specific threats — prompt injection, unsafe topics. It complements DLP: AI Security for Apps handles model-layer attacks; DLP handles sensitive-data detection. Use both on AI traffic.

8.6 MCP server portals (governing AI agents/tools)

• For orgs exposing Model Context Protocol (MCP) servers/tools to AI agents, Access → AI controls → MCP server portals lets you publish, gate, and rename tools/prompts behind Access policy.

Recommended AI rollout: Discover (8.1) → Monitor prompts with AI DLP profiles in log mode (8.3) → Enforce granular controls + DLP block on sanctioned apps (8.2) → add DLP for AI Gateway for programmatic AI (8.4) and AI Security for Apps for apps you expose (8.5).

Best practice — don't hard-block AI. Outright blocks push users to personal devices/accounts (worse shadow AI). Prefer allow + granular control + DLP. Match the layer to consumption: prompt inspection (8.2/8.3) needs decryption + client; API governance (8.4) does not.

Pitfalls: blocking instead of governing; expecting prompt inspection without decryption; treating AI Security for Apps and DLP as interchangeable (they're complementary).

9. Cloudflare WAN

Goal: Connect entire sites, data centers, and cloud networks to Cloudflare's network as an on-ramp — routing branch/DC traffic through Cloudflare for security (Magic Firewall + Gateway) and connectivity, without MPLS or full-mesh VPNs. Cloudflare WAN is an Enterprise network subscription. Docs root: developers.cloudflare.com/cloudflare-wan/.

9.1 Choose on-ramp(s)

9.2 Pre-flight: MSS clamping (do this before enabling Cloudflare WAN)

Cloudflare encapsulates packets (new headers), so you must set TCP MSS clamping on your edge to avoid black-holing large/HTTPS packets:

• GRE tunnels: clamp the GRE internal interface to 1,436 bytes.
• IPsec tunnels: clamp to 1,360 bytes maximum (lower, because the physical interface sees encrypted packets).
• Vendor specifics differ (Cisco ip tcp adjust-mss, Juniper tcp-mss); some devices set it automatically once the tunnel is up — verify, don't assume.

9.3 Setup steps

1. Confirm the subscription (engage your account team).
2. Create on-ramp(s) under Cloudflare WAN:
   • Connector: register the appliance, cable WAN/LAN, adopt it (it auto-builds redundant tunnels to Cloudflare). Configure LAN subnets/DHCP.
   • IPsec/GRE: add tunnels with your device's endpoint + interface addresses, (IPsec) pre-shared key, and tunnel health-check settings. Mirror the config on your router/firewall.
3. Configure routing:
   • Static routes — add your site/DC prefixes to the Magic routing table with the tunnel as next hop; set priority/weight for ECMP load-sharing and failover.
   • BGP (over GRE/IPsec) — establish eBGP (MD5 auth) to exchange routes dynamically and auto-add/remove subnets with failure detection.
4. Add security: apply Magic Firewall (L3/L4) rules, and route Internet-bound site traffic through Gateway so clientless sites get the same DNS/Network/HTTP/DLP policies as client users.
5. Configure tunnel health checks + alerts (dashboard / GraphQL) so you're notified before users feel an outage.

Best practices — Cloudflare WAN

• Always build redundancy: two tunnels from separate routers. The Cloudflare end is anycast — one tunnel already reaches every Cloudflare data center, so resilience is about your side. Dual routers protect against on-prem hardware failure.
• Set MSS clamping first. The classic symptom of a missed clamp: plain http:// works but https:// hangs. Test with curl http://ifconfig.me vs curl https://ifconfig.me.
• Plan IP space before adding routes — overlapping subnets across sites break Magic routing.
• Prefer BGP for multi-site/dynamic environments so route changes don't require manual edits; use static routes for simple, stable sites.
• Don't forget Magic Firewall — network traffic is unfiltered until you add rules, even when client (WARP) traffic is locked down.
• Enable tunnel health alerts and watch bandwidth/health via GraphQL analytics.

Validation: tunnels/Connector show healthy with passing health checks; site-to-site and site-to-private-resource reachability works; routes appear in the Magic routing table; https://ifconfig.me succeeds (MSS correct); failover works when you disable one tunnel; Internet-bound site traffic is filtered by Gateway.

Pitfalls: missed/incorrect MSS clamp (HTTPS hangs); single-router tunnels (no real redundancy); overlapping subnets; asymmetric routing/MTU mismatches on GRE/IPsec; unfiltered network traffic (no Magic Firewall rules).

10. Phased rollout plan

Pilot each phase with a small group/site, validate against its exit criteria, then expand.

Go-live checklist

• [ ] Team name finalized; corporate IdP + SCIM connected, tested, group claims verified
• [ ] Break-glass admin login retained; ≥2 Super Admins
• [ ] Client deployed via MDM (service-token enrollment) with root CA; default + group + BYOD profiles set
• [ ] Posture checks enabled (latest stable OS) and referenced via Access Groups
• [ ] DNS → Network → HTTP policies live; TLS decryption staged; Do Not Inspect (M365 + cert-pinned) configured
• [ ] Access apps migrated with default-deny, posture + MFA, consistent naming, reusable groups
• [ ] DLP tuned (match count + confidence); monitor → enforce; scoped to destinations/groups
• [ ] Shadow-AI reviewed; AI prompt DLP + granular controls enforced; DLP-for-AI-Gateway where applicable
• [ ] Cloudflare WAN: MSS clamped, dual-router tunnels healthy, routes correct, Magic Firewall rules applied, failover tested
• [ ] Logpush to SIEM live; tunnel health + policy alerts routed to the right admins

11. Validation, monitoring & troubleshooting

Troubleshooting order (fastest root-causes first):

1. Is the client connected and the right profile applied?
2. Is the root CA installed (for HTTPS / DLP / AI prompt inspection)?
3. Does policy order put a broad Allow above a needed Block (or a missing default-deny)?
4. Are IdP groups present in the identity payload (re-run the IdP Test)?
5. Does the feature require Enterprise (DLP custom profiles, advanced posture, Cloudflare WAN)?
6. Cloudflare WAN HTTPS hangs / large transfers fail → MSS clamp wrong (GRE 1,436 / IPsec 1,360).
7. App broken after decryption → add to Do Not Inspect (cert pinning / embedded certs).

Export Access + Gateway logs via Logpush to your SIEM for ongoing tuning, anomaly detection, and audit.

12. Best-practice summary (one-screen reference)

13. Reference links

• Cloudflare One (Zero Trust) — https://developers.cloudflare.com/cloudflare-one/
• Replace your VPN (learning path) — https://developers.cloudflare.com/learning-paths/replace-vpn/
• SASE reference architecture — https://developers.cloudflare.com/reference-architecture/architectures/sase/
• Designing ZTNA access policies — https://developers.cloudflare.com/reference-architecture/design-guides/designing-ztna-access-policies/
• Identity providers — https://developers.cloudflare.com/cloudflare-one/integrations/identity-providers/
• Cloudflare One Client (WARP) & MDM parameters — https://developers.cloudflare.com/cloudflare-one/team-and-resources/devices/cloudflare-one-client/deployment/mdm-deployment/parameters/
• Split tunnels — https://developers.cloudflare.com/cloudflare-one/team-and-resources/devices/cloudflare-one-client/configure/route-traffic/split-tunnels/
• Posture checks — https://developers.cloudflare.com/cloudflare-one/reusable-components/posture-checks/
• Access (ZTNA) controls — https://developers.cloudflare.com/cloudflare-one/access-controls/
• Access Groups — https://developers.cloudflare.com/cloudflare-one/access-controls/policies/groups/
• Cloudflare Tunnel — https://developers.cloudflare.com/cloudflare-one/networks/connectors/cloudflare-tunnel/
• Gateway / Traffic policies — https://developers.cloudflare.com/cloudflare-one/traffic-policies/
• TLS decryption + Do Not Inspect — https://developers.cloudflare.com/cloudflare-one/traffic-policies/http-policies/tls-decryption/
• Data Loss Prevention — https://developers.cloudflare.com/cloudflare-one/data-loss-prevention/
• DLP profile settings (match count / confidence / OCR / AI context) — https://developers.cloudflare.com/cloudflare-one/data-loss-prevention/dlp-profiles/advanced-settings/
• AI controls — https://developers.cloudflare.com/cloudflare-one/access-controls/ai-controls/
• DLP for AI Gateway — https://developers.cloudflare.com/ai-gateway/features/dlp/
• AI Security for Apps (WAF) — https://developers.cloudflare.com/waf/detections/ai-security-for-apps/
• Holistic AI security (learning path) — https://developers.cloudflare.com/learning-paths/holistic-ai-security/
• Cloudflare WAN / WAN — https://developers.cloudflare.com/cloudflare-wan/
• Cloudflare WAN get started + MSS — https://developers.cloudflare.com/cloudflare-wan/get-started/
• Cloudflare WAN routes (static + BGP) — https://developers.cloudflare.com/cloudflare-wan/configuration/how-to/configure-routes/
• MTU / MSS reference — https://developers.cloudflare.com/cloudflare-wan/reference/mtu-mss/

Appendix — Glossary

Prepared 2026-06-08. Grounded in current Cloudflare documentation (Cloudflare One, Cloudflare WAN, and SASE reference architecture). Verify plan entitlements and live dashboard navigation before production rollout, as Cloudflare ships changes frequently.