FIPS 140 validated encryption for CUI: what it requires

When must FIPS 140 validated encryption protect CUI?

If a contract or customer now requires NIST SP 800-171, the question is whether your encryption must use a FIPS 140 validated module or whether an approved algorithm is enough. The CMMC Assessment Guide for Level 2 answers this directly: an approved algorithm is not sufficient on its own, because the cryptographic module must be validated under FIPS 140. Validated cryptography is required for CUI that is protected outside the protected environment, including wireless and remote access. The same guide does not require validated cryptography for encryption used for other purposes inside the protected environment. Under 32 CFR 170.24, the SC.L2-3.13.11 requirement costs 5 points if no encryption is employed, but only 3 points if encryption is employed without FIPS validation. That gap is the practical reason to settle the question before the assessment, not during it.

The answer depends on where CUI travels and where it rests. Start with a data flow map that lists every transmission path that leaves the protected environment, such as VPN tunnels for remote workers, wireless links, email, file transfer to subcontractors, and API calls to cloud services, and every storage location that holds CUI, including backups, laptops and cloud object stores. For each path and location, record which cryptographic module performs the encryption and whether that module carries a current FIPS 140 validation certificate. Confirm the validation status against the module's certificate and version, not the product name, because a product can be validated in one release and not another. Requirement 03.13.11 leaves the types of cryptography to the organization, but NIST recommends FIPS-validated cryptography for protecting CUI, so an unvalidated choice is a decision you must be able to defend to an assessor.

How unvalidated encryption changes the SC.L2-3.13.11 score

This table compares the three outcomes for SC.L2-3.13.11 under the CMMC scoring method: no encryption, encryption that is not FIPS-validated, and FIPS-validated encryption. Read each row as the deduction an assessor applies and whether a plan of action and milestones (POA&M) can cover the gap. The main takeaway is that the only point-reducing gap that can go on a POA&M is the unvalidated encryption case.

Encryption state	Points deducted	POA&M eligibility
No encryption used for CUI	5 points	Not eligible. Only the 3-point case may go on a POA&M under 32 CFR 170.21.
Encryption used but not FIPS-validated	3 points	Eligible under 32 CFR 170.21, and only in this case.
FIPS-validated encryption protecting CUI outside the protected environment	No deduction	Not applicable because no gap exists for this requirement.
Algorithm is approved but module is not FIPS 140 validated	3 points	Treated the same as any unvalidated encryption, since the CMMC Assessment Guide requires the module itself to be validated.
Validated cryptography used for encryption inside the protected environment for other purposes	Not required by SC.L2-3.13.11	Confirm with your assessor how the scope boundary applies to internal encryption.
MFA (3.5.3) covers only remote and privileged users	3 points instead of 5	Partial credit case, separate from encryption. Confirm the exact MFA coverage with your assessor.

Where validated cryptography is needed and where it is not

SP 800-171 Rev. 3 requirement 03.13.11 asks for cryptography that protects CUI, and CMMC Level 2 scoring turns on whether that cryptography is FIPS-validated. Validation matters most where CUI leaves the protected environment, and much internal encryption falls outside it. The cards below show where to check your own data flow diagram before deciding which modules need validation.

CUI in transit outside the boundary

Any path that carries CUI past your protected environment, such as a connection to a subcontractor, a government system or a hosted service, is where the CMMC Assessment Guide expects validated cryptography. An approved algorithm alone does not satisfy the assessor. On your data flow diagram, trace every arrow that crosses the boundary and record the module that encrypts each one, including the library version and the validation certificate it claims. A FIPS 140 validation certificate must cover the module that actually performs the encryption, not only the parent product.

Remote access and VPN tunnels

Remote access sessions carry CUI from outside the protected environment, so the CMMC guide treats them as a case that requires validated cryptography. Check which component terminates each tunnel, whether that is a firewall, a VPN concentrator or a virtual desktop gateway, and whether its cryptographic module is validated for the protocol and mode in use. Ask the vendor for the certificate number and confirm that the validated mode is enabled in your configuration, since many devices offer both validated and non-validated modes.

