FileVault Personal Recovery Key Not Escrowed to Jamf Pro: Fix

#Current method: how the gap usually appears

FileVault

encrypts the startup volume, and Apple documents the feature in its platform security guide. A personal recovery key (PRK) is a fallback for unlocking a Mac when the user’s password is unavailable. Management tooling such as Jamf Pro

The KBY Lexicon

Jamf Pro

Jamf Pro is an MDM platform for configuring, securing and inventorying Apple devices, using scoped policies and profiles delivered via Apple's push infrastructure.

Read Full Context

can hold that key centrally, but only when the Mac was set up to escrow it and the escrow succeeded. Confirm version-specific behaviour in the vendor documentation listed in the sources.

In many fleets the gap is found at the worst moment: a user is locked out, the helpdesk searches Jamf Pro and finds no usable key. The usual response is manual and reactive, with a technician visiting the device or asking the user to run steps by hand. That is a break-fix pattern with no fleet-level visibility.

Common reasons a key is missing or invalid are inferences to test, not documented certainties in every case:

• FileVault was enabled by the user before management enrolment, so no key was ever escrowed.
• FileVault was enabled with an institutional or other mechanism rather than a personal key being sent to the MDM.
• The key was rotated or regenerated locally after escrow, leaving the stored value stale.
• A configuration profile or policy that should collect the key was out of scope for the device.

#Improved workflow: detect, scope, reissue, verify

The improved approach treats escrow as a measurable state. First, produce a list of Macs where FileVault is on but Jamf Pro has no valid key. Second, group them by likely cause. Third, reissue in small waves with the user present or a secure-token holder available. Fourth, verify escrow independently of the device’s own report.

The reasoning is containment: reissuing is a state change on a security control, so each wave should be small enough that a failure affects a handful of users and can be reversed by support.

#Implementation

#

Roles and permissions

Separate duties. One role builds the smart group and reports; a second, with the narrowest rights needed, can view recovery keys; a third approves each wave. Viewing a recovery key is a sensitive action, so restrict it and ensure it is audited. Check your Jamf Pro version for how key access is permissioned and logged.

#

Step 1: build the evidence set

Create a smart computer group or advanced search using Jamf Pro’s FileVault status and recovery key validity attributes. Attribute names vary by version, so confirm them in the Jamf documentation. Expected evidence: a count of Macs encrypted but without a valid personal key. Stop condition: if the count is implausibly high or low compared with a manual sample of five devices, fix the criteria before proceeding.

#

Step 2: classify

Sample devices from the list and check enrolment date, FileVault enablement method and profile scope. The reason for classification is that different causes need different remedies: a scoping fault is fixed once for everyone, whereas a locally rotated key needs a per-device reissue.

#

Step 3: confirm the collecting configuration

Make sure a FileVault configuration that escrows a personal recovery key to Jamf Pro is scoped to the affected group. Apple’s deployment documentation describes the management capabilities available to MDM; the exact payload behaviour should be confirmed against current Apple and Jamf documentation for your macOS

version.

#

Step 4: pilot reissue

Reissue the key on a pilot of a few Macs belonging to willing users or IT staff, using the Jamf-documented method for your version. Do not disable and re-enable FileVault; the aim is to issue a new key while encryption stays on. Expected evidence: the device reports a new key and Jamf Pro shows a valid, newer escrow record. Stop condition: any device that prompts unexpectedly, fails to report, or shows an unchanged record halts the wave.

#

Step 5: expand in waves

Widen scope only after the pilot passes validation. Schedule waves during working hours so support is available, and communicate to users beforehand what prompt they may see and that they should never share credentials.

#Guardrails

• Use a non-production or pilot group first and confirm product versions and permissions before any change.
• Never paste recovery keys into tickets, chat or email; store them only in the management system.
• Do not remove FileVault protection to work around a missing key. That risks data exposure and is outside this workflow.
• Keep a named approver for each wave and a defined stop point if error rates rise.
• Limit who can view keys and review access logs periodically.

Residual risk: a reissue that fails midway can leave a device with an old, invalid key and no new one. The pilot and wave design exist to limit how many devices are in that state at once.

#Validation

1. Re-run the inventory comparison and confirm the pilot devices left the missing-key list.
2. Check the escrow timestamp is later than the reissue time.
3. For a consenting test device, confirm through an approved process that the escrowed key matches the device, without exposing it in shared channels.
4. Confirm FileVault remains enabled on every device in the wave.
5. Review for devices that reverted to missing within a few days, which suggests another process is rotating keys.

Success is observable: the count of encrypted Macs without a valid key falls wave by wave and stays down.

#Common mistakes

• Treating the device-reported FileVault status as proof that a key is escrowed.
• Reissuing to the whole fleet at once.
• Disabling FileVault to force a clean state, which creates a decryption and re-encryption cycle and extra risk.
• Scoping the escrow configuration after the reissue rather than before, so new keys are not collected.
• Leaving keys visible to broad administrator roles.

Related reading: a verifiable FileVault compliance workflow covers the wider evidence model, and catching Platform SSO password drift before FileVault locks out users addresses a related lock-out cause.

