Silent BitLocker encryption with Intune and recovery key escrow to Entra ID

To encrypt Windows devices silently with Intune, create an Endpoint security > Disk encryption > BitLocker policy that sets Require Device Encryption to Enabled, Allow Warning For Other Disk Encryption to Disabled and Allow Standard User Encryption to Enabled, and blocks every TPM startup PIN and startup key option. To guarantee the recovery key is escrowed, also enable Choose how BitLocker-protected operating system drives can be recovered with the option that stops BitLocker from turning on until the recovery information is stored, which on Microsoft Entra joined devices means the recovery password lands in Entra ID before encryption begins.

Who this is for and what you will have

This guide is for Intune administrators who need every managed Windows device encrypted without relying on users, with a recovery password in Microsoft Entra ID for each device. It covers Windows Autopilot devices and devices already in use. At the end you will have one BitLocker profile that encrypts the OS drive with no prompts (including for standard users), escrow to Entra ID enforced before encryption, recovery password rotation, a script for devices encrypted before the policy, and fixes for the events that block silent encryption.

How silent encryption and key escrow fit together

Silent encryption is driven by three nodes in the BitLocker configuration service provider (CSP). RequireDeviceEncryption tells Windows that the device must be encrypted. AllowWarningForOtherDiskEncryption set to 0 suppresses the warning about third-party encryption and the encryption notification, and Windows then attempts to enable BitLocker silently. AllowStandardUserEncryption lets that silent path run when the signed-in user is a standard user.

When the warning is disabled, the CSP documentation states that the OS drive's recovery key is backed up to the user's Microsoft Entra account. That alone doesn't stop BitLocker from encrypting if the backup fails, so you add the recovery options policy (SystemDrivesRecoveryOptions) with Do not enable BitLocker until recovery information is stored turned on. With that option, a recovery password is generated automatically and BitLocker waits for a successful backup. Microsoft's documentation describes where the password goes:

The same "required backup" setting is also a prerequisite for recovery password rotation, so configuring it once covers both escrow and rotation.

The encryption type is decided by hardware: with silent encryption and no explicit type setting, Modern Standby devices get used space only encryption and other devices get full disk encryption.

Prerequisites

Device requirements

Microsoft lists these conditions for silent enablement:

Note that the Windows documentation describes the Allow warning for other disk encryption policy as applying to Microsoft Entra joined devices, while the Intune documentation lists hybrid joined devices as supported for silent enablement. If you manage hybrid joined devices, include several of them in the pilot before broad assignment.

Editions and licensing

BitLocker management is supported on Windows Pro, Enterprise, Pro Education/SE and Education. The Windows documentation lists the license entitlement for BitLocker management as Windows Enterprise E3 or E5 and Windows Education A3 or A5; Windows Pro/Pro Education/SE licenses alone don't grant it.

Roles

• To create policies and use BitLocker actions in Intune, the account needs an Intune role that includes Remote tasks with Rotate BitLockerKeys (preview) set to Yes. The built-in Help Desk Operator and Endpoint Security Administrator roles qualify.
• To read keys in Entra ID, the account needs the microsoft.directory/bitlockerKeys/key/read permission, included in roles such as Cloud Device Administrator and Helpdesk Administrator.

Rule out other encryption software

Disabling the warning means BitLocker proceeds even when another disk encryption product is present. Microsoft warns that this can cause data loss, boot failures and complex recovery, and can leave a device needing a Windows reinstall. Use device inventory to find devices running third-party encryption and exclude them from the assignment until that product is removed.

Step 1: Clear conflicting startup authentication settings

Silent encryption fails if any policy allows or requires a TPM startup PIN or startup key, because those protectors need user input at boot. Microsoft specifically notes that the security baseline for Microsoft Defender can enable TPM startup PIN and key settings by default.

Review every security baseline, endpoint protection template and settings catalog profile assigned to your Windows devices, and reconfigure or exclude the target devices from any profile that sets a startup PIN or startup key to Allow or Require. After assignment, Intune's policy conflict view catches anything you missed.

Microsoft also notes that the settings catalog on its own doesn't include the TPM startup authentication controls needed for reliable silent enablement, so use the endpoint security disk encryption policy (recommended) or the endpoint protection template rather than a settings catalog-only design.

Step 2: Create the BitLocker profile

1. Sign in to the Microsoft Intune admin center and go to Endpoint security > Disk encryption > Create Policy.
2. Set Platform to Windows and Profile to BitLocker, then select Create.
3. Name the profile, for example WIN-BitLocker-Silent-EntraEscrow, and configure the settings in the tables that follow.

The BitLocker profile uses the settings catalog format, so setting names and help text come straight from the BitLocker CSP. Use the Learn more link next to any setting to open its CSP entry.

