🛡️ Recipe · Security & Compliance
Check BitLocker Encryption Status Reliably with PowerShell
Avoid false positives by validating encryption, protection, and key protectors together
Complexity
Intermediate
Impact
security + compliance + endpoint-management + windows + automation
Context
Why This Matters
BitLocker status checks are a staple of endpoint compliance reporting, but naive scripts frequently produce false positives. A drive can report ProtectionStatus = 1 while only partially encrypted, or report ProtectionStatus = 0 while the data itself is still fully encrypted — the protectors just happen to be missing or suspended.
This recipe shows how to reliably verify BitLocker on a Windows endpoint by evaluating three independent signals together: volume encryption state, protection status, and key protector presence. Use this when:
- Building compliance reports for ISO 27001, SOC 2, HIPAA, or Essential 8 (ML1+) attestation
- Validating endpoints after a BIOS/firmware update (a common cause of suspended protection)
- Auditing fleet encryption via Intune proactive remediations or an RMM
- Troubleshooting why a device appears "encrypted" in Intune but fails a real-world security review
Expected Outcomes
After completing this recipe you will have:
- A reliable PowerShell function that returns true only when the system drive is fully encrypted, actively protected, and has at least one key protector configured
- Clear understanding of the three independent BitLocker states —
VolumeStatus,ProtectionStatus, andKeyProtector— and why checking only one is insufficient - A deployable script suitable for Intune proactive remediations, Configuration Manager compliance baselines, or ad-hoc audits
- Documented logic that distinguishes "suspended" from "off" from "encrypting in progress"
Risks & Considerations
Gotchas and caveats
- Administrator rights required.
Get-BitLockerVolumeand the underlyingroot\CIMV2\Security\MicrosoftVolumeEncryptionnamespace require an elevated session. Non-elevated calls may return empty or partial data, which your script could misinterpret as "not encrypted." - Suspended protection is not "off." After a BIOS update or TPM change, BitLocker may auto-suspend. The drive remains encrypted but the decryption key is stored in the clear on disk.
ProtectionStatuscorrectly reports Off in this state — do not dismiss this as a transient condition. - Encryption progress matters. A drive mid-encryption may show
ProtectionStatus = OnwhileVolumeStatusis EncryptionInProgress. Treat in-progress as a non-compliant state until it reaches FullyEncrypted. - Hardware (SED / eDrive) encryption can change what the WMI classes report. Check
EncryptionMethodif your fleet includes Opal drives. - Do not rely on Intune's "Encrypted" column alone. Intune reports MDM attestation, which can lag real device state by hours or miss suspended protection entirely.
- Never log or export recovery keys from these checks. Escrow them to AD/Entra ID or Intune — never to a file share or ticket.
Required Permissions
| Permission | Why It's Needed |
|---|---|
| Local Administrator on the target device | Required to query BitLocker key protectors and the MicrosoftVolumeEncryption WMI namespace |
| Intune: Device configuration / Remediations (Read and write) | Required if deploying this script as a proactive remediation across a managed fleet |
| PowerShell execution policy allowing signed or RemoteSigned scripts | Required to run the script outside of interactive sessions (e.g., via Intune or RMM) |
The fastest way to get this done: just ask Dex. Copy the prompt below and paste it into your Dex conversation.
For IT Admins
Paste into Dex Pro
For End Users
How an employee would ask Dex for help
Manually verify BitLocker status on a Windows endpoint
Use this walkthrough when you need to spot-check a single device (for example, before approving a support exception or investigating a compliance alert).
Option A: Control Panel (GUI)
- Press Win + R, type
control, and press Enter. - Navigate to .
- Locate the system drive (usually C:) and confirm it shows BitLocker on.
- If it shows BitLocker suspended or BitLocker off, treat the device as non-compliant and investigate further.
Option B: manage-bde (command line)
- Open an elevated Command Prompt or Windows Terminal (Run as administrator).
- Run:
manage-bde -status %SystemDrive% - Review the output and confirm all of the following:
- Conversion Status: Fully Encrypted
- Percentage Encrypted: 100%
- Protection Status: Protection On
- Key Protectors: at least one entry (TPM, Recovery Password, etc.)
- If any of these are missing or show Protection Off, the device is not compliant — even if Intune reports it as encrypted.
Option C: Windows Security app
- Open (Windows 11) or (Windows 10).
- Confirm the toggle is On. Note that this view does not distinguish suspended from active — use manage-bde or PowerShell for definitive checks.
Not applicable for this recipe. BitLocker status is a local device state queried through WMI/CIM — there is no REST API on the device itself. For fleet-wide visibility via API, query Microsoft Graph's deviceManagement/managedDevices endpoint, but note that Intune's reported isEncrypted flag lags real device state and does not distinguish suspended protection. For authoritative per-device status, run the PowerShell script below via an Intune proactive remediation or your RMM and ingest the results.
Reliable BitLocker check using Get-BitLockerVolume
The built-in Get-BitLockerVolume cmdlet (from the BitLocker module, included in Windows 10/11 and Windows Server) is preferable to raw WMI/CIM queries because it returns human-readable properties and already normalizes the underlying Win32_EncryptableVolume fields.
Step 1 — Open an elevated PowerShell session
Right-click PowerShell or Windows Terminal and choose Run as administrator. Without elevation, KeyProtector will return empty and your script will produce a false negative.
Step 2 — Inspect the raw object
# See everything PowerShell knows about the system drive
Get-BitLockerVolume -MountPoint $env:SystemDrive | Format-List *Note three properties in particular:
VolumeStatus— FullyEncrypted, EncryptionInProgress, DecryptionInProgress, or FullyDecryptedProtectionStatus— On or Off (Off includes the suspended state)KeyProtector— array of configured protectors (TPM, RecoveryPassword, Password, etc.)
Step 3 — Evaluate all three signals together
A drive is only truly compliant when all three checks pass. Checking ProtectionStatus alone is the most common source of false positives.
$volume = Get-BitLockerVolume -MountPoint $env:SystemDrive
$isEncrypted = $volume.VolumeStatus -eq 'FullyEncrypted'
$isProtected = $volume.ProtectionStatus -eq 'On'
$hasProtectors = $volume.KeyProtector.Count -gt 0
if ($isEncrypted -and $isProtected -and $hasProtectors) {
Write-Host 'Compliant' -ForegroundColor Green
} else {
Write-Warning 'Non-compliant — investigate'
}Step 4 — Deploy at scale
Wrap the logic into a script (see download below) and deploy via Intune proactive remediations, Configuration Manager compliance baselines, or your RMM. Use exit code 0 for compliant and 1 for non-compliant so the deployment platform can aggregate results.
Next steps