CMMC Encryption Requirements: A Plain-English Guide to FIPS 140-2

Any CUI leaving a system boundary must be encrypted in transit. TLS 1.0 and 1.1 are not acceptable.

This practice requires implementing cryptographic mechanisms to prevent unauthorized disclosure of CUI during transmission unless otherwise protected by alternative physical safeguards. In modern network environments, this means TLS, full stop.

TLS version requirements:

• TLS 1.2 is the minimum acceptable version. TLS 1.3 is preferred
• TLS 1.0 and TLS 1.1 must be explicitly disabled. Both are deprecated and known-vulnerable to POODLE, BEAST, and related attacks
• SSL 2.0 and SSL 3.0 must be disabled. These are completely broken protocols

Windows Server / IIS implementation: Disable legacy TLS versions via Group Policy or registry settings. The recommended approach is to use the IIS Crypto tool from Nartac Software to enumerate and configure cipher suites and TLS versions, or to deploy the Microsoft Security Baseline which includes these settings. Verify using SSL Labs' server test or a tool like testssl.sh.

Microsoft 365 implementation: Microsoft 365 uses TLS 1.2 or 1.3 by default for all service-to-service communication. However, client connections may still negotiate TLS 1.0/1.1 if the client OS allows it. Enforce TLS 1.2 minimum on all client machines via Group Policy: Computer Configuration › Administrative Templates › Network › SSL Configuration Settings.

VPN and remote access: Remote access VPN connections must use TLS or IPsec with FIPS-approved algorithms. IKEv2 with AES-256 and SHA-256 is the current standard for IPsec VPNs. Document the cryptographic configuration of your VPN solution in your encryption policy.

Common mistake: Assuming that because your web server uses HTTPS, TLS is properly configured. Many web servers still support TLS 1.0/1.1 as fallback options. Run a TLS audit against every external-facing service and every internal web application that handles CUI.

Keys that protect CUI must be generated, stored, rotated, and destroyed according to a documented process.

This practice requires establishing and managing cryptographic keys when cryptography is employed within organizational systems. Key management is often the weakest link in an otherwise solid encryption program. You can encrypt everything correctly and still be vulnerable if your encryption keys are stored alongside the data they protect or never rotated.

Key management lifecycle requirements:

• Key generation: Keys must be generated using a FIPS-validated random number generator. Windows CNG and hardware security modules (HSMs) satisfy this. Avoid generating keys in scripts or spreadsheets
• Key storage: Encryption keys must never be stored in plaintext alongside the data they encrypt. BitLocker keys backed up to Active Directory or Entra ID are appropriately protected. TLS certificate private keys should be stored in the Windows certificate store or an HSM, not in a file system folder
• Key rotation schedule: Define and document a rotation schedule. A reasonable standard is 90 days for actively used symmetric keys and annual rotation for TLS certificates (with certificate expiration monitoring). BitLocker recovery keys should be rotated after any use and when personnel with key access depart
• Key distribution: Keys must be distributed using a secure mechanism. Emailing an encryption key in plaintext is not acceptable. Use the key exchange mechanisms built into TLS, use secure key management platforms, or use out-of-band secure communication for any manual key distribution
• Key destruction: At end-of-life, keys must be securely destroyed using NIST SP 800-88 compliant methods. For keys stored in software, this means overwriting key material. For keys in HSMs, follow the vendor's secure erasure procedure. Document all key destructions

Microsoft environment implementation: Use Azure Key Vault or Microsoft Purview to manage cryptographic keys for Azure-hosted workloads. For on-premises environments, Active Directory Certificate Services (AD CS) provides key management for internal PKI. BitLocker recovery keys stored in Entra ID satisfy the key escrow requirement.

Common mistake: Having no documented key management procedure. An assessor reviewing this practice will ask: who generates keys, where are they stored, when were they last rotated, and what happens when an employee with key access leaves? Organizations that treat keys as an afterthought will fail this practice even if their encryption is technically correct.