Base settings

Operating system drive startup authentication

Under Operating System Drives, set Require additional authentication at startup to Enabled so the TPM options appear, then set:

Encryption method

If you set the encryption method policy (CSP node EncryptionMethodByDriveType), the CSP requires a value for all three drive types: operating system, fixed data and removable data. Setting only some of them makes the policy fail with a 500 status. If the policy isn't configured, BitLocker uses XTS-AES 128-bit. Microsoft recommends the XTS-AES algorithm for all drives and leaves the key size to you: 256-bit for more performant drives and CPUs, 128-bit for less performant ones, unless a regulator requires a specific size. If you have no requirement to change it, leave the setting unconfigured.

Step 3: Require escrow to Entra ID before encryption

Still under Operating System Drives, enable Choose how BitLocker-protected operating system drives can be recovered. The child options map to these data elements in SystemDrivesRecoveryOptions:

The admin center shows the ADMX wording, which mentions AD DS. Microsoft's CSP documentation confirms that the same options govern backup to Entra ID for Microsoft Entra joined devices, and to both directories for hybrid joined devices.

Two constraints matter here:

• If you require the backup but don't permit recovery passwords to be generated, Windows refuses to encrypt with an error about conflicting Group Policy settings for recovery options. Keep the recovery password allowed or required.
• Recovery password rotation, and the remote BitLocker key rotation action, only work when the recovery password backup is set to required (OSRequireActiveDirectoryBackup_Name on and OSActiveDirectoryBackup_Name true).

If you encrypt fixed data drives too, configure the equivalent fixed drive recovery policy the same way.

If your standard requires full disk encryption on Modern Standby devices, add a settings catalog profile with Windows Components > BitLocker Drive Encryption > Operating System Drives > Enforce drive encryption type on operating system drives set to Enabled and Select the encryption type: (Device) set to Full encryption.

Step 4: Assign and pilot

Assign the profile to a pilot group that includes a desktop, a Modern Standby laptop, an Autopilot device used by a standard user and, if relevant, a hybrid joined device. The encryption report can take up to 24 hours to reflect a change, so review the profile's device status for errors and conflicts before widening the assignment.

Verify encryption and escrow

On the device

Run these from an elevated prompt:

manage-bde -status C:
manage-bde -protectors -get C:
Get-BitLockerVolume -MountPoint C | Format-List MountPoint, VolumeStatus, EncryptionMethod, EncryptionPercentage, ProtectionStatus, KeyProtector

You want Conversion Status showing Used Space Only Encrypted or Fully Encrypted, ProtectionStatus On, and KeyProtector containing Tpm and RecoveryPassword. The TPM's PCR Validation Profile should include 7, which confirms Secure Boot is used for integrity.

In Intune

• Devices > Monitor > Encryption report shows readiness, status and TPM version per device; a device's Status details decode the CSP's DeviceEncryptionStatus bitmask into readable reasons.
• Devices > All devices > the device > Recovery keys > Show Recovery Key displays the key ID, key and drive type, or No BitLocker key found for this device if nothing was escrowed.

In Microsoft Graph

To check escrow in bulk, use Microsoft Graph. Listing keys doesn't return the key material, so BitlockerKey.ReadBasic.All is enough:

Connect-MgGraph -Scopes "BitlockerKey.ReadBasic.All"
Get-MgInformationProtectionBitlockerRecoveryKey -Filter "deviceId eq '1ab40ab2-32a8-4b00-b6b5-ba724e407de9'"

The filter uses the Entra device ID; run it without -Filter to list every key in the tenant and compare against your inventory.

Back up keys for devices that were already encrypted

Devices encrypted before this policy, whether by a user, by automatic device encryption or by an older profile, may have no key in Entra ID. The required-backup option only controls when BitLocker turns on, so it doesn't escrow an existing protector. Use the BackupToAAD-BitLockerKeyProtector cmdlet, for example in an Intune remediation or platform script that runs as SYSTEM:

$volume = Get-BitLockerVolume -MountPoint "C:"
$recoveryProtectors = $volume.KeyProtector | Where-Object { $_.KeyProtectorType -eq 'RecoveryPassword' }
 
foreach ($protector in $recoveryProtectors) {
    BackupToAAD-BitLockerKeyProtector -MountPoint "C:" -KeyProtectorId $protector.KeyProtectorId
}

If a device has no recovery password protector at all, the loop does nothing; those devices show up in the encryption report and need a protector added before you can escrow anything.

Control access to keys and rotate them

