FileVault recovery keys not escrowed: fixing Macs migrated to Intune from another MDM

A Mac encrypted before Intune management keeps its original personal recovery key — and Intune never sees it. Escrow only happens at the moment a key is generated, so the fix is a key rotation, not a decrypt/re-encrypt cycle.

The problem

You have migrated a batch of Macs into Microsoft Intune from another MDM — Jamf, Kandji, Mosyle, Workspace ONE, whichever. Enrolment went cleanly, FileVault shows as on, and the compliance column is green. Then a user forgets their password, or a local account breaks, and you open the device in the Intune admin centre to retrieve the FileVault recovery key. There is no key.

Microsoft's own Intune team is candid about this one:

"Getting FileVault recovery keys escrowed back to Intune is one of the biggest challenges when migrating MacOS devices from other MDM providers." — Microsoft Intune Support Team, Microsoft Tech Community blog

The trap is that nothing looks wrong until the precise moment you need the key. Intune's compliance evaluation checks whether the disk is encrypted; it does not check whether Intune holds a retrievable recovery key. A Mac encrypted under its previous MDM — or by the user, manually, before enrolment — sails through compliance while its personal recovery key sits with the old MDM, in a drawer, or nowhere at all. Anyone migrating already-encrypted Macs into Intune hits this, and most discover it during a lockout rather than an audit.

Why it happens

FileVault key escrow is a two-stage mechanism, and the order of the stages is everything.

Stage one: escrow preparation

The MDM delivers a configuration payload (com.apple.security.FDERecoveryKeyEscrow) that tells macOS where to send a recovery key and which certificate to encrypt it with in transit. In Intune this arrives as part of a FileVault disk-encryption policy (Endpoint security > Disk encryption). On its own the payload does nothing visible — it is a standing instruction, not a request.

Stage two: key generation

macOS hands a personal recovery key to the MDM only at the moment the key is created — when FileVault is first enabled, or when the key is explicitly rotated. There is no mechanism for an MDM to read an existing key off a running Mac: Apple designed escrow to capture keys in flight, never at rest. That is a deliberate security property, not an Intune limitation.

Put the two stages together and the migration failure is obvious. A Mac encrypted under its previous MDM generated its personal recovery key long before Intune's escrow instruction existed on the device. The key predates the payload, so it was never sent to Intune — it went to the old MDM at the time, or to the user's screen, or nowhere durable. Meanwhile Intune's compliance check asks "is the disk encrypted?" (true) rather than "do we hold a retrievable key?" (false). Hence the "compliant-ish" state: green in every report until the day someone is locked out.

The fix

No decrypt/re-encrypt cycle is needed. Rotating the personal recovery key is quick, never touches the encrypted data, and — critically — generates a brand-new key, which is exactly the event escrow hooks into. The plan is: get the escrow payload onto the Mac first, then rotate, then prove the key is retrievable.

1. Find the gap before a lockout does. Review FileVault state across the estate with the Intune encryption report (Devices > Monitor > Encryption report), then spot-check migrated Macs by attempting to retrieve a personal recovery key from each device's Recovery keys pane in the admin centre. "Encrypted but no retrievable key" is the population to fix. The definitive test is retrieval, not the compliance column.
2. Deploy the escrow configuration first. Assign a FileVault policy from Endpoint security > Disk encryption (or an equivalent profile carrying the com.apple.security.FDERecoveryKeyEscrow payload) to the affected Macs, and confirm the profile has actually landed on each device before rotating. Rotating before the payload is present mints a new key that, once again, nobody escrows.
3. Rotate the personal recovery key. Two workable routes:
   • Script-driven: push a shell script from Intune that prompts the signed-in user — who must hold a SecureToken — for their password and feeds it to fdesetup changerecovery -personal -inputplist. Travelling Tech Guy's write-up (linked below) includes a tested pattern using an osascript password prompt.
   • User-driven: have users run sudo fdesetup changerecovery -personal in Terminal and authenticate when prompted. Lower engineering effort, more shepherding.
   Either way the key is replaced in place; the disk is never decrypted.
4. Let the Mac check in, then verify escrow. After rotation and a device sync, retrieve the key from the device's Recovery keys pane in the Intune admin centre. If you permit end-user retrieval, users can also see it in the Company Portal. Until a key can actually be retrieved, treat the device as not yet fixed.
5. Retire the old key everywhere. Rotation invalidates the previous personal recovery key. Purge stale copies exported from the old MDM or stashed in password managers, so nobody reaches for a dead key mid-incident. On the Mac itself, fdesetup validaterecovery confirms whether a given key is still current.

Two further notes: Intune escrows personal recovery keys only — institutional recovery keys are not supported — and the FileVault policy's personal-recovery-key rotation setting can re-rotate automatically at an interval you choose, keeping the escrowed copy fresh from then on.

How Decolla handles it

Straight answer: it doesn't. Decolla, from The Cloud Platform Ltd, provisions Windows devices over your own Intune and Autopilot tenant — it has no macOS capability and will not rotate or escrow FileVault keys for you. The steps above are the fix, and they stand on their own.

This article is in our knowledge base because the underlying failure — a green compliance tick standing in for actual recoverability — is exactly the class of problem Decolla is designed to prevent on the Windows side. Every Decolla build starts from a written, itemised plan: each item states how it will be delivered and whether it is automatically reversible, reversible on request, or irreversible and flagged as such, and you approve that plan before anything runs. After the unattended deployment, Decolla can roll back its own changes item by item. Nothing is treated as done because a dashboard looks healthy.

If you run a mixed estate, borrow the same discipline for your Mac migration runbook: add an explicit escrow-verification gate, and do not mark a migrated Mac as finished until someone has actually retrieved its recovery key from Intune.

Decolla is pre-launch. If planned, reversible, verified Windows provisioning in your own tenant sounds useful, the waitlist is open at decolla.app.

Sources

• Microsoft Tech Community — How to manage FileVault personal recovery keys with Intune on previously encrypted macOS devices
• Travelling Tech Guy — Escrowing and re-issuing FileVault personal recovery keys
• Microsoft Learn — Use FileVault disk encryption for macOS with Intune