The most commonly cited encryption practice in CMMC assessments. The algorithm must be FIPS-validated, not just strong.

This practice requires employing FIPS-validated cryptography when used to protect the confidentiality of CUI. This is the core cryptographic requirement that underpins all other encryption practices.

Approved algorithms and minimum key lengths:

• Symmetric encryption: AES-128, AES-192, or AES-256 (AES-256 is the recommended standard)
• Asymmetric / key exchange: RSA with 2048-bit or larger keys; ECDSA/ECDH using P-256 or larger curves
• Hashing: SHA-256, SHA-384, SHA-512 (SHA-3 variants are also acceptable)
• Digital signatures: RSA-PSS or ECDSA with above parameters

Explicitly prohibited algorithms:

• DES and 3DES: Deprecated. 3DES is prohibited for new implementations; DES has been broken for decades
• RC4: Stream cipher with multiple known vulnerabilities. Must be disabled in TLS cipher suites
• MD5: Cryptographically broken. Not acceptable as a standalone security hash, though it appears in some TLS constructs where it is mitigated by the overall TLS design
• SHA-1: Collision attacks are feasible. Not acceptable for digital signatures or certificate issuance. Must be retired from TLS cipher suites
• RSA with keys shorter than 2048 bits: Key lengths below 2048 bits are insufficient

Enabling FIPS mode in Windows: Set the Group Policy "System cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing" under Computer Configuration › Windows Settings › Security Settings › Local Policies › Security Options. This policy restricts Windows cryptographic APIs to FIPS-validated algorithms and prevents applications from using non-compliant cipher suites through the Windows crypto layer.