• Who can read keys: the device's registered owner, plus Cloud Device Administrator, Helpdesk Administrator, Intune Administrator, Security Administrator and Security Reader. Every Show Recovery Key writes an audit entry in the KeyManagement category.
• Self-service: the Entra device setting Restrict non-admin users from recovering the BitLocker key(s) for their owned devices blocks owners from viewing their own keys (changing it needs at least Privileged Role Administrator).
• Rotation after use: with rotation configured and backup required, a numeric recovery password is rotated after it's used to unlock a drive.
• On-demand rotation: in Devices > All devices > select the device, use the BitLocker key rotation remote action (under the ellipsis if it isn't visible). It needs Windows 10 1909 or later or Windows 11.

Two limits to keep in mind: Entra ID stores a maximum of 200 BitLocker recovery keys per device, and silent encryption fails if a device hits that limit because the pre-encryption backup can't succeed. And if you delete the Intune object for a BitLocker-protected Entra joined device, the resulting sync removes the OS volume key protectors and leaves BitLocker suspended. Retire or wipe deliberately rather than deleting device objects to clean up.

Troubleshooting

Start with the Management and Operations logs under Applications and Services Logs > Microsoft > Windows > BitLocker-API.

Event ID 853: A compatible Trusted Platform Module (TPM) Security Device cannot be found on this computer. The TPM is missing or disabled in firmware. Enable it, then confirm the TPM management console shows Ready (TPM 2.0) or Initialized (TPM 1.2).

Event ID 853: BitLocker Drive Encryption detected bootable media (CD or DVD) in the computer. Remove the bootable media and restart the device.

Event ID 854: Failed to enable Silent Encryption. WinRe is not configured. Run reagentc.exe /info; if Windows RE status isn't Enabled, run reagentc.exe /enable. If that fails, check that the recoverysequence of the {current} boot loader in bcdedit.exe /enum all is a GUID rather than zeros.

Event ID 851: BitLocker Drive Encryption cannot be enabled on the operating system drive. Contact the computer manufacturer for BIOS upgrade instructions. The device boots in legacy BIOS mode. In msinfo32, BIOS Mode must be UEFI. Devices that only support legacy mode can't use Intune-managed BitLocker.

BitLocker cannot use Secure Boot for integrity because the UEFI variable 'SecureBoot' could not be read. Secure Boot is off. Check Secure Boot State in msinfo32 or run Confirm-SecureBootUEFI, which returns True when Secure Boot is supported and enabled.

Event IDs 846, 778 and 851 with error 0x80072f9a. Event 846 reads Failed to backup BitLocker Drive Encryption recovery information for volume C: to your Microsoft Entra ID, followed by 778 The BitLocker volume C: was reverted to an unprotected state. Microsoft documents this for Windows 10 version 1809, where the signed-in user can't read the private key of the certificate created during enrollment; the fix is the May 21, 2019 update (KB4497934).

There are conflicting group policy settings for recovery options on operating system drives. Your recovery options require backup while disallowing recovery passwords. Allow or require the 48-digit recovery password.

Encryption report status: To encrypt drives, the BitLocker policy requires either the user to sign in as an Administrator or, if the device is joined to Microsoft Entra ID, the AllowStandardUserEncryption policy must be set to 1. Enable Allow Standard User Encryption, which only appears after Allow Warning For Other Disk Encryption is disabled.

Encryption report status: The network isn't available, which is required for recovery key backup or Recovery key backup failed. The device couldn't reach Entra ID during the backup. Restore connectivity, then check the BitLocker-API log for the backup failure reason.

To confirm the device received your settings, check HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PolicyManager\current\device\BitLocker. Compliance policies can also use the reported BitLocker status, which feeds the device checks in a Zero Trust remote access design.

Rollout checklist

• UEFI, Secure Boot, TPM and WinRE in place; no third-party encryption.
• No profile allows or requires a TPM startup PIN or startup key.
• Require Device Encryption Enabled, Allow Warning For Other Disk Encryption Disabled, Allow Standard User Encryption Enabled.
• Recovery options enabled, backup required before encryption, recovery passwords allowed, rotation configured.
• Encryption method unset, or set for all three drive types.
• Pilot verified with manage-bde, the encryption report and Recovery keys.
• Existing devices escrowed with the remediation script; key readers limited to the roles that need them.

References

• Encrypt Windows devices with BitLocker using Intune
• Intune endpoint security disk encryption policy settings
• View report details for encryption status of devices
• BitLocker CSP
• Configure BitLocker
• Enforcing BitLocker policies by using Intune: known issues
• Manage devices in Microsoft Entra ID using the Microsoft Entra admin center
• List recoveryKeys (Microsoft Graph)
• BackupToAAD-BitLockerKeyProtector
• Get-BitLockerVolume
• Use Microsoft Graph PowerShell authentication commands