CMMC Level 2 Encryption Requirements: A Plain-Language Guide for Defense Contractors

CMMC Phase 1 enforcement went live on November 10, 2025. From that date, Level 2 self-assessment requirements began appearing in DoD solicitations and contracts. Phase 2: When C3PAO third-party assessments become mandatory — follows exactly one year later, on November 10, 2026.

That gives most defense contractors a window. The problem is how most of them are spending it.

The pattern is familiar: a contractor submits their annual CMMC affirmation, logs it in SPRS, and moves on. The assessment comes and goes. And then for the next 364 days, the organization's CUI is only as protected as their actual encryption implementation — not their documented policy, not their SSP. Their implementation.

For most Tier 2 and Tier 3 defense subcontractors, that implementation has a gap. The encryption covers the server. The file travels beyond the server every day.

This post breaks down the three CMMC Level 2 encryption controls that most contractors underestimate, what FIPS 140-3 actually requires in practice, and where the real exposure sits, before your C3PAO assessor finds it.

The Scale of the Problem

Approximately 80,000 companies in the Defense Industrial Base will need CMMC Level 2 certification. As of late 2025, 431 organizations had achieved a final Level 2 certification, roughly 0.5% of the companies that will eventually need it.

That number tells you something important: the readiness gap isn't about awareness. Contractors know CMMC is coming. The gap is in implementation, specifically in the controls that require the most technical lift. Encryption is consistently among the most common failures in Level 2 assessments.

CMMC Level 2 maps directly to the 110 security practices in NIST SP 800-171. Three of those practices carry the bulk of the encryption weight. Here's what they actually require, and what they don't.

The Three Encryption Controls in Plain Language

SC.3.177 — Employ FIPS-Validated Cryptography to Protect CUI

This is the foundational encryption requirement. The control states that when cryptography is used to protect the confidentiality of Controlled Unclassified Information (CUI), the cryptographic modules must be validated under the NIST Cryptographic Module Validation Program (CMVP).

What this means in practice: the algorithm alone isn't enough. Using AES-256 encryption is not automatically compliant with SC.3.177. The module implementing that encryption needs to appear on the NIST CMVP validation list.

Most commercially available cloud storage and productivity tools are not FIPS 140-3 validated by default. Microsoft 365, in its standard configuration, Google Workspace, and standard SharePoint — none of these apply FIPS-validated encryption to individual files as a default setting. Organizations that believe they're meeting SC.3.177 because they're using "encrypted" cloud storage are likely conflating server-side encryption (which the platform applies to their own infrastructure) with FIPS-validated encryption at the data layer.

The distinction is meaningful. Server-side encryption protects files while they sit on the provider's servers. It doesn't protect a file once it's downloaded, emailed, or copied to a contractor's device. SC.3.177 requires CUI to be protected, not just stored securely on a managed platform.

SC.3.187 — Establish and Manage Cryptographic Keys

SC.3.177 tells you to encrypt. SC.3.187 tells you to manage the keys that do the encrypting, and do it properly.

Key management failures are one of the most common points of failure in encryption implementations. The control requires that organizations establish documented key management processes, protect keys from unauthorized access or disclosure, and have procedures for key rotation, revocation, and recovery.

Where this breaks down for most contractors: encryption keys managed at the platform level (by Microsoft, by Google, by Dropbox) are outside the organization's control. The cloud provider holds the keys. The organization cannot revoke a specific key tied to a specific file when a contractor is offboarded, a breach is suspected, or a specific document needs to be removed from circulation. They can revoke access to the platform — but the key, and therefore the file, remains under the provider's jurisdiction.

SC.3.187 requires the organization to be in control of its cryptographic keys. For CUI that leaves the organizational boundary — through email, through contractor downloads, through offline work — that means per-file key management: unique keys per document, managed by the organization, with the ability to revoke access at the key level for any specific file or set of files.

MP.2.121 — Control Access to CUI on Media

The media protection control is the one most organizations underestimate. It requires that CUI on removable and portable media — USB drives, laptops, personal cloud storage, contractor devices — be subject to the same access controls and protections that apply when the data lives on organizational systems.

This is where the gap between policy and implementation becomes most visible. An organization may have strong CUI protection in SharePoint. Files are labeled, permissions are set, and access is logged. And then a contractor downloads a schematic to work offline, syncs it to their personal OneDrive for convenience, and drops it on a USB to take to a remote site. At that point, the file has left the MP.2.121 coverage area entirely. Your controls followed the folder, not the file.

For defense subcontractors handling ITAR-controlled technical data, the implications extend beyond CMMC. Export-controlled data carries its own handling requirements that are triggered the moment controlled data appears on an unmanaged device or in an uncontrolled environment, regardless of whether the contractor was authorized to download it.

What FIPS 140-3 Actually Requires

The FIPS 140-3 requirement trips up more contractors than any other single element of CMMC Level 2 encryption compliance. Here's why.

FIPS 140-3 (and its predecessor, FIPS 140-2) is not a statement about an algorithm. It is a certification status. A cryptographic module — the software or hardware component that actually performs encryption operations — must be tested and validated by an accredited laboratory and submitted to NIST's CMVP. Only then can it claim FIPS validation.

This means the following statements are not the same thing:

• "We use AES-256 encryption" — Not FIPS 140-3 compliant without validation
• "Our cloud provider encrypts data at rest" — Not FIPS 140-3 compliant unless the specific module is validated
• "Our backup tool is encrypted" — Not FIPS 140-3 compliant unless the backup software uses a CMVP-validated module

