Enforcing FileVault and Escrowing the Recovery Key

Why This Is the Encryption That Matters

FileVault is full disk encryption for the Mac. With it on, the data at rest on the internal drive is unreadable without either a credentialed user logging in or the recovery key. With it off, anyone who walks away with the machine can pull the drive's contents at their leisure. For any fleet that leaves the building, which is to say nearly all of them, this is the single most consequential security control you can apply.

But turning encryption on is the easy half. The half that actually keeps you employed is making sure the recovery key is captured and stored somewhere you can get to it. A Mac that is encrypted but whose key you do not hold is a Mac you cannot recover when a user forgets their password, leaves the company, or locks themselves out. The encryption is only as useful as your ability to get back in when something goes wrong, so escrow, the act of the device handing its recovery key up to your management system, is the real heart of this whole exercise.

This guide covers both turning FileVault on and getting the key escrowed, in Jamf Pro and in Intune, plus the handful of concepts that quietly determine whether the whole thing works or silently fails.

The Concepts You Have to Get Straight First

Three ideas underpin everything else, and skipping them is why FileVault deployments so often half work.

The first is escrow. When a Mac encrypts, it generates a recovery key. Escrow is the process by which the device encrypts that key against a certificate your MDM holds and reports it back, so the key ends up stored against the device's record in your management console. Without an escrow configuration in place at the moment encryption happens, the key is generated and then effectively lost, because it was never sent anywhere you can retrieve it.

The second is the SecureToken, and on Apple silicon the related Bootstrap Token. On modern Macs, FileVault can only be enabled by a user account that holds a SecureToken, or in the narrow case where no user on the machine holds one yet. A SecureToken is a cryptographic credential tied to a user that grants the authority to manipulate encryption. If your enablement is not happening, a missing SecureToken on the relevant account is one of the most common reasons. The Bootstrap Token, which your MDM can manage, exists largely to help grant SecureTokens smoothly during enrolment, which is why a properly enrolled device usually just works while a hand built one fights you.

The third is that encryption almost never happens the instant you deploy the policy. The sensible and default behaviour is deferred enablement, where the policy waits and triggers encryption at the next login or logout, at which point macOS can capture the user's credentials to authorise it. We will come back to why this is the right default rather than a limitation.

Personal Versus Institutional Recovery Keys

You will be asked to choose a recovery key type. There are two, and for any new deployment the choice is settled now.

A personal recovery key, often abbreviated PRK, is a unique alphanumeric string generated on each machine at the time of encryption and then escrowed to your MDM. Every Mac has its own distinct key.

An institutional recovery key, or IRK, is a single shared key, created ahead of time and installed across machines, so one key can unlock many devices.

For modern fleets, use the personal recovery key. Apple's current guidance and most MDM documentation favour personal recovery keys, and on Apple silicon Macs institutional keys are largely non-functional for the recovery scenarios that made them useful in the first place — Target Disk Mode has been replaced with the more restricted Share Disk mode, and the boot security model is different. The personal recovery key, by contrast, can boot an encrypted Apple silicon Mac directly and works in the recovery environment, and your MDM can escrow it, hide it from the user, and rotate it later. Unless you are dealing with genuinely legacy hardware and have a specific reason to share one key across machines, personal keys are the answer, and most of this guide assumes them.

Deferred Enablement, and Why It Is the Sane Default

It is tempting to want encryption to happen the moment the policy lands. In practice, enabling FileVault requires authorising the encryption against a user who holds a SecureToken, and the clean moment to capture that authority is when the user logs in or out. So both MDMs default to deferring enablement until the next login or logout event rather than forcing it mid session.

This is a feature, not an obstacle. Forcing encryption underneath a working user is disruptive and error prone, whereas catching it at a login boundary is seamless and reliable. You can usually allow the user a number of deferrals, or require it at the very next sign in. A small number of permitted bypasses tends to be the kinder choice for a fleet of real people, while still guaranteeing the machine encrypts within a day or two of the policy arriving.

Setting It Up in Jamf Pro

In Jamf, FileVault is delivered through a configuration profile with a Disk Encryption payload, and the recovery key settings live within it. The profile can only be applied at the computer level.

1. In Jamf Pro, go to Computers, then Configuration Profiles, and choose New.
2. In the General payload, give it a clear name such as "FileVault Encryption and Escrow", and confirm it is set to the computer level.
3. Select the Disk Encryption payload (in some versions this sits under a Security and Privacy grouping) and configure it.
4. Choose to require FileVault, and set the trigger to enable at the next login or logout. This is the deferred enablement described above.
5. For recovery key type, choose the personal (individual) recovery key.
6. Enable Escrow Personal Recovery Key. This is the setting that makes the device report its key back to Jamf. Without it, you encrypt but never capture the key.
7. Leave the encryption method as automatically encrypt and decrypt recovery key. This has Jamf generate and hold the signing certificate it needs to decrypt the escrowed key when you later retrieve it.
8. Set the Escrow Location Description. This text is shown to the user, so write it as a human sentence, for example explaining that their recovery key is being stored securely by IT. The optional Record Number message appears only inside Jamf and is commonly set to the $SERIALNUMBER payload variable. If you use a payload variable, the spelling and capitalisation must be exact, because $SERIALNUMBER works while any other casing is treated as literal text.
9. Go to Scope and, for the first run, scope to a single test machine.
10. Save.