Wireless transmission

Wireless links that carry CUI, including Wi-Fi used by staff outside the controlled site, fall within the same validated-cryptography expectation as other transmission outside the protected environment. Inventory each wireless network that touches CUI systems, the access points that serve them and the encryption setting on each. Confirm the access point or controller module is validated and that legacy protocol options are disabled. Guest and personal networks that never carry CUI belong outside this scope but should be documented as excluded.

Encrypted backups and storage media

Backups and removable media holding CUI are protected under the transmission and storage confidentiality requirement, 03.13.08, and the encryption they use must be checked against the validated-module expectation. Identify where backup jobs run, which tool performs encryption, and whether keys are held in the same location as the backups. Ask your backup provider which module performs the encryption and whether that module is validated, and document the answer. Any backup copy stored at a location outside your boundary needs the same treatment as a transmission.

Cloud key management

Where a cloud provider holds the keys that protect CUI, the question becomes which hardware security module holds the key material. Microsoft states that Azure and Azure Government support customer-managed keys stored in FIPS 140 validated hardware security modules managed by Azure Key Vault. Confirm with your provider which key tier you are buying, whether the keys are stored in hardware or software modules, and whether the service in your contract is covered by the provider's compliance documentation. Record the key location and custody model in your system security plan.

Encryption used for other purposes inside the boundary

Encryption that protects things other than CUI transmission inside the protected environment, such as internal service authentication, database connection security or software update signing, does not need to be validated under the CMMC guide. The guide states that validation is not required for encryption used for other purposes inside the protected environment. Mark these uses on your diagram, record why each one is out of the CUI path, and revisit the decision when the design changes, since a data path that later carries CUI across the boundary moves into scope.

How ITAR and DHS email rules set their own encryption tests

ITAR and DHS email rules set encryption tests that can be stricter than SP 800-171, so the first task is to confirm which rules apply to your CUI. Under ITAR 22 CFR 120.54(a)(5), sending, taking or storing unclassified technical data is not an export if it is protected with end-to-end encryption that uses FIPS 140-2 (or a successor) compliant modules, or other means of at least AES-128 strength, and the data is not intentionally sent to or stored in a country proscribed under 22 CFR 126.1. The safe harbor has two parts: the cryptography test and the destination test. A cryptography choice that satisfies SP 800-171 Rev. 3 still fails ITAR if an ITAR-controlled file transits or sits in a proscribed country, and a team that relies on a hosting region without checking data replicas, backups and support access may not know where the data actually goes. Ask your export compliance officer to confirm whether the technical data is ITAR-controlled and to document where every copy is held.

HSAR 3052.204-72 sets a separate test for email. It requires CUI sent by email to be encrypted, or sent within a secure communications system, using a FIPS 140-2 or 140-3 validated cryptographic module. Regular email is allowed only for Federal information systems when this is impractical, so a nonfederal organization handling DHS CUI should not assume that a standard mail tenant meets the clause. The practical decisions are which mail platform will hold the keys, whether the validated module is the one doing the encryption in each path, and what happens when a recipient is outside the secure system. Confirm with the contracting officer whether the clause appears in your contract and whether it or the DFARS and SP 800-171 requirements govern each data flow.

A contract may impose stricter rules than SP 800-171, and the contract controls. Agencies can add cryptographic requirements, specify validated modules, or limit storage locations beyond the baseline, so ask the contracting officer for every clause that touches CUI encryption and record the answer in your system security plan. Where the ITAR and DHS tests differ from the 03.13.11 scoring rule, plan to meet the strictest one for that data flow instead of the lowest one that passes an assessment.

Choosing cloud key management for FIPS validated protection

Microsoft states that Azure and Azure Government support customer-managed encryption keys stored in FIPS 140 validated hardware security modules managed by Azure Key Vault. This lets the organization keep control of the key material while the cloud provider runs the platform. The organization still has to prove that its own workloads call the validated service for CUI, and that the key configuration matches what the system security plan describes.

