BitLocker and FileVault Keys at Fleet Scale: Escrow, Rotation and Audit

At fleet scale, recovery key management is four jobs. Escrow every BitLocker recovery password to Active Directory or Microsoft Entra ID and every FileVault personal recovery key to your device management service. Prove coverage by reconciling the protectors on each device against what the directory holds. Rotate any key once someone has seen it. Log and review every read.

This guide covers the policy settings that make escrow mandatory, the commands that inventory protectors, rotation on Windows and macOS, who can read a key and where that is logged, what happens at wipe and retirement, and the reports an auditor will ask for. Every setting name comes from Microsoft and Apple documentation linked at the end.

If you are deciding where one person should keep one key, read where to store recovery keys for encrypted laptops and FileVault: iCloud or a recovery key, which to choose instead. This post is for the team that owns hundreds or thousands of them.

Key takeaways

• Escrow only counts if encryption cannot start without it. Set "Do not enable BitLocker until recovery information is stored" (Group Policy) or "Require device to back up recovery information to Microsoft Entra" (Intune).
• Prove coverage from both ends: reconcile the recovery protector IDs on each device with the key IDs the directory holds.
• Report on metadata, not keys. BitlockerKey.ReadBasic.All is enough for coverage; reading a key with $select=key writes an audit event.
• Rotation after use is built in for Entra joined and hybrid joined Windows 10 1909 and later through the CSP ConfigureRecoveryPasswordRotation, and only works when backup is mandatory. AD only devices need a script or Configuration Manager.
• FileVault escrow uses FDEFileVault plus FDERecoveryKeyEscrow, which encrypts the personal recovery key to your server's certificate. fdesetup changerecovery -personal and the MDM RotateFileVaultKey command rotate it.
• Apple no longer recommends institutional recovery keys; on Apple silicon they cannot open recoveryOS.
• Deleting a device in Entra ID deletes its BitLocker keys for good, and deleting the Intune object for an Entra joined device leaves BitLocker suspended. Wipe first, delete last.
• Auditors want encryption coverage, escrow coverage and freshness, rotation events, and a log of who read which key.

Why fleet key operations are a different job

For one laptop, the question is where to put a 48 digit number. For a fleet, the questions multiply. Did every device escrow? Is the escrowed key still the one on the disk? Who on the help desk can read it, and did they? Is a key read out over the phone still valid tomorrow? When a firmware update throws 300 machines into recovery on a Monday, can the help desk hand out 300 keys without handing out the whole vault?

NIST SP 800-111, the storage encryption guide for end user devices published in November 2007, says that if a key is lost or damaged "it may not be possible to recover the encrypted data", and asks organizations to plan key generation, use, storage, recovery and destruction. It also warns that recovery mechanisms give an attacker another way in if they are abused. That tension is the subject of this post: an escrowed key is both the reason a locked laptop can be saved and the easiest way into it.

The device side lives in companion posts: the laptop encryption startup checklist, TPM only or TPM with PIN, and BitLocker recovery boot loops.

Version and feature milestones

These dates and version numbers come from the vendor pages listed under Sources. They tell you which devices in a mixed fleet can do what.

Where can a fleet's recovery keys live? A comparison

Microsoft recommends Entra ID for Entra joined devices and AD DS for domain joined devices. It describes a Data Recovery Agent as acting "as a master key for BitLocker": convenient in a lab, a single point of failure in a fleet.

How does BitLocker escrow keys to Active Directory and to Entra ID?

Escrow to Active Directory Domain Services

For domain joined devices, BitLocker writes recovery information to a child object of the computer object. Each object has the class msFVE-RecoveryInformation and carries four attributes that matter:

The object name is a creation timestamp followed by the recovery GUID. Microsoft's recovery overview notes that Active Directory keeps the history of every recovery password for a computer object, and that old keys are not removed unless the computer object is deleted. Old passwords stay readable long after they stopped working.

Three Group Policy settings control escrow, one per drive type:

• Choose how BitLocker-protected operating system drives can be recovered
• Choose how BitLocker-protected fixed drives can be recovered
• Choose how BitLocker-protected removable drives can be recovered

In each, select "Save BitLocker recovery information to AD DS", choose password only or password and key package, and turn on "Do not enable BitLocker until recovery information is stored in AD DS". That checkbox turns escrow from best effort into a gate; Microsoft warns backup "may not happen automatically" without it.

Removable drives are the exception. Microsoft states there is no automatic way to store a removable drive's key in Entra ID or AD DS; you must back it up with PowerShell or manage-bde.

Escrow to Microsoft Entra ID

For Entra joined and hybrid joined devices, the recovery password is stored as a bitlockerRecoveryKey resource. Its properties are small and useful:

In Intune's endpoint security disk encryption profile, the matching settings are "Save BitLocker recovery information to Microsoft Entra ID" and "Require device to back up recovery information to Microsoft Entra". Microsoft's settings reference describes the default for the second one plainly: if it is not configured, "BitLocker enablement will complete even if recovery key backup to Microsoft Entra ID fails". Set it to Yes.

