BitLocker Encryption at Scale: Compliance in 72 Hours

LIMEHAWK - Managed IT

Home>Incident Reports>BitLocker Encryption at Scale: Compliance in 72 Hours

Incident

Cyber insurance renewal audit flagged a critical finding on a Tuesday: full-disk encryption was required on all endpoints within 72 hours or the policy would lapse. The client had 127 Windows workstations across 3 locations — zero had BitLocker enabled. Their previous MSP had quoted "6-8 weeks" for manual deployment. The insurance carrier was not interested in waiting 6-8 weeks.

The manual approach problem

Manual BitLocker deployment is expensive in clock time and technician time:

- per machine: 15-20 minutes hands-on
- recovery key: must be recorded somewhere secure
- TPM check: varies by hardware generation
- encryption time: 30-90 minutes depending on drive size

At 15 minutes of hands-on time per machine (not counting the encryption clock that runs in the background), 127 endpoints is 32 hours of technician time. Plus the nightmare of securely tracking 127 recovery keys. With 72 total hours and only business hours available, there was no version of manual that got there.

Why BitLocker automation is tricky

Most "BitLocker scripts" you find online fail on at least one of these:

- TPM requirements: must verify the chip is both present and ready
- protector types: TPM alone vs TPM+PIN vs USB key vs combinations
- recovery key: 48-digit key must be escrowed securely somewhere we can find it
- existing protectors: duplicate protectors cause Enable-BitLocker to error out
- SYSTEM context: RMM runs as SYSTEM, not as the user, which changes some BitLocker APIs

Scripts online tend to assume TPM is ready, skip protector cleanup, or leave recovery key escrow as "an exercise for the reader." Ours validates TPM, rotates protectors, and syncs the recovery key directly to RMM custom fields as part of the same run.

Solution

Deploy via RMM to all 127 endpoints in parallel. The script validates TPM, cleans up existing protectors, adds a fresh TPM protector and a numerical recovery password, initiates XTS-AES-256 encryption, and writes the recovery key to the asset's custom field automatically. Zero manual intervention.

What makes this script different

Key features we built in after getting burned by the online scripts:

- TPM validation: checks TpmPresent AND TpmReady before touching anything
- protector cleanup: removes duplicates before adding new ones
- dual retrieval: Get-BitLockerVolume CIM method with manage-bde as a fallback
- RMM sync: recovery key pushed to custom field automatically
- XTS-AES-256: strongest encryption method Windows offers

Recovery keys are printed to RMM logs AND synced to custom fields. Even if script output is truncated by the RMM log size limit, the key is stored with the asset record. No spreadsheets, no sticky notes, no "where did we put that key when the user traveled?"

Outcome

Script deployed Friday at 6 PM. By Saturday morning, 119 machines were encrypted. 8 machines had TPM issues that traced back to out-of-date firmware — a quick BIOS update cleared them and the next run caught them up. Full compliance report was sent to the insurance auditor Sunday afternoon, 14 hours inside the deadline.

endpoints encrypted: 127 of 127
deployment time: 18 hours (overnight)
technician time: 45 minutes total
recovery keys escrowed: 100% in RMM

Key takeaways

Takeaway

BitLocker automation requires TPM pre-validation — don't assume Enable-BitLocker will figure it out.

Takeaway

recovery key escrow is the hard part; automate it or the audit will find the gap.

Takeaway

protector rotation prevents duplicate-key errors that kill most "just enable it" scripts.

Takeaway

RMM custom fields beat spreadsheets for key storage — they travel with the asset.

Need help with something like this? Contact us

• Automating CrushFTP Upgrades and In-Place Updates (Automation)

• PC Replacement: Zero Data Loss User Profile Migration (Automation)

• Winget for RMM: Silent Software Deployment at Scale (Automation)