Module validation: Confirm which Key Vault tier and HSM type backs each key, and retrieve the FIPS 140 certificate number for that module from Microsoft's current compliance documentation.
Module boundary: Record whether the boundary covers the HSM only or the wider service, since the assessor will ask what is inside the validated boundary.
Key custody: Document who can create, rotate, and delete keys, and whether keys are generated inside the HSM or imported.
Region: Confirm that the CUI workload and the key vault sit in an approved region, and that Azure Government is used where the contract requires it.
Assessor evidence: Expect requests for the key policy, role assignments, rotation logs, diagnostic logs, and the configuration that links each encrypted store to the vault.

Before relying on this option, check the current certificate and the wording in the contract, since the assessor will test the configuration as deployed rather than the vendor's general claim.

How to move from unvalidated encryption to an assessable state

This sequence takes CUI encryption from a state where cryptography is merely in use to one an assessor can verify against FIPS 140 validation evidence. Each step produces a record that feeds the next, ending with the system security plan describing the validated configuration.

Inventory every CUI data flow
Map each place CUI moves or rests: email, file transfers, remote sessions, collaboration tools, backups, endpoints, mobile devices and cloud storage. Include flows to subcontractors and service providers. The engineering owner signs off that the list matches the system boundary. The output is a CUI data flow register that names each flow, its direction, its protection mechanism and the system that terminates the encryption.
Identify the cryptographic modules performing each function
For every flow in the register, record which software library, operating system component, hardware security module, VPN appliance, browser or cloud service performs the encryption. Confirm whether the module is used outside the protected environment, since validated cryptography is required for CUI protected outside that environment, including wireless and remote access. The output is a module inventory linking each flow to a named product, its exact version and its deployment owner.
Verify FIPS 140 validation status and exact version
Check each module against the NIST Cryptographic Module Validation Program list, matching the vendor, product name, version and validation certificate number. An approved algorithm alone does not satisfy the requirement, so confirm the validated module itself and whether the certificate is current. Record the certificate number and validation date for each module. Where a module is not listed, mark that flow as unvalidated and record it as an open gap. The output is a validation matrix with a pass or gap status per flow.
Reconfigure systems to validated mode only
Change each gap flow to use a validated module, and enable the platform's FIPS mode where it exists. Disable fallback to non-validated ciphers and protocols, and remove or disable legacy cipher suites that would let a connection negotiate outside the validated set. Test that the change does not break transfers or sessions. The output is a change record for each reconfigured system, approved through your normal change control process.
Collect configuration and certificate evidence
For each system, capture the evidence an assessor will request: the configuration setting showing FIPS mode enabled, the software or firmware version, a sample of negotiated connection parameters, the validation certificate reference and screenshots or exports dated after the change. Store these in a versioned evidence repository with the owner's name. The output is an evidence package that ties each validated flow to a verifiable configuration state.
Confirm key management and storage encryption
Review how the encryption keys for CUI at rest and in transit are generated, stored and rotated. Where a cloud provider offers customer-managed keys in FIPS 140 validated hardware security modules, confirm the key service tier and region meet your requirement and document who holds administrative control. Record the key custody model and the validation reference for each key store. The output is a key management record covering each encrypted store.
Document the result in the system security plan
Update the system security plan so that the cryptographic requirement names each validated module, its certificate reference, the flows it protects and the evidence location. Record any remaining gap in the plan of action and milestones with its owner and the approach you will take. Have the plan reviewed by the people accountable for it. The output is a system security plan section that an assessor can trace from requirement to module to evidence.

What evidence an assessor will ask to see

An assessor testing 03.13.11 and 03.13.08 will not accept a statement that encryption is FIPS validated. They will ask for records that show which modules are in use, that they run in approved mode, and that keys and cryptographic uses are managed. The organization owns this evidence, and the independent assessor judges whether it is sufficient.

Validation certificate references

Collect the NIST Cryptographic Module Validation Program certificate number for every module that protects CUI, and match each one to the exact software or hardware version deployed. The CMMC Assessment Guide Level 2 treats an approved algorithm alone as insufficient, so an algorithm name in a configuration file does not count. Check that the certificate is active and that the version on the certificate matches production, since a patched or upgraded module may fall outside its validation.

