Check Bitlocker Compliance

What the BitLocker Compliance Checker does

This Automox Worklet™ audits BitLocker drive encryption status on Windows endpoints without making any configuration changes. The Worklet uses Get-BitLockerVolume to enumerate all drives and check their encryption status, then reports the findings to the Automox activity log.

The Worklet can be configured to target specific system types using the PCSystemType filter. By default, it evaluates desktops, mobile endpoints, and workstations (types 0-3) while excluding servers. You can adjust the $maxSystemtype variable to include or exclude specific system types based on your compliance requirements.

During evaluation, the Worklet checks both the ProtectionStatus (encryption enabled and protecting) and VolumeStatus (encryption in progress) for each drive. Drives with encryption in progress are counted as compliant since the encryption process has started.

Why audit BitLocker compliance

Unencrypted endpoints create data breach risks when lost, stolen, or improperly decommissioned, potentially exposing sensitive data. Full disk encryption protects data at rest from unauthorized access, and compliance frameworks including HIPAA, PCI-DSS, and GDPR require organizations to implement these encryption controls. This Worklet identifies endpoints lacking encryption before they create compliance gaps or security incidents.

BitLocker compliance auditing provides visibility into your encryption posture without enforcing changes. This approach lets you assess the scope of remediation needed, plan deployment phases, and track progress over time. The activity log reports create an audit trail for compliance documentation.

For organizations using Automox to enforce BitLocker encryption, this Worklet provides a read-only audit capability for verification and ongoing compliance monitoring. Run this Worklet on a schedule to detect endpoints where encryption may have been disabled or new unencrypted drives added.

How BitLocker compliance checking works

1. Evaluation phase: The Worklet first checks the PCSystemType to determine if the endpoint should be evaluated (skipping servers by default). It then runs Get-BitLockerVolume to retrieve encryption status for all drives. Each drive is checked for ProtectionStatus 'On' or VolumeStatus 'EncryptionInProgress'. If all drives are encrypted or encrypting, the endpoint is compliant. If any drive is unencrypted, remediation is triggered.

2. Remediation phase: The remediation script does not enable encryption. Instead, it generates a detailed report listing all encrypted and protected drives versus unencrypted or unprotected drives. This information is written to the activity log for administrators to review and plan appropriate remediation actions.

BitLocker compliance checking requirements

• Windows 8 or later, Windows Server 2012 or later (if servers are included)

• PowerShell 4.0 or later

• BitLocker feature must be installed on the endpoint

• Administrative privileges to query BitLocker status

• Configure $maxSystemtype to include desired system types (default excludes servers)

Expected activity log output after remediation

After running, the activity log shows which drives are encrypted and which require attention. Compliant endpoints display "Endpoint Compliant" with exit code 0. Non-compliant endpoints list specific drive letters needing encryption, allowing you to prioritize remediation efforts and deploy the Enforce BitLocker Encryption Worklet to those endpoints.

For compliant endpoints where all drives are encrypted, the evaluation exits with code 0 and logs "Endpoint Compliant". For non-compliant endpoints, the remediation runs and outputs the specific drive letters that need attention. Use this data to prioritize the Enforce BitLocker Encryption Worklet deployment or investigate why specific drives remain unencrypted.