Autopilot silent BitLocker: the race between the ESP and your encryption policy

Silent BitLocker encryption during Windows Autopilot looks like a switch. You set two policy values, you assign the profile, and devices arrive encrypted. In practice it is not a switch. It is a race. On one side, Windows is trying to encrypt the disk on its own as soon as the out-of-box experience (OOBE) finishes. On the other side, Intune is trying to deliver a disk encryption policy before that happens. Whoever gets there first decides what the device ends up with. The loser leaves no obvious trace. Weeks later a compliance report shows a handful of laptops that are simply not encrypted, and nobody can say why.

The problem: the laptop reached the desktop unencrypted

The report always arrives late. Someone exports the Intune encryption report before an audit, sorts by encryption status, and finds a group of Autopilot-provisioned laptops sitting at Not encrypted. The devices are enrolled. They are compliant on everything else. The disk encryption profile shows as successfully applied. And yet the operating system volume has no protection on it.

There is a second, quieter version of this failure that catches even careful teams. The device is encrypted, so the report shows green. But it is encrypted with XTS-AES 128-bit when your policy asked for XTS-AES 256-bit. Nobody notices, because the column you are looking at only says encrypted. Microsoft is blunt about the cost of fixing this one. A device that receives the settings after encrypting automatically has to be decrypted before the algorithm can be changed. On a fleet, that is a re-provisioning exercise dressed up as a policy change.

The reason nobody notices at the time is that silent means silent. Suppressing the warning prompt suppresses the encryption notification as well. There is no toast, no wizard, no yellow shield in File Explorer to say that something did not happen. The user signs in, gets a desktop, and starts work. The evidence of what happened, or failed to happen, sits in an event log channel that nobody opens until an audit forces it.

Why it happens: two encryption engines racing one policy delivery

To fix the race you have to understand both runners. Start with the one that does not wait for you.

Runner one: automatic device encryption

Device encryption is a Windows feature that enables BitLocker automatically on qualifying devices. It starts during OOBE. Microsoft documents the hardware conditions, and they matter, because a device that does not meet them will not encrypt itself at all.

The sequencing inside automatic device encryption is the part that trips people up. Encryption is initialised on the operating system drive with a clear key, which Microsoft describes as the equivalent of BitLocker being suspended. In that state the volume looks encrypted but the data is not protected. Protection is only armed when the user signs in with a Microsoft Entra ID account or a Microsoft account. For an Entra joined device, the recovery password is created when the user authenticates to Entra ID, the key is backed up to Entra ID, the TPM protector is created, and only then is the clear key removed.

And the default algorithm is the crux of the whole post. Automatic device encryption uses XTS-AES 128-bit by default. If your organisation standardised on 256-bit, every device that encrypts itself before your policy arrives is wrong, permanently, until it is decrypted.

Runner two: policy-driven silent encryption

The BitLocker CSP path is the one you control. A handful of nodes do the work, and they are interdependent in a way the setting names do not advertise. Every node below hangs off one shared parent.

That standard-user dependency deserves its own sentence, because it is the most common reason a correct-looking policy does nothing at all. The documentation is explicit. If AllowWarningForOtherDiskEncryption is not set, or is set to 1, then RequireDeviceEncryption will not try to encrypt drives while a standard user is the current logged-on user. On a user-driven Autopilot deployment where the enrolling user is deliberately not a local administrator, that is every single device.

There is also an operating system floor that shifts with the same question. If end users sign in as administrators, silent enablement needs Windows 10 version 1803 or later, or Windows 11. If they sign in as standard users, it needs Windows 10 version 1809 or later, or Windows 11.

The actual ordering, and where the ESP sits

Here is the sequence Microsoft documents, and it is worth reading twice. BitLocker has logic that does not start encrypting until the end of OOBE, after the Enrollment Status Page device configuration phase is complete. That delay exists specifically to give the device enough time to receive the BitLocker policy settings before encryption starts. And from the Autopilot side: during Windows Autopilot, BitLocker will be enabled after the device setup portion of the Enrollment Status Page.

Then comes the line that turns the ESP from a nice-to-have into a hard requirement. In the Autopilot BitLocker guidance, the last step of configuring the policy says to configure and assign an Enrollment Status Page for the Windows Autopilot device, because if an ESP is not enabled, the BitLocker policy does not apply before encryption starts.

