BitLocker silent encryption not working is almost never a policy that failed to arrive. The policy arrives, the device evaluates a list of prerequisites, one of them is missing, and encryption simply never starts. Windows records which prerequisite failed in a status value most admins never read, while the forum threads that rank for this problem guess at causes from the outside. Below is the list Microsoft publishes, the places its own documents contradict each other, and where the device writes the answer. If the drive is encrypted and only the key is missing, that is a different problem, covered in Intune BitLocker recovery key missing, and the wider Intune troubleshooting order sits above both.
What has to be true before silent encryption starts
Microsoft’s Intune encryption documentation lists the device requirements for silent enablement. Verbatim, the device must be:
- “Microsoft Entra joined or Microsoft Entra hybrid joined”
- “TPM (Trusted Platform Module) 1.2 or later”
- “Native UEFI BIOS mode”
- “Secure Boot enabled”
- “Windows Recovery Environment (WinRE) configured and available”
Where end users sign in as standard users, it adds “Windows 10 version 1809 or later, or Windows 11”. It is also explicit about startup authentication:
For silent BitLocker to work, devices must not require TPM startup PIN or startup key, as these require user interaction.
Two further conditions are easy to miss because they live in other settings rather than in the device. Third-party encryption must not be present; the same page says to “ensure your environment doesn’t have third-party encryption software installed”. And recovery key escrow can block the whole thing. If the policy requires the key to be saved to Entra before encryption starts, a failed save means no encryption, and the documentation names one cause most people never hit until they do:
Microsoft Entra ID supports a maximum of 200 BitLocker recovery keys per device. If you reach this limit, silent encryption fails due to the failing backup of recovery keys before starting encryption on the device.
It is rare, but it is cheap to rule out by checking how many keys the device object already holds.
BitLocker silent encryption not working: read the status bits first
With BitLocker silent encryption not working on a device, the most direct answer is a value the device already exposes. The BitLocker CSP has a status node, Status/DeviceEncryptionStatus, which is a bitmask with one bit per blocking reason. The documented reasons include, verbatim:
- “Recovery key backup failed.”
- “Windows Recovery Environment (WinRE) isn’t configured.”
- “The TPM isn’t ready for BitLocker.”
- “The network isn’t available, which is required for recovery key backup.”
Each of those maps to a single fix, which is why reading the bit beats working down a checklist. A device reporting the TPM bit needs firmware or TPM attention, not another policy. A device reporting the WinRE bit needs its recovery environment repaired. A device reporting the backup bit is an escrow problem, and the 200-key limit above is worth checking before anything else.
The standard user case has its own wording in the CSP. Unless the warning for other disk encryption is suppressed, the RequireDeviceEncryption policy “won’t try to encrypt drive(s) if a standard user is the current logged-on user in the system.” This is the classic report of encryption starting only after an administrator signs in. The fix is the setting that allows standard users to enable encryption during Microsoft Entra join, together with suppressing the warning.
Three causes hiding in other policies
A security baseline turned on the PIN. This is the one I would check first in any tenant that deploys baselines, because nothing about it looks like a BitLocker problem. Microsoft states it plainly:
the Security baseline for Microsoft Defender can enable TPM startup PIN and key by default, which blocks silent enablement.
A PIN requirement makes silent enablement impossible by definition, so a baseline assigned alongside your disk encryption profile can quietly cancel it. Baseline overlaps of this kind are covered in Intune security baseline conflicts.
The profile type cannot express the setting. The same documentation warns that “Settings Catalog doesn’t include the necessary TPM startup authentication controls required for reliable silent BitLocker enablement.” It labels Endpoint security, Disk encryption as the recommended route. A silent encryption design built entirely in the settings catalog is starting from a documented gap.
The drive was already encrypted differently. OEM images and earlier policies sometimes leave a drive encrypted with a different method or type. The CSP says “Changing the encryption type has no effect if the drive is already encrypted or if encryption is in progress.” Intune will not convert it for you. The drive has to be decrypted and the policy reapplied.
Where Microsoft’s own documents disagree
Three contradictions matter for this problem, and none of the threads ranking for it point them out.
Secure Boot. The Intune encryption page lists “Secure Boot enabled” as a requirement, and the known issues article says “Silent BitLocker drive encryption requires the secure boot to be turned on.” The client-side troubleshooting article says the opposite: “Secure boot, DMA protection, and PCR7 configuration are not required for silent encryption”. Two pages say required, one says not. I would treat Secure Boot as required, because that is what the current Intune requirements page states, and treat the troubleshooting article as stale on this point.
Hybrid join. The Intune encryption page supports “Microsoft Entra hybrid joined” devices. The BitLocker CSP says of the setting that suppresses the third-party warning that “the value 0 can only be set for Entra ID joined devices”. Since that value is what makes encryption silent, the CSP reads as excluding hybrid joined devices from the silent path. At least one Microsoft Q&A thread on hybrid devices that never encrypt reaches the same conclusion, though no Microsoft answer in it confirms it. If your estate is hybrid joined, do not assume silent works because the requirements list says hybrid is supported. Test it.
Encryption type. The Intune page says silent enablement uses full disk encryption on devices without Modern Standby and “used space only encryption on modern standby devices”. The CSP says “Currently only full disk encryption is supported when using this CSP for silent encryption.” Both cannot be the whole story. This matters mostly for compliance reporting, where a policy and a drive that disagree on encryption type show up as a mismatch.
Timing, and what changed in 24H2
Encryption that has not started during Autopilot is not necessarily stuck. The BitLocker overview states that BitLocker “doesn’t start encrypting until the end of OOBE, after the Enrollment Status Page device configuration phase is complete.” A device inspected mid-provisioning will look unencrypted because it is supposed to. The Intune enrollment status page decides when that phase ends.
The same page records a change that retires a lot of old advice: “Starting in Windows 11, version 24H2, the prerequisites of DMA and HSTI/Modern Standby are removed.” Much of what ranks for this problem predates 24H2 and still sends people chasing hardware security test compliance that no longer matters on current builds.
Where the device writes the answer
On the device, open Applications and Services Logs, Microsoft, Windows, BitLocker-API. Microsoft’s troubleshooting guidance points here for missing prerequisites. The known issues article documents the specific events, including event 854, “Failed to enable Silent Encryption. WinRe is not configured.”, with the explanation that “If WinRE isn’t available on the device, provisioning stops.”
For the WinRE case, check its state and enable it with the recovery agent tool, then let the next policy refresh try again:
# Show whether the Windows Recovery Environment is enabled and where it lives
reagentc /info
# Enable it if it reports Disabled
reagentc /enable
For the TPM case, Microsoft’s troubleshooting article is precise about what ready means: “BitLocker will not be able to use the TPM until it is present, ready, enabled, activated, and owned.” A TPM that is present but not owned will not encrypt until that is fixed, and that is a firmware or provisioning job rather than anything Intune can do.
What I would do differently
I would stop debugging BitLocker silent encryption not working from the admin centre. The encryption report tells you a device is not encrypted; the status bitmask and the BitLocker-API log tell you why, in Microsoft’s own words, one reason per bit. Start there and most cases resolve in one step.
I would also audit every policy that touches startup authentication before blaming the disk encryption profile, starting with any security baseline. And on a hybrid joined estate, I would pilot silent encryption on a handful of devices before trusting the requirements list, because the CSP and the Intune page currently disagree on whether it works at all. I have not been able to test that myself. My tenant is a lab with no enrolled devices, so the contradiction above is what the documents state, not something I have measured.
Primary sources, verified on the date below: Encrypt Windows devices with BitLocker using Intune, the BitLocker CSP, and Troubleshooting BitLocker policies from the client side.
Last verified: 9 October 2026. I have not run this in production; my tenant is a lab with no enrolled devices, so everything above is what the documentation states, what practitioners report, and where I would expect it to bite.
