Network & Security
Zero Trust and secure access for people, devices, and applications.
We design and roll out access based on identity and device, not network location: zero trust network access (ZTNA) for private applications, gateway policies, and device posture checks, piloted with a small group first. Designs run on Cloudflare One alongside your identity provider and the Fortinet, Palo Alto Networks, Check Point, or Cisco firewalls you already run, and the old VPN keeps running until the last group has moved.
Platforms
Who this is for
IT and security teams that want to replace a traditional remote-access VPN, protect private applications without opening them to the internet, introduce device-aware policies, or connect distributed teams and offices. It also suits organizations whose first Zero Trust deployment stalled after the pilot because exceptions, identity, or ownership were never settled.
The right access, for the right person, in the right context
Remote teams, private applications, and cloud services need an access model that is both secure and usable. Zero Trust is a security model built on least privilege: every request is authenticated and authorized based on identity and context before access is granted. Turning that principle into a rollout is the hard part. Policies written too broadly, such as “any email from the identity provider”, defeat the point; policies written too narrowly generate a support queue that ends the project.
We map identity, device posture, and connectivity before introducing new controls, then introduce them in rings.
What you get
01
An application and access dependency map: applications, protocols, users, devices, networks, and the identity provider, with an owner for each.
02
Connectivity design: Cloudflare Tunnel for outbound-only connections to private applications, private network routes where they are needed, and a clear view of where site-to-site connectivity fits instead.
03
Policy design: least-privilege Access policies, identity-provider integration, device-posture requirements, Gateway DNS and HTTP policies, and a default block for private networks, because enrolled devices can otherwise reach everything behind a tunnel.
04
Client rollout: Cloudflare One Client deployment through your device-management tooling, split tunnels and local-domain fallback, and coexistence with the old VPN client during the transition.
05
A pilot plan with rings, exit criteria, and a rollback for each ring.
06
Runbooks: exception handling, break-glass access, and a support guide for your help desk.
How it works
Architecture
Inventory the applications behind the VPN and what each needs: protocol, user group, device requirement, and data sensitivity. Decide which applications move first, and identify what must stay on network-layer connectivity.
Onboarding
Connect the identity provider, define device requirements, create the first Access applications and policies, and deploy the client to the pilot ring.
Migration
The pilot ladder: IT first, then one low-risk application with volunteers, then a department, then everyone. Each ring has exit criteria and a rollback, and the VPN keeps running until the last group has moved.
Support
Review access logs and posture results, tune policies from evidence, retire the old VPN, and keep the runbook current.
Limits
The scope is architecture, rollout, and engineering. This service does not include security operations, round-the-clock monitoring, penetration testing, or compliance certification. Some Cloudflare features depend on the plan; for example, Cloudflare documents Cloudflare WAN as an Enterprise product, and plan limits are stated in the design. Zero Trust can help meet access-control requirements such as those in the EU’s NIS2 Directive, but the Directive does not require Zero Trust by name, and nothing here is legal advice.
Questions
What is the difference between ZTNA and a VPN?
A VPN extends a network to a device: once connected, the device can reach whatever the network rules allow. Zero trust network access (ZTNA) grants a user access to a specific application after checking identity, device, and context. Use ZTNA for application access, keep network-layer connectivity where protocols or sites need it, and run both during the migration.
Is Cloudflare WARP the same as the Cloudflare One Client?
Yes. Cloudflare’s documentation now calls the client “Cloudflare One Client (formerly WARP)”, and the warp-cli command still carries the old name. The client sends device traffic to Cloudflare and reports device posture for Access and Gateway policies. This site uses the current name and mentions the old one so older guides still make sense.
How do you pilot an access rollout?
In rings. IT goes first, then one low-risk application with volunteers, then a department, then everyone. Each ring has exit criteria and a rollback, and the old VPN keeps running until the last group has moved. A small pilot finds the exceptions while they are still cheap to fix, before they reach the help desk.
Can the new client run alongside our existing VPN?
Yes, during the transition. Cloudflare documents how to run the client next to a legacy VPN: split tunnels so each client handles its own traffic, one product in charge of DNS, and testing whenever the VPN software updates. The combination is tested on the pilot ring first, and the plan records when each group’s old client is removed.
Do you work with Check Point and other firewall vendors?
Yes. Zero Trust rarely replaces everything at once, so the design covers how Access and Gateway coexist with existing firewalls from Fortinet, Palo Alto Networks, Cisco, and Check Point, and which firewall rules can be retired as applications move. Policy intent is written down once, so a later change of vendor does not mean starting over.
What happens if the identity provider is down?
The runbook plans for it before rollout. It defines a break-glass path to the applications that matter most, who may use it, how its use is logged, and when it is reviewed. Failure modes are written down and tested during the pilot, not discovered during an outage. The runbook also names who may approve an exception and for how long.