Skip to content
Notifications
Clear all

Guide: Setting up device posture checks for contractor Macbooks, step-by-step.

2 Posts
2 Users
0 Reactions
3 Views
(@eval_engineer_101)
Estimable Member
Joined: 1 week ago
Posts: 87
Topic starter   [#20102]

We're onboarding a team of contractors who will need access to a few internal web apps. They'll be using their own MacBooks (mix of personal and company-issued from other firms), so I want to lock things down with device posture before granting access via Cloudflare Zero Trust.

I've seen the high-level docs, but I'd appreciate a reality check from anyone who has set this up in production. My goal is to ensure the devices have:
* Disk encryption enabled (FileVault)
* A passcode set
* A minimum OS version
* No jailbreaking

How does Cloudflare One's approach compare to something like Jamf or Intune for this specific use case of unmanaged contractor devices? I'm particularly unsure about the deployment step for the Cloudflare WARP client and the posture check settings.

Here's my planned step-by-step—could you point out any gaps?

1. Create a Gateway policy that requires all contractor access to our apps to have a "Passed" device posture check.
2. Set up the specific macOS posture checks in the Zero Trust dashboard.
3. Distribute the WARP client and a unique enrollment token to each contractor. I believe we generate this token in the dashboard?
4. They install WARP, enroll with the token, and the posture checks run.

My main questions:
* Is the enrollment process straightforward for non-technical users? Are we looking at detailed instructions?
* What happens if a check fails? Can we show a remediation page telling them to enable FileVault?
* Once enrolled, do posture checks run continuously, or only at connection time?



   
Quote
(@helenj)
Trusted Member
Joined: 6 days ago
Posts: 65
 

Your plan is solid on the policy side, but I'd pause on step 3. Generating a single token in the dashboard and distributing it manually is fine for a handful of contractors, but it doesn't scale and that token is a shared secret. For a larger or rotating group, you'll want to look at the "Service Auth" enrollment method instead, where each user gets a unique, short-lived token tied to their identity after they've authenticated via your identity provider. It adds a step but is much more secure for a contractor pool.

The big difference from Jamf/Intune here is that you're not managing the device, only verifying its state for access. That's perfect for your use case, but be aware you're reliant on the contractor running WARP and the checks being current at the time of connection. It's a gate, not continuous enforcement.



   
ReplyQuote