Two limits to plan around. Entra ID stores at most 200 BitLocker recovery keys per device, and when a device hits that limit silent encryption fails because the backup that must happen first fails. Entra ID also cannot hold a key package; if you rely on the BitLocker Repair tool for damaged drives, the key package has to live in AD DS or a file you protect yourself.

Escrow through Configuration Manager

Configuration Manager can also escrow keys to its recovery service, which since version 2103 runs on the management point's message processing engine. Its rotation behaviour is covered below.

How do you prove every device has escrowed?

"Every device has escrowed" is a claim about two data sets agreeing, so prove it by comparing them.

1. Device side. For each managed Windows device, collect the IDs of its recovery password protectors (never the passwords). The KeyProtector property of Get-BitLockerVolume has a KeyProtectorId and KeyProtectorType for each protector.
2. Directory side. For Entra ID, list bitlockerRecoveryKey objects through Microsoft Graph without the key property, so you get id, deviceId and createdDateTime and generate no key read events. For AD DS, list the msFVE-RecoveryInformation objects under each computer and read msFVE-RecoveryGuid.
3. Reconcile. Every recovery password protector ID on a device should appear in the directory. Every encrypted device should have at least one escrowed key newer than its last rotation.

Intune's encryption report (Devices, Manage devices, Configuration, Monitor, Device encryption status) exports to CSV and shows statuses such as "Recovery key backup failed". Status changes can take up to 24 hours to appear, and it only looks at the OS drive. The walkthrough below turns the three steps into scripts.

What is recovery password rotation after use, and how is it configured?

A recovery password is a bearer secret. Anyone who hears it read over the phone, sees it on a ticket, or copies it from a portal can unlock that volume until it changes. Rotation after use means the device generates a new recovery password once the old one has been used to unlock the drive, and escrows the new one. Microsoft describes the purpose as stopping one recovery password from being used again and again.

The policy setting behind it

The setting lives in the BitLocker configuration service provider:

./Device/Vendor/MSFT/BitLocker/ConfigureRecoveryPasswordRotation
  0 = rotation off
  1 = rotation on use for Microsoft Entra joined devices
  2 = rotation on use for Entra joined and hybrid joined devices

It applies to OS and fixed data drives on Windows 10, version 1909 and later, on the Pro, Enterprise, Education and IoT Enterprise editions. It only takes effect when backup is mandatory. For OS drives that means OSRequireActiveDirectoryBackup set to Required and OSActiveDirectoryBackup set to true; for fixed drives the FDV equivalents. In plain terms: rotation will not happen unless the device is also forbidden from encrypting without escrow. That dependency is deliberate, since rotating to a key that never reaches the directory would lock you out.

The CSP page contradicts itself on the default. Its description says that when not configured, rotation "is turned on by default for Entra ID only", but its allowed values table lists 0 (off) as the default. Intune's disk encryption settings reference says that when the setting is not configured, the default, the client does not rotate recovery keys. Do not rely on any default. Set the value explicitly to 1 or 2 and verify the behaviour on a test device.

Configuring it in Intune

In an endpoint security disk encryption policy with a BitLocker profile, set:

Microsoft's settings reference notes that Add Work Account devices (formerly Workplace Joined) are not supported for key rotation, and the CSP lists the enrollment types that are: Entra join, bulk Entra join, Entra join using device authentication, and co-management.

On demand rotation

You do not have to wait for a key to be used. An administrator can rotate a device's recovery password from the Intune admin center: Devices, All devices, select the device, then the BitLocker key rotation remote action. The Intune role needs the Remote tasks permission with "Rotate BitLockerKeys (preview)" set to Yes; the built in Help Desk Operator and Endpoint Security Administrator roles have it.

Under the hood this is the CSP's RotateRecoveryPasswords node, an Exec command that rotates every numeric recovery password for OS and fixed drives. The device answers DM_S_ACCEPTED_FOR_PROCESSING, and the server reads progress from two status nodes:

./Device/Vendor/MSFT/BitLocker/Status/RotateRecoveryPasswordsStatus
  0 = Pass, 1 = Pending, 2 = NotStarted, other values = failure codes
./Device/Vendor/MSFT/BitLocker/Status/RotateRecoveryPasswordsRequestID

Read the two together so the status you see matches the request you sent.

Rotation in Configuration Manager

Configuration Manager rotates on disclosure: when a key is recovered through its self service or help desk portal, "since it's disclosed, Configuration Manager requires the client to rotate the key", then escrows the new one.

Rotation for AD only devices

For devices joined only to on premises Active Directory, the CSP rotation does not apply. Microsoft's BitLocker operations guide recommends you "invalidate a recovery password after its use" and gives a manual pattern: remove the recovery password protector, add a new one, back it up. The walkthrough shows a safer order with a check. AD DS keeps the old object, so rotation makes the old secret useless against the disk but does not remove it from the directory.

How do manage-bde and PowerShell inventory protectors?

BitLocker has two command line surfaces. manage-bde is the older executable; the BitLocker PowerShell module wraps the same operations as objects.

Read only inventory

These commands only read state and are safe to run anywhere.

