CMMC Level 2 Practice 3.13.11: Employ FIPS-validated cryptography when used to protect the confidentiality of CUI

For CMMC Level 2, cryptography is not a “nice to have” control. Practice 3.13.11 draws a bright line: if you rely on cryptography to keep CUI confidential, the cryptography must be FIPS-validated. ¹ This requirement shows up everywhere CUI lives: endpoints, servers, cloud services, email, file transfer, remote access, backups, and the admin tooling that touches those environments.

Most failed implementations are not caused by weak algorithms. They fail because teams cannot prove they are using FIPS-validated modules, they confuse product marketing claims with validation status, or they overlook “hidden” crypto paths like database encryption, TLS termination, reverse proxies, and backup appliances. Assessors will expect you to show not only that encryption exists, but that the specific cryptographic modules in use are validated and configured properly for the way you protect CUI.

This page is written for a Compliance Officer, CCO, or GRC lead who needs to turn 3.13.11 into an executable checklist: scoping, technical decisions, required artifacts, and the operational cadence that keeps you compliant after the initial rollout. ²

Target keyword

cmmc level 2 practice 3.13.11: employ fips-validated cryptography when used to protect the confidentiality of cui requirement

Regulatory text

Requirement (mapped): “CMMC Level 2 practice mapped to NIST SP 800-171 Rev. 2 requirement 3.13.11 (Employ FIPS-validated cryptography when used to protect the confidentiality of CUI).” ¹

What the operator must do:
If you encrypt CUI (or use cryptography as a compensating safeguard to keep CUI confidential), you must ensure the crypto is implemented through FIPS-validated cryptographic modules and can prove it during assessment. Your operational job is to (1) identify all confidentiality-protection crypto uses for CUI, (2) verify validation status for the module(s) involved, (3) configure and govern those modules in FIPS-approved modes, and (4) preserve evidence that ties the validation to your real environment. ¹

Plain-English interpretation

• If CUI is protected by encryption, the encryption can’t be “whatever the product ships with.” It must be backed by a cryptographic module that has been validated under FIPS.
• This applies to data at rest (disk, database, object storage, backups) and data in transit (TLS/SSH/VPN), plus any other cryptographic mechanism you rely on to keep CUI from unauthorized disclosure. ¹

Who it applies to (entity and operational context)

Entity types: Defense contractors and federal contractors handling CUI that must meet CMMC Level 2 requirements. ³

Operational context (where this shows up):

• CUI enclaves and the corporate systems connected to them (identity, logging, endpoint management).
• Cloud services used to store, process, or transmit CUI (SaaS, PaaS, IaaS).
• Third parties that handle or transmit your CUI (managed service providers, incident response retainers, engineering partners, testing labs). You still own compliance outcomes, so contract language and due diligence must align. ²

What you actually need to do (step-by-step)

Step 1: Define and freeze your “CUI confidentiality crypto” scope

Build a scope statement that lists every mechanism used to protect CUI confidentiality, including:

• TLS for web apps and APIs that handle CUI
• VPN/zero trust remote access used to reach CUI systems
• Full disk encryption on endpoints used for CUI
• Storage/database encryption for CUI repositories
• Backup encryption and key management paths
  Deliverable: a CUI Crypto Register (system, purpose, crypto mechanism, owner). ¹

Step 2: Identify the cryptographic module behind each mechanism

Assessors will look past the checkbox (“we use TLS”) and ask what module implements it.

• For OS crypto, identify the OS crypto provider/module in use.
• For appliances and apps, identify the crypto library/module (for example, embedded OpenSSL variant, OS-provided crypto, hardware security module).
• For cloud services, identify what the service claims for FIPS validation and which endpoints/modes are FIPS. ¹

Deliverable: update your register with module name/version and where it runs (endpoint/server/service).

Step 3: Verify FIPS validation status and document proof

You need evidence that the module is FIPS-validated. Operationally, do two things:

• Collect vendor documentation that references FIPS validation for the module and your specific version/build.
• Record the environment mapping: which systems use which module version.

Deliverable: a FIPS Evidence Pack per platform (product docs, validation references, version mapping, screenshots). ¹

Step 4: Configure FIPS mode (where applicable) and harden crypto settings

Common configuration expectations for confidentiality protections:

• Enable FIPS mode on operating systems or runtimes where the product supports it.
• Restrict to approved protocols and cipher suites for TLS endpoints handling CUI.
• Confirm encryption is enabled for CUI storage locations (and not “available but off”). ¹

Deliverable: configuration standards (baseline) plus implementation records (screenshots, CLI outputs, configuration management artifacts).

Step 5: Key management and separation of duties (keep it practical)

3.13.11 focuses on FIPS-validated crypto, but assessors often connect the dots to how keys are handled.

• Assign key ownership and administration responsibilities.
• Control access to key stores (HSM/KMS/keystores) through least privilege.
• Document rotation, escrow (if any), backup, and recovery procedures tied to CUI systems. ¹

Deliverable: key management procedure plus access control evidence (group membership, role assignments).

Step 6: Operationalize recurring assurance (so it stays compliant)

Your biggest ongoing risk is drift: upgrades, new services, and “quick fixes” that bypass validated modules.

• Add a change gate: any new system that stores/transmits CUI must declare its crypto module and FIPS validation status before go-live.
• Add recurring checks: verify endpoints remain in FIPS mode, cipher suites remain restricted, and product versions haven’t invalidated the validation mapping. ²

Deliverable: change management checklist item + periodic attestation records.

