← Back to all posts
Endpoint 7 min

Zero Trust BYOD on macOS Without Owning the Device

Designing a BYOD enrollment path that enforces device posture — OS version, disk encryption, screen lock — without requiring full MDM ownership. The Headway approach.

At Headway, we were scaling fast — a cloud-first healthcare platform onboarding new engineers and clinicians every sprint. That growth created a problem I kept running into: people showing up with personal Macs and needing access to production systems on day one.

The security team’s instinct was full MDM enrollment. Lock down the device, push compliance profiles, call it done. But this was a healthcare company. HIPAA was real, and so was the workforce reality — a lot of these folks were contractors or hybrid employees who weren’t going to hand over full control of a laptop they also used for personal stuff. If we forced full enrollment, we’d either lose good people or they’d find workarounds. Neither outcome was acceptable.

The Actual Problem

The question wasn’t “should we allow BYOD?” — that was already happening whether we had a policy or not. The question was: how do we get meaningful security guarantees from a device we don’t own?

Full MDM gives you the ability to wipe a device, inspect installed apps, push configuration profiles, and enforce restrictions. That’s great for company-owned hardware. But on a personal Mac, most of those capabilities are either inappropriate or a legal gray area. We needed to verify the device was safe to use without treating it like company property.

What We Built

We went with a lightweight agent approach instead of full MDM enrollment. The agent runs locally on the device and checks four posture signals:

  • OS version — is the Mac running a supported, patched version of macOS?
  • FileVault — is disk encryption enabled?
  • Screen lock — is the screen lock timeout set to 5 minutes or less?
  • Passcode — does the device require a password to unlock?

That’s it. No remote wipe capability, no app inventory, no browsing history. The agent reports compliance status — pass or fail on each signal — and that data feeds into our conditional access policies in Okta.

Tiered Access Based on Device Compliance

This is where it gets practical. Not every app needs the same level of device trust. We set up two tiers:

High-risk apps — anything touching PHI, source code repositories, admin consoles, cloud infrastructure. These required a fully compliant device. If your FileVault wasn’t on or your OS was out of date, you were blocked. No exceptions, no grace period for these.

Low-risk apps — Slack, Notion, Zoom, general collaboration tools. These were accessible from any device with MFA. If someone needed to jump into Slack from their iPad at a coffee shop, that was fine. The risk profile didn’t justify blocking them.

This tiered model was the key to getting buy-in from both security and the broader team. Security got hard enforcement where it mattered. Employees didn’t feel like they were being punished for using their own hardware.

Self-Service Enrollment

I wasn’t going to build this and then become a bottleneck for every new hire who needed to enroll. The enrollment flow had to be self-service.

I built a portal that walked users through each posture requirement step by step — enable FileVault, set your screen lock, check your OS version. Each step had a “check again” button so people could verify compliance in real time without filing a ticket or waiting on IT. Once all checks passed, enrollment triggered automatic group assignment in Okta, which unlocked the appropriate conditional access tier.

The self-service piece ended up being one of the bigger wins. It tied directly into the broader self-service access work I was doing at Headway — we cut IT support tickets by 65% within four months, and a significant chunk of that reduction came from people being able to resolve their own device compliance issues without ever contacting us.

What I’d Change Next Time

The posture-checking model works, but it has a known gap: the signals are self-reported by the agent. In theory, someone could tamper with or spoof the compliance data. In practice, the risk is low for an internal workforce — but it’s not zero.

The next evolution is device trust attestation. Instead of just checking whether FileVault is on, attestation cryptographically proves the device’s identity and integrity. It’s a hardware-rooted trust signal that’s much harder to fake. That’s where the industry is heading — Apple’s Managed Device Attestation is built for exactly this — and it’s the right long-term investment for any organization that takes BYOD seriously.

The other thing I’d revisit is the posture check frequency. We ran checks at enrollment and on a periodic schedule, but continuous posture evaluation — re-checking compliance every time someone accesses a high-risk app — would close the window where someone could disable FileVault after passing the initial check.

BYODmacOSZero TrustMDMConditional Access
AD

Written by Alex Davenport

alexdavenport.dev