# Status of every volume: conversion, protection, encryption method
manage-bde -status

# All protectors on the OS drive, with IDs
manage-bde -protectors -get C:

# Only recovery password protectors
manage-bde -protectors -get C: -Type RecoveryPassword

# PowerShell: one object per volume
Get-BitLockerVolume | Select-Object MountPoint, VolumeType, VolumeStatus,
    ProtectionStatus, EncryptionMethod, EncryptionPercentage

# Protector IDs and types, without the secret values
(Get-BitLockerVolume -MountPoint $env:SystemDrive).KeyProtector |
    Select-Object KeyProtectorId, KeyProtectorType

Get-BitLockerVolume returns the protector list in its KeyProtector property. Each protector has a KeyProtectorType such as Tpm, TpmPin, RecoveryPassword, ExternalKey or Password. A recovery password protector object also has a RecoveryPassword property. Never include that property in an inventory, a log or a support ticket. Select the ID and type explicitly, as above.

Backing up a protector that never escrowed

When a device reports that backup failed, back up the existing recovery password protector by ID:

$id = ((Get-BitLockerVolume -MountPoint $env:SystemDrive).KeyProtector |
       Where-Object KeyProtectorType -eq 'RecoveryPassword' |
       Select-Object -First 1).KeyProtectorId

# To Microsoft Entra ID
BackupToAAD-BitLockerKeyProtector -MountPoint $env:SystemDrive -KeyProtectorId $id

# Or to Active Directory Domain Services
Backup-BitLockerKeyProtector -MountPoint $env:SystemDrive -KeyProtectorId $id

The manage-bde equivalents are manage-bde -protectors -aadbackup C: -id {ID} and manage-bde -protectors -adbackup C: -id {ID}. Microsoft's operations guide notes that the braces must be included in the ID string.

Protector changes that can lock you out

manage-bde -protectors -delete removes protectors. Microsoft's reference warns that all key protectors are removed unless you narrow the command with -type or -id, and that when the last protector on a drive is deleted, BitLocker protection of the drive is disabled. Treat any protector deletion as a change that needs a check first.

manage-bde -protectors -disable C: -rc 3 suspends protection for three restarts (the reboot count accepts 0 to 15). That is how to apply firmware updates without triggering recovery; protection resumes once the count runs out.

How does FileVault escrow a personal recovery key through an MDM profile?

On a Mac, FileVault has one personal recovery key (PRK) per encrypted volume. Apple's deployment guide describes escrow like this: the device management service provides a certificate; the Mac uses its public key to encrypt the PRK in a CMS envelope; the encrypted PRK goes back to the service in the response to a security information query; the service decrypts it for viewing. Because the encryption is asymmetric, Apple notes the service "itself may not be able to decrypt the PRK" without extra steps by an administrator, though many MDM products manage the decryption certificate for you.

The two payloads

Escrow takes two payloads in one profile, plus a certificate payload.

FDEFileVault (payload type com.apple.MCX.FileVault2) turns FileVault on and shapes the user experience. The keys that matter for fleet operations:

Apple's developer docs add one point that surprises people: removing the FileVault payload does not disable FileVault.

FDERecoveryKeyEscrow (payload type com.apple.security.FDERecoveryKeyEscrow, macOS 10.13 and later) sends the PRK to you:

When FileVault is enabled after this payload is installed, the Mac encrypts the PRK with the certificate, wraps it in a CMS envelope and stores it at /var/db/FileVaultPRK.dat. The MDM SecurityInfo command makes that data available to the server. Only one escrow payload is allowed per system.

The escrow portion of a profile looks like this; your MDM normally builds it.

<dict>
  <key>PayloadType</key>
  <string>com.apple.security.FDERecoveryKeyEscrow</string>
  <key>Location</key>
  <string>Your IT help desk: see the self service portal under Devices</string>
  <key>EncryptCertPayloadUUID</key>
  <string>REPLACE-WITH-UUID-OF-PKCS1-CERT-PAYLOAD</string>
  <key>PayloadIdentifier</key>
  <string>com.example.filevault.escrow</string>
  <key>PayloadUUID</key>
  <string>REPLACE-WITH-NEW-UUID</string>
  <key>PayloadVersion</key>
  <integer>1</integer>
</dict>

Setup Assistant versus deferred enablement

Apple describes two routes. You can require FileVault in Setup Assistant, holding the device in the awaiting configuration state until FileVault is on and the key is escrowed; on macOS 26.4 or later FileVault is on by default there, and Apple still suggests the management option so the key is escrowed and the user cannot turn FileVault off. Or you can enable it after enrollment, which Apple calls deferred enablement and which waits for a logout or login.

Setup Assistant enforcement makes escrow provable, because the Mac cannot reach the desktop without it. Deferred enablement leaves a window in which a Mac is in use without an escrowed key. Intune follows the same order, escrow preparation then encryption, and for Macs a user encrypted before policy arrived it lets the user upload their existing PRK.

How does fdesetup rotate the personal recovery key?

On the Mac itself, fdesetup is the tool. These commands only read state:

fdesetup status
fdesetup isactive                     # exit 0 and "true" if FileVault is on
sudo fdesetup haspersonalrecoverykey  # "true" if a PRK exists
sudo fdesetup hasinstitutionalrecoverykey
sudo fdesetup usingrecoverykey        # "true" if this boot was unlocked with the PRK
sudo fdesetup list                    # users enabled for FileVault

Note the man page's caveat that haspersonalrecoverykey and hasinstitutionalrecoverykey may also return "false" on any error or when FileVault is not fully enabled, so treat "false" as "check", not "missing".

To rotate the PRK locally:

sudo fdesetup changerecovery -personal

The man page says the new personal recovery key is generated automatically and "the old value will be removed and replaced". There is only one PRK per volume, so rotation is a replacement, not an addition. On APFS volumes running 10.14 or later, the existing recovery key can be used to authenticate the change. With -outputplist, the current man page (dated 2 July 2025) describes a preflight: fdesetup checks that the output path is safe to write, and if it is not, rotation is refused, the existing key stays valid and the tool exits with status 38. Only rotate locally when your MDM will collect the new key.

For a fleet, rotation should come from the MDM. Apple's RotateFileVaultKey command (macOS 10.9 and later) takes a KeyType of personal or institutional, a FileVaultUnlock dictionary to authorise the change, and a ReplyEncryptionCertificate used to encrypt the new PRK in a CMS wrapper on its way back to the server. Intune exposes this two ways:

• Scheduled rotation. In the FileVault policy, "Recovery Key Rotation In Months" or "Personal recovery key rotation" accepts 1 to 12 months. New keys are generated and escrowed and the previous key stops working once rotation succeeds.
• On demand rotation. In the device overview, Secure, then Rotate FileVault recovery key. Microsoft notes manual rotation is only available for devices marked Corporate.

Rotation after use on macOS

macOS has no built in rotation on use. It gives you fdesetup usingrecoverykey, which reports whether this boot was unlocked with the PRK. Collect it through MDM inventory or a script and trigger on demand rotation when it is true, or when the help desk logs a disclosure. The simple rule: a ticket that revealed a PRK stays open until a new key is escrowed.

How do institutional recovery keys differ from personal recovery keys?

An institutional recovery key (IRK), once called a FileVault Master identity, is a certificate based key installed on many Macs, with the private key held by IT. fdesetup can install it from /Library/Keychains/FileVaultMaster.keychain or from a DER certificate. A personal recovery key is a per volume 24 character code that macOS generates.

Apple's Platform Security guide gives the reasons for de-emphasising IRKs. It says their utility is limited in recent macOS, and that on a Mac with Apple silicon IRKs add nothing useful because they cannot be used to access recoveryOS and, with target disk mode gone, the volume cannot be unlocked by connecting it to another Mac. Apple's conclusion is that an IRK is "no longer recommended" for managing FileVault and a PRK should be used instead. The FDEFileVault payload documentation adds that the IRK certificate key is not supported on a Mac with Apple silicon.

An IRK also fails the blast radius test: one leaked private key unlocks every Mac that carries it. If you still have IRKs on Intel Macs, confirm a PRK exists and is escrowed, then remove the IRK with fdesetup removerecovery -institutional. The man page warns against removing all recovery keys at once.

Who in IT can read a recovery key, and how is access logged?

Microsoft Entra ID

Reading a BitLocker key in Entra ID requires device ownership or the microsoft.directory/bitlockerKeys/key/read permission. Microsoft's pages list slightly different built in roles that hold it: Cloud Device Administrator and Helpdesk Administrator everywhere, plus some of Intune Administrator, Security Administrator, Security Reader, Global Reader and Global Administrator depending on the page. Check your tenant's role definitions rather than memorising a list.

Three controls narrow who can read:

• Custom roles and administrative units. Microsoft suggests a custom role with just the bitlockerKeys/key/read permission, scoped to administrative units so a regional help desk only sees its own devices.
• The self service toggle. By default, users can read the keys of devices they own at myaccount.microsoft.com. The tenant setting "Restrict non-admin users from recovering the BitLocker key(s) for their owned devices" turns that off; changing it requires at least the Privileged Role Administrator role.
• Conditional Access. Intune's documentation describes requiring a compliant device for recovery key access, so keys are treated as corporate resources.

Every read is logged. Selecting Show Recovery Key in the Entra admin center or the Intune admin center writes an entry in the KeyManagement audit category, and the Entra audit activity reference lists "Add BitLocker key", "Delete BitLocker key" and "Read BitLocker key" in that category. For self service reads, Intune notes the entry includes the user principal name and the key ID. Through Graph, a GET on a key with $select=key "triggers a Microsoft Entra audit of the operation", while a GET without it does not return the key at all.

For automation, Graph offers two permissions. BitlockerKey.ReadBasic.All returns key metadata; BitlockerKey.Read.All can return the key. A coverage report needs only the first. Give the second to as few identities as possible, ideally none that run unattended.

Intune