After the profile is scoped, force a check in or wait for the device to collect it, then have the test user log out and back in to trigger encryption.

# Force a check in on a Jamf managed Mac
sudo jamf recon
sudo jamf mdm

Setting It Up in Intune

In Intune, FileVault lives under the endpoint security disk encryption area rather than a custom plist. Note that the older macOS Endpoint Protection template is deprecated for this, so new work should use the disk encryption policy or the settings catalog.

1. In the Intune admin centre, go to Endpoint security, then Disk encryption, and choose Create policy.
2. Set the platform to macOS and select FileVault as the profile.
3. Give it a name such as "macOS FileVault Encryption".
4. Set Enable FileVault to Yes.
5. For recovery key type, choose Personal recovery key.
6. Set the Escrow location description of personal recovery key. As in Jamf, this text is shown to the user, including on the lock screen when they need the key, so write it to guide them. A good example tells them to sign in to the Company Portal website, open Devices, select the device and choose Get recovery key.
7. Consider setting Personal recovery key rotation, anywhere from one to twelve months, so the key regularly regenerates and re-escrows. Six months is a common choice. Left unset, the key does not automatically rotate.
8. Tune the deferral behaviour: how many times a user may bypass the prompt, whether to allow deferral until sign out, and whether to disable the prompt at sign out so it appears at sign in instead. These mirror the deferred enablement idea.
9. On the assignments page, assign to a group containing only your test machine for the first run.
10. Create the policy.

Intune applies this in two stages by design. First it prepares the device for escrow, then once the device is ready to report its key, encryption is allowed to begin. This two stage shape is why you should not panic if encryption does not start the very instant the policy lands.

To nudge an Intune managed Mac to pick up the policy, use the Company Portal app to sync, or run:

sudo profiles renew -type enrollment

Verifying Encryption and That the Key Escrowed

As with any policy, verify at two levels: that the Mac encrypted, and separately that the key made it back to your console. The second is the one people forget, and it is the one that bites.

On the device, check the encryption state directly:

# Overall FileVault status
fdesetup status

# Detailed encryption / decryption progress on the volume
diskutil apfs list

# Which users are enabled for FileVault on this Mac
fdesetup list

# Whether the current user holds a SecureToken (look for ENABLED)
sysadminctl -secureTokenStatus <username>

A healthy result from fdesetup status reports that FileVault is on, and once the volume finishes, that encryption is complete rather than in progress.

Then confirm escrow in your console, which is the authoritative check that you can recover the machine:

In Jamf, open the computer's inventory record and look under Disk Encryption. The personal recovery key should be present there once the device has encrypted and updated its inventory. If the section is empty after encryption, escrow did not succeed and you need to investigate before trusting the machine.

In Intune, you can both check status in aggregate and retrieve an individual key. For the fleet view, go to Devices, then Monitor, then the device encryption status report. To get a specific key, open the device and choose Get recovery key. If the key is shown, escrow worked.

Rotating and Re-Issuing Keys

Recovery keys are not necessarily forever. You will want to rotate one when it has been exposed, when a device changes hands, or simply on a routine schedule as good hygiene.

In Intune, rotation can be automatic if you set the personal recovery key rotation interval in the policy, anywhere from one to twelve months, and the key regenerates and re-escrows on that schedule. You can also rotate manually by selecting Rotate FileVault recovery key on the device record, though manual rotation is available only for corporate devices, not personal ones.

In Jamf, you re-issue a key with a policy using the Disk Encryption payload set to the action of issuing a new recovery key. Under the hood Jamf attempts to use the current valid key, and where that is not available it can fall back to the management account if that account holds a SecureToken. A practical tip is to build a smart group that flags machines whose escrowed key is missing or invalid, so you can target re-issue at exactly the devices that need it rather than the whole fleet.

Troubleshooting and Gotchas

Encryption never starts

The usual cause is that the account being asked to enable FileVault does not hold a SecureToken, so it lacks the authority to turn encryption on. Check with sysadminctl -secureTokenStatus. On Apple silicon this often traces back to Bootstrap Token handling during enrolment, which is another reason a properly enrolled device behaves while a manually built one resists.

Encrypted, but no key in the console

This is the dangerous one, because the machine looks fine until the day you need to get in. It means encryption happened but escrow did not. In Jamf, confirm the escrow setting was enabled in the profile and that the device has run an inventory update since encrypting. In Intune, remember the two stage process and that the device must be able to report the key; an unrotated pre existing key may need a rotation to force a fresh escrow.

The device was already encrypted by the user before you managed it

