SC.L2-3.13.11 CUI encryption: requirements and evidence

What SC.L2-3.13.11 CUI encryption requires and why it is hard

A contractor preparing for a Level 2 assessment often finds that its CUI is encrypted but cannot show that the cryptographic modules doing the work are FIPS-validated. SC.L2-3.13.11 requires FIPS-validated cryptography whenever cryptography protects the confidentiality of CUI. An approved algorithm is not enough. The module that implements it must be validated under FIPS 140. The scoring makes the gap concrete: under 32 CFR 170.24, the requirement costs 5 points if encryption is not employed and 3 points if encryption is employed but is not FIPS-validated. It is the only requirement above 1 point that may go on a POA&M, and only in the 3-point case.

The current status matters for planning. On 13 July 2026 the Department of War suspended CMMC Phase II, which had included the Level 2 C3PAO certification requirement, and started a 60-day review by a CMMC Reform Task Force. Phase I self-assessments, SPRS postings, annual affirmations and DFARS 252.204-7012 obligations remain in place, and the Department has said it will enforce NIST SP 800-171 Rev. 2 in the interim. The requirement you are assessing against is therefore the Rev. 2 wording, and the cryptography obligations under DFARS 252.204-7012 do not depend on the Phase II schedule. Confirm the current status with the DoW CIO and your contracting officer before you set a certification date.

The work is hard for two reasons. First, cryptography is often used in places no one has inventoried: VPN tunnels, backup jobs, database columns, file sync clients, email gateways, and remote administration tools, each with its own library. Build a cryptographic inventory that lists every service, the module it calls and its FIPS 140 validation certificate. Second, the evidence is about the module, not the algorithm. Ask each vendor for the certificate number and confirm it on the validated modules list, and confirm that the mode and configuration in use are the ones covered by the certificate. A TLS setting that uses AES is not evidence on its own.

Which CUI paths and systems fall under FIPS-validated encryption

Not every cryptographic operation in a CMMC environment needs a FIPS-validated module. The boundary decisions below determine which CUI paths must be encrypted with validated cryptography, how many modules must be validated, and who owns each path. Settle these questions before selecting tools, because they set the size of the assessment.

CUI in transit outside the protected environment

Any CUI that leaves the protected environment needs validated cryptography, including traffic over wireless networks and remote access sessions such as VPN and remote desktop. Map every path that carries CUI across the boundary, from email and file transfer to administrative sessions, and record the module behind each one. A TLS endpoint that uses an approved algorithm without a FIPS-validated module does not satisfy the requirement, so confirm the validation certificate for each. Check the wireless and remote access paths first, since assessors often look there.

CUI at rest protected by cryptography

Where CUI sits on servers, databases, object storage, laptops and backup media, and the protection relies on encryption, the encryption must use a validated module. Identify which storage layers perform the encryption, such as the database engine, the file server, the disk encryption driver or the backup application, because each one may need its own validation evidence. Keys and encryption behavior should be documented per storage system. Note that Nextcloud server-side encryption protects file contents but not file names or folder structure, so metadata exposure must be assessed separately.

Cryptography used for other purposes

The CMMC Assessment Guide Level 2 states that validated cryptography is not required for encryption used for other purposes inside the protected environment. Examples include password hashing for internal logins, internal session tokens or integrity checks that do not protect CUI confidentiality. This scoping decision must be documented and defensible, because an assessor will ask how each use was classified. Record the purpose of each cryptographic function, and if a function touches CUI confidentiality, move it into the validated scope.

Third-party and cloud services holding CUI

A cloud email provider, a managed file service, a SaaS ticketing tool or a backup vendor that stores or transmits CUI sits inside the scope of the requirement. Ask each provider which FIPS-validated modules protect the data, which validation certificate numbers apply, and whether those modules cover the specific services you use. Contractual statements alone are not evidence. Obtain the provider's documentation and confirm that the environment matches the validated configuration, including the government or commercial regions in use.

Teams that own each path