#Recovery

If a wave misbehaves, pause further scoping and keep the failed devices in a holding group. Reissuing does not alter the encrypted data, but a device whose new key was not collected has no central fallback. Reissue again once the cause is understood. If the user is locked out and no valid key exists, escalate to your security owner and consult Apple and Jamf documentation and support; do not improvise a decrypt or erase.

Rollback of the workflow itself means removing devices from the wave scope and restoring the previous configuration scope. A previously escrowed key cannot be assumed valid once superseded, so record each reissue time.

#Measurable outcome

Track three figures per week: encrypted Macs, Macs with a valid escrowed key, and the gap between them. Add the number of lock-out tickets that required a key lookup and how many found one. Set your own target, such as a gap of zero for enrolled devices, and review at a fixed cadence. Baseline before the first wave so improvement is attributable rather than assumed; no results are claimed here.

#Checklist

• Product versions and permissions confirmed.
• Inventory comparison built and sampled.
• Escrow configuration scoped before reissue.
• Pilot passed with escrow timestamps verified.
• Waves approved, communicated and monitored.
• Keys never shared in open channels.
• Gap metric reviewed on a schedule.

#Next safe decision after reissue

#Prerequisites and access checks before any wave

#

Console and device prerequisites

Before the pilot, record the Jamf Pro version, the macOS versions in the affected group and the name of the change approver. Confirm that the account used for reporting cannot view recovery keys, and that the account used for key lookups is a named individual rather than a shared login. On a pilot Mac, check the baseline locally with fdesetup status and note the output in the change record. Run profiles list in an elevated shell to confirm which configuration profiles are installed, then compare that list with the scope shown in Jamf Pro.

#

Secure token and user readiness

Reissue methods generally depend on an account that can authorise the change. Check the account state with sysadminctl -secureTokenStatus username for the intended user, and record who holds a token on each pilot device. If nobody suitable is available, move the device to the holding group instead of attempting a workaround.

#Expected evidence at each stage

#

Evidence to attach to the change record

• Export of the smart group membership with a timestamp, before and after each wave.
• For each pilot device, the serial number, the local fdesetup status output and the escrow timestamp shown in Jamf Pro.
• The policy log entry for the reissue, with its start and end times.
• The name of the person who viewed any key, the date and the reason, taken from the audit log rather than from memory.

Never store the key itself as evidence. A matching timestamp and an access-log entry are enough to show that collection occurred.

#Monitoring between waves

Allow at least one full check-in cycle after each wave before widening scope. Compare the missing-key count at the end of the wave, after one day and after one week. A count that rises again points to another process regenerating keys, such as a local script or a user-run command. Search your management scripts and login hooks for fdesetup changerecovery and for any custom extension attribute that reports FileVault state. Where a scheduled inventory update is not frequent enough to show the result, trigger a manual update on pilot devices with sudo jamf recon and note that you did so.

#Realistic failure symptoms

#

What to look for and the likely meaning

• Policy shows completed but the escrow timestamp is unchanged: the device may not have reported back. Run an inventory update and check connectivity to the Jamf Pro server before reissuing again.
• User sees a password prompt they did not expect: stop the wave, confirm the communication reached them and check that the prompt matches what the pilot produced.
• Key is present but a lookup fails to unlock a test device: treat the record as untrustworthy, mark the device as unresolved and do not close the ticket.
• Device appears in the missing list only after a wave: compare its scope membership with the escrow configuration, since it may have fallen out of the group during reissue.
• Policy log shows errors from fdesetup: copy the exact text into the record and compare it with Apple and Jamf documentation. Do not guess at its meaning.

#Escalation thresholds

Agree numbers before the first wave and write them in the change record. Suggested starting points, to be adjusted by your security owner: pause when any pilot device fails, pause a wider wave when more than one in twenty devices shows an unchanged record, and escalate immediately when a locked-out user has no valid key. Escalate to the security owner for the first two cases and to Apple or Jamf support for any behaviour that contradicts their documentation. Include the Jamf Pro version, macOS version, policy log and timestamps in the support request.

#Change-control records

#

Minimum content

1. Reason for change, with the baseline gap figure.
2. Scope, listing group names and device counts per wave.
3. Approver, implementer and key-viewing role holders.
4. Planned start time, stop thresholds and communication sent to users.
5. Outcome per wave, including devices moved to the holding group and the reason.

Close the record only after the one-week comparison, not at the end of the final wave.

#Safe rollback actions

Rollback is limited to what can be undone without touching encryption. Remove devices from the wave scope, restore the previous configuration scope from the saved export, and move failed devices to the holding group. Keep the escrow configuration in place unless it is itself the fault, because removing it prevents later collection. Do not run fdesetup disable or erase a device as a rollback step. If a device was reissued and its new key was not collected, treat it as unprotected centrally, flag it for supervised reissue with the user present, and keep that flag until a verified record appears.

Once the gap is closed, decide whether enrolment-time enforcement should prevent it recurring. Hold new waves if the pilot shows any unresolved failure, and confirm all version-specific steps in the Apple and Jamf documentation listed in the sources.