Rescuing a Fleet of Un-Escrowed FileVault Keys with Escrow Buddy

This is the companion to the earlier guide on enforcing FileVault and escrowing the recovery key. That post is about setting things up correctly from a clean start. This one is about the messier and more common situation: a fleet that is already encrypted, has been for years, but where a large share of the recovery keys never actually made it into your MDM. The Macs are secure. But if a user is ever locked out, you have nothing to unlock them with. That is a bad place to be, and it is worth fixing properly rather than with the ageing password-prompt reissue tooling most fleets inherited.

The fix I settled on uses Escrow Buddy, an open-source tool I will introduce properly below, combined with a gated Smart Group that acts as both the worklist and the progress bar. The whole thing is self-healing: any Mac that loses a valid escrowed key in future gets picked up and fixed automatically, with nothing shown to the user at any point.

The Two Ideas People Mix Up

Before anything else, the distinction that the whole problem hinges on, because getting these two confused is what leads to a fleet quietly sitting in a broken state for years.

Enabling FileVault is turning encryption on for a Mac that is not yet encrypted. This generates a Personal Recovery Key. Most fleets have this part sorted; it is the visible, obvious half.

Escrowing the key is sending a valid copy of that recovery key up to your MDM so it can be retrieved later. This is governed by a configuration profile carrying an escrow payload, and this is the invisible half that quietly fails.

The crucial fact: a Mac can be fully encrypted and still have no valid key escrowed. The encryption works, the user is protected, everything looks fine on the surface, and yet if that user forgets their password you have no way in. That was exactly the situation I walked into.

The Problem and How I Found It

An audit of the fleet turned up an uncomfortable picture. A large share of Macs were encrypted but had no valid recovery key escrowed in Jamf. A little under sixty percent had escrowed correctly, which left a substantial minority where Jamf either held no key at all or held one that no longer validated.

Newer machines were disproportionately affected, and that detail turned out to be the clue that explained the root cause.

Root cause

A recovery key is only escrowed at the exact moment it is generated, and only if a working escrow profile is applied at that moment. If a key was generated at some earlier point when the escrow settings were missing, misconfigured, or simply not yet applied, then nothing ever goes back later to escrow it. The key stays perfectly valid on the Mac itself, but it was never copied to Jamf, and nothing in the normal run of things will ever copy it retroactively.

This is why newer machines were worse. They had been set up during a window where the escrow configuration was not reliably in place, so their keys were generated and then orphaned. Compounding it, the legacy reissue policies relied on an older password-prompt script method that no longer works reliably on current macOS, and several overlapping FileVault profiles and policies had accumulated over the years, quietly fighting each other.

What the audit found in Jamf

Digging through the Jamf console turned up a familiar kind of archaeological layering, the sort of thing any fleet accumulates over years of different admins solving the same problem different ways:

• A combined profile with both enablement and escrow payloads, confirmed working on a freshly wiped test Mac. This became the keeper.
• A deprecated recovery key redirection payload for macOS 10.9 to 10.12, doing nothing at all on modern machines.
• A second redirection profile, also carrying an escrow payload, later confirmed to use the same certificate as the keeper (which made it safely redundant).
• A multi-purpose security profile with FileVault enablement (enablement only, no escrow) bundled together with Firewall and General settings, scoped to most user machines.
• On the policy side: an enablement policy, an accidental duplicate of it, a legacy reissue-key script policy, and a superseded "require new key" policy.

Scope analysis on a representative healthy Mac showed that only the keeper escrow profile plus the enablement profile and policy were in effect. The redirection profiles were not broadly scoped and were doing nothing. Knowing that made the cleanup much less nerve-wracking than it first looked.

What Escrow Buddy Is

Escrow Buddy is an open-source macOS authorization plugin created by Elliot Jordan and the Client Systems Engineering team at Netflix, released in 2023 and now maintained under the community macadmins GitHub organisation. It exists to solve exactly the problem above: Macs that are encrypted but lack a valid escrowed key.

The clever part is how it generates the new key. Rather than showing the user a password prompt (the old, fragile approach that most inherited reissue tooling used), Escrow Buddy hooks into the standard macOS login authorization database. When a FileVault-enabled user logs in, it uses their login credentials as the input to fdesetup to generate a fresh recovery key silently, as part of the login they were doing anyway. No prompt, no dialog, no on-screen message. The user sees a completely normal login.

It replaced, for me, an entire category of clunky password-prompt reissue steps that had been shared around the Mac admin community for years, with something dramatically more reliable. The tool and its reasoning are documented on the Netflix Tech Blog, and the project openly credits the earlier Crypt project as its inspiration.

The Design: Gated Smart Group as Worklist

The approach I landed on has a few deliberate design decisions that are worth understanding before you build it, because each one solves a specific failure mode.

A single escrow profile, scoped to all Macs. One configuration profile is the sole home for FileVault settings and the sole escrow destination. Not five overlapping ones. This profile is the single load-bearing piece of the whole system.