Encryption scope spans several owners, so assign each path to a named team before the assessment begins. Network engineering typically owns wireless and VPN validation, platform or infrastructure teams own storage and database encryption, application teams own TLS settings inside services, and security or compliance owns the scoping record and key management evidence. An implementation partner can prepare configurations and evidence, but the organization must own the controls and keep the scoping decisions current when systems change.

How an assessor tests CUI encryption under SC.L2-3.13.11

This table walks through the single SP 800-171A objective for SC.L2-3.13.11, the evidence an assessor examines, the tests they run, and the findings that most often cost points. Read it as the assessor's checklist: the organization prepares final-form evidence, while the assessor independently decides whether the objective is met.

Assessor step	What the assessor does	Evidence the organization supplies	Common finding
Objective to test	Confirms that FIPS-validated cryptography is employed to protect the confidentiality of CUI, the only objective for this requirement	Written statement of where cryptography protects CUI, mapped to the system security plan	Cryptography described generically, with no link to CUI paths
Examine validation certificates	Checks each cryptographic module against its FIPS 140 validation certificate	Certificate numbers for every module in use, with the vendor and version named	Approved algorithm running in a module with no validation certificate
Compare the validated module list	Matches the certificate's module name and version against the published list of validated modules	Exact module name, version, and build as deployed, with the list entry it matches	Validation covers a different module version than the one deployed
Review cryptographic procedures	Reads documented procedures for how cryptographic protection is configured, enabled, and kept in FIPS mode	Configuration standards, FIPS mode settings, and approved cipher configurations in final form	Drafts or undated procedures that do not match the running configuration
Trace CUI data paths	Follows CUI through storage, transmission, remote access, wireless, and backups to find each protected path	Data flow diagrams that include backups, replicas, logs, and remote sessions	CUI paths missed, such as backup copies, admin consoles, or remote support tools
Review audit records	Samples logs and records showing that cryptographic mechanisms were active and used	Audit records showing cryptographic events, failures, and configuration changes	No records showing the protection was operating during the assessment period
Test the mechanisms	Tests the implementing mechanisms directly, such as confirming that a connection or stored object is encrypted with a validated module	Access to test accounts or a supervised demonstration, plus a documented test procedure	Protection enabled on paper but not enforced, for example a fallback to an unvalidated cipher
Scope confirmation	Confirms that validated cryptography covers CUI outside the protected environment, including wireless and remote access	Scope statement showing which encryption uses are for CUI and which are for other internal purposes	Unclear scoping that leaves external CUI transmissions unverified

Why an approved algorithm does not satisfy the FIPS-validation requirement

An approved algorithm is not the same thing as a FIPS-validated cryptographic module. AES is an approved algorithm, but SC.L2-3.13.11 asks whether the cryptography that protects CUI is FIPS-validated, which means the software or hardware module that performs the encryption has been tested and validated under FIPS 140. The CMMC Assessment Guide Level 2 is explicit that using an approved algorithm is not enough. The module must be validated, and that validation applies to cryptography protecting CUI outside the protected environment, including wireless and remote access. Encryption used for other purposes inside the protected environment does not carry the same validation requirement. The practical gap is that a system can use AES correctly and still score 3 points under 32 CFR 170.24 because the module doing the work was never validated.

Validation attaches to a specific module, version and configuration, not to a product name. A validation certificate names the module, its version, the operational environment it was tested in and, in many cases, the security policy describing how it must be run. Upgrading a library, changing a container base image, or enabling a non-validated code path can move a system outside the validated configuration even though the product name stays the same. Reviewing the certificate and the security policy is therefore part of the work. Confirm the exact module name and version your systems load at runtime, check that the certificate covers the operating environment you run it in, and confirm that required settings such as FIPS mode are enabled and recorded in your configuration baseline.