FIPS mode configuration settings

Export the settings that place each system into FIPS mode, such as operating system crypto policy, application TLS libraries and VPN gateways. Assessors look for evidence that the mode is enforced at runtime, not just configured in a file that a service ignores. Capture a dated screenshot or command output from each system, and note any service that still negotiates non-validated ciphers, because that gap determines whether the finding is scored or placed on a POA&M.

Cryptographic inventory

Maintain a list of every place CUI is encrypted in transit or at rest, including email gateways, managed file transfer, databases, backups, remote access and collaboration tools. For each entry, record the module, the algorithm, the key length and whether the use sits inside or outside the protected environment. The CMMC guide requires validation for CUI outside the protected environment, including wireless and remote access, so this inventory is how the organization proves where that boundary applies.

Key management records

Keep records showing who generates, stores, rotates, backs up and destroys cryptographic keys, and where the keys sit. Where keys live in a cloud key vault or hardware security module, retain the vendor documentation that states the FIPS 140 validation of that service and the customer-managed key configuration. Check that key custody matches the access control and separation of duties described in the system security plan, because an assessor will test those records against the policy.

POA&M entries, if any

If a system still uses encryption that is not FIPS validated, the only route to a passing score on that requirement is a plan of action and milestones entry, and only for the 3-point case under the CMMC scoring rules. Record the affected system, the compensating controls, the owner and the dated remediation milestones. An entry with no milestones or with a closure date that keeps moving will draw questions, so confirm the entry against the current scoring rules with the sponsor or assessor before relying on it.

Administrator interview answers

Assessors interview the people who run the systems and compare their answers with the documents. Administrators should be able to explain how FIPS mode is enabled, what happens when a service falls back to a non-validated cipher, how keys are rotated and who approves a new encryption tool. Prepare these staff in advance, confirm that their answers match the configuration exports and the inventory, and record any gap openly so the organization, not the assessor, finds it first.

Questions buyers ask about FIPS validated encryption for CUI

Does an approved encryption algorithm satisfy the FIPS requirement for CUI?

No. Using an approved algorithm is not enough under the CMMC Assessment Guide for Level 2, which says the cryptographic module itself must be validated under FIPS 140. An assessor will ask for the module's validation certificate number and check that the module is the one actually performing the encryption, not just a library that implements an approved algorithm. Confirm the validation status of each module in your environment against the NIST Cryptographic Module Validation Program listing before you write the system security plan.

Can a 3-point encryption finding go on a plan of action and milestones?

Yes, but only in one narrow case. Under 32 CFR 170.21, SC.L2-3.13.11 is the only requirement worth more than 1 point that may go on a POA&M, and only when it is scored at 3 points, meaning encryption is employed but not FIPS-validated. If no encryption is used at all, the finding is worth 5 points and cannot be deferred to a POA&M. Check the current text of 32 CFR 170.21 and the CMMC program guidance for any conditions on closing the item, since those rules govern timing and what the assessor will accept.

Does encryption inside our boundary also need FIPS validation?

Not always. The CMMC Assessment Guide for Level 2 requires validated cryptography to protect CUI outside the protected environment, including wireless and remote access. It does not require validated cryptography for encryption used for other purposes inside the environment. The practical consequence is that you must map every path that carries CUI across the boundary, such as VPN tunnels, remote administration, wireless links and external file transfer, and confirm each is validated. NIST's discussion of 03.13.11 still recommends FIPS-validated cryptography for protecting CUI, so validating inside the boundary is a sound design choice even where the assessment does not test it.

What drives the cost of changing to validated encryption modules?

The cost comes mainly from how many systems use unvalidated cryptography and how hard each one is to change. Cost components usually include internal engineering time to inventory libraries and protocols, configuration changes or upgrades to operating systems, applications, VPN concentrators and storage platforms, testing for compatibility, and updating the system security plan and evidence. Some vendors ship validated modes that only need enabling, while others require a version upgrade or a replacement. Ask any quote to list each system, whether the work is an upgrade or a replacement, and which items are one-time versus recurring, such as renewed licenses or support contracts.