Escrow Buddy deployed fleet-wide, but only triggered on Macs that need it. Installing the tool and telling it to act are kept as two separate steps on purpose. Every Mac gets the tool installed. Only Macs that lack a valid key get told to generate one. This separation means you can ask any Mac to regenerate a key again in future without reinstalling anything.

A gated Smart Group as the worklist. This is the heart of it. A Smart Group whose membership is precisely the set of Macs that still need fixing. Macs appear in it when they need a key and drop out automatically once they have one. It is simultaneously the to-do list and the progress bar. When it hits zero, you are done.

The gate: an inventory check so no Mac is asked to act before the tool is present. The Smart Group criteria include a check that Escrow Buddy is present. This prevents the race condition where a Mac is told to generate a key before the tool that generates it has landed. Without this gate, you get confusing partial failures.

What to Build in Jamf

Five objects make up the whole system. Here is each one and what it does.

1. Extension Attribute: "Escrow Buddy Installed"

A script-based inventory check that reports Installed or Not Installed by testing for the presence of the plugin bundle. This is what gates the Smart Group.

#!/bin/bash
if [ -d "/Library/Security/SecurityAgentPlugins/Escrow Buddy.bundle" ]; then
    echo "<result>Installed</result>"
else
    echo "<result>Not Installed</result>"
fi

2. Smart Group: "FileVault Encryption, Device requires key escrow"

The worklist. Membership is defined by three criteria combined:

Read that as: the Mac is encrypted, its escrowed key is missing or broken, and the tool needed to fix it is present. Only Macs meeting all three are asked to generate a key.

3. Policy: "Install Escrow Buddy"

Installs the signed Escrow Buddy package, then updates inventory so the Extension Attribute re-evaluates.

4. Policy: "Escrow Buddy, Generate New Key"

Sets the GenerateNewKey flag to true via a Files and Processes command, then updates inventory. This is the trigger that arms a Mac to generate a fresh key at next login.

defaults write /Library/Preferences/com.netflix.Escrow-Buddy.plist GenerateNewKey -bool true

Because the scope is the Smart Group, this policy only ever touches Macs that need a key. As soon as a Mac successfully escrows and drops out of the group, the policy stops applying to it.

5. The escrow configuration profile (the keeper)

This is the load-bearing piece, and in a remediation scenario you very likely already have one that works, buried among the redundant ones. It needs the Enable FileVault payload and, critically, the Escrow Personal Recovery Key payload, scoped to All Computers. The escrow location description is the text users would see on the recovery screen, so make it name your IT team. Set the encryption method to automatic.

How the Cycle Works for One Mac

Once all five objects are in place, here is the full lifecycle for a single Mac, which runs entirely on its own with nothing visible to the user.

The Smart Group is both the worklist and the progress bar: Macs appear when they need fixing and vanish once fixed. When the group is empty, everything is escrowed.

Consolidating the FileVault Mess

Alongside the remediation, this was the right moment to clean up the accumulated FileVault objects, because a single clear configuration is far easier to reason about than five overlapping ones. The key insight that made it safe: the escrow payload can only live in a configuration profile, not a policy, so all the consolidation happens among the profiles.

Why it was safe to consolidate

• The escrow payload lived only in the keeper profile. The multi-purpose security profile carried FileVault enablement only, with no escrow. So removing the duplicate enablement changed nothing about escrow.
• The enablement settings matched between the two profiles, so removing one copy changed no actual behaviour.
• The one setting that differed between them (require unlock after hibernation) was confirmed identical on both beforehand, so its removal was a no-op.
• The two escrow-bearing profiles were confirmed to share the same certificate, making the redundant one safely redundant.

The consolidation procedure

1. Confirm the keeper profile is self-sufficient: both Enable FileVault and Escrow Personal Recovery Key payloads present, scoped All Computers.
2. Note the payloads present in the multi-purpose profile before editing (in my case General, FileVault, Firewall).
3. In the multi-purpose profile, select the FileVault sub-payload and remove it, leaving General and Firewall untouched. Save.
4. Allow machines to check in so the revised profile propagates.
5. Delete the deprecated redirection profiles (confirmed unscoped, zero impact).
6. Disable, then after a day or two of clean observation delete, the duplicate and legacy policies.

• The Smart Group did not grow after the change (proving escrow is intact).
• Firewall and General payloads still present and configured in the multi-purpose profile.
• A test Mac still shows Individual Key Validation = Valid, with the keeper profile still listed in its profiles.

Managing It Day to Day

See what still needs fixing

Open the Smart Group. Its membership is the live list of Macs still waiting. The count should stay flat or fall. If it rises, a Mac has newly lost a valid escrowed key, which the system will pick up and fix on its own.

See the whole picture