CMMC assessors will ask to see evidence: the CMVP certificate number, or documentation showing that the specific modules in use appear on the active NIST validation list. "We believe our provider is FIPS compliant" is not sufficient evidence.

Two areas where contractors consistently discover gaps at assessment time:

1. Email attachments: Email transport encryption (TLS) is often FIPS-compliant. Email attachment encryption typically is not, and the attachment is where the CUI lives. A CUI document sent as a standard PDF attachment travels through an encrypted channel but arrives at its destination as an unprotected file.
2. Contractor-facing file sharing: SharePoint and Teams provide platform-level encryption. When external contractors download files to their own devices, that encryption ends. There is no FIPS-validated protection traveling with the file once it leaves the managed environment.

Three Scenarios Where Encryption Falls Short

1. The Subcontractor Download

A Tier 3 defense subcontractor is authorized to access a repository of ITAR-controlled design files for a specific program. Over 18 months, their team downloads files to work in disconnected environments — standard practice for controlled program work.

The program ends. You remove their SharePoint access on day one of offboarding. The downloaded files remain fully readable on their devices: no FIPS-validated encryption, no key-based access control, no way to verify that the files have been deleted or can no longer be accessed.

This is a SC.3.177 and MP.2.121 gap. The encryption never traveled with the file. MP.2.121 required it to.

2. The Affirmation Window

Your CMMC Level 2 self-assessment is complete. You've submitted your score in SPRS. For the next 364 days, until your next annual affirmation, your CUI is operating under your actual controls, not the documented ones. If your encryption implementation only covers files on your managed servers, every file that's been downloaded, forwarded, or copied to a contractor device is operating outside your compliant boundary.

The annual affirmation cycle assumes your controls are continuous. The question is whether your encryption is actually continuous, or just present on assessment day.

3. The Sensitive Bid Preparation

A program manager is building a proposal response under time pressure. They pull existing technical documentation from your SharePoint environment, combine elements into a new proposal document, and email the draft to an approved subcontractor for review. The email attachment leaves your mail server. No FIPS-validated encryption on the attachment. No key-based access control. If the subcontractor's email account is compromised three weeks later, that document is fully readable.

This is SC.3.177 applied to email transmission. The control requires FIPS-validated encryption to protect CUI in transit and at rest — not just on your servers, but anywhere CUI exists.

What a Day-47 Assessor Visit Looks Like

C3PAO assessments are methodical. For the encryption control family, assessors will typically request: evidence of FIPS-validated module usage, documentation of key management procedures, and a demonstration of access controls on CUI that has left the organizational perimeter.

That last requirement is where most assessments slow down. An assessor asks: "Show me how CUI on a contractor device is protected once that contractor's access has been revoked." The expected answer is cryptographic, not "we removed their SharePoint access."

Showing that you've revoked platform access is a necessary but insufficient response. The assessor is asking about the file, not the folder. For SC.3.177 and MP.2.121, the protection must travel with the data.

Organizations that can demonstrate per-file FIPS 140-3 validated encryption with cryptographic key revocation — showing that a file becomes unreadable ciphertext when a contractor's access is removed, regardless of where the file is stored — produce the evidence that maps directly to the control requirements. Organizations that can only show permission changes in SharePoint have a documentation problem for SC.3.177 and a compliance problem for MP.2.121.

If you want a detailed breakdown of the specific controls where defense subcontractors fail assessments and how to close the gaps, see our guide to passing C3PAO assessments.

How Per-File Encryption Closes the Gap

The controls above describe a requirement for encryption that follows the data. That's not a server-side control, it's a file-level control.

Data-centric security applies FIPS 140-3 validated AES-256 encryption to the file itself — not to the folder it's stored in, not to the server it lives on. Each file carries its own unique key. Access is governed by context-aware policy: identity, device compliance, geographic location, network, and time parameters are evaluated on every open attempt. The encryption and access controls travel with the file through email, onto contractor devices, into offline environments, and across cloud storage.

When a contractor is offboarded, the "revocation" happens at the cryptographic layer. You don't need to retrieve or delete the file from their device. Instead, because the user’s identity no longer meets the required contextual controls, the authorization is not granted, and the key is not released. The file remains on their device, but it is instantly rendered an inaccessible, encrypted block of data. This is cryptographic revocation—the persistent, verifiable proof of control that C3PAO assessors look for.

For organizations managing ITAR-controlled technical data alongside CMMC CUI, the same per-file controls address both ITAR data handling requirements and CMMC's SC.3.177 and MP.2.121 requirements simultaneously. One implementation, two compliance frameworks.

UK-based defense prime contractors or subcontractors operating under DCC (Defence Cyber Certification) requirements will find that the same data-layer controls map directly to DCC's information security requirements for protected defence information.

What This Doesn't Require

The question most security teams ask: Does FIPS 140-3 file-level encryption mean replacing SharePoint, migrating off Microsoft 365, or rebuilding file workflows?

No. Per-file encryption integrates at the file layer, not the platform layer. It works alongside your existing cloud storage, email infrastructure, and endpoint environment. Files are protected through a classification workflow applied to existing repositories. End users open files with the same applications they use today.

The implementation footprint for a proof of concept is a defined file population — a CUI repository, a contractor project folder, and an ITAR-controlled design library — configured, protected. See how Theodosian's platform works for the full architecture.

FAQs: CMMC Level 2 Encryption Requirements