A vendor statement that a product "supports FIPS" or is "FIPS compliant" is a claim, not evidence. Ask the vendor which validated module the product calls, which certificate covers it, and which configuration the vendor requires for that certificate to apply. Then check the validation records yourself rather than relying on the vendor's summary. Keep the certificate reference, the validation record and your own configuration evidence together, because an assessor testing this objective will look for the module, its validation and the mechanisms that implement it. Confirm all of this directly against the official validation records and your own environment before you record SC.L2-3.13.11 as met.

How to implement FIPS-validated encryption for CUI, step by step

This sequence takes an organization from an unknown set of encryption paths to a documented, FIPS-validated configuration for every place cryptography protects CUI, with the records an assessor will ask for.

Inventory every cryptographic path touching CUI
The organization's IT and security staff list every place cryptography protects the confidentiality of CUI: TLS on web and API traffic, VPN tunnels, remote and wireless access, database and file encryption at rest, backup encryption, and encrypted removable media. Each entry names the system, the data it carries, and the owner. Encryption used for purposes unrelated to CUI confidentiality inside the protected environment is noted separately, since the assessment guide does not require validated cryptography there. The output is a cryptographic inventory that the system security plan can reference.
Identify the validated module behind each path
For each entry, the team records the cryptographic module that actually performs the work, not just the protocol or algorithm named in the product documentation. They locate the module's FIPS 140 validation certificate, check its validation status, and confirm the deployed software version and operating mode appear on that certificate. A module can be validated in one mode and run in another, so the mode check matters. The output is a module register with certificate numbers, versions, and modes, and any path without a matching certificate is flagged for remediation.
Enable the validated configuration on each system
System administrators turn on the validated mode or FIPS configuration for each flagged or confirmed system, such as the operating system's FIPS mode, the TLS library's validated provider, and the storage or database encryption settings. Changes go through the organization's change control process so the before and after states are recorded. Where a platform's encryption is set in a configuration file, the file is kept under version control. The output is a configuration baseline in which each in-scope system reports the validated mode in its own settings.
Replace unvalidated implementations or document the POA&M case
Where a path uses an approved algorithm without a validated module, the team either replaces the implementation with a validated one or, if the 3-point case applies, records it on the plan of action and milestones as the only permitted POA&M item for this requirement. The 5-point case, where no encryption is employed for CUI, cannot go on a POA&M and must be fixed before assessment. The owner should confirm the scoring with the assessment guide and their assessor, since POA&M eligibility rules carry contractual consequences. The output is either a closed gap or a POA&M entry with a named owner.
Retain configuration and test records
The organization keeps evidence an assessor can review: the module register, certificate copies from the validation list, configuration exports showing the validated mode, the encryption procedures, and test results showing that encrypted sessions and stored data use the validated module. Audit records of cryptographic configuration changes are retained with the other audit logs. Evidence should be in final form, since drafts do not satisfy an objective. The output is a dated evidence package mapped to the single assessment objective for SC.L2-3.13.11, ready for a self-assessment or a C3PAO review.

Evidence that proves FIPS-validated CUI encryption

An assessor testing SC.L2-3.13.11 looks for proof on two fronts: that the cryptographic module is FIPS-validated and that the deployed system actually runs it in validated mode. The artifacts below connect the validation paperwork to the live configuration, the procedures and the logs. The organization owns these records, and an independent assessor decides whether they meet the objective.

Cryptographic module validation certificates

These are the FIPS 140 validation certificates for every cryptographic module that protects CUI, including modules inside the operating system, the web server, the VPN client and the database. The assessor checks that the certificate is current, names the module version actually deployed, and covers the operational environment in use. An approved algorithm alone does not count, so an algorithm listed in a standard without a validated module will not satisfy the objective. Record the certificate number beside each system in the system security plan.

FIPS-validated module list entries

Match each deployed module and version against the official list of FIPS-validated cryptographic modules. A certificate in a file share is weaker evidence than a list entry that names the same vendor, module and version your systems run. Re-check the list after every patch or major upgrade, because a module version in production can differ from the one validated. Keep dated screenshots or exported entries as proof of the check.

Configuration exports showing validated mode

