Check BitLocker Encryption Status Reliably with PowerShell

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

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, and KeyProtector — 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"

Gotchas and caveats

• Administrator rights required. Get-BitLockerVolume and the underlying root\CIMV2\Security\MicrosoftVolumeEncryption namespace 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. ProtectionStatus correctly reports Off in this state — do not dismiss this as a transient condition.
• Encryption progress matters. A drive mid-encryption may show ProtectionStatus = On while VolumeStatus is 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 EncryptionMethod if 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.