Skip to main content

🧱πŸͺŸπŸ’»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.

🧱Type Endpoint SecurityπŸͺŸPlatform WindowsπŸ’»Target Devices
reference-build Β· es-bitlockerGolden Master reference
License tier
Business Premium (Intune, Windows 11 Pro)
Control plane
Intune Endpoint Security, BitLocker CSP
Scope
Windows 11 Pro/Enterprise, physical devices
Reversibility
clean-revert (policy), permanent (encryption)

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.

πŸ€” Silent means silent

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​

SettingValue
Require Device EncryptionEnabled
Allow Warning For Other Disk EncryptionDisabled
Allow standard users to enable encryption during AutopilotAllowed
Configure Recovery Password RotationRefresh 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​

SettingValue
Encryption method for operating system drivesXTS-AES 256-bit
Require additional authentication at startupEnabled
Configure TPM startupRequired
Configure TPM startup PINDo not allow
Recovery key file creationBlocked
Save BitLocker recovery information to Microsoft Entra IDEnabled
Store recovery information in Entra ID before enabling BitLockerRequired
Hide recovery options during BitLocker setupEnabled

Fixed data drives​

SettingValue
Encryption method for fixed data drivesXTS-AES 256-bit
Write access to fixed data drives not protected by BitLockerBlocked
Save BitLocker recovery information to Microsoft Entra IDEnabled
Store recovery information in Entra ID before enabling BitLockerRequired

Assignment​

SettingValue
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.


Encrypt everything, escrow before you encrypt, and find out where the keys live before the day you need one. πŸ”