⚙️🍏💻CP - Disk Encryption - FileVault
The macOS answer to the stolen-laptop question. Encrypted at first boot, impossible for the user to switch off, and with a recovery key you can actually produce eighteen months later.
What this policy is about 🔐
FileVault is what stands between a stolen MacBook and everything on it. Apple silicon encrypts the drive at rest whether you ask or not, but without FileVault the keys are available to anything that can boot the machine, which means the protection is real against a bin-diver and irrelevant against anyone who opens the lid.
This policy switches FileVault on during Setup Assistant, before the user has done anything, then locks the switch so it cannot be turned back off. The personal recovery key goes to Intune, where support can retrieve it.
Enabling FileVault during Setup Assistant means the machine is encrypted before the first document exists on it. Enable it later and you get a background conversion on a disk that already holds company data, on a laptop that may well be closed halfway through. Front-load it.
Why this matters 🕵️
The consequence is the same as on Windows and worth repeating because customers ask about it in exactly these terms. An encrypted Mac that walks out of a café is a hardware loss: replace it, close the ticket. An unencrypted one is a personal data breach, and in the Netherlands that starts a clock on a notification to the Autoriteit Persoonsgegevens whether or not anyone ever reads the disk.
The half that goes wrong in practice is not the encryption, it is the key. Macs get encrypted by somebody, at some point, often by the user during setup because Apple asks nicely. What is missing eighteen months later is a recovery key anybody can produce when a firmware update, a logic board swap or a forgotten password puts the machine at a recovery prompt. Escrow is the entire difference between a two-minute lookup and a rebuild.
🛠️ Configuration
Where: Intune admin center → Devices → Configuration → Create → macOS → Settings catalog → Full Disk Encryption → FileVault.
| Setting | Value |
|---|---|
| Enable | On |
| Force Enable In Setup Assistant | True |
| Defer | Enabled |
| Recovery Key Rotation In Months | 6 |
| Prevent FileVault From Being Disabled | True |
| Location (escrow message) | See below |
| Assignment, include | All devices, macOS filter |
Set the escrow Location string to something the user will understand when macOS shows it to them:
You can retrieve the personal recovery key for your macOS device from the Microsoft Intune app, Company Portal website, or Company Portal apps for Android and iOS/iPadOS. Support cannot access recovery keys that belong to personal devices.
Prevent FileVault From Being Disabled is the setting that makes this a control. Without it, FileVault is a suggestion: the user opens System Settings, switches it off, and nothing tells you. With it, the option is greyed out and the machine stays encrypted whatever anyone decides on a Friday afternoon.
Six months on key rotation, not one. Rotation replaces the personal recovery key on a schedule, so a key that leaked or was used once stops being valid. Monthly rotation is defensible for a high-security tenant and is mostly churn for everyone else; six months gets the benefit without the noise. Rotation is client-driven and invisible to the user either way.
Defer plus Force Enable In Setup Assistant work together. Defer holds encryption until the user signs in, and forcing it in Setup Assistant means that sign-in is the very first one. The net effect is encryption starting on a machine with nothing on it yet.
Caveats ⚠️
Escrow only works for enrolled, managed Macs. The recovery key lands in Intune because the device is managed. A personally-owned Mac that was never properly enrolled has a key that lives only on that machine, and no amount of policy will retrieve it afterwards. Worth checking during onboarding rather than during an incident.
Encryption is permanent, the policy is not. Remove the profile and macOS stops enforcing FileVault, but the disk stays encrypted with the key it already has. That is fine, and it is the reason this is not a setting to experiment with on production hardware.
A recovery prompt is FileVault working. Firmware updates and hardware changes can put a Mac at a recovery screen. That is the design, not a fault, and it is precisely when the escrowed key earns back the effort. Make sure the helpdesk knows the path before the first mass macOS upgrade: Intune admin center → Devices → the device → Recovery keys.
Users on macOS are usually local administrators. The MDM profile enforces FileVault regardless of local rights, which is one of the places where macOS management is stronger than people expect. It does not, however, stop a determined admin from wiping and re-enrolling a machine outside your control.
Clean-revert on the profile, in the macOS sense. Removing the configuration profile removes the payload, unlike a Windows registry policy that would sit there afterwards. The macOS baseline needs no inverse policies for this reason.
👥 Assignment scope
Baseline for every managed Mac. Assign to all devices with a macOS platform filter so new enrolments are covered without anybody remembering to add them.
There is no exception group. "This Mac does not need encryption" does not survive the first laptop left on a train.
Worth verifying at tenant takeover: which Macs report as encrypted but have no recovery key in Intune. That combination looks healthy on a dashboard and is exactly the state that leaves you locked out later.
🔗 Related
- ⚙️🍏💻CP - Device Security - Accounts and Login: closes the unauthenticated routes onto the same machine.
- 🧱🪟💻ES - BitLocker: the Windows half of the same story, including the escrow-before-encrypt rule.
- 🚦🟢💻CA - Require Compliant Device 🍏: what encryption buys you at the access layer.
Encrypt during setup, lock the switch, and know where the key lives before the day somebody needs it. 🔐