Exported configuration proves that validated cryptography is enforced, not just available. Examples include the server setting that forces FIPS mode, TLS settings that disable non-validated ciphers and protocols, and encryption settings that place keys on the server side. Capture the exact keys and values, such as fips_mode or the cipher suite list in your web server, and tie each export to a host and date. Assessors often test a sample of systems, so the same settings must appear on every in-scope host.

Procedures for cryptographic protection

Written procedures state which data needs cryptographic protection, which modules are approved for it, who can change cryptographic settings and how exceptions are approved. They should cover CUI in transit, at rest, on remote access and on wireless links, since the Level 2 guidance expects validated cryptography in these places. A procedure that names the module and its validation status is more useful to an assessor than a general policy statement. Review the procedure whenever the module set changes.

Audit records of cryptographic operations

Logs show that cryptographic functions ran and that configuration changes were recorded. Useful entries include key creation and rotation events, certificate issuance and renewal, changes to FIPS mode or cipher settings, and failed handshakes that show a non-validated connection was refused. Protect these logs from alteration and retain them as the audit objective requires. Confirm with your logging platform that these event types are captured, because default logging often omits key and configuration events.

Test results from cryptographic mechanisms

Testing shows that the mechanisms work as configured. Keep results from scans that check negotiated TLS versions and ciphers, from tests that attempt connections with non-validated settings, and from restores of encrypted data that confirm keys are usable. Assessors look for tests of the mechanisms themselves, not only a statement that encryption is enabled. Record the date, tester, scope and any failures with their remediation, and repeat the tests after changes.

What FIPS-validated CUI encryption costs to meet

This table lists the cost components of meeting SC.L2-3.13.11 and who is paid for each, marking whether it is one-time or recurring. Read it to see which costs grow with the number of CUI paths and modules, and which ones you can reduce by standardizing on validated modules. No dollar figures are given because none are supplied for this requirement; ask each provider for a quote built from your written scope.

Cost component	Who is paid	One-time or recurring	What drives it up or down
Validated module licensing or support	Commercial module vendor	Recurring	Up with the number of commercial modules and support tiers; down when a validated open-source module covers the path
Path inventory and engineering time	Internal staff or implementation partner	One-time, with updates after changes	Up with the number of CUI paths, including wireless and remote access; down when paths are documented and standardized early
Reconfiguring systems to validated modules	Internal engineers or implementation partner	One-time	Up with heterogeneous stacks that need different cryptographic libraries; down with a single, consistent module set
Validation status verification	Internal compliance staff or consultant	Recurring at each module change	Up with many modules and frequent upgrades; down when the validation certificate and module version are recorded per system
Evidence upkeep after module upgrades	Internal compliance staff or implementation partner	Recurring	Up when upgrades change module versions or configurations; down with automated configuration records and version inventories
Pre-assessment or external review	Consultant or readiness provider (optional)	One-time or periodic	Up with a broad scope and undocumented paths; down when the scope and evidence are settled before the review
Auditor or assessor sampling time	Independent assessor (C3PAO or other assessor as applicable)	Per assessment	Up with the number of systems and CUI paths sampled; down when evidence for each path is complete and in final form

How self-hosted open-source tools support the encryption evidence

Open-source tools can produce much of the encryption evidence for SC.L2-3.13.11, but none of them establishes FIPS validation on its own. The assessment objective is about whether FIPS-validated cryptography protects CUI, so the first task for each tool is to confirm whether the build or mode in use runs on a validated cryptographic module and to obtain that module's certificate. Only then does the tool's own behavior become useful evidence. Nextcloud's server-side encryption protects file contents at rest on local and external storage, with keys kept on the server. Its documentation also states that file names and folder structure are not encrypted, so a CUI folder name can still be exposed on disk. Treat that gap as a finding to document or remediate, and record how the encryption module was enabled and which cryptographic library it calls.

