How to Enable and Configure BitLocker Using Microsoft Intune
Deploy silent BitLocker encryption to Windows devices with a Microsoft Intune disk encryption policy - the exact settings that make it silent, recovery-key escrow to Entra ID, and how to verify and enforce it.
- Difficulty
- Intermediate
- Time required
- 20-30 minutes to configure; encryption completes in the background
- Steps
- 8
- Platform
- Microsoft Intune
- Last tested
- July 5, 2026
Table of contents
Quick Answer
Go to the stepsIn the Intune admin center, go to Endpoint security > Disk encryption and create a BitLocker profile for Windows 10 and later. Enable full disk encryption, set Warning for other disk encryption to Blocked, allow standard users to encrypt during Entra join, require TPM startup while blocking any startup PIN or key, and require recovery-key backup to Entra ID before encryption. Assign it to a pilot device group, then monitor the Encryption report.
- Confirm TPM, Native UEFI, Secure Boot, and Entra join.
- Create a Disk encryption > BitLocker profile.
- Set the silent-enablement settings (block startup PIN/key).
- Require recovery-key escrow to Entra ID before encryption.
- Assign to a pilot device group and monitor the report.
Intune admin center > Endpoint security > Disk encryption > Create Policy > Windows 10 and later > BitLockermanage-bde -statusExpected result: Assigned devices silently encrypt in the background, and their recovery keys appear in the Intune Encryption report and on the device's Entra ID object.
Key takeaways
- How to create an Intune disk encryption policy that silently enables BitLocker on Windows devices, escrows recovery keys to Microsoft Entra ID, and how to verify and enforce encryption across a fleet.
- Silent BitLocker only works when a precise combination of settings lines up - most failed deployments come from one wrong toggle (a TPM startup PIN, a blocked prompt, or a missing escrow), so getting the exact configuration right is what turns a policy into encrypted drives.
- Silent BitLocker is a specific combination of settings, not a single toggle - block the TPM startup PIN and require key escrow before encryption.
Introduction
BitLocker turns a lost or stolen laptop into a useless brick for anyone without the key, and Microsoft Intune lets you deploy it across an entire Windows fleet from one policy - encrypting drives, escrowing recovery keys to Microsoft Entra ID, and reporting status centrally. The recommended path is an Endpoint security > Disk encryption BitLocker profile, which is purpose-built for encryption. The catch is that *silent* enablement - encryption with no prompts, even for standard users - depends on a specific combination of settings working together; there is no single "make it silent" switch. This guide gives you that exact combination, the hardware prerequisites that silent mode genuinely requires (TPM, Native UEFI, Secure Boot), how to escrow keys safely before encryption starts, and how to verify and enforce the result. It also flags the setting that quietly breaks most deployments: a TPM startup PIN or key, often inherited from a security baseline, which forces user interaction and blocks silent encryption entirely.
Who this is for: IT admins and MSPs managing Entra-joined Windows 10/11 devices who want centralized, hands-off drive encryption with cloud-escrowed recovery keys.
Before you start
- Access
- Access to the Microsoft Intune admin center (https://intune.microsoft.com) with a role that can create disk encryption policies, and a set of Entra-joined test devices that meet the hardware prerequisites.
- Required roles
- Intune Endpoint Security Manager, or equivalent disk-encryption RBAC
- Intune Endpoint Security Manager, or another role with disk encryption policy and remote key rotation rights
- Required licenses
- Microsoft Intune license
- Windows 10/11 Pro, Enterprise, or Education on target devices
- Microsoft Intune (standalone or via Microsoft 365 E3/E5 or Business Premium)
- Windows 10/11 Pro, Enterprise, or Education on the target devices - no separate BitLocker license is needed
- Environment
- Devices must be Microsoft Entra joined or hybrid joined, run Windows 10 version 1803 or later (1809+ if the signed-in user is a standard user) or Windows 11, boot in Native UEFI mode with Secure Boot on, and have a TPM - TPM 2.0 is strongly recommended and effectively required for reliable silent encryption. Note Windows 10 reached end of support on October 14, 2025.
- Vendor
- Microsoft
- Tested environment
- Verified against Microsoft Learn (Encrypt Windows devices with BitLocker using Intune, Disk encryption policy settings reference, Enforcing BitLocker policies known issues) and Microsoft Q&A, July 2026. Not executed against a live tenant.
- Last tested
- Administrator permissions required
Setting names reflect the Settings-Catalog-format BitLocker profile (the format Intune has used since June 2023); labels can shift as the portal evolves.
The policy takes minutes to build; devices pick it up at their next check-in (up to 8 hours, or immediately on a forced sync) and encrypt in the background.
Warning: Blocking the third-party encryption warning can cause data loss
Setting "Warning for other disk encryption" to Blocked is required for silent enablement, but it also lets BitLocker proceed even if third-party encryption is already present, which can corrupt data. Confirm no third-party encryption exists on target devices (use device inventory) before you deploy.
Warning: A TPM startup PIN or key blocks silent encryption
If any policy - including a Microsoft Defender security baseline - requires a TPM startup PIN or startup key, BitLocker cannot enable silently and will prompt the user. Set the compatible TPM startup PIN and key to Blocked and resolve conflicting baselines first.
Note: Pilot before you scale
Assign to a small pilot device group first. Encryption is disruptive to reverse across a fleet, and policy issues are far easier to catch on 10-20 devices than on thousands.
1Confirm the device prerequisites for silent BitLocker
Make sure your target devices can actually encrypt silently before you build the policy.
On a representative device, verify the four things silent enablement depends on. Check the TPM with tpm.msc or Get-Tpm (you want a present, ready TPM - 2.0 recommended). Check BIOS mode and Secure Boot by running msinfo32 and confirming BIOS Mode: UEFI and Secure Boot State: On (silent encryption needs Secure Boot / PCR 7). Confirm the device is Microsoft Entra joined and running a supported Windows build. Finally, confirm there is no third-party disk encryption installed.
Get-Tpm
Expected result: TPM is present and ready, BIOS Mode is UEFI, Secure Boot State is On, the device is Entra joined, and no third-party encryption is present.
Note
Devices in Legacy BIOS mode or without a TPM cannot silently encrypt - they would require a password or PIN (interactive). A common blocker is Secure Boot State: Unsupported, which prevents silent enablement entirely.
2Create a BitLocker disk encryption policy
Start the recommended, purpose-built policy for BitLocker.
Endpoint security > Disk encryption > Create Policy > Windows 10 and later > BitLockerSign in to the Microsoft Intune admin center at https://intune.microsoft.com (the older endpoint.microsoft.com address redirects here). Go to Endpoint security > Disk encryption, then click Create Policy. Set Platform to Windows 10 and later and Profile to BitLocker, then click Create. Give it a clear name such as WIN-BitLocker-Silent-Pilot.
Expected result: The BitLocker profile wizard opens on the Configuration settings step.
Note
Use the Disk encryption profile rather than the Settings Catalog for silent scenarios - the Settings Catalog lacks the TPM startup-authentication controls needed for reliable silent enablement.
3Configure the base encryption and recovery-escrow settings
Turn on encryption and guarantee the recovery key is saved before any drive is encrypted.
In Configuration settings, set the core options:
- Enable full disk encryption for OS and fixed data drives: Yes
- Encryption method for operating system / fixed / removable drives: XTS-AES 128-bit is the Windows default and best for performance; choose XTS-AES 256-bit if a compliance framework requires it (apply the same method consistently).
- Warning for other disk encryption: Blocked - this is required for silent enablement (see the data-loss warning above).
- Allow standard users to enable encryption during Microsoft Entra join: Allowed.
Then configure recovery so keys escrow to the cloud:
- Save BitLocker recovery information to Microsoft Entra ID: Enabled, storing recovery passwords and key packages.
- Store recovery information in Microsoft Entra ID before enabling BitLocker: Required (this blocks encryption until the 48-digit key is safely escrowed).
- Configure client-driven recovery password rotation: Refresh on for Microsoft Entra joined (or both Entra and hybrid joined) devices.
Expected result: Encryption is enabled, the escrow-before-encryption safeguard is on, and recovery password rotation is set.
Note
There is no "rotation frequency in days" field - client-driven rotation is a mode that automatically rotates a recovery password after it has been used to unlock a device, invalidating the old one.
4Set the OS drive settings that make encryption silent
Require the TPM while ensuring no startup PIN or key forces user interaction.
Expand the operating system drive settings and configure them so encryption needs no user input at startup:
- Require additional authentication at startup: Yes
- Compatible TPM startup: Required
- Compatible TPM startup PIN: Blocked
- Compatible TPM startup key: Blocked
- Compatible TPM startup key and PIN: Blocked
Blocking the PIN and key options is what keeps encryption silent - requiring either one forces the user to interact at boot and disables silent enablement. Leave Minimum PIN length unset unless you deliberately choose an interactive (PIN-based) deployment instead.
Expected result: The OS drive is configured to require the TPM alone, with no startup PIN or key, which is the combination needed for silent encryption.
Note
If you actually want an interactive, PIN-protected deployment, set Compatible TPM startup PIN to Required and configure a minimum PIN length instead - but then encryption is no longer silent.
5Assign the policy to a pilot device group
Target the right devices and start small.
Assignments > Add groups > (device group)Click through Scope tags (assign tags if you use role-based administration, otherwise continue), then on Assignments click Add groups under Included groups and select a device group - for example BitLocker-Pilot-Devices with 10-20 machines. Add an Excluded group for any devices that must not be encrypted. Disk encryption policies should target device groups, not user groups, so encryption applies consistently regardless of who signs in.
Expected result: The policy is scoped to your pilot device group with any exceptions excluded.
Note
Avoid overlapping BitLocker policies on the same devices - conflicting settings (especially TPM startup requirements) are a leading cause of failed silent enablement.
6Review, create, and monitor deployment
Deploy the policy and watch encryption progress across the pilot.
Devices > Monitor > Encryption reportOn Review + create, check the platform, profile, settings, and assignments, then click Create. Devices apply the policy at their next check-in (up to 8 hours, or immediately if you force a sync). Track progress under Devices > Monitor > Encryption report, which shows each device's readiness and encryption state and whether its recovery key is escrowed.
Expected result: Pilot devices move from a ready state to encrypting, then to encrypted, with recovery keys shown as escrowed.
Note
The report's Encryption readiness column is the fastest way to spot devices that fail a prerequisite (no TPM, Legacy BIOS, Secure Boot off) before they ever start encrypting.
7Verify encryption and key escrow on a device
Confirm the drive is actually protected and the recovery key is retrievable.
Devices > All devices > (device) > Recovery keysOn a pilot device, open an elevated prompt and check status:
manage-bde -statusGet-BitLockerVolume
Confirm the OS volume shows Protection Status: Protection On, an XTS-AES encryption method, and a TPM key protector. Then confirm the recovery key is centrally available: in Intune, open Devices > All devices, select the device, and check its Recovery keys, or view it on the device's object in Microsoft Entra ID.
manage-bde -statusExpected result: The device reports Protection On with a TPM protector, and its recovery key is visible in Intune and on the Entra ID device object.
Note
End users can retrieve their own recovery key without a helpdesk call through the Company Portal app or the My Account portal (myaccount.microsoft.com); these keys are treated as corporate resources and access can be logged and gated by Conditional Access.
8Enforce encryption with a compliance policy (optional)
Make BitLocker a condition of access, not just a deployed setting.
Devices > Compliance > Create policy > Windows 10 and later > Device HealthGo to Devices > Compliance > Create policy, choose Windows 10 and later, and name it (for example WIN-Compliance-BitLocker). Under Device Health, set Require BitLocker to Require (optionally add Require Secure Boot and Require code integrity). On Actions for noncompliance, stage escalating actions - mark noncompliant immediately, email the user after a day, and only block access to resources after a grace period. Assign it to the same device groups as your BitLocker policy.
Expected result: Devices without BitLocker are flagged noncompliant, and - combined with a Conditional Access policy requiring compliant devices - can be blocked from corporate resources.
Note
Give users time and support before the block action triggers; an abrupt access block on an encryption hiccup generates avoidable helpdesk load.
How to Confirm BitLocker Deployed Correctly Through Intune
Confirm configuration
A healthy deployment shows up in three places that should agree. On the device, manage-bde -status and Get-BitLockerVolume report Protection On, an XTS-AES method, and a TPM key protector - with no prompt ever shown to the user. In Intune, Devices > Monitor > Encryption report shows the device as encrypted with its recovery key present. And on the device's Microsoft Entra ID object, the recovery key is escrowed and retrievable. If the device encrypted but no key is escrowed, treat it as incomplete - the escrow-before-encryption safeguard should normally prevent that, and its absence points to an Entra connectivity or policy problem.
Normal result: Silent encryption with Protection On, XTS-AES, a TPM protector, no user prompts, and a recovery key visible in both Intune and Entra ID.
Abnormal result: The user saw an 'Encryption needed' toast or a BitLocker wizard (silent enablement was blocked), the device shows 'Not applicable' or an error, or the drive encrypted without an escrowed key.
Encrypted OS volume
Protection Status: Protection On; Encryption Method: XTS-AES 256; Key Protectors: TPM
Expected manage-bde output after a successful silent deployment.
Escrowed key
Recovery key visible under Devices > device > Recovery keys
Confirms the key was backed up to Entra ID before encryption.
Troubleshooting
Devices show an 'Encryption needed' prompt instead of encrypting silently
Warning
Cause: A TPM startup PIN or startup key is required somewhere in policy - often from a Microsoft Defender security baseline - which forces user interaction and blocks silent enablement.
In the BitLocker profile set Compatible TPM startup PIN and Compatible TPM startup key to Blocked, and check any assigned security baselines for conflicting TPM startup settings. Remove the conflict, then resync the device.
Device shows 'Not applicable' or won't encrypt
Warning
Cause: Missing/disabled TPM, Legacy BIOS, or Secure Boot off - silent BitLocker requires a TPM, Native UEFI, and Secure Boot (PCR 7).
Enable the TPM in firmware, switch the BIOS mode to Native UEFI, and turn on Secure Boot. Verify with msinfo32 (BIOS Mode: UEFI, Secure Boot State: On) and re-check the Encryption readiness column.
"Failed to enable Silent Encryption. WinRE is not configured"
Warning
Cause: The Windows Recovery Environment is missing or disabled, which BitLocker needs during provisioning.
Check WinRE with reagentc /info; if it is disabled, re-enable it with reagentc /enable (repairing or recreating the recovery partition if needed), then retry encryption.
Hybrid-joined devices encrypt inconsistently
Note
Cause: The Disk encryption policy requires Active Directory backup of recovery information for silent encryption on hybrid-joined devices, but Intune can reach devices that have no line of sight to a domain controller.
For off-network hybrid devices, ensure domain-controller connectivity during encryption, or use the Endpoint protection template (Device configuration) that escrows recovery info to Entra ID only. Confirm keys land in Entra via the Encryption report.
Third-party encryption is present on the drive
Critical
Cause: Another product (e.g. VeraCrypt or a vendor tool) already encrypts the volume; layering BitLocker on top can render data unusable.
Fully decrypt the drive with the third-party tool (or manage-bde -off if it is a prior BitLocker state) and wait for decryption to finish before the Intune policy applies. Never rely on the blocked warning to "just work" over existing encryption.
Frequently asked questions
Can Intune enable BitLocker silently without any user interaction?
Yes. With the right settings - encryption enabled, the third-party encryption warning blocked, standard-user encryption allowed, and no TPM startup PIN or key - an Entra-joined device with TPM 2.0, Native UEFI, and Secure Boot encrypts silently, even for non-admin users.
Where are BitLocker recovery keys stored, and how do users get them?
Keys are escrowed to the device's Microsoft Entra ID object and are visible to admins in the Intune Encryption report and device properties. Users can retrieve their own key through the Company Portal app or the My Account portal.
Should I use XTS-AES 128-bit or 256-bit encryption?
XTS-AES 128-bit is the Windows default and is recommended for performance on modern hardware. Choose 256-bit when a compliance framework requires a higher strength; apply the same method consistently across drive types.
What happens to devices without a TPM?
They cannot encrypt silently, because BitLocker would need a password or startup key that requires user interaction. Such devices show as not applicable for silent encryption; use an interactive method or exclude them.
Should the policy target user groups or device groups?
Target device groups. Disk encryption policies apply to the device, so device-group assignment ensures encryption is consistent regardless of who signs in.
Conclusion
Deploying BitLocker from Intune is straightforward once the pieces line up: create an Endpoint security disk encryption BitLocker profile, enable encryption, block the third-party warning, allow standard-user encryption, require the TPM while blocking any startup PIN or key, and require recovery-key escrow to Entra ID before encryption begins. Assign it to a pilot device group, watch the Encryption report, and verify Protection On with an escrowed key on real devices. Enforce it with a compliance policy and Conditional Access, and remember the settings that silently break silent mode - a TPM startup PIN, a missing Secure Boot, or existing third-party encryption.
Silent BitLocker is a specific combination of settings, not a single toggle - block the TPM startup PIN and require key escrow before encryption.
Intune admin center > Endpoint security > Disk encryption > Create Policy > Windows 10 and later > BitLockerSources4
