BitLocker Configurations That Pass a CMMC Assessment

Assessors accept BitLocker on CUI endpoints when you enforce FIPS-validated cryptography, protect recovery keys, and present evidence that shows an implemented and sustained baseline. The CMMC Level 2 Assessment Guide instructs assessors to review documentation, interview staff, and test mechanisms. Build your configuration and your records for that review.

CMMC expectations for data-at-rest encryption

CMMC Level 2 pulls in all 110 NIST SP 800-171 requirements. Control SC.L2-3.13.11 states that you must employ FIPS-validated cryptography when you use cryptography to protect the confidentiality of CUI. The Level 2 Assessment Guide explains the assessment method. Assessors read your policy and system security plan, talk to administrators, and test host settings.

Scope drives the BitLocker footprint. Encryption settings matter on systems that store, process, or transmit CUI. If you have not drawn that boundary with care, start there. See CMMC scoping and the CUI boundary.

FIPS-validated cryptography in Windows

Windows exposes a security option named “System cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing.” Microsoft documents this setting and how it changes the algorithms Windows and BitLocker use. Group Policy and MDM can enforce it on domain-joined and Entra-joined devices.

Enable the FIPS setting first, then enable BitLocker. That order avoids a re-encryption cycle. Test your line-of-business applications under FIPS mode before you turn it on broadly. Some products call non-validated crypto routines; your team needs to find and fix those cases.

FIPS 140 validation attaches to cryptographic modules. An algorithm choice by itself does not meet SC.L2-3.13.11 if the module that implements it has no FIPS validation. Have your team confirm current CMVP status for the Windows build and BitLocker components you deploy. Keep that confirmation with your assessment evidence.

BitLocker policy baseline for CUI endpoints

Administrators configure BitLocker through Group Policy or the BitLocker CSP in MDM. Microsoft documents policy names and behavior, and those policies align cleanly with assessment activities.

Use a standard baseline for operating system volumes and apply the same shape to fixed and removable data volumes. A defensible starting point for CUI workstations includes these elements, all enforced by device configuration policies and verified by reporting:

Require a hardware TPM and enable “Require additional authentication at startup.” Use TPM+PIN on devices with higher theft risk or weak physical controls. For lower-risk desktops in controlled spaces, TPM-only can meet risk tolerance if you document the rationale and compensating controls.
Select the encryption method and strength that match the FIPS validation for your Windows release. Microsoft supports XTS-AES and AES-CBC with 128 or 256-bit strength. Pick the option that your CMVP check confirms for the deployed version, then enforce full drive encryption on the OS volume.

Data volumes need equal rigor. Configure fixed data drives to auto-encrypt when the OS volume encrypts and bind them to the OS protector. For removable media, enable BitLocker To Go and “Deny write access to removable drives not protected by BitLocker.” That one control closes a common CUI exfil path.

Back the baseline with device configuration at scale. You can use Intune or Group Policy. Intune offers assignment, compliance reporting, and device remediation in one place. If you manage CUI endpoints through Intune, align your BitLocker settings with the broader Intune compliance baseline for CUI.

Recovery key storage and access controls

Recovery key handling decides whether your encryption story holds up during an assessment. Two parts matter most.

Escrow every recovery key to an enterprise directory before you finish device provisioning. Use Entra ID device objects or AD DS BitLocker recovery attributes. Block local writes of recovery keys to files and block printing. Rotate the key after any use and capture that activity in a ticket.
Control who can read recovery keys and how they request them. Restrict read access to a small group. Require a ticket and identity verification, then require a second person to approve release. Log the request, the approval, and the retrieval. Treat these logs as evidence and retain them for the period your records policy sets.

If you use self-service recovery, gate it behind strong authentication and device ownership checks. Publish a support runbook and train the service desk on the checks and the rotation step.

Evidence that assessors accept

The Assessment Guide and the CAP v2.0 both point to three evidence types. You will provide documents, you will answer questions, and you will show the setting on live systems. Build your package so it covers all three.

Design and policy evidence. Deliver a system security plan entry that names the BitLocker baseline, the FIPS setting, the key storage location, and the authentication model. Include Group Policy or Intune policy exports, screenshots of policy blades with tenant and time visible, and a diagram that shows key escrow and access paths.
Operational evidence. Produce device reports that show encryption state, algorithm, and protector type for in-scope assets. Use “manage-bde -status” output on samples the assessor selects and attach the collection steps to a ticket. Provide recovery key rotation logs tied to specific incidents. Show service desk training records and the support runbook. Present at least one change record where your team updated a BitLocker policy and verified results.

Assessors will test devices. Plan for a room and a process. Bring an admin who can navigate Intune or Group Policy results on a live endpoint and can run commands as needed. Capture the device names the assessor picked and keep those in your after-action file.

Common pitfalls and quick checks

Teams often miss one of two things. Each one can turn a strong baseline into a finding.

FIPS drift created by timing. Administrators enable BitLocker before they enforce the Windows FIPS cryptography policy. That order can leave volumes on a non-validated path. Fix it by flipping the policy first, decrypting one pilot device, confirming the algorithm and module path after re-encryption, then scheduling the rest. Keep screenshots and command output that show the before and after state.
Weak or unmanaged recovery key process. Many teams escrow keys, then allow broad read access, or fail to rotate after use. Tighten the ACLs on your recovery store. Force a ticket for access. Rotate the key at the end of the support call. Pull a monthly sample of recovery events and check for approvals and rotation. Store that sample with your evidence.

Two quick checks help you catch configuration gaps. On a test device, run “manage-bde -status” and confirm encryption method, protection type, and percentage encrypted. In Intune or Group Policy Results, confirm the FIPS setting, BitLocker CSP or ADMX policy state, and assignment to the device group that maps to CUI scope.

Server and VDI notes

You can apply the same principles on servers that store CUI. Use TPM protectors on physical hosts and add a startup PIN on servers that leave a data center. If you run virtual machines with sensitive data, encrypt the guest OS volume with BitLocker and use a virtual TPM bound to a trusted host. Document the design and keep evidence for both the host and the guest.

For VDI pools, decide how you will protect non-persistent disks that cache user data. Pair disk encryption with controls that block CUI from landing outside approved storage. Data loss prevention in Microsoft Purview and conditional access on storage round out the picture. See Microsoft Purview DLP for CUI.

Pulling it into the SSP and POA&M

Your system security plan must name the control, the configuration, and the sustaining activities you run. Map SC.L2-3.13.11 to the BitLocker and FIPS policies, the recovery key process, and the evidence you retain. State who owns the baseline, who reviews evidence, and how often they review it. If you have gaps, open a POA&M with a clear action, owner, and target date, and show progress in your self-assessment records.

Bottom line configuration pattern

A configuration that stands up in a Level 2 assessment follows a simple pattern. Enforce FIPS mode before you encrypt. Configure BitLocker with TPM-based protection and add a startup PIN where risk warrants. Escrow recovery keys to a controlled enterprise store and rotate after use. Prove it with exports, screenshots, and device reports tied to real change tickets. That mix aligns with the Assessment Guide and CAP v2.0 and gives assessors what they need to score SC.L2-3.13.11 as met.