Put those together and the failure mode is obvious. The ESP device setup phase is the window. Your disk encryption policy has to arrive inside that window. Turn the ESP off, or let the device leave the ESP early, and the window closes before the policy lands. Automatic device encryption then does what it was always going to do, with its own defaults.

Encryption type, and why you cannot choose it under silent enablement

When BitLocker is enabled silently, the encryption type is decided by hardware, not by you. Microsoft documents that the system automatically uses full disk encryption on non-Modern Standby devices and used space only encryption on Modern Standby devices, and that the type cannot be customised for silent encryption scenarios. The BitLocker CSP puts it even more starkly for RequireDeviceEncryption: only full disk encryption is supported when using this CSP for silent encryption.

If you need to pin the type anyway, that is what SystemDrivesEncryptionType is for, surfaced in the settings catalog as Enforce drive encryption type on operating system drives. But like the algorithm, it only applies when BitLocker is first enabled. Late is the same as never.

Recovery key escrow, and its own separate timing problem

Encryption succeeding and the key being recoverable are two different outcomes. The order of backup endpoints for a fixed data drive is documented and specific: the user's Active Directory Domain Services account, then the user's Entra ID account, then the user's personal OneDrive for MDM or MAM only. Encryption waits until one of those three locations backs up successfully.

For the operating system drive the behaviour hinges on the warning prompt. When you disable the warning prompt, the OS drive's recovery key backs up to the user's Entra account. When you allow the prompt, the user who receives it chooses where the key goes, which is not a decision you want a new starter making on their first morning.

One capacity limit is worth committing to memory, because it produces a genuinely baffling symptom. Microsoft Entra ID supports a maximum of 200 BitLocker recovery keys per device. Reach that limit and silent encryption fails, because the recovery key backup that has to happen before encryption starts cannot complete. Devices that have been reset and re-provisioned many times over are the ones that hit it.

The Group Policy surface underneath all of it

BitLocker predates MDM, so most of these settings are ADMX-backed and land in the same registry key whether they arrive by Group Policy or by CSP. The Group Policy home for all of them is Computer Configuration > Administrative Templates > Windows Components > BitLocker Drive Encryption, with per-drive-type subfolders. The shared registry parent is stated once here, and every value in the table sits directly under it.

How to verify: read the device, then read the fleet

Verification comes before the fix, because the fix depends on which of the two runners won. A device that never encrypted needs a prerequisite corrected. A device that encrypted with the wrong algorithm needs decrypting. Those are different tickets, and only the device can tell you which one you have.

Step one: the volume itself

Two commands answer most of it. manage-bde -status gives you the conversion status and the encryption method. Get-BitLockerVolume gives you the same information plus the protector types, which is the tell you actually want.

Three readings matter together. ProtectionStatus of Off on a volume that reports FullyEncrypted is the clear-key state, which means encryption ran but protection was never armed. A protector list that contains TpmPin, TpmStartupKey or Password means something interactive created it, so silent enablement is not what happened here. And XtsAes128 on a device whose policy asks for 256-bit is the fingerprint of automatic device encryption winning the race.

Step two: the event log, and the channel names that are not what the docs say

This is where the timeline lives. Microsoft directs you to Event Viewer, under Applications and Services Logs > Microsoft > Windows > BitLocker-API, and to read the Management and Operational logs there.

There is a wrinkle worth knowing if you script against these logs. The troubleshooting article names the channels as Microsoft-Windows-BitLocker-API/Management and Microsoft-Windows-BitLocker-API/Operational, but the wevtutil example on that same page uses a different string. On a current Windows 11 install, the channel names that wevtutil el actually enumerates are the second form. Use the enumerated names in scripts and treat the folder label in Event Viewer as a display name.

Read that list as a story rather than a set of unrelated rows. The 846 followed immediately by a 778 is the sequence that produces an unencrypted device: the escrow failed, so BitLocker reverted the volume rather than leaving a key nobody could recover. That is the system behaving correctly and still handing you a non-compliant laptop.

The documented event identifiers are worth keeping in one place. All of them appear in the Management log of the channel named above.

Reading escrow evidence is a one-liner, and this is the query worth wiring into a proactive remediation detection script.

Step three: the registry, for what policy actually arrived

Microsoft names two subkeys to check when confirming that Intune policy reached the device. Read them together with the FVE key, because they tell you three different things: what the CSP delivered, what the ADMX-backed settings resolved to, and whether device encryption was suppressed outright.

