A stolen laptop can expose far more than local files. It can hold cached Exchange Online mail, synced Office365 documents, Teams data, browser sessions, and tokens tied to Azure and other Microsoft services.
For most IT teams in 2026, a safe BitLocker setup starts long before you click Create policy. You need to verify your encryption method, ensure you have working TPM hardware, maintain clean recovery key handling, and execute a rollout plan that will not lock users out of their devices.
The good news is that Windows 11 and Windows 10 give you a solid path if you set the pieces in the right order using Microsoft Intune.
Key Takeaways
- Prioritize Managed BitLocker: For company-owned Windows 11 devices, use policy-driven BitLocker via Intune rather than basic device encryption to ensure standardized settings and reliable recovery key management.
- Ensure Hardware Readiness: Verify that devices meet TPM 2.0 standards, have Secure Boot and UEFI mode enabled, and maintain a healthy Windows Recovery Environment (WinRE) before deploying encryption policies.
- Secure Recovery Escrow: Always configure Intune to back up recovery keys to Microsoft Entra ID before encryption begins; never treat a device as fully protected until the key is confirmed in the cloud.
- Adopt Ring-Based Rollouts: Deploy encryption in phases, starting with a small pilot group across different hardware manufacturers to identify firmware-related issues or potential conflicts before expanding to the fleet.
- Maintain Hygiene: Use device-based groups for assignments, avoid mixing silent deployment with startup PIN requirements, and proactively suspend protection before performing BIOS or motherboard maintenance to prevent unnecessary recovery prompts.
Pick the right encryption approach first
On modern Windows 11 hardware, device encryption and BitLocker Drive Encryption are close relatives. While device encryption provides a simpler, consumer-style experience that users might occasionally toggle via the Control Panel, BitLocker is the managed, policy-driven version that professional company fleets require.
For company laptops, the choice usually looks like this:
| Option | Best fit | Main limits |
|---|---|---|
| Device encryption | Small environments, lightly managed devices, supported hardware with default protection | Less control over settings, reporting, drive types, and rollout behaviour |
| BitLocker with Intune | Company-owned Windows 11 laptops, compliance needs, recovery key escrow, standardised policy | Needs planning around TPM, firmware, key storage, and assignments |
If a laptop is enrolled in Intune, joined to Microsoft Entra ID, and holds company data, managed BitLocker is usually the better path. That matters even more when users keep Outlook OST files from Exchange Online, OneDrive content, or downloaded Office365 data on disk.
While some administrators still refer to Active Directory, current Microsoft terminology uses Entra ID. In either case, the key point is the same: your BitLocker recovery data needs a trusted cloud escrow target before you encrypt at scale.
Access also matters. Give policy creation rights only to admins who manage endpoint security. They need permission to create Intune endpoint security policies, assign them to device groups, and review encryption reports. Recovery key retrieval should stay even tighter, because that permission can unlock a lost or seized laptop. Most teams do not need to hand out Global Administrator for daily BitLocker work.
One more decision sits here. If your security policy requires a startup PIN, do not use the same silent deployment pattern described later. Silent enablement and pre-boot PIN requirements do not mix, and a rushed change there is one of the fastest ways to create a help desk storm.
Check TPM, firmware, and Windows readiness
BitLocker works best when the laptop already meets the necessary system requirements and boot configurations. On company-managed Windows Enterprise devices, that means having a Trusted Platform Module (TPM) active, UEFI boot enabled, Secure Boot turned on, and a healthy Windows Recovery Environment.
Start with the hardware. On the device, run Get-Tpm in PowerShell to confirm the TPM chip is present and ready. If the result shows the hardware is missing, not ready, or stuck in an odd ownership state, fix that first in the BIOS menu or through the OEM process. You must ensure the device meets the TPM 2.0 standard before pushing your policy, rather than hoping the endpoint sorts itself out later.
Next, confirm the boot state. A laptop that still runs in legacy BIOS mode can derail a silent BitLocker rollout. Secure Boot also matters because it protects the boot chain that BitLocker relies on. You can confirm the current state in System Information, and you should run reagentc /info to ensure WinRE is enabled. Silent encryption often fails when WinRE is broken or missing.
Company ownership is another filter. Target only devices you actually manage. In Intune, use device groups and exclude BYO, labs, and most VMs. A dynamic group based on deviceOwnership eq "Company" is a far safer starting point than “All Devices”.
If the device can’t store its recovery key in Entra and can’t pass TPM checks, it isn’t ready for silent BitLocker.
This is also the right time to look for existing encryption. Some OEM builds arrive with device encryption already active. Some users may have turned on BitLocker manually, while others may still have remnants of third-party disk encryption. Those differences can trigger conflicts, warning prompts, or false error states in Intune later.
A clean pre-check saves time because BitLocker failures rarely come from one bad setting alone. More often, they come from two or three small issues stacked together, such as a healthy TPM on a device with broken WinRE, or a good Intune policy assigned to a hybrid device that cannot back up its key where you expect.
Store recovery keys where your team can actually use them
Recovery keys are the components people remember only after a lockout happens. By then, it is often too late. A solid BitLocker setup starts with a robust plan for your recovery key.
For pure Entra-joined laptops, store these keys in Microsoft Entra ID rather than on-premises Active Directory. If you still run hybrid-joined devices, then on-premises Active Directory can fit specific workflows, but do not point cloud-first laptops at the wrong escrow target. When admins mix that up, BitLocker Drive Encryption may never start, or the recovery process becomes an impossible scavenger hunt.
Within the Intune policy, require the device to back up recovery information before the process completes. That setting puts a necessary guardrail around the rollout. If the recovery key cannot escrow to the cloud, the device should not move forward as if it is fully protected.
Keep access to sensitive data narrow. Your service desk may need the ability to retrieve a key during a verified support call, but that does not mean everyone should have broad admin rights across Intune and Entra. Use role-based access, scope tags where needed, and a clear approval path for sensitive devices.
Also, keep keys out of insecure locations. Do not paste them into tickets, Teams chats, or email threads. Do not send them through Exchange Online as plain text because that creates a second exposure point. Instead, retrieve the information when needed, verify the user and device, and record only the support event rather than the full key itself.
Key rotation matters as well. Client-driven recovery password rotation is worth enabling on Entra-joined and hybrid Entra-joined devices. If a key gets used during a recovery event, rotating it reduces the chance that an old value lingers in screenshots, notebooks, or copied chat logs.
Create the BitLocker policy in Intune
Microsoft’s own Intune BitLocker guide tracks the current admin center flow, and it’s the right baseline for Windows 11 fleets in 2026. The shortest path is through Endpoint security, not the older device configuration maze.
- In the Microsoft Intune admin center, go to Endpoint security -> Disk encryption -> Create Policy. Choose Windows 10 and later as the platform and BitLocker as the profile to build your primary BitLocker policy. In 2026, that still covers Windows 11 devices.
- Name the BitLocker policy clearly. A format like “Company BitLocker Silent 2026” makes reporting easier later, especially if you run pilot and production variants.
- Turn on Require Device Encryption. For silent rollout, also disable Allow Warning For Other Disk Encryption. That helps suppress prompts that can appear when Windows suspects another encryption product is present.
- For startup authentication settings, block the TPM startup PIN, startup key, and startup key plus PIN options unless you are doing a user-assisted deployment. Silent BitLocker needs no pre-boot prompt. If you require a PIN for compliance, build a separate policy and rollout plan.
- Set the recovery section to back up recovery information to Entra before encryption proceeds. On Entra-joined devices, this is the control that prevents a protected laptop with no retrievable key.
- Choose your encryption method with intent. For most fleets, XTS-AES 128 on the operating system drive is the right default because it balances performance and protection. Select your encryption method based on your compliance needs; move to XTS-AES 256 only if your cipher strength requirements demand it. For fresh Autopilot builds, used space only encryption can speed things up, whereas for older in-use laptops, full encryption is often the safer choice.
- If you want stronger control over non-OS storage, enable write blocking for fixed data drives that are not protected and deny write access to removable data drives that are not protected by BitLocker. Those settings matter when staff move files to USB media or keep data on secondary internal drives.
- Under assignments, target device groups, not user groups. This is a device control, and device-based assignment avoids a lot of confusion. For Autopilot builds where the user is not an administrative user, allow standard users to enable encryption during Autopilot so silent enablement can complete.
After the policy lands, wait for sync, then verify it on a pilot machine. Don’t assume a green assignment means the drive is encrypted. Check the device and confirm the recovery key exists in Entra before you widen the rollout.
Roll out in rings, not all at once
Encryption is one of those changes that punishes impatience. A careful rollout beats a large one every time.
Start with a pilot ring of five to ten laptops. Include one device from each major hardware family in your fleet, because TPM and firmware behavior can vary between Dell, HP, Lenovo, and Microsoft Surface hardware. Watch the devices long enough to catch reboot cycles, firmware prompts, and recovery key escrow.
Then expand to an early ring, around 10 to 20 percent of company-owned laptops. Leave it there for at least several business days. In Intune reports, pay attention to devices that sit in waiting states. Those machines usually need TPM, WinRE, or firmware cleanup, not a weaker policy.
If you want a portal-level walkthrough with recent screenshots, this Windows 11 Intune policy guide lines up well with today’s admin center.
For a broad deployment, use dynamic device groups and keep BYO devices out of scope. Scope tags help if different regional or business-unit admins manage separate device pools. Also, make Autopilot part of the plan. New company laptops should pick up the BitLocker policy during enrollment so encryption happens early, before the user starts filling the drive with client files.
Most importantly, don’t target All Devices. That one shortcut can sweep in test VMs, stale records, kiosks, and personally owned machines. BitLocker at scale works best when the group logic is boring and predictable.
Confirm encryption and watch for drift
After deployment, validate the status from both the device side and the Intune portal.
On the laptop, open the Command Prompt and run manage-bde -status c: to inspect the encryption status of your operating system drive. Look for the conversion state and protection status in the output. Whether the report shows Used Space Only Encrypted or Fully Encrypted, both are acceptable provided they match your organization’s plan. What matters most is that protection is enabled, the encryption method aligns with your policy, and recovery data is successfully stored in Entra.
In Intune, review the device encryption reports and export them whenever you need audit evidence. That report catches trends faster than waiting for user tickets. A machine that suddenly moves into a non-compliant state may have suspended protection, a failed firmware change, or a conflict with a competing policy.
Keep a close eye on firmware operations. BIOS and UEFI updates often change the measurements BitLocker uses to trust the boot path. If the update was planned, suspend protection before the change, complete the maintenance, then resume encryption after the first healthy boot. If you skip that step, the user may land on a recovery screen the next morning.
Log review helps when a device refuses to behave. The DeviceManagement-Enterprise-Diagnostics-Provider admin log shows MDM policy application details. The BitLocker-API log is where Windows often spells out exactly why encryption failed. Those two logs save far more time than clicking sync again and hoping for a different result.
Troubleshoot common BitLocker problems
TPM is missing or not ready
When Get-Tpm reports no TPM, BitLocker may still work with weaker startup options, but that is rarely the right answer for company laptops. First, check firmware settings and vendor updates. Some devices ship with the Trusted Platform Module (TPM) disabled, while others need a firmware reset after a board replacement.
If the TPM chip exists but isn’t ready, clear the issue before pushing policy wider. Don’t relax the silent deployment settings to fit a broken device. Fix the device.
Protection is suspended
A suspended BitLocker state often appears after BIOS updates, hardware servicing, or manual admin work. In manage-bde -status, you will see protection off even though the drive remains encrypted, which you may also notice if you check the legacy encryption status via the Control Panel.
Resume protection as soon as the approved maintenance ends. Then verify that the next reboot doesn’t trigger recovery. If suspension keeps returning, check for an automation tool or update process that disables protection and never turns it back on again.
Policy conflicts stop encryption
Conflicts usually show up in hybrid environments or on machines with history. A device may already be encrypted by hand, may have old Group Policy (GPO) settings from on-prem AD, or may still carry traces of another disk encryption product. In those cases, Intune can report failure even when the drive looks encrypted.
Start by checking whether multiple policies touch the same BitLocker settings. Then review any on-prem GPOs still applying to hybrid devices. For the deeper rule set behind CSP and Group Policy behaviour, Microsoft’s BitLocker configuration reference is the source worth checking.
If the device was manually encrypted with settings that don’t match your standard, decrypt it during a maintenance window and let Intune re-apply the approved profile. That is slower than leaving the mismatch in place, but it removes long-term confusion.
Recovery key prompts appear after firmware changes
This issue is common and often legitimate. BitLocker watches the boot environment, so a BIOS update, Secure Boot change, boot order edit, TPM reset, or motherboard replacement can trigger recovery.
Treat that prompt as a security event first, not a user annoyance. Confirm the change was planned. Retrieve the escrowed recovery key from Entra through your approved process. Once the device boots, check the firmware history, TPM status, and BitLocker protection state before you hand it back to the user.
For repeat firmware work, suspend BitLocker before the change and resume it after. That cuts down unnecessary recovery prompts without weakening protection permanently.
The device keeps waiting for user interaction
Silent enablement can stall when you accidentally require a startup PIN, the TPM isn’t ready, WinRE is unhealthy, or the laptop can’t escrow its recovery key. It can also stall on devices that aren’t the right target, such as VMs or personally owned endpoints.
When that happens, don’t widen the policy or lower standards to force a pass. Fix the preconditions on that device, then test again. A messy workaround on day one often becomes a permanent exception that no one trusts later.
Frequently Asked Questions
Why is my BitLocker deployment stalling in a “waiting” state?
Silent enablement often stalls due to missing prerequisites like an uninitialized TPM, a broken Windows Recovery Environment, or a failure to escrow the recovery key to Entra ID. It can also occur if the policy configuration conflicts with existing settings, such as requiring a startup PIN on a device targeted for silent, non-interactive encryption.
Can I use the same BitLocker policy for both Windows 10 and Windows 11?
Yes, the Intune “Windows 10 and later” profile is designed to support both operating systems simultaneously. However, you should ensure your hardware and firmware prerequisites—such as TPM 2.0 support—are consistent across both OS versions to avoid deployment failures on older devices.
What should I do if a user receives a recovery key prompt unexpectedly?
First, verify if any recent firmware updates, BIOS changes, or motherboard repairs occurred, as these hardware modifications often trigger BitLocker security measures. If the change was authorized, retrieve the correct recovery key from Entra ID, restore access to the device, and then re-enable or resume BitLocker protection.
Should I target user groups or device groups for BitLocker policies?
It is highly recommended to target device groups for all BitLocker and encryption policies. Targeting users can lead to unpredictable results if a single user logs into multiple devices with different hardware capabilities or security configurations.
Final thoughts
The safest company-wide rollout is the one that feels uneventful. Users keep working, laptops encrypt in the background, and your team can retrieve a recovery key only when a real support process calls for it.
If you remember one rule, make it this: don’t treat encryption as complete until the recovery key is in Entra and protection is active. Once using BitLocker Drive Encryption becomes part of your normal Windows 11 and Intune workflow, security stops being a risky project and becomes standard device hygiene.