Table of Contents
BitLocker for CMMC, Encrypting CUI at Rest Without Failing Your Assessment
Encrypting CUI at rest sounds like a solved problem. Turn on BitLocker, move on. Then a C3PAO assessor opens a laptop, looks at how the key is protected and where the recovery password lives, and the control falls apart.
BitLocker is the right tool for protecting Controlled Unclassified Information on Windows endpoints. It is built in, it is centrally manageable through Group Policy, and it uses FIPS-approved cryptography. But the default way most teams enable it does not hold up against a CMMC Level 2 review. The gap is rarely the encryption itself. It is the configuration choices around it.
Here is how to deploy it so it stands as evidence rather than a finding.
What BitLocker actually proves
BitLocker is one technical control inside a larger media-protection and system-protection program. On its own it does not satisfy a control, but configured correctly it provides supporting evidence for a few specific requirements.
- SC.L2-3.13.16 (protect the confidentiality of CUI at rest), through full-disk encryption of OS and fixed data drives.
- SC.L2-3.13.11 (use FIPS-validated cryptography), through XTS-AES implemented by the validated Windows cryptographic library, with FIPS mode enabled.
- MP.L2-3.8.1 and 3.8.2 (protect and control CUI on media), through recovery key escrow and deny-write on unencrypted drives.
Map these to the exact language in your SSP. The point of the deployment is to make those control narratives true and provable.
Deploy it through Group Policy, not by hand
Per-machine BitLocker is how you end up with inconsistent settings and no central recovery story. Build a single GPO, link it to the OU holding your in-scope machines, and let policy enforce the configuration.
The settings that matter live under Computer Configuration → Policies → Administrative Templates → Windows Components → BitLocker Drive Encryption. The four that carry the compliance weight.
- Choose drive encryption method and cipher strength. Set XTS-AES 256-bit for OS, fixed, and removable drives. 128-bit is also FIPS-approved if performance is a concern, but 256 is the right default for CUI.
- Choose how OS drives can be recovered. Save recovery information to Active Directory, store passwords and key packages, and check the option to block BitLocker until recovery information is stored in AD.
- Require additional authentication at startup. This is where the pre-boot decision lives, and it is the one most teams get wrong (more below).
- Deny write access to fixed and removable drives not protected by BitLocker, so users cannot move CUI onto unencrypted media.
Separately, enable FIPS mode under Security Settings, Local Policies, Security Options, then the policy named “System cryptography: Use FIPS compliant algorithms”. Record the FIPS validation certificate number for the Windows build you run. That certificate is your 3.13.11 evidence.
The mistakes that fail assessments
The deployment steps are easy. These four are what actually cost people.
TPM-only protection on machines that hold CUI
TPM-only is the path of least resistance because the user never sees a prompt. The machine boots, the TPM releases the key, the desktop loads. That convenience is the problem. A powered or sleeping laptop that gets lost or stolen has effectively handed over its key, and it is exposed to DMA and cold-boot attacks.
For CUI assets, require TPM + PIN. The PIN is a pre-boot factor that physical possession alone cannot bypass. If TPM + PIN genuinely is not feasible (shared kiosks, unattended servers, remote-reboot needs), TPM-only can be your documented minimum, but then you owe the SSP a justification, the compensating controls, and a risk acceptance. An undocumented TPM-only laptop full of CUI is a finding waiting to happen.
Assuming “BitLocker is on” means the key is escrowed
The TPM protector is not what backs up to Active Directory. The numeric recovery password is. Enable BitLocker with only a TPM protector and you have an encrypted drive with no recoverable key in AD, which is both an operational risk and a control gap.
Add a recovery password protector and confirm it escrowed.
Enable-BitLocker -MountPoint "C:" -EncryptionMethod XtsAes256 -TpmAndPinProtector -Pin $pin -SkipHardwareTest
Add-BitLockerKeyProtector -MountPoint "C:" -RecoveryPasswordProtector
manage-bde -protectors -get C:The “do not enable until recovery information is stored in AD” policy setting enforces this automatically. Turn it on and let the policy do the work.
Used-space-only encryption on a machine that already had data
Used-space-only encryption is fast, which makes it tempting. It is only safe on a freshly provisioned or wiped drive. On a machine that has already held CUI, deleted files can sit recoverable in unencrypted free space. For any existing endpoint coming into the boundary, use full disk encryption.
Forgetting to suspend before firmware updates
A TPM firmware or UEFI update changes the boot measurement, and the next reboot drops every affected machine into recovery mode. That is a fleet-wide help desk event, not a compliance failure, but it teaches people to disable BitLocker out of frustration. Suspend it as part of your patch process.
Suspend-BitLocker -MountPoint "C:" -RebootCount 1Protection resumes on its own after the reboot.
Verify and collect the evidence
After the policy applies (gpupdate /force, then gpresult /r to confirm the GPO landed), check the result on a client.
manage-bde -statusYou want Protection Status On, encryption at 100%, and key protectors that include both your TPM protector and a recovery password. Then confirm the recovery password shows up in Active Directory Users and Computers on the computer object’s BitLocker Recovery tab.
Capture that as you go, the GPO export, the Get-Tpm and manage-bde -status output, a screenshot of the recovery key in AD, and the FIPS certificate reference. An assessment goes faster when the evidence is already indexed against the controls instead of gathered under pressure during the assessment week.
The short version
BitLocker passes a CMMC review when you treat it as a managed control, not a checkbox. Push it through Group Policy, require TPM + PIN on CUI machines, escrow the recovery password to AD before encryption starts, encrypt the full disk on anything that has held data, and keep FIPS mode on with the certificate on file. Get those right and your encryption-at-rest narrative writes itself.
Where Stratify IT Helps
Stratify IT helps Defense Industrial Base contractors build and document the technical controls that hold up under CMMC assessment, from endpoint encryption posture through the full set of NIST SP 800-171 requirements behind a Level 2 certification. If you want a second set of eyes on your encryption posture or your broader SSP, we can help.
Contact us to talk through your encryption-at-rest evidence, or explore our CMMC certification services for the full scope of what we support across the certification timeline.
For more on the broader framework, see our CMMC Compliance Guide for Defense Contractors.