Enforce Bitlocker Encryption

What the BitLocker encryption enforcer does

This Automox Worklet™ enforces BitLocker drive encryption on Windows endpoints that have a functional Trusted Platform Module (TPM). The Worklet inspects each target volume with Get-BitLockerVolume, gates remediation on Get-Tpm reporting TpmPresent, TpmEnabled, and TpmReady, then runs Enable-BitLocker with the encryption method the policy specifies. Endpoints without a TPM exit as not applicable rather than failing, so a single policy can target the same Windows device group whether or not every machine carries a TPM 2.0 chip.

The Worklet supports three encryption methods. AES-128 balances security and throughput for performance-sensitive endpoints. AES-256 raises the cryptographic bar at a small cost on older or heavily utilized drives. Hardware mode hands encryption off to drives that advertise self-encrypting capability. Full drive encryption is selected on purpose (UsedSpaceOnly = $false) so deleted file remnants and slack space are protected, not just the live filesystem.

Drive targeting is controlled by the $drive parameter. Set it to all to encrypt every physical volume, OS to encrypt only the volume Windows reports as VolumeType OperatingSystem, or a single drive letter (no colon) to scope to one mount point. Recovery options are controlled by $recoveryType: Key writes an encrypted .BEK file to $keyPath, Password generates a 48-character recovery password, and Both produces a key file and a recovery password. The TPM is always attached as the primary key protector regardless of $recoveryType.

Why enforce BitLocker drive encryption

A laptop that walks out of an office is the most common data-loss event a fleet sees. Without BitLocker, the drive can be removed, mounted in another chassis, and read sector-by-sector with no credentials required. Encryption with TPM-bound keys makes that data inaccessible to anyone who does not boot the original hardware through the original measured-boot chain. HIPAA, PCI-DSS, GDPR, and SOC 2 all address data-at-rest protection as part of their broader control sets, and CIS Microsoft Windows benchmarks explicitly call out BitLocker as the recommended implementation for the operating system volume. Enforcing BitLocker supports the evidence those frameworks expect; it does not by itself satisfy every related control.

New hardware lands unencrypted from the OEM, a field tech disables BitLocker for a troubleshooting session and forgets to re-enable it, an image refresh wipes the protector set. Bind this enforcer to the Windows workstation group on the same schedule as your patch policy, and Get-BitLockerVolume reports the regression on the next pass; Enable-BitLocker brings the TPM-bound key back online before the laptop walks out of a coffee shop with an unprotected C: drive.

How BitLocker enforcement works

1. Evaluation phase: The Worklet calls Get-Tpm first. If TpmPresent is false, evaluation writes Not Applicable to the activity log and exits 0 so endpoints without a TPM are not held against compliance. With a TPM present, it runs Get-BitLockerVolume and filters by the $drive scope (all, operating system volume, or a specific MountPoint). Any volume reporting VolumeStatus of decrypted triggers remediation, and any volume reporting EncryptionInProgress is reported with its EncryptionPercentage so administrators can see how far along an in-flight encryption is. The endpoint is flagged compliant only when every targeted volume is FullyEncrypted with protection on.

2. Remediation phase: Remediation re-checks TPM state and exits with a hard error if TpmEnabled or TpmReady is false, because Enable-BitLocker against an unprepared TPM produces silent half-states. It validates each input ($drive, $encryption, $recoveryType, $keyPath), creates the $keyPath directory if missing, and walks the unencrypted volume list. For each volume it attaches a TPM protector with Add-BitLockerKeyProtector -TpmProtector, optionally adds a RecoveryKeyProtector to $keyPath, optionally adds a RecoveryPasswordProtector, then calls Enable-BitLocker -EncryptionMethod $encryption -UsedSpaceOnly $false -SkipHardwareTest. Each volume's KeyProtectorId, BEK filename, and 48-character recovery password are written to the Automox activity log for capture. The script tallies $encryptionSuccessCount and $encryptionFailureCount and exits 1 if any volume failed so the policy run is flagged as not green.

BitLocker enforcement requirements

• Windows 8 or Windows Server 2012 and later, with the BitLocker Drive Encryption feature installed (default on Pro, Enterprise, Education, and Server SKUs)

• TPM 1.2 or later present, enabled in firmware, and reporting TpmReady = $true from Get-Tpm; virtual machines need a virtual TPM exposed by the hypervisor

• PowerShell 4.0 or later, executed by the Automox agent in its default SYSTEM context (no interactive user required)

• Set $drive in both evaluation.ps1 and remediation.ps1 to the same scope: all, OS, or a single drive letter without the trailing colon

• Set $encryption to AES128, AES256, or Hardware, and $recoveryType to Key, Password, or Both

• Set $keyPath to a writable local path when $recoveryType is Key or Both; the script creates the directory with New-Item -Force if it is missing, and aborts cleanly if creation fails

• Capture the activity-log output. Recovery passwords and BEK file locations are not stored anywhere else and are required to unlock the volume if TPM measured boot fails after a firmware update

Expected encryption state after remediation

Each targeted volume reports ProtectionStatus of On, EncryptionMethod matching the configured $encryption value, and VolumeStatus that progresses from EncryptionInProgress to FullyEncrypted over the course of several hours depending on disk size. The TPM protector is attached, and either an ExternalKey protector (BEK file) or a RecoveryPassword protector (or both) is present on the volume. Subsequent Automox evaluations report compliant without applying remediation again, because Get-BitLockerVolume no longer matches the decrypted filter.

Validate from an elevated PowerShell session with Get-BitLockerVolume | Select-Object MountPoint, VolumeStatus, ProtectionStatus, EncryptionMethod, EncryptionPercentage. Confirm the protector set with (Get-BitLockerVolume -MountPoint C:).KeyProtector. For audit evidence, also run manage-bde -status C: and capture the output alongside the Automox policy run identifier. Encryption continues in the background and tolerates reboots; the endpoint remains usable during the process, with some throughput cost on the volume currently encrypting. Plan firmware and TPM updates carefully after encryption, since a TPM clear or measured-boot change invalidates the TPM protector and forces the recovery password at next boot.