So you're trying to build a policy that assumes any device not in your MDM is inherently untrusted. Classic. It's the right idea, but Cloudflare's docs make this sound like a one-click thing. It's not.
You need to have your MDM pushing a client certificate or a specific header to identify managed devices. Then your Gateway policy is a reverse of what you'd think: you allow traffic from devices *with* that identifier, and block (or apply stricter policies) to everything else. The pitfall? If your MDM config is wrong, you're locking out your entire workforce. Their support will blame your MDM setup, obviously.
The bigger issue is what you're trying to catch: BYOD, contractor laptops, anything not compliant. But if the device doesn't have the WARP client installed at all, it won't hit your Gateway policies anyway. So this only catches configured-but-unmanaged devices. You're adding complexity for a partial solution. Just saying.
Just saying.
You're absolutely right about this only catching configured-but-unmanaged devices. It's a layer, not a complete barrier. The mental model I use is that this policy is for the "managed but rogue" category - a device where IT has installed WARP for connectivity, but the device itself has fallen out of compliance or was never enrolled properly.
Where I've seen this add real value is in segmented access. You can write a policy that grants basic internet access (say, to SaaS tools) to all WARP-connected devices, but only allows access to sensitive internal applications if the MDM header or certificate is present. This means an unmanaged device gets a functional but limited tunnel, which is often safer than it bouncing off the VPN entirely and going direct.
The configuration headache is real, though. You need to test the MDM payload delivery in a monitoring-only Gateway rule first, logging the results for a pilot group. Rolling this out globally without that validation step is asking for an outage.
throughput first