Cloudflare Zero Trust readiness checklist
Use this checklist to prepare a Cloudflare Zero Trust rollout across VPN use cases, private applications, identity groups, SCIM, WARP profiles, split tunnels, local domain fallback, cloudflared tunnels, Gateway policies, logs, support workflows, and rollback.
Use this checklist to prepare a Cloudflare Zero Trust rollout across VPN use cases, private applications, identity groups, SCIM, WARP profiles, split tunnels, local domain fallback, cloudflared tunnels, Gateway policies, logs, support workflows, and rollback.
Topics: cloudflare, resource, cloudflare, zero, trust, readiness, checklist
Machine-readable context: /ai-index.json
Step by step
Step-by-step checklist
- 1
Inventory the VPN and remote-access use cases you intend to replace: who connects, to which private applications and subnets, from which device types, and what currently authorises them.
- 2
Confirm identity readiness: which identity provider (or providers) will back Cloudflare Access, whether SSO and MFA are enforced, and whether SCIM is available to sync the user groups your policies will reference.
- 3
Build an application and resource inventory — internal web apps, admin portals, SSH/RDP targets, and private subnets — and note which will sit behind Access and which need a cloudflared tunnel.
- 4
Assess device posture prerequisites: which platforms are in scope, whether the WARP client can be deployed via MDM, and which posture signals (OS version, disk encryption, running services) you can realistically enforce at launch.
- 5
Plan WARP profiles and split-tunnel strategy: which traffic should be tunneled, what stays local, and how local domain fallback should resolve internal hostnames.
- 6
Map the initial Gateway policy intent (DNS and HTTP filtering) and the Access policy groups, deciding what starts in log-only mode versus enforcement.
- 7
Decide logging and visibility up front: enable Gateway and Access activity logging and configure Logpush to your SIEM or storage so the rollout is observable from day one.
- 8
Sequence the rollout by user group with a rollback path for each phase, and define the support workflow for enrollment issues, posture failures, and policy exceptions.
Risk register
Risks to control
Identity groups are not in place or not synced, so Access policies cannot reference the right populations.
Confirm IdP integration and, where possible, SCIM group sync before designing policies, and validate group membership against test accounts.
The WARP client cannot be deployed at scale because no MDM path was confirmed.
Verify managed deployment per platform during readiness, and identify any unmanaged or BYOD devices that need a different enrollment route.
Split-tunnel and local domain fallback settings are wrong, so internal hostnames stop resolving or too much traffic is forced through WARP.
Map internal domains and required routes during readiness and test resolution and routing with the pilot group before wider rollout.
Posture checks are set too strictly at launch and lock out legitimate, slightly-out-of-date devices.
Start with posture signals in log/monitor mode, baseline the real fleet, then tighten enforcement once you understand the spread of device states.
Private applications are reachable through a tunnel but were never inventoried, leaving gaps or shadow access paths.
Complete the application and subnet inventory first and map each target to either an Access app or a cloudflared route with a named owner.
The rollout has no rollback or support plan, so a policy problem becomes an outage for a whole group.
Sequence rollout by group, keep the prior access method available per phase, and stand up a support workflow for posture, enrollment, and exception handling before go-live.
Output
Useful deliverables
- A VPN and remote-access use-case inventory mapping users, private apps, subnets, and current authorisation.
- An identity-readiness summary: IdP(s), SSO/MFA status, and SCIM group-sync availability.
- An application and resource inventory tagged as Access-fronted or cloudflared-tunnel, each with an owner.
- A device-posture and WARP deployment plan covering platforms, MDM path, profiles, split tunnels, and local domain fallback.
- An initial Gateway and Access policy plan with log-only versus enforcement decisions.
- A logging plan enabling Gateway/Access activity logs and Logpush to a SIEM or storage destination.
- A phased rollout sequence by user group with per-phase rollback and a defined support workflow.
Keep reading
Related resources
FAQ
Frequently asked questions
Common questions teams ask when putting this resource into practice.
What do we need in place before starting a Cloudflare Zero Trust rollout?
The core prerequisites are an integrated identity provider with SSO/MFA, an inventory of the private apps and subnets you want to protect, a confirmed way to deploy the WARP client (typically via MDM), and a decision on which posture signals you can realistically enforce.
Is SCIM required for Cloudflare Access?
It is not strictly required, but SCIM group sync keeps the user groups your Access policies reference accurate as people join and leave. Without it you rely on IdP claims at login, which is workable but harder to manage at scale.
How do internal hostnames keep resolving once WARP is deployed?
Through your split-tunnel configuration and local domain fallback settings, which tell WARP which domains and routes to send through Cloudflare One versus resolve locally. Mapping internal domains during readiness avoids resolution breakage.
Can we roll out Zero Trust without removing the existing VPN immediately?
Yes, and that is the safer approach. You sequence the rollout by user group, keep the legacy access method available per phase as a fallback, and decommission the VPN only after the corresponding use cases are confirmed working on Cloudflare One.
Nanosek
Plan Zero Trust rollout
Nanosek can turn this resource into a practical delivery plan for your environment — with rollback planning, stakeholder alignment, and 24/7 managed operations support.