CMMC Level 2 BitLocker Policy Implementation With Evidence Screenshots

If you’re preparing for CMMC Level 2, BitLocker is one of those controls that sounds simple until the assessor asks, “Show me proof.” The goal isn’t just turning on encryption, it’s producing repeatable evidence that every CUI-scoped Windows device is encrypted, uses an approved method, and has recoverability under IT control.

In this guide, I’ll walk through how I set up an Intune BitLocker policy, then how I capture the screenshots I use in an evidence package. You’ll get exact UI paths, what each screenshot must show, and a checklist you can hand to someone else and still get consistent results.

What “good” looks like for CMMC Level 2 BitLocker evidence

For CMMC Level 2, I treat BitLocker as three proof points that must line up:

1. Policy intent in Intune (settings and assignments)
2. Key escrow to Entra ID (recovery works, centrally controlled)
3. On-device state (encrypted volumes, expected algorithm, protectors present)

That “triangle” matters because auditors don’t accept “we configured it” without showing devices actually complied.

If you want broader endpoint context, I like how PreVeil frames endpoint compliance as a system, not a single toggle, in their guide to CMMC endpoint compliance. I also keep our own reference handy for Microsoft cloud scoping and decision points in Microsoft 365 CMMC alignment guidance.

One more practical note: I’m writing this for Small Business IT teams that wear five hats. In the real world, BitLocker has to fit alongside Cloud Infrastructure, Office 365 Migration, Data Center Technology, Restaurant POS Support, and Kitchen Technology Solutions. That’s why I focus on simple steps, clean evidence, and fewer “special cases.” It supports Cybersecurity Services, Endpoint Security, and Device Hardening without slowing the business. When I act as a Business Technology Partner, this is part of Tailored Technology Services, Cloud Management, Technology Consulting, Infrastructure Optimization, and Digital Transformation, tied back to IT Strategy for SMBs, Secure Cloud Architecture, Managed IT for Small Business, and Business Continuity & Security.

If a device holds CUI and you can’t produce a recovery key on demand, you don’t have a supportable encryption program, you have a hope-and-pray program.

Build the CMMC-ready Intune BitLocker policy (step-by-step)

I build BitLocker using the Endpoint security blade because it keeps encryption controls together and makes reporting easier later. If you want a second viewpoint while you set it up, these walkthroughs can help: Create an Intune BitLocker policy for Windows 11 devices and BitLocker disk encryption policy for Intune.

Step 1: Create the policy in Endpoint security

1. Go to Intune admin center > Endpoint security > Disk encryption > Create policy
2. Platform: Windows 10 and later
3. Profile: BitLocker (Disk encryption)

Set your baseline choices (adjust to your risk and device mix):

• Encrypt OS drive and fixed data drives
• Use silent or “no user prompt” behavior where possible (reduces missed endpoints)
• Set the encryption method to XTS-AES 256-bit for OS and fixed drives (common expectation for CUI at rest)
• Require TPM protector (TPM 2.0 on modern devices), then decide if you also require a pre-boot PIN (more secure, more user friction)

Screenshot Evidence:
[Intune admin center > Endpoint security > Disk encryption > (your policy) > Properties > Settings]
[Snapshot must show: encryption method for OS and fixed drives, silent/automatic enablement behavior, and TPM protector requirements.]

Step 2: Require recovery key escrow to Entra ID

In the same policy, configure recovery options so keys back up to Entra ID. I also allow the 48-digit recovery password because it’s the most practical support path.

Screenshot Evidence:
[Intune admin center > Endpoint security > Disk encryption > (your policy) > Properties > Settings]
[Snapshot must show: recovery password enabled, and the setting that backs up or stores recovery info in Entra ID.]

Step 3: Assign only to your CUI-scoped device group

Assign the policy to a device group that matches your CMMC scope. I avoid “All devices” unless I’m confident every Windows device meets prerequisites.

Screenshot Evidence:
[Intune admin center > Endpoint security > Disk encryption > (your policy) > Assignments]
[Snapshot must show: included groups (name visible) and any exclusions.]

Step 4: Prove the policy applied

