Confirm Escrow of FileVault Recovery Keys in Microsoft Entra

A couple of weeks ago I wrote about confirming the escrow of BitLocker recovery keys in Microsoft Entra — driven by the urgency of the Secure Boot certificate changes. On the macOS side, there is no equivalent certificate crisis forcing our hand right now, but that does not make FileVault key escrow any less important.

macOS continues to grow as a platform in the enterprise. More and more organizations are offering Macs as a choice — or even a default — for their workforce, and with Apple Silicon delivering strong performance across developer, creative, and general productivity workloads, that trend is only accelerating. As your Mac fleet grows, so does the importance of managing it with the same rigour you apply to Windows.

Having your FileVault recovery keys safely stored in Entra is simply good operational hygiene. Let me walk you through why, how to report on it, and how to remediate devices that have fallen through the cracks.

Why You Want FileVault Keys Escrowed

#

There are several scenarios where having the recovery key readily available in your tenant saves you from a world of pain:

1. User incidents — Whether an employee leaves the organization and you need to recover data or repurpose their Mac, or a user simply forgets their macOS login password — the recovery key is your way back in. Without an escrowed key, a FileVault-encrypted disk becomes a brick.

2. Device recovery after hardware repair — After a logic board replacement or certain firmware updates, macOS may prompt for FileVault recovery. If the key was never escrowed, you’re looking at a full disk wipe.

3. Compliance and audit readiness — Regulatory frameworks and internal policies often require proof that disk encryption keys are centrally managed. Having keys escrowed in Entra gives you that audit trail.

4. Incident response — In a security incident, your SOC team may need to unlock and examine a device urgently. Waiting for a user who is unavailable (or compromised) is not an option when time matters.

The common thread here is simple: if the key is not escrowed, your options reduce to wiping the device and losing the data. That is never a good position to be in.

The Remediation Script

#

To address devices that have FileVault enabled but have never escrowed their recovery key to Intune, I have put together a script that can be deployed as a shell script through Intune.

The script performs four checks and actions:

1. Verifies FileVault is enabled on the device
2. Verifies the MDM escrow profile (FDERecoveryKeyEscrow) is present
3. Downloads and installs Escrow Buddy if not already present
4. Sets the GenerateNewKey flag to trigger key escrow at the next user login

📖 remediateFileVaultEscrow.zsh — GitHub

#!/bin/zsh
#set -x

############################################################################################
##
## remediateFileVaultEscrow.zsh
##
## Remediates macOS devices where FileVault is enabled but the recovery key
## has never been escrowed to Intune. Uses Escrow Buddy (by Netflix/macadmins)
## to generate and escrow a new key at the next user login.
##
## https://github.com/macadmins/escrow-buddy
##
## Prerequisites:
##   - FileVault must already be enabled on the device
##   - The Intune FileVault configuration profile (with FDERecoveryKeyEscrow)
##     must be assigned
##
## Designed to run as root via Microsoft Intune shell script deployment.
##
## What this script does:
##   1. Verifies FileVault is enabled
##   2. Verifies the MDM escrow profile is present
##   3. Downloads and installs Escrow Buddy if not already present
##   4. Sets GenerateNewKey flag to trigger key escrow at next login
##
## Logging: /Library/Logs/Intune/RemediateFileVaultEscrow.log
##
## Author:  Simon Pauly Kofoed Mose
## Blog:    https://paulycloud.com
## Version: 2.0 - Replaced fdesetup approach with Escrow Buddy
##          1.0 - Initial release
##
############################################################################################

## Define variables
appname="RemediateFileVaultEscrow"
logandmetadir="/Library/Logs/Intune"
logfile="$logandmetadir/$appname.log"

## Escrow Buddy
escrowBuddyPlugin="/Library/Security/SecurityAgentPlugins/Escrow Buddy.bundle"
escrowBuddyPkg="https://github.com/macadmins/escrow-buddy/releases/download/v1.0.0/Escrow.Buddy-1.0.0.pkg"
escrowBuddyPlist="/Library/Preferences/com.netflix.Escrow-Buddy.plist"

## Create log directory if needed
if [ ! -d "$logandmetadir" ]; then
    mkdir -p "$logandmetadir"
fi

############################################################################################
## Functions
############################################################################################

log () {
    local msg="$(date) | $*"
    echo "$msg"
    echo "$msg" >> "$logfile"
}