The PolicyManager key is the one that answers "did the policy arrive at all". If that key is absent, no BitLocker CSP policy has ever reached the device, and every other check is downstream of that. If PreventDeviceEncryption exists and is set to 1, automatic device encryption has been suppressed by the image or the manufacturer, and only your policy can encrypt the machine.

Step four: the CSP status bitmask, which names the exact failure

The BitLocker CSP exposes Status/DeviceEncryptionStatus, and this is the most precise diagnostic Microsoft publishes. Zero means compliant. Anything else is a bitmask where each bit names one specific reason. The Intune encryption report surfaces these as its Status details field, so the same list explains both the device and the portal.

Step five: audit the whole fleet, not one device

One device tells you the mechanism. The fleet tells you the scale. The Intune encryption report is the front door, and it is exportable to CSV from the report pane. Behind it, Microsoft Graph exposes the same data as a collection you can query and group.

The useful field on each record is advancedBitLockerStates, which carries the same failure vocabulary as the bitmask above in readable form. Group your unencrypted Windows devices by it and the pattern usually falls out in one pass: a pile of loggedOnUserNonAdmin means the standard-user node is missing; a pile of recoveryKeyBackupFailed means escrow, not encryption, is your problem; windowsRecoveryEnvironmentNotConfigured means your image is the problem; and osVolumeEncryptionMethodMismatch is the timing race, quantified.

The fix: make the policy land before the disk does

The fix has two halves, and doing only one of them is how most people end up here. The first half is the disk encryption policy itself. The second half is the ESP that gives it time to arrive.

Half one: the disk encryption policy

1. Sign in to the Microsoft Intune admin center.
2. Select Endpoint security, then under Manage select Disk encryption.
3. Select + Create Policy. Set Platform to Windows and Profile to BitLocker, then select Create.
4. Give the profile a name, then select Next.
5. Set Require Device Encryption to Enabled.
6. Set Allow Warning For Other Disk Encryption to Disabled. Doing this reveals the next setting.
7. Set Allow Standard User Encryption to Enabled. Skip this and any device whose enrolling user is a standard user will not encrypt.
8. Expand BitLocker Drive Encryption and set Choose drive encryption method and cipher strength to Enabled, then pick a method for all three drive types: fixed data drives, operating system drive, and removable data drives.
9. Expand Operating System Drives. Set Require additional authentication at startup to Enabled, which reveals the four TPM controls.
10. Set Configure TPM startup to Allow TPM or Require TPM. Set Configure TPM startup PIN, Configure TPM startup key, and Configure TPM startup key and PIN all to the corresponding Do not allow option.
11. Still under Operating System Drives, configure the recovery options so that recovery information is saved to Entra ID and BitLocker does not enable until that backup succeeds.
12. Optionally set Enforce drive encryption type on operating system drives to Enabled and choose full or used-space-only, if you need to override the hardware-determined default.
13. Optionally set Configure Recovery Password Rotation to enable rotation on use.
14. On Assignments, target the device group containing your Autopilot devices. Microsoft is explicit that this must be a device group and not a user group.
15. Review and save.

If you are on the older device configuration template rather than endpoint security, the equivalent settings live under Windows Encryption in the Endpoint protection profile, with different names: Warning for other disk encryption set to Block, and Allow standard users to enable encryption during Microsoft Entra join set to Allow.

Half two: the Enrollment Status Page

1. Go to Devices, expand Device onboarding, and select Enrollment.
2. On the Windows tab, under Windows Autopilot, select Enrollment Status Page.
3. Select Create, or edit the default profile if you would rather not add another.
4. Set Show app and profile configuration progress to Yes. Without this the ESP does not appear, and the window your policy needs never opens.
5. Set Block device use until all apps and profiles are installed to Yes. This is the setting that keeps the device in the ESP long enough.
6. Review the time-out value. The default is 60 minutes. Raise it if your device-phase app set is large.
7. Decide on Allow users to use device if installation error occurs. Setting it to Yes gives users an escape hatch out of the ESP, which is also an escape hatch out of the encryption window.
8. On Assignments, target the same Autopilot device group. Remember that in pre-provisioning and self-deploying scenarios, Intune only applies profiles targeted at devices.
9. Review and create. If you have multiple ESP profiles, check the priority order, because the highest-priority device-targeted profile wins.