OpenBao's transit secrets engine encrypts and decrypts application data without storing the plaintext, and it supports versioned encryption keys with key rotation. That gives an assessor a concrete mechanism to test: an application sends data to the engine, the ciphertext is stored, and key versions and rotation history can be shown in audit records. The engine's cryptography must still be tied to a validated module, so confirm with the project and your deployment whether a FIPS-validated build or mode is available and cite its certificate. FreeIPA includes an integrated certificate authority based on Dogtag for issuing and managing certificates, which supports the certificate side of protected channels. Its validation status is a separate question, so check whether the CA operates on a validated module and capture the configuration and issuance records that show who issued what certificate and when.

cert-manager creates TLS certificates for workloads in Kubernetes or OpenShift from issuers such as ACME, a CA key pair, HashiCorp Vault, CyberArk or a self-signed issuer, stores them in Kubernetes Secrets, and renews them before they expire. Its issuer configuration is the artifact an assessor will ask for, so keep the ClusterIssuer or Issuer manifests under version control and capture renewal events. Each issuer's signing path raises the same FIPS question as above, and an ACME issuer such as Let's Encrypt is outside your control, so document how the chain is validated and whether that path meets your contract's requirements. Before the assessment, ask your implementation partner and your assessor to agree which of these records count as final evidence, and confirm each validation status with the vendor or project.

Who does what for CUI encryption: your team, a partner and the assessor

Your organization owns the requirement. Only you can say where CUI moves, which cryptographic decisions protect it, which module is in use and whether any gap is acceptable on a plan of action. SC.L2-3.13.11 is assessed against whether FIPS-validated cryptography protects the confidentiality of CUI, so the responsibility for that statement sits with the people who run the system and sign the System Security Plan.

CUI data flows: Maintain the list of systems, links and storage locations that carry CUI, including remote access and wireless paths that sit outside the protected environment.
Cryptographic decisions: Decide which algorithms, protocols and key lengths apply to each path, and record why encryption is or is not used for each one.
Module choices: Confirm that each cryptographic module carries a FIPS 140 validation certificate and that the deployed mode is the one the certificate covers.
POA&M decision: Choose whether any gap is recorded on a plan of action. Under 32 CFR 170.21, this requirement is the only one above 1 point that may go on a POA&M, and only in the case where encryption is used but not FIPS-validated.
Sign-off: Accept the evidence pack as your own record, since the assessor tests what you present.

Before any assessment, ask internally who can answer for each CUI path and where the validation certificate numbers are recorded.

Questions buyers ask about CUI encryption under SC.L2-3.13.11

Is an approved encryption algorithm enough for SC.L2-3.13.11?

No. An approved algorithm is not enough. SC.L2-3.13.11 asks for FIPS-validated cryptography wherever cryptography protects the confidentiality of CUI, which means the cryptographic module itself must be validated under FIPS 140. The CMMC Assessment Guide Level 2 makes this distinction explicit. A team can use AES inside a library that has never been validated and still fail the requirement. Assessors look for the module's validation certificate and confirm that the deployed version matches a validated entry. Validated cryptography is expected for CUI outside the protected environment, including wireless and remote access. Encryption used for other purposes inside the environment is not covered by the same expectation, so scope the work to where CUI actually travels or rests.

How does SC.L2-3.13.11 scoring work, and when is a POA&M allowed?

The scoring is three tiers. Under 32 CFR 170.24, the requirement costs 5 points if encryption is not employed, 3 points if encryption is employed but not FIPS-validated, and nothing extra when it is FIPS-validated. Under 32 CFR 170.21(a)(2)(ii), it is the only requirement worth more than 1 point that may appear on a plan of action and milestones (POA&M), and that allowance applies only to the 3-point case, where encryption exists but the module is not validated. A missing encryption control cannot be placed on a POA&M. Confirm the current status of POA&M rules and the Level 2 assessment schedule with the DoW CIO's CMMC pages, because the program's implementation milestones have changed.

How much effort does a FIPS-validated encryption project take, and what drives it?

