How AES-256 Encryption Supports CMMC Compliance

Defense contractors pursuing Cybersecurity Maturity Model Certification (CMMC) 2.0 face a fundamental requirement: protect controlled unclassified information (CUI) with encryption that meets federal cryptographic standards. AES-256 encryption satisfies this requirement when implemented through FIPS-validated cryptographic modules, but the encryption algorithm alone does not guarantee compliance. CMMC assessors examine not only whether encryption is present but whether it is properly implemented, appropriately validated, and supported by sound key management practices.

Most organizations in the defense industrial base (DIB) will pursue CMMC Level 2 certification, which incorporates all 110 security controls from NIST SP 800-171. Several of these controls explicitly require cryptographic protection for CUI at rest and in transit. Understanding how AES-256 encryption maps to these specific requirements—and where implementation gaps commonly occur—is essential for achieving and maintaining certification.

This guide examines the encryption requirements within CMMC Level 2, explains why AES-256 meets federal standards when properly implemented, and addresses the critical question of encryption key management when CUI resides on cloud infrastructure.

Key Takeaways

1. CMMC Level 2 requires FIPS-validated encryption for protecting CUI at rest and in transit, with specific requirements defined in NIST SP 800-171 controls SC.L2-3.13.8 and SC.L2-3.13.16.
2. Defense contractors must use FIPS-validated cryptographic modules, not simply FIPS-approved algorithms—FIPS 140-3 validation represents the current standard and demonstrates forward-looking compliance.
3. AES-256 encryption satisfies CMMC cryptographic requirements when implemented within a validated module and applied consistently across all systems and communication channels where CUI resides.
4. When CUI resides on FedRAMP Authorized cloud infrastructure, encryption key ownership directly impacts CMMC compliance posture—customer-owned keys (where only you can access the keys) provide unambiguous control boundaries versus customer-managed keys (where the cloud provider retains access).
5. Encryption key management practices receive significant scrutiny during CMMC assessments, including documentation of key generation, storage, rotation, and destruction procedures in the System Security Plan.

CMMC Encryption Requirements by Certification Level

CMMC 2.0 establishes three certification levels, each with distinct requirements based on the sensitivity of information being protected. Level 2 applies to organizations handling CUI and represents the certification tier most DIB contractors will pursue.

CMMC Level 1 addresses organizations handling only federal contract information (FCI) and includes 17 basic safeguarding practices. These foundational controls do not include explicit encryption requirements, though encryption remains a recommended practice for protecting any sensitive data.

CMMC Level 2 incorporates all 110 controls from NIST SP 800-171 Revision 2, including specific requirements for cryptographic protection. The System and Communications Protection (SC) control family contains the primary encryption mandates. Control SC.L2-3.13.8 requires cryptographic mechanisms to protect CUI during transmission, while SC.L2-3.13.16 requires protection of CUI at rest. These controls do not specify AES-256 by name but require encryption implementations that use FIPS-validated cryptographic modules.

CMMC Level 3 applies to organizations handling the most sensitive CUI and adds controls from NIST SP 800-172. These enhanced requirements may include stricter key management procedures, more frequent cryptographic assessments, and additional protections against advanced persistent threats. Organizations pursuing Level 3 should expect heightened scrutiny of their encryption architecture and key management practices.

Why AES-256 Meets CMMC Level 2 Standards

The Advanced Encryption Standard with 256-bit keys (AES-256) is approved by the National Institute of Standards and Technology (NIST) for protecting classified and unclassified federal information. This approval makes AES-256 the appropriate choice for CMMC compliance, but a critical distinction determines whether your implementation actually satisfies assessment requirements.

CMMC assessors verify that encryption is implemented through FIPS-validated cryptographic modules, not merely that a FIPS-approved algorithm is in use. An organization could implement AES-256 encryption using non-validated software libraries and fail their CMMC assessment despite using the correct algorithm. The cryptographic module itself—whether software, firmware, or hardware—must hold a valid FIPS 140 certificate.