Intune adds its own role layer on top. Rotating a BitLocker key needs the Remote tasks permission with "Rotate BitLockerKeys (preview)". For FileVault, viewing and rotating needs the Remote tasks permission with "Rotate FileVault key", and administrators can only view PRKs for Macs marked Corporate. Microsoft states recovery keys for Personal devices "aren't accessible to administrators".

Active Directory

By default only Domain Admins can read BitLocker recovery information in AD DS, and access can be delegated. The BitLocker Recovery Password Viewer, part of the Remote Server Administration Tools, adds a BitLocker Recovery tab to computer objects and a forest wide search by the first eight characters of the password ID. AD DS does not hand you a per read log the way Entra ID does. If you need one, plan directory service access auditing on the recovery objects and test that it records what you expect before you rely on it in an audit.

What should an access review cover?

The read volume row is the one that finds problems. A help desk agent who reads 40 keys in a week with 12 tickets has either a process gap or a story to tell.

What happens to keys when a device is wiped, reassigned or retired?

This is where fleets lose keys they still needed, or keep keys they should have destroyed.

Deleting a device in Entra ID deletes its keys

Deleting a device in Entra ID removes everything attached to it, BitLocker keys included, and Microsoft calls it "a nonrecoverable activity". The stale device guidance repeats the point: "There's no way to recover BitLocker recovery keys after deleting the associated device." A stale device cleanup on a timer can destroy the only key for a laptop sitting in a drawer under legal hold. Before deleting a device object, confirm the disk was sanitized, or archive the key under a controlled process.

Deleting the Intune object removes protectors

Intune's BitLocker page warns that deleting the Intune object for an Entra joined BitLocker device triggers a sync that "removes the key protectors for the operating system volume", leaving BitLocker suspended. The disk stays encrypted, but anyone who boots it gets in. That is not a harmless clean up for a device still in someone's hands.

Active Directory keeps history

AD DS keeps every recovery object until the computer object is deleted. Reimaging under the same name adds new objects beside the old ones: handy for an old disk, and a standing exposure to anyone with delegated read access.

Reassignment

Microsoft notes BitLocker can be forced into recovery before a device goes to a new user, and that for reused Windows Autopilot devices scoped administrators may keep access to keys for devices that changed hands. Rotate the recovery password at handover and confirm the new key escrowed before the device leaves IT. For Macs, rotate the PRK with the MDM command and check the ownership flag, since Intune admins only see PRKs for Corporate devices.

Retirement and wipe

On Apple silicon and T2 Macs, Apple says the Secure Enclave can erase the media key, for example through a remote management command, which "renders the volume cryptographically inaccessible". The escrowed PRK then unlocks nothing. On Windows, a wipe and fresh BitLocker setup creates new protectors and new escrowed keys. The safe order:

1. Confirm the device is not needed for a legal hold or investigation.
2. Wipe or sanitize the storage and record the method and date.
3. Only then delete the Entra ID device or AD computer object, and mark the key retired in your inventory.
4. If the device is not wiped (repair, evidence), keep the key and record why.

How should recovery keys be handled during an incident or a mass recovery event?

There are two kinds of incident here, and they need opposite instincts.

A mass recovery event

Many devices land on the recovery screen at once. Microsoft's triggers include firmware updates, boot manager changes, TPM and PCR changes, and boot order changes; a firmware rollout without suspending BitLocker is the classic cause. The instinct is speed. The risk is that speed becomes bulk disclosure.

1. Stop the trigger. Pause the rollout, and in future firmware jobs suspend with a reboot count (manage-bde -protectors -disable C: -rc 1).
2. Use self service where it is safe. Users with Conditional Access gated self service can read their own key from a second device. Set a custom preboot recovery message and URL in advance.
3. Widen help desk access narrowly. Use a temporary role assignment scoped to the affected administrative unit, not a tenant wide grant.
4. Follow Microsoft's help desk checklist. Verify identity, record the device name and the key ID on screen, locate the password, gather root cause information, then hand it over. Each 6 digit block has a checksum, so the console catches most typos.
5. Rotate what was revealed, automatically on Entra joined and hybrid devices with rotation on, on demand for the rest.
6. Reconcile the day's "Read BitLocker key" events against rotation status. A read with no later rotation is an open item.

A security incident involving keys

An admin account with key read rights is compromised, an export leaks, or a laptop is stolen with its key in the ticket. The instinct here is containment.

• Find what was read from KeyManagement audit events for the identity and window; each event names the key.
• Rotate what was read with Intune's BitLocker or FileVault rotation, and watch RotateRecoveryPasswordsStatus until it reports Pass.
• Know the limit. Rotation only reaches devices that check in. A stolen laptop that stays offline keeps its old key, so treat its data as exposed if the key went with it, and wipe it if it ever connects.
• Fix the role. Remove standing assignments and look for other identities holding BitlockerKey.Read.All.
• Treat repeated recovery as a signal. Microsoft's root cause questions ask whether a boot file change came from the user or malicious software, and whether the device was left unattended. A cluster of recoveries deserves investigation, not just more keys.

What reports should an auditor expect?