The effort depends mainly on how many systems and data paths carry CUI, and how many of them already use validated modules. The main drivers are the number of CUI transfer paths (web, email, file sharing, remote access, backup), the number of storage locations that hold CUI, whether applications embed their own cryptography libraries, and how many keys and certificates need lifecycle management. Mapping and remediation are usually the longest steps, because each component must be checked against the validation list and replaced or reconfigured where needed. No duration is stated here; ask any provider for a written estimate tied to a named inventory of systems and paths.

Can our internal team implement SC.L2-3.13.11 without outside help?

Yes, many teams can, provided they have engineers who understand both the cryptographic modules in their stack and the assessment evidence. The internal team owns the controls and the outcome. The work usually splits into three parts: finding every place CUI is encrypted, confirming the validation status of each module in the exact version deployed, and producing evidence such as validation certificates, the module list, procedures and configuration records. Outside help is most useful for the inventory, for a second review of module claims and for building repeatable evidence. Assessment itself must be performed by an independent assessor, not by the implementation partner.

What does the organization need to provide for an encryption project?

The organization has to supply the facts that no outside party can infer. Expect to provide a CUI data flow inventory showing where CUI is created, stored, transmitted and deleted, a named owner for each system and application, and access to configuration, certificate and key management records. Change windows matter because enabling validated cryptography often means restarting services, replacing certificates, or updating client software. Agree those windows in advance with operations teams. Ask any provider to list these inputs in the written scope before work starts, so that delays from missing inputs are visible early.

How do we verify that a product's FIPS claim is real?

Start with the validation certificate, not the marketing page. SP 800-171A lists cryptographic module validation certificates and the list of FIPS-validated modules as evidence for this requirement. Confirm that the certificate names the exact module, version and build you run, that its status is active, and that the operating mode you configured is one the certificate covers. Then check the product configuration to confirm the validated mode is actually enabled, because many systems ship with validated and non-validated code paths side by side. Record both the certificate and your configuration evidence. Where a product claims FIPS support without a matching certificate, treat it as the 3-point case, not as compliant.

Which open-source components can help produce encryption evidence?

Several open-source platforms can support the work, but none of them makes a system compliant by default, so confirm each module's FIPS status against the validation list. Nextcloud's server-side encryption protects file contents at rest, with keys kept on the server, but it does not encrypt file names or folder structure, which you should document as a scope limit. OpenBao's transit secrets engine encrypts application data, supports versioned keys and key rotation, and produces records useful for key management evidence. FreeIPA's integrated certificate authority and cert-manager help issue and renew TLS certificates in Kubernetes or OpenShift. Each product's FIPS mode and validated build must be verified separately.

How DeployOpen prepares FIPS-validated CUI encryption evidence

DeployOpen works on SC.L2-3.13.11 by preparing the systems and evidence that show FIPS-validated cryptography protects CUI wherever it is used, inside your own infrastructure. We do not issue assessment results; your organization owns its controls, and an independent assessor reviews the evidence.

How we scope

Engagements are fixed-scope, with the CUI flows, cryptographic modules and environments to be covered agreed in writing before work starts.
We inventory every place CUI is encrypted for confidentiality, including remote access, wireless and external links.
Scope records which cryptographic modules and validation certificates each system must use, so gaps are visible before build work begins.

How we build

We configure self-hosted platforms to use FIPS-validated cryptographic modules, and confirm the validated mode is active on each host.
We deploy key and certificate services such as OpenBao, FreeIPA and cert-manager, with keys held inside your environment.
We test the encryption mechanisms directly, checking that cleartext CUI does not cross protected boundaries during test transactions.

How we hand over

We document the validation certificate numbers, module versions and configuration baselines that assessors will ask to see.
We produce test records and audit log extracts that show encryption settings were applied and verified, in final form.
We confirm with your assessor which artifacts they accept, and list items that must be finalized before the assessment date.

How we support

Ongoing support, upgrades and continuous testing are available as retainers, so module validations and configurations are rechecked over time.
We track changes to platform versions and cryptographic configurations, and document each change for the evidence file.
Quotes follow from the written scope, so ask us to itemize one-time build work separately from recurring support.

SC.L2-3.13.11 CUI encryption