downloadFile () {
    local url="$1"
    local dest="$2"
    local maxAttempts=3
    local attempt=1
    while [ $attempt -le $maxAttempts ]; do
        log "Downloading [$url] (attempt $attempt of $maxAttempts)"
        if curl -f -s -L --connect-timeout 30 -o "$dest" "$url"; then
            log "Download successful"
            return 0
        fi
        log "Download attempt $attempt of $maxAttempts failed"
        attempt=$((attempt + 1))
        [ $attempt -le $maxAttempts ] && sleep 10
    done
    log "Download failed after $maxAttempts attempts"
    return 1
}

############################################################################################
## Begin Script Body
############################################################################################

log "Starting $appname"

##
## 1. Check if FileVault is enabled
##
fvStatus=$(fdesetup status)
if ! echo "$fvStatus" | grep -q "FileVault is On"; then
    log "FileVault is not enabled. Nothing to remediate."
    log "Status: $fvStatus"
    exit 0
fi

log "FileVault is enabled"

##
## 2. Check if the MDM escrow profile is present
##
if ! profiles show -all 2>/dev/null | grep -q "com.apple.security.FDERecoveryKeyEscrow"; then
    log "No FDERecoveryKeyEscrow profile found. Assign the Intune FileVault policy first."
    exit 1
fi

log "MDM escrow profile is present"

##
## 3. Install Escrow Buddy if not already present
##
if [ -d "$escrowBuddyPlugin" ]; then
    log "Escrow Buddy already installed at [$escrowBuddyPlugin]"
else
    log "Escrow Buddy not found, downloading and installing..."
    tmpPkg=$(mktemp /tmp/escrow_buddy_XXXXX.pkg)
    if ! downloadFile "$escrowBuddyPkg" "$tmpPkg"; then
        log "Failed to download Escrow Buddy. Exiting."
        rm -f "$tmpPkg"
        exit 1
    fi
    if installer -pkg "$tmpPkg" -target /; then
        log "Escrow Buddy installed successfully"
    else
        log "Failed to install Escrow Buddy. Exiting."
        rm -f "$tmpPkg"
        exit 1
    fi
    rm -f "$tmpPkg"
fi

##
## 4. Set GenerateNewKey flag
##
##    At the next user login, Escrow Buddy intercepts the login authorization
##    and triggers a new personal recovery key generation + escrow
##
log "Setting GenerateNewKey flag..."
defaults write "$escrowBuddyPlist" GenerateNewKey -bool true

if defaults read "$escrowBuddyPlist" GenerateNewKey 2>/dev/null | grep -q "1"; then
    log "GenerateNewKey flag set successfully"
    log "A new recovery key will be generated and escrowed at the next user login"
else
    log "Failed to set GenerateNewKey flag"
    exit 1
fi

log "$appname completed"

Escrow Buddy — Solving the fdesetup Problem

#

You might wonder: why not just use Apple’s built-in fdesetup changerecovery command to rotate the key and escrow it? The answer is that fdesetup requires the user’s login password to be provided interactively or passed as input. In an MDM-driven, unattended deployment context, you simply do not have the user’s password available.

This is the problem that the team at Netflix set out to solve when they developed Escrow Buddy. It is now maintained under the macadmins GitHub organization and has become the community-standard approach for FileVault key escrow remediation.

How Escrow Buddy Works

#

Escrow Buddy installs as a Security Agent plugin (/Library/Security/SecurityAgentPlugins/Escrow Buddy.bundle). It hooks into the macOS login authorization process — the same mechanism that powers the login window itself.

The flow is straightforward:

1. The remediation script sets the GenerateNewKey flag in Escrow Buddy’s preferences
2. At the next user login, Escrow Buddy captures the user’s credentials as they authenticate (the same way macOS itself does)
3. It uses those credentials to call fdesetup changerecovery -personal behind the scenes
4. The newly generated personal recovery key is then escrowed to the MDM server (Intune) via the FDERecoveryKeyEscrow profile payload

The result: a new recovery key is generated and escrowed to Entra without any user interaction beyond their normal login. No prompts, no popups, no helpdesk tickets.

📖 Escrow Buddy — GitHub (macadmins)

Keeping Your Tenant in Good Shape

#

Whether you are managing Windows, macOS, or both — disk encryption key escrow is one of those things that should never be left to chance. It is easy to assume everything is working because the policies are deployed, but configuration drift, re-enrollments, and edge cases mean that some devices will inevitably slip through.

Make it a regular practice to:

• Report on escrow status for both BitLocker and FileVault across your fleet
• Remediate gaps proactively rather than discovering them during an incident
• Validate after changes — any time you modify encryption policies, profiles, or enrollment flows, verify that keys are still being escrowed correctly

If you haven’t already, take a look at my previous post on confirming BitLocker recovery key escrow for the Windows side of the house. Together, these two approaches give you full visibility and control over disk encryption recovery across your entire multi-platform fleet.

Stay on top of it — future you will be grateful.