The federal government is transitioning from FIPS 140-2 to FIPS 140-3 as the validation standard for cryptographic modules. FIPS 140-2 certificates remain valid until their expiration dates, but new validations are issued under FIPS 140-3. Organizations selecting encryption solutions should prioritize FIPS 140-3 validated products, which demonstrate alignment with current federal cryptographic requirements and avoid the risk of relying on aging FIPS 140-2 certificates that may expire during a contract period.

The 256-bit key length provides the security margin appropriate for protecting CUI. While AES-128 also holds NIST approval, AES-256 offers greater resistance to future cryptanalytic advances and aligns with DoD preferences for protecting sensitive defense information.

Encrypting CUI at Rest for CMMC Compliance

NIST SP 800-171 control SC.L2-3.13.16 requires organizations to protect the confidentiality of CUI at rest. This requirement applies wherever CUI is stored: file servers, databases, endpoints, backup systems, email archives, and cloud storage.

Defense contractors must identify all locations where CUI resides and verify that encryption protects each repository. Common storage scenarios requiring encryption include engineering drawings and technical specifications stored on file shares, contract documents and correspondence in document management systems, email archives containing CUI exchanged with government agencies or subcontractors, database records with controlled technical information, backup tapes and disaster recovery systems, and endpoint devices including laptops used by employees with CUI access.

Encryption at rest can be implemented at multiple levels. Full-disk encryption protects entire storage volumes, while file-level encryption protects individual files regardless of where they are stored or moved. Database encryption protects structured data within database management systems. Many organizations implement layered encryption, combining volume-level and file-level protection for defense in depth.

The encryption implementation must use a FIPS-validated module. Self-encrypting drives, operating system encryption features, and third-party encryption solutions all require FIPS 140 validation to satisfy CMMC requirements. Organizations should maintain documentation of the FIPS certificate numbers for each encryption product deployed in their environment.

Encrypting CUI in Transit for CMMC Compliance

NIST SP 800-171 control SC.L2-3.13.8 requires cryptographic mechanisms to prevent unauthorized disclosure of CUI during transmission. This requirement covers all communication channels used to transmit CUI: network connections, email, file transfers, and API communications.

Transport Layer Security (TLS) provides the foundation for most transmission encryption. TLS 1.2 and TLS 1.3 support cipher suites that use AES-256 for bulk encryption, satisfying the cryptographic strength requirements for protecting CUI. Organizations should configure their systems to require TLS 1.2 or higher and disable older protocol versions that contain known vulnerabilities. TLS 1.3 offers improved security and performance over TLS 1.2 and represents the current best practice for protecting CUI in transit.

Email presents a particular challenge for defense contractors. Standard email transmission does not encrypt message content end-to-end, leaving CUI exposed as messages traverse mail servers. Secure email solutions that apply AES-256 encryption to message content—not just the transmission channel—provide the protection CMMC requires for email containing CUI.

File transfer operations require similar attention. Secure File Transfer Protocol (SFTP) and FTPS both support encrypted transmission, but organizations must verify their implementations use FIPS-validated cryptographic modules. Large file transfers between defense contractors, subcontractors, and government agencies frequently contain CUI and require consistent encryption protection.

API communications between systems also fall under transmission encryption requirements. Organizations integrating with government systems or exchanging CUI through automated interfaces must ensure these connections use appropriately encrypted channels.

Encryption Key Management on FedRAMP Authorized Infrastructure

Many defense contractors leverage FedRAMP Authorized cloud services for storing and processing CUI. While FedRAMP Authorization confirms that a cloud service provider meets federal security requirements, it does not automatically satisfy the contractor’s CMMC obligations. The contractor remains responsible for their own compliance, including demonstrating appropriate control over CUI access.

Encryption key management determines who can actually access encrypted CUI, regardless of where it is stored. Three key management models exist for cloud-hosted data, each with different implications for CMMC compliance.

Provider-managed keys represent the simplest implementation: the cloud provider generates, stores, and controls encryption keys. While the data is encrypted, the provider retains technical capability to decrypt it. This model raises significant questions during CMMC assessment about whether the contractor maintains adequate control over CUI access.

