CMMC discussions often collapse two separate questions into one: how the organization protects CUI at rest, and when cryptography used for that protection must be FIPS validated. NIST SP 800-171 Rev. 2 requirement 3.13.16 calls for protecting the confidentiality of CUI at rest; requirement 3.13.11 addresses FIPS-validated cryptography when cryptography is employed to protect CUI confidentiality.
That means the architecture should be analyzed by storage location and threat. A controlled server room, a laptop carried off site, a cloud disk, a removable drive, a backup copy, and a printer hard drive are not interchangeable simply because all can store the same file.
Map every place CUI can come to rest
Start beyond the obvious file server. CUI may rest on laptops, workstation caches, local downloads, shared drives, collaboration platforms, databases, email mailboxes and attachments, application storage, virtual-machine disks, snapshots, backup repositories, removable media, mobile devices, print spools, scanner destinations, and temporary export folders. Include synchronization clients that create local copies.
Map each storage location to the CMMC asset boundary and data flow. Identify owner, platform, type of CUI, protection method, who can access it, and what happens when the device is lost, removed, decommissioned, or backed up. This exposes locations that a simple 'disk encryption enabled' statement misses.
Pay special attention to administrative exports and troubleshooting copies. An engineer may export logs, database rows, or configuration bundles containing CUI to a desktop for analysis and then forget the file. Procedures should define approved locations and cleanup expectations so temporary handling does not create an unmanaged at-rest copy.
Choose protection based on the storage context
Full-disk encryption is useful for portable endpoints because it protects data when a powered-off device is lost or stolen. It does not necessarily protect CUI from a logged-in user who already has access. File-, volume-, database-, or application-level controls may be needed depending on the threat and workflow. Layer encryption with access control, least privilege, and physical protection rather than treating one mechanism as the entire control.
For fixed systems in controlled facilities, physical safeguards can be part of the confidentiality protection strategy. Document the actual boundary, access restrictions, server-room controls, and operational assumptions rather than relying on an undocumented belief that 'it never leaves the building.' If removable drives, maintenance, backups, or remote administration change that assumption, update the protection model.
Cloud storage requires the same data-location discipline. Identify the service, tenant, repositories that may contain CUI, encryption state, key-management model, access roles, backup or replication behavior, and any endpoint sync that creates local copies. Do not stop at a provider marketing page.
Decide when physical protection is doing real work
Physical protection can be part of the at-rest design where access to the storage media is genuinely constrained—for example, equipment inside a controlled facility or protected enclosure with tightly governed access. Document the boundary, who can enter, how access is controlled, and what changes when the media leaves that boundary.
Do not use 'physical protection' as a blanket explanation for portable devices, removable media, or systems routinely taken into uncontrolled locations. Once the threat model includes loss, theft, off-site maintenance, or unauthorized physical access, encryption or other safeguards may become necessary to maintain confidentiality.
Understand what FIPS validation means in this control
Requirement 3.13.11 applies when cryptography is used to protect the confidentiality of CUI. The evidence should identify the cryptographic module and its validated status, not merely an algorithm name. A product can support a strong algorithm while using an implementation that has not been validated for the relevant mode or version.
Document the relationship between the deployed product or operating-system feature and the validated cryptographic module it uses. Keep configuration evidence showing that the product is operating in the intended FIPS-validated mode where that is required. Product upgrades can change modules or validation status, so the mapping should be maintained rather than created once and forgotten.
Avoid vague assertions such as 'Microsoft is FIPS' or 'AES-256 is compliant.' The assessor needs a chain from the specific protection mechanism to the module and configuration in use. Where cryptography is not the protection method, document the alternative safeguards and why they protect CUI confidentiality at rest.
- Identify the cryptographic module/implementation actually used
- Confirm the relevant FIPS validation evidence for that implementation
- Record configuration that enables the validated mode where applicable
- Avoid treating algorithm names such as AES-256 as validation proof
Treat keys and recovery material as part of the design
Encryption fails operationally if keys are broadly accessible, escrowed insecurely, or unrecoverable after an employee leaves. Define who can administer keys, who can recover data, where recovery material is stored, how emergency access is approved, and how key-related administrative events are logged.
Separate ordinary data access from key administration where practical. A cloud administrator who can both grant themselves access and replace or export encryption keys may hold more power than the organization intends. Use the platform's role model to reduce standing privilege and review high-impact key operations.
Test recovery. A laptop encryption deployment that has no usable recovery key can create availability problems, while a recovery key stored in an unrestricted spreadsheet can defeat confidentiality. Preserve evidence of controlled recovery procedures without placing live secrets into the assessment evidence folder.
Cover backups, removable media, and device lifecycle
Backups can contain the same CUI as production systems and may retain older versions long after the live file is removed. Identify whether backup media or repositories are encrypted, who can restore them, whether copies leave the facility or region, and how retention and deletion work. Do not classify the backup system as outside the data boundary solely because users do not interact with it every day.
Removable media needs an approved handling model. If the organization permits CUI on portable storage, determine how the media is identified, controlled, encrypted during transport where applicable, stored, and sanitized before reuse or disposal. If the policy prohibits it, technical controls and monitoring should support the prohibition instead of relying only on employee memory.
At disposal or reassignment, connect at-rest protection to media sanitization. Encryption alone does not eliminate the need to follow the organization's sanitization or destruction process when media containing CUI is reused or discarded. Keep disposition records for representative devices and media.
Prepare evidence by storage location, not by vendor
Build an evidence matrix with rows for endpoint storage, servers, cloud repositories, email, backups, removable media, mobile devices, and any specialized location that can contain CUI. For each row, list the protection method, responsible control owner, cryptographic module where relevant, configuration evidence, recovery process, and test artifact.
Sample the real state. Verify disk-encryption status on multiple endpoints, storage encryption on representative servers or cloud repositories, key-role assignments, backup settings, and controls that prevent unapproved local copies. If an exception exists, show the approved alternate protection and why it is sufficient for the context.
This location-based approach prevents a common assessment failure: presenting one FIPS certificate and assuming it proves every CUI copy is protected. The assessor can instead trace the CUI data flow to each place it rests and see the specific safeguard applied there.
A short working check
- ✓Inventory every location where CUI can rest
- ✓Assign a documented confidentiality protection method to each location
- ✓Verify real endpoint, server, cloud, and backup configurations
- ✓Map cryptographic mechanisms to FIPS-validated modules where cryptography protects CUI
- ✓Control key administration and recovery material
- ✓Address temporary exports, caches, and synchronization copies
- ✓Include backups and removable media in the protection model
- ✓Connect device disposal and reuse to media sanitization
Common questions
Does 3.13.16 mean every CUI file must always be encrypted?
The requirement is to protect the confidentiality of CUI at rest. Cryptography is a common protection method, but the assessment should examine the actual safeguards and context. If cryptography is used to protect CUI confidentiality, requirement 3.13.11 requires FIPS-validated cryptography.
Is AES-256 by itself proof of FIPS compliance?
No. FIPS validation applies to the cryptographic module and its validated implementation or mode, not merely to the name or key size of an algorithm. Evidence should map the deployed feature to the applicable validated module.
Do backups count as CUI at rest?
If the backup contains CUI, it is a storage location for CUI and should be included in the protection model, including encryption or other safeguards, access control, recovery, retention, and disposal considerations.
Official sources used for this guide
Open the primary source before making a contract-specific decision. Regulations and program implementation can change.