Frameworks rarely name BitLocker or FileVault; they ask for evidence that endpoint data at rest is encrypted and its keys are managed. CIS Benchmarks for Windows and macOS publish encryption checks per OS version. In practice an auditor will want this:

Present escrow coverage as a count and a list, not a percentage alone. "99.4 percent" hides the six laptops that matter.

Step by step: a weekly escrow verification job

This walkthrough builds the coverage and freshness reports from the sources above. It reads key metadata, never key values, so it creates no key read events.

Step 1: collect protector IDs on each Windows device

Run this as a device side script through your management tool. It emits JSON with protector IDs and types only.

# Inventory BitLocker protectors without exposing secrets.
$out = foreach ($v in Get-BitLockerVolume) {
    [pscustomobject]@{
        Computer         = $env:COMPUTERNAME
        MountPoint       = $v.MountPoint
        VolumeType       = "$($v.VolumeType)"
        ProtectionStatus = "$($v.ProtectionStatus)"
        VolumeStatus     = "$($v.VolumeStatus)"
        RecoveryIds      = @($v.KeyProtector |
                             Where-Object KeyProtectorType -eq 'RecoveryPassword' |
                             ForEach-Object { $_.KeyProtectorId.Trim('{}').ToLower() })
        ProtectorTypes   = @($v.KeyProtector | ForEach-Object { "$($_.KeyProtectorType)" })
    }
}
$out | ConvertTo-Json -Depth 3

Flag any volume where ProtectionStatus is Off while VolumeStatus shows encryption; that is a suspended volume. Flag any OS volume with no RecoveryPassword protector at all.

Step 2: list escrowed keys from Entra ID, metadata only

Use the Microsoft Graph PowerShell SDK with the least privileged permission.

Install-Module Microsoft.Graph.Identity.DirectoryManagement, Microsoft.Graph.Identity.SignIns -Scope CurrentUser
Connect-MgGraph -Scopes 'BitlockerKey.ReadBasic.All','Device.Read.All' -NoWelcome

# Windows devices known to Entra ID
$devices = Get-MgDevice -All -Filter "operatingSystem eq 'Windows'" |
    Select-Object DisplayName, DeviceId, TrustType, ApproximateLastSignInDateTime

# Escrowed keys: id, deviceId, createdDateTime, volumeType. No key values.
$keys = Get-MgInformationProtectionBitlockerRecoveryKey -All |
    Select-Object Id, DeviceId, CreatedDateTime, VolumeType

$byDevice = $keys | Group-Object DeviceId -AsHashTable -AsString

$report = foreach ($d in $devices) {
    $k = $byDevice[$d.DeviceId]
    [pscustomobject]@{
        Device        = $d.DisplayName
        DeviceId      = $d.DeviceId
        TrustType     = $d.TrustType
        LastSignIn    = $d.ApproximateLastSignInDateTime
        EscrowedKeys  = @($k).Where({ $_ }).Count
        NewestEscrow  = ($k | Sort-Object CreatedDateTime -Descending |
                         Select-Object -First 1).CreatedDateTime
        EscrowedIds   = @($k | ForEach-Object { $_.Id.ToLower() })
    }
}
$report | Export-Csv .\entra-escrow.csv -NoTypeInformation

The list endpoint is GET /informationProtection/bitlocker/recoveryKeys, it pages through @odata.nextLink, and it does not support $top; the -All switch handles paging. Microsoft's Graph reference also lists User-Agent as a required request header, which the SDK supplies.

Step 3: list escrowed keys from AD DS

For domain joined devices, read the recovery objects under each computer. Only the ID and timestamp are needed.

Import-Module ActiveDirectory
$adReport = foreach ($c in Get-ADComputer -Filter 'Enabled -eq $true' -Properties OperatingSystem |
                       Where-Object OperatingSystem -like 'Windows*') {
    $rec = Get-ADObject -SearchBase $c.DistinguishedName `
                        -Filter "objectClass -eq 'msFVE-RecoveryInformation'" `
                        -Properties 'msFVE-RecoveryGuid', whenCreated
    [pscustomobject]@{
        Computer     = $c.Name
        EscrowedKeys = @($rec).Where({ $_ }).Count
        NewestEscrow = ($rec | Sort-Object whenCreated -Descending | Select-Object -First 1).whenCreated
        EscrowedIds  = @($rec | ForEach-Object { ([guid]$_.'msFVE-RecoveryGuid').ToString() })
    }
}
$adReport | Export-Csv .\ad-escrow.csv -NoTypeInformation

Do not request msFVE-RecoveryPassword. The account running this needs read access to the objects, which by default only Domain Admins have, so run it under a delegated account with the narrowest rights that work and do not run it as a Domain Admin on a schedule.

Step 4: reconcile

Join the device side output from Step 1 with Step 2 or Step 3 by device name or device ID. Put each device in one bucket:

Step 5: rotate a recovery password on an AD only device, safely

This is the manual rotation from Microsoft's operations guide, with a check added. Warning: removing protectors before a new one exists can leave the volume with only a TPM protector, and deleting the last protector disables BitLocker protection on the drive. Run the check first, and do not continue if it fails.

