Part 14 built out the access control layer: applications locked behind identity-aware policies, short-lived certificates replacing static credentials, and SSH and browser-based access running through Cloudflare's edge without a traditional VPN in sight. If you followed that part closely, you now have applications that only the right people can reach. That's real progress. But here's the problem: controlling who gets in says nothing about the condition of the device they're using to get there.
A user with valid credentials on an unencrypted, unpatched laptop sitting on open airport Wi-Fi is still a threat vector. Identity verification alone doesn't close that gap. Endpoint control does.
This part covers the tools Cloudflare provides to extend Zero Trust from the application layer down to the device itself: the WARP client, Cloudflare Gateway, and device posture checks. By the end, you'll know how to enroll devices into your Zero Trust organization, filter DNS queries through Cloudflare's threat intelligence, inspect HTTP and HTTPS traffic at the application layer, and gate access based on verifiable device health signals.
Why Endpoint Control Is the Missing Piece of Zero Trust
The perimeter is dead. And your devices are the new edge
For a long time, network security operated on a simple assumption: if traffic came from inside the corporate network, it was probably fine. Firewalls guarded the boundary. VPNs extended that boundary to remote workers by creating an encrypted tunnel back to headquarters. Once you were inside the tunnel, you were trusted. The tunnel was the credential.
That model made sense when everyone worked from the same building and "the network" was a physical thing with walls around it. It doesn't make sense when your team is split across home offices, coffee shops, hotel lobbies, and co-working spaces in three time zones.
The failure mode of perimeter security isn't theoretical. When a device connects through a VPN, it inherits whatever trust level the tunnel carries. If that device is compromised, the tunnel becomes a direct path into your infrastructure. Lateral movement becomes trivial. The attacker is already "inside."
Zero Trust inverts this. No device is trusted by default, regardless of where it connects from. Trust is earned continuously, based on verified identity and verified device state.
What 'device trust' actually means in practice
Device trust is the practice of evaluating a device's health and configuration before granting it access to resources, and continuing to evaluate it during the session. It's not a one-time check at login. It's an ongoing signal.
In a Cloudflare Zero Trust deployment, device trust comes from three interlocking layers. The WARP client routes device traffic through Cloudflare's edge and ties the device to an enrolled identity. Cloudflare Gateway filters that traffic against threat intelligence and policy rules. Device posture checks verify specific health signals: Is disk encryption enabled? Is the OS patched? Is an endpoint detection agent running?
Legacy VPN models trusted the tunnel. Zero Trust models trust nothing until identity and device state are both verified. That distinction sounds subtle. In practice, it's the difference between a security posture and a security theater.
This part walks through all three layers in sequence: enrolling devices with WARP, applying Gateway DNS and HTTP policies, and enforcing posture checks that make device health a hard requirement for access.
Understanding the Cloudflare WARP Client
WARP modes: Consumer vs. Zero Trust
WARP started as a consumer product. If you've used the 1.1.1.1 app on your phone, you've used WARP. It routes your device traffic through Cloudflare's network, improving privacy and performance. That's the consumer version, and it has nothing to do with organizational control.
WARP for Zero Trust is a different deployment model entirely. When a device enrolls in your Zero Trust organization, WARP becomes the enforcement point for every Gateway policy you configure. The client is the same underlying technology: a WireGuard-based tunnel that routes traffic through Cloudflare's global edge. The difference is what happens to that traffic once it arrives.
There are three WARP modes to understand before you start deploying:
WARP mode is the default for most Zero Trust deployments. All device traffic routes through Cloudflare's edge, where Gateway policies apply. This is what you want for general endpoint protection.
Proxy mode routes only specific applications through WARP rather than all traffic. Useful when you need selective inspection without touching the full network stack, or when full tunnel routing conflicts with existing infrastructure.
Tunnel-only mode establishes the tunnel connection without applying Gateway filtering. This is primarily useful for routing traffic to private networks via Cloudflare Tunnel without enabling the full inspection stack.
Choosing the right mode
For most organizations starting with Zero Trust, WARP mode is the right default. Proxy mode is worth considering if you have legacy applications that behave poorly when all traffic is tunneled. Tunnel-only mode is a niche configuration; don't reach for it unless you have a specific architectural reason.
How WARP routes traffic through Cloudflare's global network
When WARP is active on an enrolled device, it establishes a WireGuard tunnel to the nearest Cloudflare edge location. DNS queries go to Cloudflare Gateway instead of the device's configured resolver. HTTP and HTTPS traffic passes through Gateway's inspection engine. The device's public IP appears as a Cloudflare IP, which also means your Gateway logs show the enrolled user identity rather than an anonymous address.
This architecture means policy enforcement happens at the network level, not on the device itself. You don't need agents running complex local inspection logic. The edge does the work.
Supported platforms and deployment options
WARP supports Windows, macOS, Linux, iOS, and Android. Coverage is broad enough that most organizations can achieve full fleet enrollment without carving out exceptions.
Deployment options split into two categories. Manual enrollment works for small teams: a user opens the WARP client, enters your organization's team name, authenticates through your identity provider, and the device is enrolled. It takes about two minutes.
MDM deployment is the right answer at scale. Using tools like Jamf, Intune, or any MDM platform that supports configuration profiles, you can pre-configure the WARP client with your organization's settings, push it to devices silently, and enforce enrollment without any user action. MDM deployment also lets you lock the WARP client so users can't disconnect it or switch modes.
Enrollment ties the device to a specific identity from your connected identity provider. That linkage is what makes posture checks and user-specific policies possible. Without it, you have a tunnel. With it, you have an identity-aware endpoint.
Enrolling Devices into Your Zero Trust Organization
Creating an enrollment policy in the Zero Trust dashboard
Enrollment doesn't happen automatically when someone installs the WARP client. You control exactly who can enroll and under what conditions through an enrollment policy in the Zero Trust dashboard.
Navigate to Settings > WARP Client > Device enrollment permissions. This is where you define which identity providers are valid for enrollment and what criteria a user must meet. You can restrict enrollment to specific email domains, specific identity provider groups, or combinations of both.
A typical policy for a company using Okta might require that the user authenticates through Okta and belongs to the "Employees" group. Contractors using personal email addresses would fail the enrollment check and be turned away before the tunnel is established.
Authenticating users during WARP enrollment
When a user opens the WARP client and enters your organization's team domain, the client redirects them to your identity provider's login page. This is the same authentication flow used by Cloudflare Access. If you've already configured an identity provider in Part 13, it's available for WARP enrollment without additional setup.
After successful authentication, the WARP client installs a device certificate and establishes the WireGuard tunnel. The certificate ties the device to the authenticated user identity. This certificate is what Gateway and Access policies reference when evaluating device-level rules.
One thing worth understanding: enrollment is per-user, per-device. If the same user enrolls from their work laptop and their personal iPad, both devices appear separately in your dashboard with distinct identities. That granularity matters when you're writing posture policies that should apply differently to managed versus unmanaged devices.
Verifying enrollment status
The My Team > Devices section of the Zero Trust dashboard shows every enrolled device in your organization. Each entry includes the device name, operating system, the user it's enrolled under, the last-seen timestamp, and the serial number.
Serial number visibility is particularly useful for MDM-managed fleets. You can cross-reference your MDM inventory against the Cloudflare device list to confirm that every managed device is enrolled and that no unmanaged devices have slipped through.
Revoking enrollment is straightforward: select the device in the dashboard and revoke it. The active tunnel terminates within seconds. If that user is mid-session through a Gateway-protected application, the session ends. There's no grace period, which is exactly what you want when a device is lost or an employee is offboarded.
Gateway DNS Filtering: Your First Line of Defense
How Gateway intercepts DNS queries from enrolled devices
Every DNS query from an enrolled WARP device goes to Cloudflare Gateway rather than whatever resolver the device's network would normally use. This happens automatically once WARP is active. The user doesn't configure anything. The device's DNS settings don't change visibly. But every name resolution request is now passing through a policy engine before it gets answered.
Gateway supports both DNS-over-HTTPS and DNS-over-TLS for enrolled devices, which means queries are encrypted in transit and can't be intercepted or manipulated by whatever network the device happens to be on. This matters on untrusted networks like public Wi-Fi, where DNS hijacking is a realistic threat.
DNS filtering operates at the resolution layer. When a device tries to reach a malicious domain, Gateway returns a block response before any connection is established. No packet reaches the destination. The attack surface is the DNS query itself, which is orders of magnitude cheaper to intercept than full HTTP traffic.
Built-in threat intelligence categories
Cloudflare maintains a continuously updated threat intelligence feed that categorizes domains by threat type. The categories relevant to most security policies include Malware, Phishing, Command and Control, Botnet, Cryptomining, and DNS Tunneling.
These categories are available as selectors in the Gateway DNS policy builder without any configuration on your part. Cloudflare's threat intelligence team updates the underlying domain lists continuously. You don't manage the list. You just decide which categories to act on.
Beyond threat categories, Gateway also provides content categories for filtering by topic: social media, gambling, adult content, and dozens of others. These are useful for compliance-driven organizations but aren't the focus here.
Creating your first DNS policy
DNS policies live under Gateway > Firewall Policies > DNS in the Zero Trust dashboard. Each policy consists of one or more rules built from selectors, operators, and actions.
A baseline policy for any organization looks like this: create a rule where the Security Category selector matches Malware and Phishing, set the action to Block, and apply it to all enrolled devices. That single rule stops a significant percentage of commodity threats before they have any chance to execute.
The policy builder uses a logical AND/OR structure for multiple conditions. You can create rules that apply only to specific user groups, specific device types, or specific times of day. A policy that blocks social media during business hours for non-IT staff is four selectors and two minutes of configuration.
DNS filtering is fast and cheap to enforce. It's also limited: it works at the domain level, not the URL level. A malicious page hosted on a legitimate domain like a compromised GitHub Pages site won't be caught by DNS filtering alone. That's where HTTP inspection picks up.
Secure Web Gateway: Inspecting HTTP and HTTPS Traffic
Enabling TLS inspection on enrolled devices
DNS filtering catches requests to known-bad domains. A Secure Web Gateway goes further: it inspects the actual content of HTTP and HTTPS requests, including full URLs, request headers, file types, and response content. The difference matters because a significant portion of modern threats operate over legitimate domains with valid TLS certificates.
To inspect HTTPS traffic, Gateway needs to act as a trusted intermediary. It decrypts the TLS connection from the device, inspects the content, re-encrypts it, and forwards it to the destination. This is TLS inspection, and it requires installing the Cloudflare root certificate on enrolled devices so the device trusts Gateway's re-signed certificates.
Via MDM, certificate installation is silent and automatic. You export the Cloudflare certificate from the Zero Trust dashboard under Settings > WARP Client > Install WARP Certificate, push it through your MDM as a trusted root certificate, and every managed device trusts Gateway's inspection without user interaction. Manual installation is also possible for individual devices, but it's not practical at scale.
Certificate pinning exceptions
Some applications, particularly banking apps and certain enterprise software, use certificate pinning. They verify the exact certificate the server presents and reject anything else, including Gateway's re-signed certificates. Add these applications to your Do Not Inspect list to prevent broken connections. Cloudflare maintains a default list of known pinned applications, but you'll likely need to add a few specific to your environment.
HTTP policy rules and selectors
HTTP policies in Gateway operate on a richer set of selectors than DNS policies. You can match on domain, full URL, application (Cloudflare maintains an application intelligence database covering thousands of SaaS apps), content category, file type, HTTP method, and MIME type.
Actions available in HTTP policies include Block, Allow, Isolate (route to Cloudflare's browser isolation), and Do Not Inspect. The combination of selectors and actions covers most real-world policy requirements.
Blocking risky destinations beyond DNS
A practical example of where HTTP policies add value beyond DNS: blocking file downloads from uncategorized sites. Create an HTTP policy where the content category is Uncategorized, the HTTP method is GET, and the file type matches executable types like .exe, .msi, or .dmg. Set the action to Block. This stops drive-by downloads from sites that haven't been categorized yet, which is exactly the kind of site an attacker would use for payload delivery.
Application-level controls are another place where HTTP policies earn their keep. You can allow access to Google Drive while blocking personal Gmail by writing policies at the application feature level rather than the domain level. Both services share Google's domains, but Gateway's application intelligence distinguishes between them. A user can access their work Drive and be blocked from sending personal email, all without touching their Google account settings.
The Do Not Inspect list deserves a final note. It's not a bypass for convenience. It's a deliberate exception for applications that break under TLS inspection. Keep the list short, document every entry, and review it quarterly. Every entry is a gap in your inspection coverage
Building User and Device Policies That Scale
Gateway policies aren't a flat list of rules applied equally to everyone. They're an ordered stack, evaluated top to bottom, and the first matching rule wins. That architecture gives you real flexibility. It also gives you real ways to shoot yourself in the foot if you don't think through the order carefully.
Segmenting Policies by User Group and Device Type
The cleanest way to build a policy stack is in three layers. Start with a base policy that applies to every authenticated user: block malware, phishing, and cryptomining categories, and allow everything else. That's your floor. On top of that, create group-specific policies scoped to identity provider groups. Your Finance team gets an additional block on personal file storage and social media during work hours. Your contractors get a stricter policy that isolates all uncategorized sites rather than allowing them through. Your IT admins get an override policy near the top of the stack that bypasses certain inspection rules so their security tooling doesn't break.
Device scoping adds another dimension. Gateway lets you target policies by operating system, so a rule that blocks executable downloads can apply only to Windows endpoints while leaving macOS developer machines untouched. For environments with strict asset management, you can scope policies to specific device serial number ranges, which is useful when you want pilot policies to hit only your test fleet before rolling to production.
Policy Priority and Evaluation Order
Priority numbers in Gateway run from lowest to highest, and lower numbers evaluate first. Put your most specific, restrictive rules at the top with low priority numbers. Put broad allow rules at the bottom. If your contractor isolation rule sits below a broad "allow all authenticated users" rule, it never fires. That's a common misconfiguration and it's silent: everything appears to work, contractors just aren't getting the treatment you intended.
The Allow, Block, Isolate, and Do Not Inspect actions each serve a distinct purpose. Use Block for categories you never want to reach the endpoint. Use Isolate for sites you want to permit but not trust fully, rendering them in a remote browser. Use Do Not Inspect for traffic that breaks under TLS inspection, like banking apps or certain SaaS tools with certificate pinning. Use Allow explicitly when you need to override a broader block for a specific group.
Avoiding Common Policy Conflicts
Watch Out: Internal Domain Breakage
One of the most common Gateway rollout problems is forgetting to add internal domains and private DNS zones to a Do Not Inspect or Allow rule. If your internal tooling resolves through split DNS and Gateway intercepts those queries, things break in ways that are hard to trace back to the policy.
Before pushing any new policy to your full user base, test it against a pilot group of five to ten users. Check the Gateway activity log for unexpected blocks during the first 24 hours. Look specifically for tools your team uses daily: password managers, developer APIs, internal dashboards. Fix conflicts before they become a helpdesk queue.
Protecting Remote Workers: A Real-World Scenario
Some problems look like technology problems but are really architecture problems. A hub-and-spoke VPN built for 40 office workers doesn't scale to 200 remote employees across a dozen countries. The latency alone makes it painful. The single point of failure makes it dangerous. And the operational overhead of managing VPN clients, certificates, and concentrators makes it expensive. This scenario walks through how WARP and Gateway replace that architecture with something that actually fits how distributed teams work.
Scenario Setup: 200 Remote Employees Across 12 Countries
The company in this scenario has 200 employees working from home offices, coworking spaces, and hotel rooms across 12 countries. They previously connected through a VPN concentrator in a US-based data center. Employees in Singapore and Berlin were seeing 180ms to 300ms latency on internal tools. Helpdesk tickets about VPN disconnects were a weekly occurrence. The security team had no visibility into what those endpoints were doing when the VPN wasn't connected, which was most of the time.
The replacement architecture deploys WARP via MDM, enforces enrollment through a policy scoped to the company email domain, and enables Gateway DNS and HTTP inspection for all enrolled devices.
Applying WARP + Gateway to Replace a Legacy VPN
The DNS policy stack blocks four categories by default: malware, phishing, cryptomining, and adult content. Those apply to every enrolled device, everywhere, regardless of what network the employee is on. HTTP inspection adds two more rules: block file uploads to personal cloud storage destinations like personal Dropbox or Google Drive accounts, and isolate any uncategorized site rather than allowing it through uninspected.
Split tunneling is configured to send internal SaaS traffic through Gateway while excluding video conferencing tools from inspection entirely. A 90-minute all-hands call shouldn't be routed through a filtering layer. Performance-sensitive traffic gets a free path.
What the Employee Experience Looks Like
Employees don't interact with WARP directly. It installs via MDM, enrolls automatically, and runs in the background. There's no connect button, no disconnect button, no certificate prompts. The employee in Singapore connects to internal tools and sees latency around 40ms because WARP routes through Cloudflare's Singapore point of presence rather than backhauling to the US. That's not a small improvement. It's the difference between a tool people use and a tool people avoid.
Logging, Visibility, and Incident Response with Gateway
Filtering traffic without logging it is just hoping for the best. The Gateway activity log is where enforcement becomes evidence. Every DNS query, every HTTP request, every blocked event gets attributed to a specific user and device. That attribution is what makes incident response possible instead of just incident guessing.
What Gateway Logs and Where to Find Them
The Zero Trust dashboard surfaces Gateway logs under the Logs section, split between DNS queries and HTTP requests. Each entry includes the timestamp, the user identity, the device ID, the queried domain or requested URL, the policy that matched, and the action taken. You can filter by any of those fields. Looking for everything a specific device did in the last six hours is four clicks. Looking for every blocked event across your entire fleet in the last 24 hours is the same.
Log retention defaults to 30 days for most plans. If your compliance requirements need longer retention, the right answer is to export rather than extend in-dashboard storage.
Privacy Consideration: Tell Employees What You Log
Monitoring employee traffic is a legitimate security practice. It's also something employees have a right to know about. Document your logging policy, include it in your acceptable use policy, and be specific about what's captured. DNS query logs and HTTP request logs contain behavioral data. Treat them accordingly.
Exporting Logs to a SIEM
Logpush handles log export. Supported destinations include Splunk, Datadog, Amazon S3, Cloudflare R2, and several others. Configure a Logpush job in the Zero Trust dashboard, select the Gateway DNS or HTTP dataset, choose your destination, and set the frequency. Logs arrive in your SIEM with user and device attribution intact, which means your existing detection rules can reference Cloudflare events alongside everything else.
Using Logs to Investigate a Blocked Event
Here's a concrete example. A device starts making DNS queries to a domain flagged as a known command-and-control address. Gateway blocks the queries and logs them. In the dashboard, you filter DNS logs by that domain and see 47 queries from a single device over 20 minutes. You pull the device ID, cross-reference it with your MDM inventory, identify the employee, and escalate to your security team. The device gets isolated. The investigation starts with a timestamp, a user, and a query log rather than a vague report that "something seemed wrong."
That's what visibility actually means in practice. Not dashboards for dashboards' sake, but attribution that makes the next step obvious.
Requiring an Enrolled Device for Application Access
A valid identity is not enough. That's the core premise of device-aware access control, and it's the premise that makes Zero Trust more than a rebranded VPN. If a credential gets phished, an attacker with that credential and an unenrolled device should hit a wall. WARP enrollment as an Access policy requirement is how you build that wall.
Combining WARP Enrollment with Access Application Policies
Every application protected by Cloudflare Access has a policy that defines who can reach it. That policy evaluates identity by default: the user authenticates through your identity provider, the claim matches the rule, access is granted. Adding a WARP enrollment requirement changes the evaluation to include device state. The user must be authenticated and on an enrolled, WARP-connected device. Both conditions must be true simultaneously.
Adding the rule takes about two minutes in the Access application policy editor. Add a new require rule, select "WARP" or "Device Enrolled" from the selector list, and save. The policy now enforces both conditions on every request.
The 'Require Enrolled Device' Rule in Practice
When an unenrolled device attempts to reach the application, it hits a block page. That page is customizable: you can add your IT helpdesk contact, instructions for enrolling WARP, or a link to your MDM enrollment portal. The user isn't left staring at a generic error. The attacker with a phished credential is stopped before they see anything useful.
For environments where WARP enrollment isn't sufficient, client certificate posture checks add another layer. The enrolled device must present a certificate issued by your organization's CA. That check survives credential theft and survives device enrollment spoofing attempts, because the certificate has to be present on the physical machine.
"Before this policy, a phished password was a breach. After it, a phished password is an inconvenience to the attacker and a logged event for us."
Handling Exceptions and Break-Glass Scenarios
Executives lose laptops. Devices get wiped unexpectedly. Someone needs access to a critical application from a borrowed machine during an incident. Break-glass access needs a process that doesn't involve disabling your security policy for everyone.
The right pattern is a time-limited bypass: a temporary Access policy that grants a specific user access for a defined window, logged explicitly, reviewed after the fact. Create the bypass rule, set an expiration, document the reason, and remove it when the window closes. That process satisfies the spirit of SOC 2 and ISO 27001 requirements around managed device access while acknowledging that real environments have real emergencies.
Part 15 Action Checklist: Lock Down Your Endpoints Today
Part 15 covered a lot of ground. This checklist turns it into action. Some of these take under an hour. Some require coordination with your MDM team or security stakeholders. All of them move your environment closer to a posture where device health is part of every access decision.
Quick Wins You Can Implement in Under an Hour
Longer-Term Hardening Tasks
What's Next: Cloudflare Browser Isolation and Advanced Threat Protection
Where WARP and Gateway Leave Off
Part 15 built the device layer of your Zero Trust architecture. WARP enrollment puts devices under management. Gateway DNS filtering stops threats before they resolve. HTTP inspection adds content-aware controls. Device posture checks tie policy enforcement to actual device health. Logging and Logpush give you the visibility to investigate when something goes wrong. That's a complete foundation, and it's one that satisfies most of what auditors mean when they ask about endpoint security controls.
But there's a category of threat that DNS and HTTP filtering don't fully address: the browser itself. A user visits a legitimate-looking site that serves a zero-day exploit targeting the browser engine. The domain wasn't on any block list. The certificate was valid. Gateway allowed it through. The exploit runs.
Preview of Part 16
Part 16 covers Cloudflare Browser Isolation, which addresses that problem by rendering web content remotely on Cloudflare's infrastructure and streaming only a visual representation to the user's device. The browser runs in Cloudflare's network, not on the endpoint. A zero-day in the browser engine fires in an isolated container that gets discarded after the session. Nothing executes locally.
Browser Isolation integrates directly with the Gateway HTTP policies you configured in this part. The Isolate action you saw in the policy builder is the entry point. Part 16 goes deep on how to configure it, when to apply it broadly versus selectively, and how to tune it so users don't notice the difference in normal browsing.
Before moving on, run the WARP client diagnostics on your test device and check the Gateway activity log for at least one full day of traffic. Confirm your policies are matching the way you intended.