Use a saved Advanced Search on recovery key validation, with columns for computer name, Individual Key Validation, Partition Encryption State, the Escrow Buddy Installed attribute, and last inventory update. Valid means Jamf holds a working key; Unknown or Invalid means it does not yet. This is the truest overall progress measure and exports cleanly to CSV.

Check a single Mac

Open the Mac's record and look at the FileVault or Disk Encryption section. Individual Key Validation should read Valid and the last inventory update should be recent. An admin with the right permission can reveal the stored key to prove it is retrievable.

Speed up a specific Mac

If you do not want to wait for the normal check-in cycle, run these on the Mac, then have the user restart or log out and back in (that final step is what generates the key).

sudo jamf policy    # pull any pending policies now (install and trigger)
sudo jamf recon     # update inventory, refresh key validation, move in/out of the Smart Group
sudo jamf manage    # re-apply configuration profiles (useful after a profile change)

Diagnosing a Mac That Will Not Remediate

If a Mac has definitely been restarted but still shows Unknown or Invalid, work through these in order. The first one is by far the most common cause.

fdesetup status

sudo fdesetup list

This lists FileVault-enabled users. The person logging in must be on this list, or Escrow Buddy cannot generate a key. This is the single most common reason a Mac gets stuck. If the user is not on the list, the fix is to grant them a SecureToken, which is a separate task (and one the FileVault setup guide covers in its troubleshooting section).

defaults read /Library/Preferences/com.netflix.Escrow-Buddy.plist GenerateNewKey

Returns 1 if the Mac is armed to generate a key at next login, 0 or nothing if not. If it is not armed, run sudo jamf policy to pull the trigger.

ls "/Library/Security/SecurityAgentPlugins/Escrow Buddy.bundle"

Confirms the tool is present. If it is missing, sudo jamf policy will pull the install policy.

Confirm a recovery key works

If you have retrieved a key from Jamf and want to prove it unlocks the Mac without rebooting to test it:

sudo fdesetup validaterecovery

Prompts for the key and reports whether it is valid for this Mac. A quick way to prove a retrieved key is good before you rely on it.

What Not to Do

• Do not remove or unscope the escrow profile. It is the foundation and the sole home of FileVault settings. Removing it breaks escrow everywhere, silently.
• Do not delete the Escrow Buddy install or trigger policies, the Smart Group, or the Extension Attribute. Together they keep the fleet self-healing for any future key loss. Delete them and you are back to fixing keys by hand.
• Do not fix keys by hand with fdesetup changerecovery or by removing keys manually. Let Escrow Buddy handle generation through the login flow. Manual key surgery is the one reliable way to end up with a Mac whose only valid key exists nowhere at all.
• When cleaning up the legacy policies, keep the real enablement policy and remove only the accidental duplicate. Read the names carefully; the duplicate is usually the one with a copy suffix.

---

Quick-Action Checklist

For when you need to set this up. Each step links back to the section above with the detail.

1. Confirm you have a working escrow profile with the Escrow Personal Recovery Key payload, scoped to All Computers. Everything else depends on this. If you have several overlapping FileVault profiles, identify the one that actually works on a freshly wiped test Mac.
2. Create the Extension Attribute that reports whether Escrow Buddy is installed.
3. Create the gated Smart Group: Individual Key Validation is Invalid or Unknown, AND Partition Encryption State is Encrypted, AND Escrow Buddy Installed is Installed.
4. Create the install policy (Escrow Buddy package + Update Inventory, once per computer, all computers).
5. Create the trigger policy (set GenerateNewKey true + Update Inventory, once per computer, scoped to the Smart Group only).
6. Watch the Smart Group populate, then drain as users naturally restart. It is your progress bar.
7. For stragglers, run sudo jamf policy then sudo jamf recon and ask the user to restart.
8. For stuck Macs, work through the diagnostic order. The usual culprit is the login user not being FileVault-enabled (not a SecureToken holder). Check with sudo fdesetup list.
9. Once the backlog is clear, take the opportunity to consolidate your FileVault objects down to the single keeper profile, and delete the deprecated and duplicate ones after a short observation window.
10. Then leave it alone. The system is self-healing. Any Mac that loses a valid key in future is picked up and fixed automatically, with no user prompt.

Closing Thoughts

The thing I like most about this setup is that it turns a fix into a permanent property of the fleet. Once it is in place, "do all our Macs have valid escrowed keys?" stops being a question you have to periodically re-answer and becomes something the system keeps true on its own. The Smart Group is empty or it is not, and if it is not, you can see exactly which Macs and why. Combined with Escrow Buddy doing the actual key generation silently through the login flow, the whole thing runs without ever bothering a single user. That is a good place to get to, and it is a great deal more restful than the old password-prompt reissue tooling it replaced.

If you are setting FileVault up from scratch rather than rescuing an existing fleet, start with the companion guide on enforcing FileVault and escrowing the recovery key instead, then come back here if you ever inherit a backlog.

← All guides