What to do about the devices that already lost the race

For devices that are unencrypted, fix the prerequisite the bitmask or event log named, then let the policy re-evaluate on the next sync. Nothing needs to be destroyed.

For devices encrypted with the wrong algorithm or the wrong type, the honest answer is that there is no in-place fix. Microsoft says it twice, once for the algorithm and once for the encryption type: the device must be decrypted before the new setting can apply, and changing the type has no effect if the drive is already encrypted or encryption is in progress. Plan that as a wipe-and-reprovision wave rather than a policy tweak, and make sure the new policy and the ESP are both in place before the devices come back.

Proof it worked: what a correctly encrypted device looks like

The companion script for this post is Get-AutopilotBitLockerReadiness.ps1. It is read-only, it never prints a recovery password or a key protector identifier, and it aborts with a clear message rather than reporting a misleadingly clean result if any query it depends on fails. It checks the platform prerequisites, the volume state, the escrow evidence, the delivered policy, and the encryption-method comparison that exposes the timing race.

That output block is illustrative rather than a capture from a production Autopilot device, and it is labelled as such deliberately. The script itself was run and validated on Windows PowerShell 5.1 and PowerShell 7, with zero parse errors and no non-ASCII characters, but the values above represent the healthy shape rather than any real machine.

Three signals in that output prove the race was won. The encryption method on the volume equals the method in policy, which can only happen if the policy arrived before BitLocker was first enabled. The protector list is exactly Tpm plus RecoveryPassword, with nothing interactive, which is the fingerprint of silent enablement rather than a wizard. And there is an 845 with no 846, which means a recoverable key genuinely exists in Entra ID rather than merely being expected to.

Finish in the portal, because the device view and the tenant view have to agree before you close the ticket.

One last honest caveat. Nothing on the device records the exact moment an Intune policy arrived relative to an ESP phase boundary. Every check in this article is evidence, not proof. A matching encryption method and a clean escrow trail is a very strong indicator that the ordering worked, and that is the most you can get from the device alone. Cross-check the tenant report before you declare a fleet clean.

References

• Setting the BitLocker encryption algorithm for Windows Autopilot devices - the ordering statement that BitLocker is enabled after the device setup portion of the ESP, and that without an ESP the BitLocker policy does not apply before encryption starts.
• Encrypt Windows devices with BitLocker using Intune - the full silent-encryption prerequisite list, the required settings for both policy types, the TPM startup guidance, the encryption-type behaviour, and the 200-keys-per-device Entra limit.
• BitLocker CSP - every node used here, including the AllowStandardUserEncryption dependency on AllowWarningForOtherDiskEncryption, the escrow endpoint order, and the full Status/DeviceEncryptionStatus bitmask.
• BitLocker overview - device encryption, the clear-key behaviour, the local-accounts-remain-unprotected statement, and the logic that delays encryption until after the ESP device configuration phase.
• Configure BitLocker - the CSP-to-GPO mapping for every setting, including the four that are documented as GPO not available.
• Enforcing BitLocker policies by using Intune: known issues - events 853, 854, 851, 846 and 778, the Secure Boot UEFI variable error, the HSTI and Modern Standby enforcement-type table, and the two registry subkeys to check.
• BitLocker issues troubleshooting - the event log channel names, the data-collection command set, and the prerequisite checklist.
• BitLocker drive encryption in Windows 11 for OEMs - the automatic device encryption hardware requirements, the PCR 7 detail, and the Windows 11 24H2 removal of the HSTI, Modern Standby and DMA prerequisites.
• Set up the Enrollment Status Page - the three ESP phases, the blocking settings, and the profile priority order.
• View report details for encryption status of devices - the encryption report columns, the readiness definitions, the 24-hour reporting lag, and the OS-drive-only caveat.
• managedDeviceEncryptionState resource type (beta) - the property list and the full advancedBitLockerStates enumeration used for the fleet audit.
• Get-BitLockerVolume - the property list, including ProtectionStatus, VolumeStatus, EncryptionMethod and KeyProtector.

Two community deep-dives are worth reading alongside the official documentation. Both were checked and are genuinely on this topic.

The companion read-only script for this post is Get-AutopilotBitLockerReadiness.ps1. It reads only the documented locations listed above, never prints a recovery password or key identifier, prompts before installing anything, and exits with an explicit failure rather than a clean-looking empty result if a query it relies on cannot complete.