BitLocker – CIAOPS

Every MSP ends up doing BitLocker. Very few do it silently on the first attempt. Between TPM quirks, third-party encryption leftovers, and the three different Intune policy surfaces that all claim to configure BitLocker, the difference between “encrypted fleet with recoverable keys” and “2am call from a locked-out CEO” is a handful of settings. Here’s the pattern to deploy in production under Microsoft 365 Business Premium.

Prerequisites people skip

Silent means standard user, no prompts, no elevation — which is a higher bar than “BitLocker on.”

TPM 2.0, ready state, UEFI, Secure Boot on. If the TPM reports “not ready” or is owned by a prior OEM image, silent encryption aborts. Check with Get-Tpm before blaming policy.
Entra joined or Hybrid joined. Workgroup and AD-only devices have no key escrow target and will not silently encrypt.
No third-party encryption agent. McAfee DE, Sophos SafeGuard, legacy Dell Data Protection — all block BitLocker takeover until fully decrypted and uninstalled.
No startup PIN or startup key requirement. Silent mode and pre-boot authentication are mutually exclusive. Pick one.
WinRE present and healthy. BitLocker uses it for recovery.

If any of those are wrong, don’t touch policy yet. Fix the device first.

Where to configure it

Ignore the Settings Catalog for this one. Microsoft is explicit that the Settings Catalog does not expose the TPM startup authentication controls silent enablement depends on (docs).

Use the Endpoint security path:

Intune admin center → Endpoint security → Disk encryption → Create Policy → Platform: Windows → Profile: BitLocker.

The settings that actually matter for silent:

Enable full disk encryption for OS and fixed data drives: Yes
Hide prompt about third-party encryption: Yes
Allow standard users to enable encryption during Autopilot: Yes
Require device to back up recovery information to Azure AD: Yes (gates encryption on successful escrow — this is the setting that saves you)
Recovery password rotation: Enable on Entra and Hybrid-joined devices
OS and fixed drive: XTS-AES 256, TPM-only protector, no PIN

Full setting reference: Disk encryption profile settings.

The rollout pattern

Do not target All Devices. Ever.

Pilot ring (5–10 devices): your own, one per client hardware family. Watch the Endpoint security → Disk encryption report for “Encrypted” status and a recovery key present in Entra. If the key isn’t there, the device isn’t safe, regardless of what Windows says.
Early ring (10–20% by dynamic group): let this soak for a week. Check the encryption report daily. Anything stuck in “Waiting for response” usually means TPM readiness or a WinRE issue — remediate per device, don’t loosen policy.
Broad rollout: remaining corporate devices via a dynamic group filtered on deviceOwnership eq "Company". Never include BYO.
New builds: bake the policy into Autopilot so encryption completes during ESP. Standard-user silent enablement only works if “Allow standard users to enable encryption during Autopilot” is Yes — double-check before you cut a new image.

The help desk also needs the recovery-key retrieval flow documented before you go broad, not after the first lockout.

The pitfalls that bite

Silent and startup PIN are incompatible. If compliance demands pre-boot auth, you’re running standard BitLocker, not silent. Decide once.
Recovery key escrow failures hide in plain sight. Without “Require device to back up recovery information to Azure AD = Yes”, devices encrypt, keys never land in Entra, and you discover it the day a laptop gets stolen. Audit the encryption report monthly — the ground truth is “Recovery key: Yes/No” per device, not policy compliance.
Don’t mix endpoint protection + disk encryption profiles targeting the same devices. Conflicts resolve unpredictably. Pick the Disk encryption profile and delete the legacy Endpoint protection one (policy comparison).

Get those three right and BitLocker becomes a checkbox — exactly what your clients are paying for.

Bitlocker is the Microsoft technology that allows you to full encrypt your Windows PC hard disk. This is a good thing as it provides additional security and protection for that device, especially if that device ever gets lost or stolen. Typically, Bitlocker will use the Trusted Platform Module (TPM) chip on your PC to provide the encryption key for BitLocker. This means that the user doesn’t have to type in a password to unlock their drive for use. Now having an automatically managed key raises a question, what happens if you actually need that key? If everything is automated and I never see the key how can I get access to it if needed? If, say, the original PC died and I wanted to recover the original encrypted drive how would I recover? To do that, you’d need the encryption key.

You can manually backup you BitLocker Recovery key to a file or USB drive however, if your device is Azure AD joined then that Recovery Key should be saved directly into Azure AD. Here’s how you check this.

If you are using something Microsoft 365 Business and Intune navigate to Intune inside the Azure portal. Select Devices.

Select All Devices.

Select the PC in question from the list.

Now select the Recovery keys option.

On the right you should see the Recovery keys listed. You’ll note here that I don’t see the expected BitLocker Key.

If you don’t see the Recovery Key for your device go to that device and open BitLocker management on your PC. Select the option to Back up your recovery key as shown.

Then select the option to Save to your cloud account as shown. This should then upload the Recovery Key to Azure AD, provided you have an Azure AD joined machine first of course.

If you return to the device in Intune and refresh the display, you should now see the Recovery key for you device as shown above.

If you do not have access to the Intune portal, perhaps because you are not an administrator, simply navigate to:

https://account.activedirectory.windowsazure.com

and login with your Microsoft 365/Office 365 credentials and view your profile. You should then see any registered device plus the option to get the BitLocker keys as shown. Remember BitLocker is for Windows devices, not iOS or Android.

Even though Azure AD joined machines should save BitLocker keys automatically, I’d suggest you go and have a look and make sure that they are indeed actually there! Best be sure I say.