Required evidence and artifacts to retain

Keep evidence tied to the assessor’s core question: “Show me that CUI confidentiality is protected by FIPS-validated cryptography, and that it’s running in your environment.”

Minimum practical artifact set:

• CUI Crypto Register (authoritative inventory for 3.13.11) ¹
• Network/data flow diagrams showing where CUI transits and where TLS terminates (reverse proxies, load balancers) ²
• System configuration evidence:
  • FIPS mode enabled (screenshots/command output)
  • TLS/cipher configuration for CUI services
  • Disk/database/storage encryption settings enabled
• Version mapping: module versions in production (from CMDB, endpoint management, config management)
• Policies and procedures:
  • Cryptography standard for CUI systems
  • Change management gate for CUI crypto
  • Key management procedure (high level plus role-based access evidence)
• Exceptions log with risk acceptance and remediation plan where FIPS validation is not currently met ²

Common exam/audit questions and hangups

Expect these and pre-answer them in your evidence pack:

1. “Where exactly is CUI encrypted in transit, and where does TLS terminate?” Have diagrams and load balancer/proxy configs ready.
2. “Show me that your crypto module is FIPS-validated, not just ‘supports FIPS.’” Provide module/version evidence and configuration state. ¹
3. “Which endpoints handle CUI and how are they encrypted at rest?” Provide endpoint encryption configs plus device inventory.
4. “How do you prevent a team from spinning up a non-compliant SaaS workflow?” Show your intake process, third party review, and change gate. ²

Frequent implementation mistakes (and how to avoid them)

• Mistake: Confusing “FIPS-compliant” marketing with “FIPS-validated module.”
  Fix: require module validation evidence tied to version/build in your procurement and architecture review checklist. ¹

• Mistake: Enabling encryption but missing the real choke points.
  Fix: map data flows. Pay special attention to email gateways, reverse proxies, remote access concentrators, and backup systems.

• Mistake: Partial rollout (endpoints in scope, servers not; production yes, backups no).
  Fix: the register must include backups, replicas, exports, and admin access paths.

• Mistake: No drift controls.
  Fix: put 3.13.11 verification into change management and periodic configuration checks. ²

Enforcement context and risk implications

CMMC is implemented through DoD program requirements and rulemaking, and compliance is assessed for certification. ³ For 3.13.11, the most common practical exposure is assessment failure due to weak evidence or non-validated modules embedded in common products. The operational risk is straightforward: if CUI confidentiality relies on non-validated crypto, you may not meet the practice intent and may face contractual and program delivery impacts tied to certification outcomes. ²

Practical execution plan (30/60/90-day)

Use this as an operator’s cadence. Adjust sequencing to your environment size and CUI footprint.

First 30 days: Get to a defensible scope and gaps list

• Stand up the CUI Crypto Register (systems, data flows, owners).
• Identify all CUI transit and storage locations; document TLS termination points.
• Collect current-state evidence (configs, versions, screenshots).
• Produce a gaps list: where FIPS validation proof is missing or configs are not in FIPS-approved modes. ¹

By 60 days: Fix high-risk gaps and lock standards

• Implement or enable FIPS mode where applicable for in-scope platforms.
• Standardize TLS configurations for CUI services (protocol/cipher restrictions) and document baselines.
• Implement key management access controls and produce role/access evidence.
• Add procurement/architecture review checks for FIPS validation status before new CUI workflows go live. ²

By 90 days: Make it repeatable and assessment-ready

• Convert the register and evidence into an assessor-ready package with clear traceability.
• Add change management gates and recurring checks; record results as recurring evidence.
• Run an internal readiness review: pick a sample system and “walk the chain” from CUI data flow to crypto module validation proof to config state. ¹

Where Daydream fits (earned, not intrusive): Daydream helps teams keep a living CUI Crypto Register, attach FIPS evidence to each in-scope system, and schedule recurring evidence capture so 3.13.11 doesn’t regress during upgrades and migrations. ²

Frequently Asked Questions

Does “FIPS-compatible” software satisfy CMMC Level 2 Practice 3.13.11?

Not by itself. You need FIPS-validated cryptography when you use cryptography to protect CUI confidentiality, and you must be able to show validation and configuration evidence for what’s actually deployed. ¹

Does this apply to encryption in transit (TLS) or only encryption at rest?

It applies whenever cryptography is used to protect the confidentiality of CUI, which commonly includes both data in transit and data at rest. Document both in your CUI Crypto Register. ¹

What evidence do assessors usually want for 3.13.11?

Expect proof of (1) where CUI is encrypted, (2) which cryptographic modules implement that encryption, (3) that those modules are FIPS-validated, and (4) that FIPS-approved modes/configurations are enabled in your environment. ¹

If we use a cloud service for CUI, how do we meet 3.13.11?

Treat the cloud service as part of your CUI confidentiality crypto scope. Collect provider documentation and configuration evidence showing the service uses FIPS-validated cryptography for the specific CUI data paths you rely on. ²

Do backups and archives count for this requirement?

Yes if they contain CUI and you rely on encryption to keep that CUI confidential. Add backup systems, media, and storage locations to your register and retain encryption and module evidence. ¹

How do we prevent regression after upgrades?

Add a change gate requiring teams to confirm FIPS validation and FIPS mode/configuration for any new or changed CUI system. Then perform periodic checks and retain the results as recurring evidence. ²

Footnotes

1. NIST SP 800-171 Rev. 2

2. DoD CMMC Program Guidance

3. 32 CFR Part 170