# Check: confirm the target volume, that it is the OS volume, and what protectors exist.
$mp  = $env:SystemDrive
$vol = Get-BitLockerVolume -MountPoint $mp
$vol | Select-Object MountPoint, VolumeType, ProtectionStatus, VolumeStatus
$vol.KeyProtector | Select-Object KeyProtectorId, KeyProtectorType
if ($vol.VolumeType -ne 'OperatingSystem' -or
    -not ($vol.KeyProtector.KeyProtectorType -match 'Tpm')) {
    throw "Stop: unexpected volume or no TPM protector on $mp"
}

Safer order than the guide's remove then add: add the new protector, escrow it, confirm escrow, then remove the old one.

$old = @($vol.KeyProtector | Where-Object KeyProtectorType -eq 'RecoveryPassword').KeyProtectorId

Add-BitLockerKeyProtector -MountPoint $mp -RecoveryPasswordProtector | Out-Null
$new = ((Get-BitLockerVolume -MountPoint $mp).KeyProtector |
        Where-Object { $_.KeyProtectorType -eq 'RecoveryPassword' -and $_.KeyProtectorId -notin $old }).KeyProtectorId

Backup-BitLockerKeyProtector -MountPoint $mp -KeyProtectorId $new
# Confirm the new ID now exists under the computer object in AD DS (Step 3) before continuing.

foreach ($id in $old) { Remove-BitLockerKeyProtector -MountPoint $mp -KeyProtectorId $id }

If the policy "Choose how BitLocker-protected operating system drives can be recovered" requires backup to AD DS, Microsoft notes the explicit backup step is not needed, but confirming the object exists before removing the old protector still is.

Step 6: the Mac side

From your MDM, export FileVault status and escrow state per device. Intune's encryption report covers macOS and can be exported to CSV. For a device side check, these read only commands give you the same signals:

#!/bin/sh
# Read only FileVault inventory. Prints no secrets.
printf 'serial=%s\n' "$(ioreg -rd1 -c IOPlatformExpertDevice | awk -F'"' '/IOPlatformSerialNumber/{print $4}')"
printf 'filevault=%s\n' "$(fdesetup isactive)"
printf 'prk=%s\n' "$(fdesetup haspersonalrecoverykey)"
printf 'irk=%s\n' "$(fdesetup hasinstitutionalrecoverykey)"
printf 'unlocked_with_prk=%s\n' "$(fdesetup usingrecoverykey)"
ls -l /var/db/FileVaultPRK.dat 2>/dev/null || echo 'escrow_blob=missing'

Bucket Macs the same way: FileVault off, FileVault on without a PRK, PRK present without escrow on the server, IRK present (plan removal), and unlocked with PRK (rotate).

Step 7: run it weekly and keep the output

Keep the CSVs and track bucket counts over time. Escrow missing should reach zero and stay there, and reveal to rotation time should be measured in hours.

Where Safeguard fits, honestly

Safeguard does not manage devices, store recovery keys, rotate them or read your directory audit logs, and nothing in this guide depends on it. The fit is indirect. The scripts above live in a repository, run on an admin workstation or a build agent, and pull modules and packages to do their work; keeping that tooling and the machines it runs on free of known vulnerable open source components is the part Safeguard covers. Safeguard scans repositories, container images and SBOM files for known vulnerabilities (safeguard scan --dir .), shows which projects contain a given component and version, and can open fix pull requests when autonomous remediation is turned on. Its CLI assistant asks for approval before each command, which suits the same two person habit this post recommends for anything that touches recovery keys.

Common mistakes

• Treating "encrypted" as "recoverable". The Intune encryption status says the OS drive is encrypted, not that its key is escrowed.
• Leaving backup optional. Without the "do not enable until stored" or "require backup" setting, encryption completes even when escrow fails.
• Trusting the rotation default. Microsoft's pages disagree on what "not configured" means. Set ConfigureRecoveryPasswordRotation explicitly.
• Expecting rotation on AD only devices. Client driven rotation needs Entra joined or hybrid joined devices.
• Logging the secret. Inventories that select RecoveryPassword, or reports that add $select=key, copy keys into logs.
• Granting BitlockerKey.Read.All to automation when reporting needs only ReadBasic.All.
• Deleting devices on a timer before wiping or archiving keys.
• Keeping an IRK or a DRA as a convenience. Both are master keys.
• Rotating a Mac's PRK locally without collecting it. Nobody holds the new key.
• Forgetting removable and fixed data drives. Removable drive keys are not escrowed automatically, and the Intune status ignores fixed drives.

FAQ

How do I check if a BitLocker recovery key is backed up to Entra ID?

Compare the recovery protector IDs from Get-BitLockerVolume with the key IDs Entra ID holds for that deviceId. For one device, the Intune or Entra admin center lists the key IDs under Recovery keys.

How do I find which admin viewed a BitLocker recovery key?

Filter Microsoft Entra audit logs on the KeyManagement category and the "Read BitLocker key" activity. Admin center reads and Graph reads with $select=key are both logged.

Does BitLocker automatically rotate the recovery key after it is used?

