A lost laptop is only a data breach if the drive isn't encrypted. Full-disk encryption is what turns a stolen device into a useless brick instead of a spreadsheet of customer records. An MDM lets you enforce it centrally: it switches on FileVault on Mac, BitLocker on Windows, escrows the recovery key so a locked-out user isn't a lost machine, and reports which devices are actually encrypted rather than assumed to be.
Doing this by hand across a mixed fleet doesn't scale. Here's how disk encryption via MDM works on each platform, and the one step most teams skip.
What does enforcing disk encryption with an MDM actually do?
It pushes a configuration profile that requires encryption, then verifies the result. The MDM doesn't encrypt the drive itself. It tells the operating system to do it, collects proof, and flags anything that falls out of line.
Three things happen. The MDM turns encryption on (or blocks the user from turning it off). It captures the recovery key and stores it server-side. And it surfaces a compliance state you can act on: encrypted, not encrypted, or key not escrowed yet. That last state matters more than it looks, and we'll come back to it.
How do you enforce FileVault on macOS?
You send a FileVault payload in a configuration profile. On enrollment, the Mac either encrypts at the next login or forces the user to enable it, and you can allow a set number of deferrals before it becomes mandatory. Set that to zero for high-risk roles and the user encrypts before they reach the desktop.
On Apple silicon and T2 Macs, the data is already encrypted at the hardware level. Enabling FileVault doesn't re-encrypt the whole disk overnight the way it did on older spinning drives. It binds the encryption to the user's password, so the drive is worthless without credentials. That means enforcement is close to instant, not a two-hour job that kills a workday.
FileVault uses XTS-AES-128 encryption with a 256-bit key. When it activates, macOS generates a personal recovery key and shows it to the user exactly once. If that key isn't captured somewhere central, it's gone. Which is the whole reason escrow exists.
How do you enforce BitLocker on Windows?
Windows uses BitLocker, and the MDM drives it through the BitLocker configuration service provider (CSP). You set the encryption method (XTS-AES 256 is the sensible default on modern hardware), require encryption of the OS drive and fixed data drives, and decide whether to allow the machine to sit unencrypted while a user finishes setup.
BitLocker leans on a Trusted Platform Module to hold its keys, and it works cleanly with TPM 2.0, which ships on essentially every business laptop sold in the last several years. Older machines without a TPM can still encrypt, but you'll have to allow a startup PIN or USB key, and that's friction your help desk will feel.
The recovery key here is a 48-digit numerical password. Same principle as macOS: if it isn't escrowed, a forgotten PIN or a TPM reset after a firmware update can lock a user out of their own machine permanently.
What about iPhone, iPad, and Android?
These are the easy ones. iOS and iPadOS encrypt storage by default the moment a passcode is set, using hardware-backed file-level encryption tied to the Secure Enclave. Android has done file-based encryption by default since Android 10. You don't switch encryption on with a profile the way you do on a laptop.
What you enforce instead is the passcode policy that unlocks it: minimum length, complexity, auto-lock timeout. No passcode, no meaningful encryption. So on mobile, disk encryption via MDM is really passcode enforcement plus a check that the device reports as encrypted and not jailbroken or rooted.
Recovery key escrow: the step teams skip
Turning encryption on is the part everyone gets right. Storing the recovery key is the part that bites six months later.
Picture a finance manager who forgets her Mac password after a long holiday, or a Windows laptop that prompts for a BitLocker key after a BIOS update nobody scheduled. Without an escrowed key, that device is a paperweight and the data on it is unrecoverable. With escrow, an admin pulls the key from the MDM and the user is working again in five minutes.
So the real definition of "done" isn't encryption enabled. It's encryption enabled and the recovery key confirmed in escrow. Treat a device as non-compliant until both are true. If your tooling reports encryption status but not escrow status, you have a blind spot that will surface at the worst possible moment.
How do you turn encryption into a compliance signal?
Auditors don't want a policy document that says drives should be encrypted. They want evidence that they are, on which machines, right now. An MDM gives you that: a live inventory of encryption state across macOS and Windows, with the gaps named.
Wire that state into your access rules. A device that isn't encrypted, or whose key isn't escrowed, shouldn't reach email or internal apps until it's fixed. This is the difference between encryption as a checkbox and encryption as an enforced control, which is what frameworks like SOC 2, ISO 27001, and HIPAA actually ask for. For the mechanics of gating access on device state, see our guide to conditional access and device compliance.
One console for a mixed fleet
Most teams don't run only Macs or only Windows. They run both, plus a pile of phones. Managing FileVault in one tool, BitLocker in another, and passcode policy in a third is how devices slip through unencrypted. A cross-platform MDM like Appaloosa enforces encryption and escrows keys for macOS, Windows, iOS, and Android from a single console, so "is every device encrypted?" is a question you can answer in one screen instead of three.
Start with your highest-risk group, set deferrals to zero, confirm keys are landing in escrow, then widen the policy. If you're mapping out broader device controls first, our primer on endpoint management covers where encryption fits alongside patching and app control.