BitLocker Enterprise Deployment: Intune Silent Encryption, Group Policy Configuration, and Recovery Key Escrow to Azure AD
Retool's new app builder is where AI-generated code ships safely
Building apps with AI is easy. Getting them to production safely is another story.
BitLocker deployment at enterprise scale fails in predictable ways: recovery keys not escrowed before encryption begins (resulting in unrecoverable devices after a TPM change or firmware update), Intune policies configured for TPM+PIN that prevent silent encryption and generate a helpdesk surge from users confused by the PIN setup prompt, and encryption compliance reports that show 80% of devices encrypted but no process for investigating or remediating the remaining 20%.
The Intune silent encryption deployment model solves the first two problems: keys are escrowed to Azure AD automatically before encryption, and TPM-only authentication requires no user interaction. The compliance reporting and remediation workflow addresses the third.
Pre-deployment: TPM inventory and pilot group testing
The preparation work before deploying the BitLocker Intune policy determines whether the rollout succeeds silently or generates a helpdesk surge. The single most important pre-deployment step is inventorying TPM presence and version across the device fleet, because applying the silent encryption policy to devices without a functional TPM causes silent failures that show up only as non-encrypted devices in the compliance report with no error visible to the user. Practitioners use the Intune Encryption report or a Get-Tpm PowerShell script collected via Intune shell script assignment to identify TPM 1.2 devices (which have known weaknesses and should be prioritized for hardware refresh), devices with TPM disabled in firmware (requiring a BIOS change), and devices with no TPM at all (requiring a separate non-silent policy or hardware exception). After grouping devices by TPM status, the pilot phase targets 20 diverse devices across hardware models and Windows versions to confirm that silent encryption starts in the background, recovery keys appear in Azure AD, and no user interaction is required before expanding to the full fleet.
Inventory TPM presence and version before deploying the BitLocker policy
Run a TPM inventory report in Intune under Devices, Monitor, Encryption report which shows TPM version alongside encryption status, or run Get-Tpm via an Intune shell script to all Windows devices and collect TPM TpmPresent and TpmReady status. Identify devices with TPM 1.2 (which has known security weaknesses and should be upgraded to TPM 2.0 hardware when possible), devices with no TPM, and devices where TPM is present but disabled in firmware (requiring a BIOS setting change). Create a separate device group for no-TPM devices and configure a separate policy that either excludes them from the TPM-based BitLocker policy or applies a startup key alternative. Do not apply the silent encryption policy to no-TPM devices — it will fail silently and the devices will show as non-encrypted in the compliance report with no visible error.
Pilot the Intune BitLocker policy on 20 devices before company-wide deployment
Target the BitLocker Intune policy to a pilot device group of 20 diverse devices (mix of hardware models, Windows 11 and Windows 10, laptops and desktops) before expanding to the full fleet. Monitor the pilot group for 48 hours: confirm encryption starts in the background, confirm recovery keys appear in Azure AD for all pilot devices, confirm no pilot device requires user interaction or shows encryption errors in the Intune device details. Check whether the pilot devices successfully received the policy by reviewing the Device Configuration and Endpoint Security reports in Intune for the pilot device group. After confirming successful silent encryption and key escrow on all pilot devices, expand the policy target to the full enrollment group.
Post-deployment: compliance tracking and recovery key management
After the BitLocker policy reaches the full device fleet, the work shifts from deployment to maintaining and verifying encryption coverage. The Intune Encryption Report is the primary tool, but the value comes from acting on it: segmenting non-encrypted devices by failure reason (TPM issues, Windows Update blocks, offline devices, unsupported hardware) and creating targeted remediation tickets for each category with a 30-day SLA. Recovery key management is the second operational concern — escrowing keys to Azure AD at encryption time is automatic with the correct Intune policy settings, but the escrow process can fail silently if the policy was applied before the Azure AD backup requirement was set to Required. Practitioners must test recovery key retrieval quarterly on real devices by triggering a BitLocker recovery event and following the Azure AD portal procedure, confirming the escrowed key unlocks the device before an incident requires it.
Investigate and remediate non-encrypted devices within 30 days of policy deployment
After the BitLocker policy reaches the full device fleet, export the Intune Encryption Report and segment devices by encryption failure reason: devices with TPM issues (TPM not ready, TPM firmware update required), devices with Windows Update pending that is blocking BitLocker, devices that received the policy but have not checked in recently (offline devices), and devices with unsupported hardware. Create a remediation ticket for each failure category with the appropriate team: hardware team for TPM issues, endpoint team for Windows Update blocks, and helpdesk for devices to chase offline users. Set a 30-day SLA for reaching 95% encryption coverage across the managed fleet, with documented exceptions for devices with unresolvable hardware limitations.
Test recovery key retrieval quarterly to confirm the process works before an incident
Quarterly, test the BitLocker recovery process end-to-end: select a test device, trigger a BitLocker recovery event by entering 10 consecutive incorrect PINs or by simulating a TPM change (a firmware update that resets TPM measurements is the most realistic test), then follow the recovery procedure using the Intune or Azure AD portal to retrieve the recovery key and use it to unlock the device. Confirm the recovery key displayed in Azure AD unlocks the device successfully. If the recovery key is not present in Azure AD for the test device, investigate why — common causes include the device not having received the Intune policy requiring Azure AD backup, a policy configuration error where backup to Azure AD was not marked as Required, or a timing issue where the device was encrypted before the policy requiring Azure AD backup was applied.
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
The bottom line
BitLocker enterprise deployment with Intune uses silent encryption (TPM-only, no PIN, no user interaction) with automatic Azure AD recovery key escrow. The key configuration settings are: BitLocker required on OS drive, startup authentication allowing TPM without additional authentication (enabling silent encryption), and Azure AD backup required before enabling BitLocker. Run a TPM inventory before deployment to identify no-TPM devices that need separate handling. Pilot with 20 devices before full deployment to confirm silent encryption and key escrow work correctly. After deployment, track the Encryption Report weekly until 95% or more of managed devices are encrypted, and test recovery key retrieval quarterly to confirm the process works before an incident requires it.
Frequently asked questions
How do I configure BitLocker silent encryption using Intune?
Configure BitLocker silent encryption in the Intune admin center under Endpoint security, Disk encryption. Create a new policy with the BitLocker profile type and configure: Require BitLocker encryption on OS drive set to Yes, BitLocker encryption method for OS drive set to XTS-AES 128-bit (or 256-bit for higher security), Require additional authentication at startup set to Block (to enforce TPM-only authentication without a PIN, enabling silent encryption), Enable BitLocker recovery information in Azure Active Directory set to Yes, Store recovery information in Azure Active Directory before enabling BitLocker set to Required, BitLocker recovery password rotation set to Enable rotation on Azure AD-joined devices. Target this policy to the device group containing all Windows endpoints. On a TPM-equipped device enrolled in Intune, BitLocker encryption begins in the background within minutes of policy receipt, with the recovery key uploaded to Azure AD before encryption starts.
How do I retrieve a BitLocker recovery key from Azure AD?
Retrieve the BitLocker recovery key from the Entra ID portal (formerly Azure AD portal) by navigating to Devices, All Devices, searching for the device name, selecting the device, and clicking BitLocker Keys. The recovery keys page shows all BitLocker keys escrowed for that device with the date each key was uploaded — the most recent key is the current active key. IT helpdesk staff with the Cloud Device Administrator or Intune Administrator role can view recovery keys. For self-service recovery, Microsoft's BitLocker Recovery portal (aka.ms/myrecoverykey) allows users to retrieve their own device's recovery key if the device is registered in Azure AD and the user authenticates with their corporate account. The 48-character alphanumeric recovery key entered at the BitLocker recovery screen allows the device to boot when the TPM cannot release the encryption key (such as after a firmware update changes the TPM measurements).
How do I deploy BitLocker using Group Policy for non-Intune managed devices?
Configure BitLocker via Group Policy under Computer Configuration, Administrative Templates, Windows Components, BitLocker Drive Encryption, Operating System Drives. Key policy settings: Require additional authentication at startup should be configured to Allow BitLocker without a compatible TPM unchecked (requiring TPM) with Require startup PIN with TPM for higher security environments. Configure Use enhanced startup PINs for startup to allow alphanumeric PINs. Under Choose how BitLocker-protected operating system drives can be recovered, enable Active Directory backup of recovery keys by selecting Store recovery passwords and key packages, and require that backup be saved to AD DS before enabling BitLocker by checking Do not enable BitLocker until recovery information is stored to AD DS. This ensures recovery keys are stored in Active Directory before encryption begins. The recovery key is stored in the computer object's ms-FVE-RecoveryInformation attribute, accessible through the BitLocker Recovery tab in ADUC with the Microsoft BitLocker Administration and Monitoring RSAT tools installed.
How do I verify BitLocker encryption status across my entire device fleet?
In Intune, go to Reports, Device Compliance, then filter for the BitLocker encryption compliance policy to see device-level encryption status. The Encryption report under Devices, Monitor, Encryption report shows each device's encryption status for OS and data drives. For non-Intune managed devices with Group Policy, run a PowerShell script across the fleet using Invoke-Command: Get-BitLockerVolume | Select-Object MountPoint, EncryptionPercentage, VolumeStatus, ProtectionStatus and collect results through a centralized report. Alternatively, use the Veeam One or SCCM/ConfigMgr Hardware Inventory to collect BitLocker status using the Win32_EncryptableVolume WMI class. Target 100% encryption of OS drives on all managed endpoints, and investigate any device showing FullyDecrypted or EncryptionPaused status — paused encryption indicates a TPM issue or policy conflict that requires investigation.
What is BitLocker Network Unlock and when should I configure it?
BitLocker Network Unlock allows domain-joined devices on the corporate network to boot without requiring a PIN by using a network key distributed by a Windows Deployment Services (WDS) server on the corporate network. When a TPM+PIN device on the corporate network boots, it sends a network unlock request to the WDS server; if the device is on the trusted network segment (identified by DHCP server), the WDS server returns the unlock key and the device boots without user PIN entry. When the device is off-network (such as a laptop taken home), Network Unlock is not available and the PIN is required at boot. Use Network Unlock for server environments where unattended reboots must not require console access, for desktops that are always on the corporate network and would otherwise require a technician to enter a PIN after every reboot, and for remote branch offices where server reboots must be manageable without physical access.
How do I handle BitLocker on devices without a TPM chip?
Devices without a TPM chip (older hardware, some virtualized environments) can use BitLocker with a USB startup key or a startup password, but these modes cannot be deployed silently and require user or administrator action at every boot. For virtual machines in VMware or Hyper-V: enable vTPM (virtual TPM) in the VM configuration to provide a software TPM that supports TPM-based BitLocker encryption with silent deployment. For physical hardware without TPM: enable the Allow BitLocker without a compatible TPM Group Policy setting to permit BitLocker with a startup key (a USB drive that must be connected at boot) or startup password. For older hardware without TPM 2.0, assess whether the device can be upgraded to a TPM 2.0 module or whether it should be excluded from BitLocker policy with a documented exception and scheduled for hardware replacement. Maintain an inventory of devices without TPM to track the unencrypted device population and prioritize hardware refresh.
How do I configure BitLocker for Windows servers in addition to workstations?
BitLocker on Windows servers requires the same TPM hardware support as on workstations but must be configured with consideration for unattended reboots. For domain controllers and other servers requiring unattended reboots: use Network Unlock (which provides the unlock key from a WDS server when the server is on the corporate network) or TPM-only authentication (which boots without any PIN or key but provides encryption-at-rest protection only). For highly sensitive servers such as those containing healthcare or financial data: use TPM+PIN with documented procedures for entering the PIN after planned maintenance reboots. Enable BitLocker on the OS drive (C:) and on all data drives containing sensitive data using the Add-BitLockerKeyProtector cmdlet in PowerShell: Enable-BitLocker -MountPoint D: -RecoveryPasswordProtector -RecoveryKeyPath \\server\bitlocker-keys\ enables the data drive and saves the recovery key to a network location.
Sources & references
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, daily, no spam.
Unsubscribe anytime. We never sell your data.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals every morning.
Win a $2,495 Black Hat pass.
Full-access to Black Hat USA 2026 in Las Vegas. Subscribe free to enter.