A Mac a user encrypted themselves has a key your MDM never saw. Both platforms can assume management of an already encrypted device, but it generally requires getting a key escrowed after the fact. In Intune, the user can manually escrow their existing recovery key via the Company Portal website at portal.manage.microsoft.com; this is the intended path for BYOD scenarios and for any Mac encrypted outside the MDM provisioning flow. In Jamf, you typically issue a fresh recovery key via a policy using the Disk Encryption payload. Until escrow has happened by one means or another, treat the device as one you cannot recover. Tools like Netflix's open-source Escrow Buddy can automate the escrow during a migration if you have many devices in this state.

Personal versus corporate device ownership in Intune (and the BYOD case)

This is the single most surprising bit of the Intune FileVault model and worth understanding before you need it. Intune marks every enrolled device as either Corporate or Personal. Administrators can only view and manage recovery keys for devices marked as Corporate. For Personal/BYOD devices, the key is escrowed but admins genuinely cannot see it — this is by design, for user privacy.

What this means in practice:

• For corporate-owned Macs: enrol them as Corporate at the time of enrolment. Admins can view and rotate keys through the device record and the encryption report. This is the normal flow.
• For BYOD/Personal Macs: admins cannot retrieve the key for the user during a lockout. The user must retrieve their own key themselves by signing in to the Company Portal website (portal.manage.microsoft.com), opening their device, and choosing Get recovery key. Communicate this clearly to BYOD users in the escrow location description text, and ideally in onboarding documentation, because the moment they realise they need the key is a bad time to discover the support team cannot help.
• For BYOD Macs already encrypted before enrolment: prompt the user to upload their existing key through the same Company Portal website. There is a specific manual escrow flow for this case — without it, the device is technically encrypted but not under Intune's recovery model at all.

If a device is marked the wrong way at enrolment it is not always trivial to change after the fact, so getting the ownership setting right at enrolment time is worth more attention than it usually gets.

The Jamf Security and Privacy over reach

As noted earlier, driving FileVault through the graphical Security and Privacy grouping can enforce that grouping's other defaults too, potentially locking users out of firewall or other settings you never meant to manage. If you see unexpected restrictions appear alongside encryption, this is a likely culprit.

The Command Reference

Everything from above, collected for quick use on a device.

Checking FileVault and encryption state

# Is FileVault on, and is encryption complete
fdesetup status

# Volume level encryption detail and progress
diskutil apfs list

# Users currently enabled for FileVault
fdesetup list

Checking SecureToken (the usual blocker)

# Look for ENABLED in the output
sysadminctl -secureTokenStatus <username>

Confirming the profile landed

# All MDM delivered profiles and their content
sudo profiles show -all

# Force a check in (Jamf)
sudo jamf recon
sudo jamf mdm

# Force a check in (Intune)
sudo profiles renew -type enrollment

---

Quick-Action Checklist

For when you just need to do it. Each step links back to the section above with the detail and the reasoning, in case you hit something unexpected.

1. Decide your key type. Personal recovery key (why this is settled now). You almost certainly want this.
2. Choose your deferral approach. Deferred enablement at next login or logout (why this is the sane default). Allow a small number of bypasses to be kind to users.
3. Build the profile. In Jamf: Configuration Profiles → New → Disk Encryption payload → require FileVault → personal key → Escrow Personal Recovery Key on. In Intune: Endpoint security → Disk encryption → new policy → FileVault profile → Enable FileVault: Yes, personal recovery key, set escrow location description, optionally set rotation interval.
4. Set the user-facing escrow location text. Users see this on the lock screen when they need the key. Make it tell them where to retrieve it (Company Portal for Intune; your IT helpdesk for Jamf).
5. Confirm device ownership in Intune. For Intune specifically: corporate devices have admin-recoverable keys; BYOD/Personal devices do not. Get this right at enrolment, not after.
6. Scope to one test machine first. Always. Never to a group on the first run.
7. Force a check-in on that test machine and log out / back in to trigger encryption.

   # Jamf
   sudo jamf recon
   sudo jamf mdm
   
   # Intune
   sudo profiles renew -type enrollment

8. Verify on the device. Two-level check: fdesetup status should report encryption on; sysadminctl -secureTokenStatus <user> should report ENABLED on the user account that enabled it.
9. Verify the key escrowed in your console. This is the bit people skip and regret. In Jamf: device record → Disk Encryption → key should be present. In Intune: device record → Get recovery key — works for corporate devices only.
10. Test recovery. Pretend the user forgot their password. Can you get them back in? If yes, you are done. If no, fix it before widening scope.
11. Roll out to the wider fleet only after the previous step succeeded.
12. Plan rotation if you have not already. In Intune, set the rotation interval in the policy (1–12 months; 6 is common). In Jamf, build a smart group for devices missing or with stale keys, and target a re-issue policy at that group.

Closing Thoughts

FileVault rewards the same discipline as any other fleet policy, with one extra emphasis. Turning encryption on is necessary but not sufficient. The thing that protects you is proving, every time, that the recovery key has been escrowed and that you can retrieve it, because an encrypted machine you cannot get back into is its own kind of incident. Use personal recovery keys, lean on deferred enablement rather than fighting it, watch the SecureToken when enablement stalls, and treat the empty key field in your console as the alarm it is. Get those right and disk encryption stops being a thing you hope worked and becomes a thing you can prove.

← All guides