Managing BitLocker Encryption with Microsoft Intune

A lost or stolen laptop is only a data breach if the disk is readable. BitLocker management with Intune is how you make sure every Windows device in the fleet encrypts itself and, just as importantly, escrows its recovery key somewhere you can actually retrieve it. This post covers deploying a disk encryption policy that encrypts silently, the one setting that decides whether you can ever recover a device, and the startup-authentication trap that quietly stops silent encryption from working.

Key Takeaways

• BitLocker management with Intune uses a disk encryption policy to enforce encryption and escrow the recovery key to Entra ID automatically.
• Silent encryption only works when no TPM startup PIN or startup key is required — configuring either forces an interactive prompt and breaks the silent flow.
• The "require recovery information to be saved to Entra ID before enabling" setting is what guarantees you never end up with an encrypted device whose key was never escrowed.
• Recovery keys are retrievable from the Intune or Entra admin center, and users can self-serve their own key through the account portal.
• The disk encryption report tells you which devices are actually encrypted versus merely targeted, which is the difference between a policy and a result.

Environment

• Microsoft Intune (Plan 1) with Windows 10/11 devices enrolled.
• Entra ID, with devices Entra joined or Microsoft Entra hybrid joined.
• Devices with a TPM 2.0 chip, UEFI firmware, and Secure Boot — the baseline for modern silent encryption.
• Windows 10/11 Pro, Enterprise, or Education, which is where BitLocker is available.

The Problem

Encryption itself is the easy part — BitLocker has been in Windows for years and the hardware does the work. The two things that actually go wrong in practice are recovery and rollout. Recovery goes wrong when a device encrypts but its recovery key never makes it to a directory, so when someone hits a recovery prompt at the airport there is no key to give them. Rollout goes wrong when encryption demands user interaction — a PIN at boot, a prompt mid-day — and the helpdesk inherits a queue of confused users.

Intune solves both, but only if you configure it deliberately. The defaults are deliberately cautious, and at least one of them — whether the recovery key must be escrowed before encryption proceeds — is left permissive in a way that can bite you months later. The point of managing BitLocker through Intune is to make encryption automatic and recovery guaranteed, not just to turn it on.

The Solution

Step 1 — Create the disk encryption policy

In the Microsoft Intune admin center, go to Endpoint security → Disk encryption → Create policy, choose the Windows platform and the BitLocker profile. This is the modern home for BitLocker settings, replacing the older endpoint-protection device configuration template. The settings break down into how the OS drive is encrypted, how fixed and removable drives are handled, and how recovery works.

For the encryption method, XTS-AES 128-bit is the sensible default for fixed and OS drives; 256-bit is available if your compliance regime calls for it. Removable drives are a separate decision — many environments leave them unencrypted by policy and handle them through data-loss prevention instead.

Step 2 — Configure silent encryption correctly

Silent encryption means BitLocker turns on without bothering the user, using the TPM to protect the key. The combination that makes this work is enabling the OS-drive settings that allow encryption with a TPM-only protector, allowing standard users to enable encryption during Entra join, and not warning about other disk encryption. The critical detail that trips people up:

• Do not require a TPM startup PIN or startup key. If either is set to Required, silent encryption cannot complete — BitLocker needs to prompt the user to set the PIN, which is the opposite of silent. Leave startup authentication at TPM-only if your threat model allows it.
• A startup PIN does add protection against certain physical attacks. It is a real trade-off: TPM-only encrypts silently with no user friction; TPM+PIN is stronger but interactive. Pick one intentionally rather than discovering the conflict after a failed rollout.

Microsoft's guide to encrypting Windows devices with Intune documents the exact silent-enablement prerequisites, and they are worth reading before you assign the policy to anything but a test group.

Step 3 — Force recovery-key escrow before encryption

This is the setting that matters most and is easiest to get wrong. Under the OS drive recovery settings, there is an option to require the device to back up recovery information to Microsoft Entra ID before enabling BitLocker. Its behaviour:

• Not configured (default): BitLocker proceeds to encrypt even if the recovery key fails to upload. You can end up with an encrypted device whose key is nowhere in the directory.
• Yes: BitLocker will not finish enabling until the recovery key has been successfully saved to Entra ID. Encryption and escrow succeed or fail together.

Set it to Yes. The whole point of central management is that recovery is guaranteed, and the cost of an un-escrowed key is a permanently inaccessible device. With silent encryption, the recovery key is backed up to Entra ID automatically as the device encrypts, so this setting mostly insures you against the failure case.

Step 4 — Retrieve a recovery key when you need one

When a device hits a recovery prompt, the key lives on the device's object in the directory. From the Intune admin center → Devices → Windows, select the device and open Recovery keys; the Entra admin center exposes the same data on the device's BitLocker keys blade. Reading a recovery key is a privileged action and is recorded in the audit log, the same as reading a LAPS password.

Users can also self-serve. A signed-in user can retrieve their own device's recovery key from their account portal, which cuts the helpdesk out of the most common recovery case entirely. Decide whether you want that enabled, since it changes who can read keys.

Step 5 — Verify with the encryption report

A policy that is assigned is not the same as a device that is encrypted. Under Endpoint security → Disk encryption, the report lists each device's encryption readiness and status, including the reason a device has not encrypted — most often an unmet prerequisite like missing TPM readiness or a pending reboot. Checking encryption state is exactly the kind of fleet-wide posture signal that pairs with device compliance: an unencrypted device is a non-compliant device, and you can feed that straight into the access decisions I covered in essential Conditional Access policies for Microsoft 365.

Frequently Asked Questions

Why is BitLocker not encrypting silently on my devices?

The most common cause is a required TPM startup PIN or startup key. If either is set to Required in the policy, BitLocker must prompt the user and cannot encrypt silently. Other causes are missing TPM readiness, the device not being Entra joined, or Secure Boot being disabled.

What happens if the recovery key fails to back up to Entra ID?

It depends on the "require backup before enabling" setting. If it is Not configured, encryption proceeds anyway and you may have an encrypted device with no escrowed key. If it is set to Yes, BitLocker will not finish enabling until the key is saved, so you never end up in that state.

Can standard users retrieve their own BitLocker recovery key?

Yes. A signed-in user can retrieve the recovery key for their own registered device through their account portal. This handles the most common recovery scenario without involving the helpdesk, though you should confirm this self-service path fits your support model.

Do I need a startup PIN if the device has a TPM?

Not necessarily. TPM-only encryption is silent and protects against the common lost-or-stolen-device scenario. A startup PIN adds protection against certain physical and cold-boot attacks but requires user interaction at boot. It is a deliberate trade-off between security and friction, not a default you must enable.

Does BitLocker management require an Entra ID P1 or P2 license?

The BitLocker policy and recovery-key escrow work with Intune Plan 1 and standard Entra ID. You only need Entra ID P1 or higher if you want to enforce encryption as part of a Conditional Access decision through device compliance, which is a separate, complementary control.

Conclusion

Managing BitLocker through Intune turns disk encryption from a per-device chore into a fleet-wide guarantee. The encryption itself is handled by the hardware; the value Intune adds is making it automatic and, crucially, making recovery dependable by escrowing every key to Entra ID.

Two settings carry most of the weight. Keep startup authentication at TPM-only if you want silent encryption, and require recovery-key backup before enabling so you never produce an encrypted device you cannot recover. Get those two right, verify with the encryption report rather than trusting the assignment, and the rest is the kind of control that just runs quietly in the background — which is exactly where you want your disk encryption to live.

Related Posts

• Essential Conditional Access Policies for Microsoft 365 — make encryption a precondition for access through device compliance.
• Windows Security: Registry Forensics — Where Attackers Hide — context on the local artifacts encryption protects at rest.
• Essential Windows Event IDs for Security Monitoring — the monitoring layer that complements device hardening.

Editorial note: posts on this blog are drafted with AI assistance and then reviewed, edited, and tested against a real environment before publishing. Commands, output, and screenshots come from systems I actually ran the work on.