After deployment, I check device status before I ever collect screenshots.

Screenshot Evidence:
[Intune admin center > Endpoint security > Disk encryption > (your policy) > Device status]
[Snapshot must show: at least one compliant device, and any non-compliant device states if present.]

Evidence screenshots: Intune reports, Entra escrow, and on-device validation

This is where most CMMC evidence packages get weak. I capture proof from three places, then I label each screenshot with device name, date, and who captured it.

Evidence checklist (use this table as your artifact index)

Artifact	Source	Screenshot needed	Notes
BitLocker policy settings	Intune admin center	Yes	Capture settings page showing XTS-AES 256 and recovery options
Policy assignments	Intune admin center	Yes	Show CUI-scoped group targeting
Policy device status	Intune admin center	Yes	Show successful apply results
Disk encryption report (fleet view)	Intune admin center	Yes	Proves coverage across scoped devices
Device record (identity)	Intune admin center	Yes	Show device name, primary user, last check-in
Recovery key escrow (per device)	Entra admin center	Yes	Show BitLocker recovery key entries for the device
On-device BitLocker UI	Windows Control Panel	Yes	Show OS drive On, encryption method
On-device protectors and status	PowerShell or manage-bde	Optional screenshot	Use when assessor wants protector details (TPM, recovery password)

A quick fleet-level view helps your story.

Screenshot Evidence:
[Intune admin center > Devices > Monitor > Disk encryption]
[Snapshot must show: device list with encryption state, and enough columns to tie status to device name.]

Show recovery key escrow in Entra ID (this is often the deciding screenshot)

When an assessor asks, “Can you recover a locked device,” I show Entra evidence, not a promise.

Screenshot Evidence:
[Entra admin center > Devices > All devices > (select device) > BitLocker keys]
[Snapshot must show: at least one recovery key entry and the key ID metadata that ties to the device.]

March 2026 operational tip: Entra has had a historical limit on stored recovery keys per device. If key rotation goes wild, escrow can fail until old keys clear. When I see escrow issues, I check for excessive key entries first, then correct the root cause (often re-enrollment loops or repeated protector resets).

Prove compliance on the device (what I capture for the evidence binder)

I prefer screenshots that any admin can reproduce without special tooling.

Screenshot Evidence:
[Control Panel > System and Security > BitLocker Drive Encryption]
[Snapshot must show: OS drive status “BitLocker on” and the encryption method (XTS-AES 256-bit if that’s your standard).]

When I need protector-level proof, I capture a screenshot of a command output window after running manage-bde -status and manage-bde -protectors -get C: (or the equivalent PowerShell Get-BitLockerVolume). That gives the assessor what they want: method, conversion status, and protectors in one place.

Don’t hide the device name. Tie every screenshot to an asset ID or hostname, or the evidence won’t connect to your inventory.

Troubleshooting common Intune BitLocker failures (and what to screenshot)

• TPM not ready: On the endpoint, open tpm.msc and confirm it’s ready. If not, initialize TPM in BIOS/UEFI per vendor guidance.
  Screenshot to capture: [tpm.msc showing Status: The TPM is ready for use]
• Policy conflict: This happens when you set BitLocker in multiple places (Endpoint security plus a Settings catalog profile). Pick one authority.
  Screenshot to capture: [Intune policy “Per-setting status” or device status showing conflict]
• Silent encryption doesn’t start: Check if the user is standard and your settings require user interaction, or the device has an unsupported drive layout.
  Screenshot to capture: [Control Panel BitLocker showing “waiting for activation” or not enabled]
• Recovery keys not backing up: Confirm device is Entra-joined or Hybrid joined as expected, then re-check the escrow setting. Also look for excessive stored keys.
  Screenshot to capture: [Entra device record with missing BitLocker keys section, or empty keys list]

Conclusion

CMMC Level 2 assessors don’t grade effort, they grade evidence. When I build an Intune BitLocker policy, I plan the screenshots at the same time, so I can prove intent, escrow, and on-device reality without scrambling later. If you want, I can review your current Intune configuration and help you tighten scope, reporting, and recovery workflows so your next evidence pull feels routine instead of stressful.