Only if you set ConfigureRecoveryPasswordRotation to 1 or 2 and make backup mandatory, on Entra joined or hybrid joined Windows 10 1909 or later.

How do I rotate a BitLocker recovery key in Intune?

Devices, All devices, select the device, BitLocker key rotation. Your role needs Remote tasks with Rotate BitLockerKeys set to Yes.

How do I rotate a FileVault recovery key?

Use your MDM's rotate action (Intune: Secure, Rotate FileVault recovery key, Corporate devices only) or schedule rotation every 1 to 12 months. Locally, sudo fdesetup changerecovery -personal replaces the PRK.

Should we use a FileVault institutional recovery key?

Not for new deployments. Apple no longer recommends them, and on Apple silicon they cannot open recoveryOS.

What happens to BitLocker keys when I delete a device from Entra ID?

They are deleted with it, permanently. Wipe or archive first.

How many BitLocker recovery keys can Entra ID store per device?

Up to 200. At the limit, silent encryption fails because the backup that must come first fails.

Where are BitLocker recovery keys stored in Active Directory?

In msFVE-RecoveryInformation objects under the computer object, with the password in msFVE-RecoveryPassword and its ID in msFVE-RecoveryGuid.

Fix it without waiting for upstream

Software supply chain hygiene still matters here because the tooling that runs a key management program is ordinary software: PowerShell modules, MDM agents, scripts in a repository and the build agents that run them all ship open source components that can carry known vulnerabilities. Safeguard does not touch recovery keys, so this fit is indirect, but keeping that tooling patched is the same discipline this post applies to keys, and fork and patch for components with no upstream fix is early access.

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

None of these demos touch a recovery key; they show the software and approval habits around it. You can download the CLI from https://safeguard.sh/download and read the setup guide at https://docs.safeguard.sh/docs/cli .

The first demo is a real CLI session. After install, safeguard opens the interactive terminal, you ask it to fix the lodash CVE in a repo, and it reads the finding and advisory, asks before each command, edits package.json to lodash 4.17.21, runs npm install and npm test with your approval, prints a summary and pushes nothing. If your escrow reports or help desk tooling live in a repository with their own dependencies, the same flow keeps them current, and nothing runs without a person reading the command first.

Click through it at your own pace, or open it full screen.

The second demo is a real Android session: you send work to a computer running the CLI and approve each command on the phone with Allow once, Allow for turn or Deny. That is the same pattern this post asks for around key operations: the person who asks is not the only person who decides.

Click through it at your own pace, or open it full screen.

The third demo connects Claude to the Safeguard MCP server with OAuth and lets you choose which tools Claude can use. Choosing the narrowest set of tools is the same principle as giving a reporting job BitlockerKey.ReadBasic.All instead of BitlockerKey.Read.All.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• Microsoft Learn: BitLocker recovery overview
• Microsoft Learn: BitLocker recovery process
• Microsoft Learn: BitLocker operations guide
• Microsoft Learn: Configure BitLocker (policy settings)
• Microsoft Learn: BitLocker CSP
• Microsoft Learn: Encrypt Windows devices with BitLocker in Intune
• Microsoft Learn: Intune disk encryption profile settings
• Microsoft Learn: Monitor device encryption with Intune
• Microsoft Learn: Encrypt macOS devices with FileVault in Intune
• Microsoft Learn: Wipe devices with Microsoft Intune
• Microsoft Learn: Configuration Manager BitLocker recovery service
• Microsoft Learn: manage-bde protectors
• Microsoft Learn: BackupToAAD-BitLockerKeyProtector
• Microsoft Learn: Backup-BitLockerKeyProtector
• Microsoft Learn: Get-BitLockerVolume
• Microsoft Graph: bitlockerRecoveryKey resource type
• Microsoft Graph: Get bitlockerRecoveryKey
• Microsoft Graph: List recoveryKeys
• Microsoft Learn: Manage device identities in Microsoft Entra ID
• Microsoft Learn: Manage stale devices in Microsoft Entra ID
• Microsoft Learn: Microsoft Entra audit log activity reference
• Microsoft Learn: ms-FVE-RecoveryPassword attribute
• Microsoft Learn: ms-FVE-RecoveryInformation class
• Apple Platform Deployment: Manage FileVault with device management
• Apple Platform Deployment: Intro to FileVault
• Apple Platform Deployment: FileVault payload settings
• Apple Platform Deployment: Use secure token, bootstrap token and volume ownership
• Apple Platform Security: Volume encryption with FileVault in macOS
• Apple Platform Security: Managing FileVault in macOS
• Apple Developer: FDERecoveryKeyEscrow
• Apple Developer: FDEFileVault
• Apple Developer: RotateFileVaultKeyCommand
• fdesetup(8) man page (macOS, dated 2 July 2025)
• NIST SP 800-111, Guide to Storage Encryption Technologies for End User Devices
• CIS Benchmarks: Microsoft Windows Desktop
• CIS Benchmarks: Apple macOS

Last reviewed: 24 October 2026. Policy names and portal paths change between releases; check the linked Microsoft and Apple pages before you change a production policy.