Can we validate our encryption ourselves, or do we need outside help?

Your organization can do this internally if it has staff who can inventory cryptographic use, check module validation status, change configurations and produce evidence. Outside help is useful when the environment is large, legacy systems are tightly coupled, or the team lacks time to test changes against CUI workflows. An implementation partner such as DeployOpen can plan the scope in writing, prepare configurations and evidence for self-hosted platforms in your own infrastructure, and document the results. The organization still owns its controls, and the partner does not certify the result.

Who issues the assessment result for encryption under NIST SP 800-171?

The assessment result comes from an independent assessor, not from your implementation partner or from NIST. For DoD contractors, a Level 2 certification or self-assessment is handled under the CMMC program, and the score is entered into SPRS through the process set by the DoD. Your implementation partner can prepare systems, documentation and evidence, but it does not issue reports or certificates. Confirm with your contracting officer which assessment path applies to your contract, since the current DoD requirements and their timing have changed.

Who owns the encryption decision and who verifies it

The organization owns its cryptographic choices and key custody, and that decision sits with the people accountable for the CUI, not with a consultant. Under 03.13.11, the organization must define which types of cryptography protect CUI, and it must make those choices consistent with the laws and agreements that govern the data. In practice, the organization decides whether a given module is FIPS 140 validated, which cloud or on-premises key management service holds the keys, who can administer them, and how keys are rotated and recovered. Those decisions belong in the system security plan, signed by someone with authority over the system.

An implementation partner such as DeployOpen works on the preparation side of that decision. DeployOpen can inventory where encryption is used, check whether each module is validated against the FIPS 140 certificate listings the organization can look up, configure TLS, disk and backup encryption and key management to the chosen design, and assemble the configuration exports, screenshots and logs that an assessor will ask to see. DeployOpen does not issue reports, attestations or certificates, and it does not decide the scoring outcome. Only an independent assessor or certification body reaches that conclusion, and the organization should confirm with the assessor, before work starts, which evidence they expect.

Hiring a partner does not guarantee a result. A partner can reduce the gap between the current environment and the design, but the organization still carries the risk if a legacy application bypasses the validated module or a key custodian leaves without a handover. Ask any provider to state in writing which controls the organization must operate, which evidence will be delivered, and what remains with the organization after handover. Confirm with the assessor the version of the CMMC Assessment Guide and the scoring rules that apply to your contract, since those determine whether an unvalidated encryption finding costs 3 points or a larger penalty.

How DeployOpen prepares encryption evidence for assessment

DeployOpen plans, implements and documents self-hosted open-source platforms inside the client's own infrastructure, including the cryptographic configuration that protects CUI. We prepare the systems and evidence for FIPS 140 validated encryption, while the organization owns its controls and an independent assessor or certification body issues any report.

How we scope

Each engagement starts with a written scope that lists the CUI flows, storage locations and remote paths that need validated cryptography.
We identify which encryption uses sit outside the protected environment and which sit inside it, so effort follows the assessment rules.
Scope, deliverables and timelines are agreed in writing before work starts, and a quote follows from that written scope.

How we build

We configure self-hosted platforms to use cryptographic modules whose FIPS 140 validation status the client confirms against the NIST validation list.
We set up key management for data at rest and in transit, including who holds keys and how they rotate, documented in the system security plan.
We test wireless, remote access and email paths to confirm that encryption is enabled and that the validated mode is the one in use.

How we hand over

We deliver configuration records, a cryptographic inventory and test results that map each encryption path to its validated module.
We document the evidence an assessor will ask for, such as module certificate numbers, configuration exports and key management procedures.
We walk the client's team through the evidence package so the organization can answer assessor questions about its own controls.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer, so validated configurations stay current after platform changes.
We review module validation status and configuration drift when systems are upgraded or when new CUI paths are added.
Any scoring, plan of action and milestones decision, or assessment result remains the organization's decision, supported by its independent assessor.

FIPS 140 validated encryption for CUI