Important caveat: Some applications break when FIPS mode is enabled in Windows because they rely on MD5 or SHA-1 internally. Test FIPS mode in a non-production environment before deploying. Applications that fail under FIPS mode are using non-compliant crypto and either need to be updated or evaluated for whether they handle CUI (if they don't touch CUI, they may be out of scope).

Common mistake: Relying on application-layer encryption without verifying the underlying cryptographic module. An application that claims to use AES-256 may be using an embedded, unvalidated library. Check for a FIPS 140-2 or FIPS 140-3 validation certificate. NIST maintains the CMVP database at csrc.nist.gov/projects/cryptographic-module-validation-program.

CUI sitting on a disk that isn't encrypted is a breach waiting for a stolen laptop.

This practice requires protecting the confidentiality of CUI at rest. Encryption at rest protects data when the system is powered off, when storage media is lost or stolen, and during decommissioning when drives are removed from service.

Endpoint implementation (Windows):

• Enable BitLocker on all in-scope Windows endpoints. BitLocker using AES-256 is FIPS 140-2 validated when FIPS mode is enforced
• Configure BitLocker via Group Policy: Computer Configuration › Administrative Templates › Windows Components › BitLocker Drive Encryption. Set encryption method to AES-256
• Require a PIN or startup key in addition to the TPM for higher-security scenarios involving CUI (this satisfies two-factor pre-boot authentication)
• Back up BitLocker recovery keys to Active Directory or Entra ID. This is the key escrow mechanism that satisfies part of practice 3.13.10
• Verify BitLocker status across the fleet using Intune compliance reports, Group Policy results, or the manage-bde -status command on individual machines

Endpoint implementation (macOS): Enable FileVault with AES-128 or AES-256 encryption. While FileVault uses XTS-AES-128 by default, the underlying Apple Secure Enclave and crypto library are FIPS 140-2 validated on modern Macs. Manage FileVault via Intune MDM profiles, and escrow recovery keys to Intune or a documented secure location.

Server implementation: BitLocker for Windows Server volumes containing CUI. For Linux, LUKS (Linux Unified Key Setup) with AES-256 is commonly used; verify the underlying OpenSSL or kernel crypto implementation has FIPS validation. Cloud-hosted storage (Azure Blob, SharePoint, Exchange) is encrypted at rest by Microsoft using BitLocker on the underlying infrastructure, satisfying the server-side requirement for those services.

Database encryption: Databases containing CUI should use Transparent Data Encryption (TDE) in addition to disk-level encryption. SQL Server TDE is available in SQL Server 2008 and later. Azure SQL Database enables TDE by default.

Common mistake: Encrypting the OS drive but leaving data drives unencrypted. BitLocker encrypts the drive it is applied to. A laptop with BitLocker on C: but a 2TB external drive containing CUI backups is not compliant. All drives, volumes, and removable media containing CUI must be encrypted.

Passwords stored in plaintext or with weak hashing are a critical vulnerability. Store them right.

This practice requires protecting passwords using cryptographic mechanisms. This applies to any system that stores passwords for accounts used to access CUI: Active Directory, web applications, VPN concentrators, network devices, and any other credential store in scope.

Acceptable password storage approaches:

• bcrypt: Specifically designed for password storage. Includes a work factor (cost parameter) that can be tuned to slow down brute force attacks as hardware improves. Widely considered the gold standard for application password storage
• PBKDF2 with SHA-256 or SHA-512: NIST recommended in SP 800-132. Used by many compliance-focused platforms. Requires a high iteration count (at minimum 210,000 iterations per OWASP 2023 recommendations)
• Argon2id: Winner of the Password Hashing Competition. Resistant to both GPU and side-channel attacks. Recommended for new implementations
• scrypt: Memory-hard hashing function. Provides good resistance to hardware-accelerated attacks

Active Directory: Windows Server 2008 and later stores passwords using AES-256 Kerberos encryption when legacy LAN Manager hash storage is disabled. Ensure the following GPO settings are configured: Network security: Do not store LAN Manager hash value on next password change (enabled), and Network security: LAN Manager authentication level set to "Send NTLMv2 response only. Refuse LM and NTLM."

What is explicitly not acceptable: MD5 password hashes (trivially crackable with rainbow tables), SHA-1 without salting, unsalted SHA-256, or any plaintext credential storage. These are automatic findings in any serious security assessment.

Common mistake: Assuming Active Directory handles this correctly by default. Default Windows environments may still have LAN Manager hash storage enabled for backwards compatibility. Verify this is disabled via Group Policy and that legacy NTLMv1 authentication is blocked across the domain.

A phone with CUI in email or files is an encrypted endpoint requirement, not an exception.

This practice requires encrypting CUI on mobile devices and mobile computing platforms when such devices are identified as in scope. If employees access CUI via mobile email clients, cloud storage apps, or business applications on personal or corporate phones, those devices are in scope.

iOS implementation: iOS uses AES-256 hardware encryption by default with a secure enclave. The device must have a passcode set to activate data protection (the encryption key is derived in part from the passcode). Manage via Intune MDM: enforce a minimum passcode complexity, enable encryption reporting, and configure remote wipe capability. The Apple cryptographic modules used in iOS are FIPS 140-2 validated (check Apple's Security Certifications page for current validation certificates).

Android implementation: Android has required full-device encryption since Android 6.0, and file-based encryption is the default since Android 7.0. Modern Android devices use AES-256 or AES-128. For corporate-managed Android devices, enforce encryption compliance via Intune or another MDM: require a device passcode, verify encryption is enabled in compliance policies, and block non-compliant devices from accessing corporate resources via Conditional Access.

Scoping consideration: If your organization has a clear policy that CUI is never accessed on mobile devices, and you have technical controls enforcing this (Conditional Access blocking mobile platforms from CUI systems, DLP policies preventing CUI downloads to mobile), mobile devices may be arguable out of scope. However, this requires both a documented policy and a technical enforcement mechanism, not just a policy alone.

Common mistake: Allowing employees to access work email on personal phones without MDM enrollment. Personal phones are not subject to your Group Policy or MDM compliance policies. If CUI flows into a mailbox that is accessed on personal devices, those devices are in scope and must be encrypted and managed. The solution is either MDM enrollment of personal devices or blocking mobile access to CUI systems entirely.