Does every device holding CUI need FIPS validation? No. Does an AES-256 checkbox prove compliance? Also no. Start with the information, the applicable requirement, and the protection actually used.
Business Communication Solutions helps Austin and Houston contractors review CMMC encryption requirements, provider responsibilities, and supporting evidence. This guide focuses on CMMC Level 2 and its NIST SP 800-171 Revision 2 baseline.
Discuss your environment: Austin: 512-257-1433 | Houston: 281-815-8784.
The core rule: encryption protecting CUI confidentiality
SC.L2-3.13.11 requires FIPS-validated cryptography when cryptography protects CUI confidentiality. Validation applies to a cryptographic module and its approved implementation—not automatically to an entire company, device, application, or encryption algorithm.
Read the related requirements together: remote access (3.1.13), wireless (3.1.17), mobile devices (3.1.19), digital media transport (3.8.6), transmission confidentiality (3.13.8), and CUI at rest (3.13.16). Their wording and permitted safeguards differ. Source: NIST SP 800-171 Revision 2.
NIST has published Revision 3, but do not substitute its numbering or wording for the CMMC Level 2 baseline. Confirm the requirements applicable to your contract and assessment.
When is FIPS-validated encryption required?
Use this comparison to guide discovery. The result depends on actual data flows, the cryptographic implementation, and any expressly permitted alternative safeguards.
| Situation | FIPS-validation treatment | What to verify |
|---|---|---|
| CUI sent over the internet: email, file transfer, cloud sync | Use validated cryptography for the encryption protecting CUI confidentiality in transit. | Trace the actual protected path and endpoints; an ordinary HTTPS or TLS label alone is not validation evidence. |
| Remote access to the CUI environment: VPN or remote desktop gateway | Remote-access sessions require cryptographic protection; validate the relevant implementation protecting CUI. | Check the VPN/gateway, clients, approved modes, and traffic paths. MFA does not replace encryption. |
| Wireless carrying CUI | Wireless protection requires authentication and encryption; verify FIPS validation for the cryptography protecting CUI. | A WPA2/WPA3 or Enterprise label alone does not prove validation. Review the actual architecture and cryptographic layer relied on. |
| Laptops and other mobile devices storing CUI | Apply the mobile-device encryption requirement and use validated cryptography for CUI confidentiality. | Confirm encryption coverage, module/platform/version, approved operation, and protected recovery keys. |
| USB drives and other digital media transporting CUI | Use validated encryption unless the applicable media-transport requirement is satisfied through alternative physical safeguards. | A general media policy does not demonstrate adequate safeguards; document and verify the actual transport arrangement. |
| Offsite or cloud backups containing CUI | Verify validated encryption wherever encryption protects CUI confidentiality, including transfers and stored copies. | Review backup storage, restores, replicas, key handling, provider boundaries, and applicable cloud obligations separately. |
| Internal wired transmission within a protected environment | Alternative physical safeguards may satisfy transmission confidentiality under 3.13.8. | Being inside the office or assessment boundary is insufficient by itself. Establish how the entire path prevents unauthorized disclosure. |
| Stationary server or on-site NAS holding CUI | Protect CUI at rest. Depending on the environment, appropriate non-cryptographic controls may satisfy 3.13.16. | A locked room alone is not a complete analysis. Review logical access, maintenance, theft, media removal, disposal, backups, and other applicable requirements. |
| Extra encryption inside an already protected environment | Do not automatically assume either exemption or mandatory validation from the feature’s presence alone. | Determine whether it protects CUI confidentiality or serves another purpose. Calling it an extra layer does not waive applicable requirements. |
| SIEM records verified to contain no CUI | 3.13.11 is not triggered solely by encrypting non-CUI security data. | The service may remain in scope as a Security Protection Asset. Check payloads, file samples, attachments, and other requirements. |
Physical safeguards: an exception must be demonstrated
Requirements 3.13.8 and 3.8.6 expressly permit alternative physical safeguards for their respective transmission and media-transport scenarios. This is not a blanket exception for every system located inside an assessment boundary. Wireless and remote access have additional requirements that must also be addressed.
For CUI at rest, 3.13.16 requires confidentiality protection without prescribing encryption as the only possible method. A stationary storage design may use effective physical and logical protections. However, the review must account for unauthorized access, service personnel, drive removal, failed disks, disposal, and every copy of the data.
An SSP documents the implemented approach; it does not create an exemption. Describe and verify how the controls satisfy the relevant objectives. If CUI confidentiality depends on encryption, verify the applicable FIPS validation.
Three practical examples
1. On-site NAS: A NAS stays in a controlled server room. Review access permissions, physical access, administration, removed drives, and backup destinations before deciding whether non-cryptographic safeguards satisfy the relevant requirements. Encryption used for a cloud copy must be evaluated separately from the on-site NAS.
2. Traveling laptop: A laptop containing CUI leaves the controlled workspace. Do not extend a stationary-server rationale to this mobile device. Verify the applicable encryption requirement, the implementation, and the protection of recovery information.
3. MDR or SIEM: A service receives security telemetry only. Confirm whether investigation features upload file contents, screenshots, or attachments that could introduce CUI. A product’s security role alone does not determine which data it actually processes.
AES-256, FIPS-approved, and FIPS-validated are different
AES identifies an encryption algorithm; a key length does not identify a validated module. Algorithm testing and cryptographic-module validation are different steps. Products can incorporate another vendor’s validated module, so a brand-name search alone may not settle the question.
Ask the vendor for the module name and certificate number, product-to-module mapping, supported version and environment, and required approved-mode configuration. Check the CMVP entry, Security Policy, caveats, and certificate status. A FIPS-mode checkbox alone does not show the application uses that module for the relevant data path. Do not assume every product requires the same global operating-system switch.
NIST’s CMVP validated-modules guidance and search explains the evidence to check. “In process,” a roadmap promise, and a general “military-grade encryption” claim do not establish completed module validation.
FIPS and FedRAMP answer different questions
FIPS validation concerns cryptographic modules. FedRAMP addresses a cloud service’s security requirements and assessment or authorization context. Neither label automatically establishes every requirement for your configuration. Review our ESP/FedRAMP comparison and five CMMC asset categories.
What evidence should you keep?
Map the CUI: Identify devices, transfers, applications, storage, backups, and providers.
Identify the control: Record which requirement applies and whether encryption or permitted alternative safeguards provide protection.
Verify implementation: Retain vendor statements, relevant certificates and Security Policies, configuration evidence, and test results.
Control changes: Review updates, new platforms, changed modes, backup destinations, and certificate status before assuming the evidence still applies.
Assign an owner: Identify who maintains the configuration, keys, evidence, and provider coordination.
For assessment scoring and conditional POA&M considerations, read CMMC Level 2: 88 vs. 87 and the backup-encryption mistake. An encryption gap is not resolved by describing the product as strong encryption.
CMMC encryption readiness support in Austin and Houston
BCS helps small businesses connect compliance requirements with practical IT implementation. We can review CUI workflows, encryption settings, backup architecture, mobile access, and vendor evidence alongside your internal IT team or existing provider.
Start with a free cybersecurity risk assessment conversation, or explore CMMC consulting in Austin and Houston. Detailed validation reviews, testing, and remediation are scoped separately. Readiness support does not replace an assessment or guarantee CMMC status.
Austin: 512-257-1433
Houston: 281-815-8784
Lampasas: 512-865-4000
Primary references: NIST SP 800-171 Revision 2; DoD CMMC Level 2 Assessment Guide; NIST CMVP. Guidance reviewed October 25, 2026.