π§±πͺπ»ES - BitLocker
The control that decides whether a stolen laptop is an insurance claim or a data breach notification. Silent, invisible to the user, and worthless if the recovery key is not somewhere you can find it.
What this policy is about πβ
A laptop goes missing. It happens on a train, in a taxi, out of a car in a station car park, and it happens to every customer eventually. What happens next is decided entirely by a setting somebody either configured or did not.
Encrypted, with the key escrowed: the device is a hardware loss. You bill for a replacement, the user gets a new machine, and the incident closes. Not encrypted: whoever has it can pull the drive, mount it on another machine, and read every document, every cached credential, every mailbox that was sitting in the local OST. That is a personal data breach, and in the Netherlands that means the clock on a notification to the Autoriteit Persoonsgegevens has already started.
This policy makes the first outcome the automatic one. BitLocker turns itself on during enrolment, without asking the user anything, and the recovery key lands in Entra ID before the encryption even starts.
Configured correctly, nobody sees a prompt, a wizard, or a request to write down a 48-digit number. The device encrypts in the background on first sign-in and the user never learns it happened. The best security control is the one nobody has to cooperate with.
Why this matters π΅οΈβ
Encryption is the one control on this site that fails in a way you cannot argue your way out of. Most misconfigurations produce risk you can debate: this one produces a notifiable incident with a fixed deadline and a regulator on the other end of it. And it is the first thing anyone asks about after a loss, which means it is also the first thing you want to be able to answer instantly rather than by going device by device.
The other half is the recovery key, and it is the half that actually goes wrong in practice. Plenty of devices are encrypted by somebody at some point; far fewer have a key anyone can produce eighteen months later when a firmware update trips the TPM and the machine boots to a recovery prompt in front of a very unimpressed director. Escrow to Entra ID before encryption starts is what turns that from an outage into a two-minute lookup.
π οΈ Configurationβ
Where: Intune admin center β Endpoint security β Disk encryption β Create policy β Windows β BitLocker.
Base settingsβ
| Setting | Value |
|---|---|
| Require Device Encryption | Enabled |
| Allow Warning For Other Disk Encryption | Disabled |
| Allow standard users to enable encryption during Autopilot | Allowed |
| Configure Recovery Password Rotation | Refresh on for Microsoft Entra ID joined devices |
Those four together are what "silent" means. Allow Warning For Other Disk Encryption = Disabled is the counter-intuitive one: it suppresses the prompt that would otherwise ask the user for consent, which is precisely what lets encryption start on its own.
OS driveβ
| Setting | Value |
|---|---|
| Encryption method for operating system drives | XTS-AES 256-bit |
| Require additional authentication at startup | Enabled |
| Configure TPM startup | Required |
| Configure TPM startup PIN | Do not allow |
| Recovery key file creation | Blocked |
| Save BitLocker recovery information to Microsoft Entra ID | Enabled |
| Store recovery information in Entra ID before enabling BitLocker | Required |
| Hide recovery options during BitLocker setup | Enabled |
Fixed data drivesβ
| Setting | Value |
|---|---|
| Encryption method for fixed data drives | XTS-AES 256-bit |
| Write access to fixed data drives not protected by BitLocker | Blocked |
| Save BitLocker recovery information to Microsoft Entra ID | Enabled |
| Store recovery information in Entra ID before enabling BitLocker | Required |
Assignmentβ
| Setting | Value |
|---|---|
| Assignment, include | π‘οΈπͺπ»βοΈGroup - Windows Devices |
| Assignment, exclude | π‘οΈπͺπ»βοΈGroup - Devices - Virtual Machines, π‘οΈπͺπ»βοΈGroup - Autopilot Devices - W365 Boot |
"Required" on the escrow setting is doing the heavy lifting. Set to Required, Windows refuses to begin encrypting until the key has actually been written to Entra ID. Set to anything softer and you get the failure mode that ruins the whole exercise: a device that encrypted itself, and a key that never made it anywhere you can reach. Never relax this one.
XTS-AES 256 everywhere, and set it before the fleet encrypts. The encryption method applies at the moment a drive is encrypted and changing it afterwards does nothing to drives that are already done. Getting this right on day one avoids a decrypt-and-re-encrypt cycle you will not enjoy explaining.
No startup PIN, deliberately. A pre-boot PIN is real additional protection against a determined attacker with physical access and time. It is also a second credential every user types before Windows even loads, on top of the Hello PIN they type afterwards, and it breaks unattended reboots after patching. For MKB on modern hardware with TPM 2.0 and Hello, TPM-only is the right trade. Regulated customers who genuinely need pre-boot authentication are a documented exception, not a baseline change.
Caveats β οΈβ
Windows 11 Pro is enough, Home is not. BitLocker needs Pro, Enterprise or Education. If a device shipped with Home, no policy in Intune will fix it: the feature is not there. On a tenant takeover this shows up as a handful of machines that report as non-compliant forever, and the answer is an edition upgrade, not troubleshooting.
Virtual machines and Cloud PCs are excluded. A VM without a virtual TPM cannot satisfy the policy and will churn in a failure loop. Windows 365 Cloud PCs are encrypted by Microsoft at the platform layer, so pointing BitLocker at them adds a compliance headache and no security. Both groups sit this one out.
Encryption is permanent, the policy is not. Unassign the profile and BitLocker stops being enforced, but every drive that is already encrypted stays encrypted, with keys that were escrowed under a policy that no longer applies. That is fine, and it is worth saying out loud: this is not a setting to test on production hardware "to see what happens".
Firmware updates and the recovery prompt. A BIOS update, a Secure Boot change, or a hardware swap can alter the measurements the TPM seals against, and the device boots to a recovery screen. This is BitLocker working, not failing. It is also exactly when the escrowed key earns its keep, so make sure the helpdesk knows where to look before the first mass firmware rollout: Entra ID β Devices β the device β BitLocker keys.
Who can read a recovery key. By default, standard users can retrieve keys for devices they own from the My Account portal, and helpdesk roles can retrieve them from Entra. Worth checking that Restrict users from recovering the BitLocker keys for their owned devices matches what the customer actually wants: convenient self-service, or keys that only support can hand out.
Removable drives are a separate conversation. Denying write access to unencrypted USB sticks is a genuinely strong control and a genuinely large support burden, because every partner's file transfer, every camera card and every conference giveaway stick stops working the same afternoon. It is not in this baseline. Deploy it as its own policy when a customer asks for it, with the helpdesk warned.
π₯ Assignment scopeβ
Baseline for every physical Windows device. Virtual machines and Cloud PCs are excluded structurally rather than by exception, because the platform handles it differently, not because someone asked nicely.
No exception group exists for this policy and none should. "This device does not need encryption" is not a scenario that survives contact with an incident.
Worth verifying at tenant takeover: which devices report as encrypted but have no key in Entra ID. That combination looks healthy on a compliance dashboard and is the exact state that leaves you locked out later. The BitLocker compliance policy tells you the drive is encrypted; only the Entra key blade tells you whether you can get back into it.
π Relatedβ
- ππͺπ»Compliance - Device Health - Bitlocker: the compliance check that gates Conditional Access on this policy having worked.
- βοΈπͺπ»CP - Security - Config Refresh: re-applies this policy every 30 minutes if something tries to switch it off.
- π§±πͺπ»ES - Windows Hello for Business: the sign-in credential that makes skipping a pre-boot PIN reasonable.
Encrypt everything, escrow before you encrypt, and find out where the keys live before the day you need one. π