Customer-managed keys (often called Bring Your Own Key or BYOK) give the contractor control over key generation and lifecycle decisions, but the keys are uploaded to and stored within the cloud provider’s key management service. The provider retains technical access to these keys and can be compelled to decrypt data under the CLOUD Act or other legal processes—often without notifying the customer. For CMMC purposes, this model creates ambiguity about who truly controls access to CUI.

Customer-owned keys (Hold Your Own Key or HYOK) provide genuine separation. The contractor maintains encryption keys exclusively in their own key management system or hardware security module (HSM), and the cloud provider never possesses the keys. Even if the provider receives a government subpoena, they cannot decrypt CUI because they lack the keys to do so. This model establishes unambiguous control boundaries that satisfy CMMC assessor scrutiny.

FedRAMP Authorized status addresses the cloud provider’s security posture but does not determine the contractor’s key management approach. CMMC assessors will examine how the contractor controls access to CUI. Customer-owned encryption keys—where the contractor is the sole party capable of decrypting CUI—provide definitive evidence of that control. Customer-managed keys, despite the reassuring terminology, leave cloud providers with technical access that complicates compliance narratives.

Common CMMC Encryption Deficiencies

CMMC assessments frequently identify encryption-related deficiencies that prevent certification. Understanding these common gaps helps organizations prepare more effectively.

Using non-validated encryption modules remains a frequent finding. Organizations may implement AES-256 encryption through libraries or products that lack FIPS 140 validation, failing to meet the validated module requirement even though the algorithm is correct.

Incomplete encryption coverage creates gaps when CUI is not encrypted in all locations where it resides. Email systems, collaboration platforms, and endpoint devices often lack encryption even when core file storage is protected.

Inadequate documentation in the System Security Plan (SSP) leads to assessment findings even when technical controls are properly implemented. The SSP must document encryption methods, FIPS certificate numbers, key management procedures, and the systems covered by encryption controls.

Reliance on cloud provider encryption without understanding key management implications can create ambiguity about CUI access control. Assessors will examine whether the contractor or the cloud provider ultimately controls access to encrypted CUI.

Outdated FIPS validation certificates present compliance risk if certificates expire during a contract period. Organizations should track certificate expiration dates for all encryption products in their environment.

Gaps in encryption coverage during data movement occur when CUI is protected at rest and during external transmission but moves unencrypted between internal systems. Assessors examine the complete data flow, not just storage and external communications.

Protect CUI with Kiteworks’ Robust Encryption Capabilities

CMMC Level 2 certification requires defense contractors to demonstrate that CUI is protected by FIPS-validated encryption at rest and in transit, supported by documented key management practices. AES-256 encryption satisfies the cryptographic requirements when implemented through properly validated modules and applied consistently across all systems handling CUI.

The choice of key ownership model significantly impacts CMMC compliance posture, particularly when CUI resides on cloud infrastructure. Customer-owned encryption keys—where only you possess the keys and even your cloud provider cannot access them—establish definitive control boundaries that satisfy assessor scrutiny and eliminate ambiguity about CUI access.

Kiteworks supports nearly 90% of CMMC Level 2 requirements out of the box. This includes FIPS 140-3 validated encryption—the current federal validation standard, not the older FIPS 140-2—for protecting CUI at rest and in transit. The platform, a Private Data Network, secures data in motion with TLS 1.3 encryption, the strongest available transport layer protocol, across email, file sharing, managed file transfer, and web forms.

For email communications containing CUI, the Kiteworks email protection gateway automatically applies AES-256 encryption to outbound messages, eliminating reliance on end users to make encryption decisions and ensuring consistent protection across the defense supply chain.

Kiteworks features a customer-owned key architecture ensures defense contractors maintain sole ownership of their encryption keys, even when deployed on FedRAMP Authorized infrastructure. Your cloud provider cannot access your CUI because they never possess the keys required to decrypt it—providing unambiguous evidence of CUI access control for CMMC assessors.

Organizations requiring the highest level of key protection can integrate Kiteworks with hardware security modules (HSMs) for tamper-resistant key storage that meets FIPS 140-3 validation requirements.

To learn how Kiteworks supports CMMC 2.0 compliance with FIPS 140-3 validated, customer-owned encryption keys, schedule a custom demo tailored to your defense contracting environment.