CMMC Level 2 Practice 3.13.8: Implement cryptographic mechanisms to prevent unauthorized disclosure of CUI during

CMMC Level 2 Practice 3.13.8 requires you to use cryptography so CUI is not disclosed to unauthorized parties while it is being transmitted or otherwise in transit across networks or external connections. To operationalize it fast, define all CUI transit paths, standardize on approved encryption protocols, enforce them through configuration, and keep assessor-ready evidence that encryption is consistently on. ¹

Key takeaways:

• Scope first: map every place CUI leaves a boundary (email, VPN, SaaS, file transfer, APIs, remote access).
• Standardize encryption: pick a small set of approved cryptographic mechanisms and disable weak/legacy options.
• Prove operation: retain configs, logs, and test results that show encryption in transit is enforced for CUI flows. ²

“Encrypt CUI in transit” sounds simple until you list all the ways your organization moves CUI: user-to-SaaS, workstation-to-file share, enclave-to-enclave, supplier exchanges, remote admin, scanning to email, and machine-to-machine integrations. CMMC Level 2 Practice 3.13.8 (mapped to NIST SP 800-171 Rev. 2 3.13.8) is the requirement that forces discipline across those paths: if CUI can traverse a network or external link, cryptographic mechanisms must prevent unauthorized disclosure. ¹

For a CCO, compliance officer, or GRC lead, the fastest path is not a “crypto project.” It is a controlled scoping and standardization exercise: identify the CUI transit surfaces, define acceptable encryption standards by use case, harden configurations so encryption is mandatory (not optional), and set up evidence capture that makes the control easy to re-prove every assessment cycle. CMMC assessments are evidence-driven; teams often have encryption “available” but cannot show it is enforced for the actual CUI flows. ²

This page gives requirement-level implementation guidance you can hand to IT/security to execute, and it tells you what artifacts to retain so you are ready for a CMMC Level 2 assessment under the CMMC Program. ³

Regulatory text

Requirement (excerpt): “CMMC Level 2 practice mapped to NIST SP 800-171 Rev. 2 requirement 3.13.8 (Implement cryptographic mechanisms to prevent unauthorized disclosure of CUI during).” ¹

Operator meaning: you must ensure CUI is protected by encryption when it traverses networks or external connections where interception or unauthorized access could occur. In practice, assessors will look for (1) defined CUI transit scenarios, (2) cryptographic protections selected for each scenario, (3) configurations that enforce those protections, and (4) evidence the protections operate consistently. ²

Plain-English interpretation

You have to encrypt CUI whenever it moves between systems or across a network boundary in a way that could be observed, intercepted, or accessed by someone who is not authorized. “During transit” includes common pathways like:

• user access to internal apps over a network
• remote access into the CUI environment
• sending CUI to a third party or receiving it from one
• file transfers, API calls, admin protocols, and email carrying CUI attachments

The control fails when encryption is merely “supported” but not required, or when a single overlooked channel (for example, SMTP relays, printer/scanner workflows, unmanaged endpoints, or legacy file shares) can transmit CUI without strong cryptographic protection.

Who it applies to

Entities: defense contractors and federal contractors that handle CUI and are seeking or maintaining CMMC Level 2 compliance. ³

Operational context:

• Any network segment, enclave, or cloud tenant where CUI is processed, stored, or transmitted
• Any workforce model (on-site, hybrid, remote) if staff access or send CUI
• Any third party connection that can receive, transmit, or access CUI (managed service providers, engineering partners, logistics providers, SaaS providers)

If your CUI boundary is an enclave, 3.13.8 still applies to traffic entering/leaving the enclave and traffic inside it if internal interception is plausible (for example, shared networks, wireless, or multi-tenant segments).

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

Step 1: Define “CUI in transit” for your environment (scope)

Create a CUI Data Flow Inventory that lists each way CUI moves. Keep it practical; it must match reality.

• Sender/receiver (system, user group, third party)
• Transport method (TLS web, VPN, SFTP, email, API, remote admin)
• Network path (internal LAN, Wi-Fi, Internet, cross-tenant, site-to-site)
• Current encryption state (enforced / optional / unknown)
• Owner and remediation ticket

Deliverable: a scoped list of CUI transit paths you will test and enforce.

Step 2: Standardize approved cryptographic mechanisms by use case

Write a short Encryption-in-Transit Standard that sets the “allowed mechanisms” for each transit type, such as:

• Web apps and APIs: TLS with strong configurations
• Remote access: VPN or equivalent encrypted tunnels
• File transfer: SFTP/FTPS/managed transfer with encryption enforced
• Admin access: encrypted administrative protocols (avoid cleartext)
• Email: enforce encryption for messages containing CUI, or route CUI email through approved secure channels

Keep the list short so teams follow it. This requirement is about preventing unauthorized disclosure; selecting a consistent cryptographic baseline is how you reduce human choice and drift. ¹

Step 3: Enforce encryption technically (make it non-optional)

Translate the standard into configurations:

• Disable legacy/weak protocols that allow downgrade or cleartext.
• Require encrypted sessions at ingress points (load balancers, reverse proxies, VPN gateways, email gateways, file transfer services).
• Block non-compliant ports/services at firewalls and host controls.
• Turn on certificate management controls so encryption does not fail open when certificates expire.

A fast test: attempt to connect using non-encrypted or legacy options from a controlled test host. If it connects, you likely have an enforcement gap.

Step 4: Cover common “missed channels”

Most assessment surprises live here:

• Email and scanning workflows: copiers/scanners that send attachments via SMTP, or users forwarding CUI externally.
• Wireless and guest networks: CUI accessed over Wi-Fi without appropriate controls.
• Local admin and device management: remote desktop/admin tools configured without encryption or with weak settings.
• Third party exchange paths: ad hoc file sharing, consumer sync tools, or unmanaged collaboration spaces.

Your CUI Data Flow Inventory should explicitly include these channels, even if the answer is “prohibited.” “Prohibited” is acceptable if you enforce it and can prove it.

Step 5: Validate and continuously prove operation

Build an evidence routine that produces artifacts without heroics:

• periodic config snapshots of gateways and critical services
• periodic tests of representative CUI flows (sample transactions)
• monitoring and alerts for encryption failures (for example, certificate expiry, VPN misconfigurations)

Daydream can help you map CMMC Level 2 Practice 3.13.8 to a documented control, assign control owners, and schedule recurring evidence capture so you are not rebuilding proof right before an assessment. ²

Required evidence and artifacts to retain

Keep evidence that shows both design (what you intended) and operation (what actually happened).

Design artifacts

• Encryption-in-Transit Standard (approved mechanisms by use case) ¹
• CUI Data Flow Inventory with in-scope transit paths and owners
• Network diagrams showing CUI boundary and ingress/egress points
• Exception register (any approved non-standard cases, with compensating controls)

Operational artifacts

• Configuration exports/screenshots for: VPN gateways, reverse proxies/load balancers, email gateways, file transfer services, key SaaS settings
• Firewall rules showing blocked cleartext protocols where relevant
• Certificate inventory and renewal records
• Log samples demonstrating encrypted connections (for example, TLS session logs, VPN session logs)
• Test records (connection attempts, protocol scans, or scripted checks) tied to specific CUI flows

Quality rule: evidence must be traceable to the CUI scope you declared for CMMC Level 2. ²

Common exam/audit questions and hangups

Assessors typically pressure-test these points:

• “Show me where CUI is transmitted.” If you cannot enumerate flows, you cannot prove coverage. ¹
• “Is encryption enforced or just available?” They will look for settings that refuse cleartext and prevent downgrade.
• “How do you handle CUI sent to third parties?” Expect questions about secure file exchange, email controls, and access methods.
• “What happens when certificates expire?” A common operational gap is certificate hygiene causing outages or teams bypassing encryption.

Hangup to anticipate: teams show a policy and a diagram but lack live configs/logs demonstrating encryption for the actual services used to move CUI.

Frequent implementation mistakes (and how to avoid them)

Mistake	Why it fails 3.13.8	How to avoid
Treating “VPN exists” as full compliance	CUI might still go out via email, SaaS, or direct file transfer	Build the CUI Data Flow Inventory and test each path
Allowing optional TLS / mixed-mode services	Users/apps can fall back to cleartext	Enforce redirects, disable cleartext listeners, block ports
Ignoring third party connections	Many CUI disclosures happen through partner exchange	Require approved secure exchange methods and document them
Evidence scramble before assessment	You “have encryption” but cannot prove it	Set recurring evidence capture and assign an owner 2

Enforcement context and risk implications

CMMC Level 2 is part of the DoD’s CMMC Program framework, and organizations handling CUI are expected to meet the mapped NIST SP 800-171 Rev. 2 practices. Failure to protect CUI in transit raises confidentiality risk (interception, misdelivery, unauthorized access) and can lead to assessment findings that delay contract eligibility or create remediation obligations under the CMMC program structure. ⁴

Practical 30/60/90-day execution plan

Days 0–30: Scope and standardize

• Name a control owner (IT/security) and a GRC evidence owner.
• Build the CUI Data Flow Inventory for transit paths (include third parties).
• Publish the Encryption-in-Transit Standard with allowed mechanisms per use case. ¹
• Identify gaps where encryption is optional or unknown; open remediation work items.

Days 31–60: Enforce and harden

• Enforce TLS for web/apps/APIs; disable cleartext listeners where possible.
• Standardize remote access (VPN or equivalent) into the CUI environment.
• Lock down file transfer and email pathways for CUI (approved routes only).
• Establish certificate management ownership and monitoring.

Days 61–90: Evidence, testing, and assessment readiness

• Run validation tests for representative CUI flows and store results.
• Collect configuration exports/screenshots and log samples for each in-scope channel.
• Document exceptions with compensating controls and approvals.
• In Daydream, map 3.13.8 to the control narrative and schedule recurring evidence collection so the control stays provable year-round. ²

Frequently Asked Questions

Does 3.13.8 mean “encrypt everything everywhere”?

It means encrypt CUI to prevent unauthorized disclosure during transit across networks and connections where interception is a realistic risk. The fastest way to stay tight is to scope CUI flows and enforce encryption on those paths. ¹

Is TLS enough to satisfy the requirement for web apps and SaaS?

TLS is commonly the right mechanism, but assessors will care that it is enforced and correctly configured for the CUI flow. Keep evidence from the SaaS/admin console and connection logs that show encrypted sessions are required.

How do we handle CUI sent to a third party?

Treat third party exchange as a defined CUI transit path with an approved method (secure portal, encrypted file transfer, or controlled access). Document the method, enforce it contractually and technically where possible, and retain proof of the configuration and transactions.

What evidence do assessors accept for “encryption in transit”?

Expect to provide configuration settings (gateways/services), log samples showing encrypted connections, and test results demonstrating cleartext is blocked. Tie each artifact to a specific CUI transit path you documented. ²

If we prohibit emailing CUI, do we still need email encryption controls?

If your environment can still send CUI by email in practice, you have an exposure path and an assessor question. Either enforce the prohibition (technical blocks and monitoring) and document it, or implement secure email controls for CUI-capable workflows.

How do we keep this from becoming a one-time project?

Make evidence capture routine: scheduled config exports, periodic validation tests, and certificate monitoring with accountable owners. Track it as an operated control in your GRC system so you can reproduce proof on demand. ²

Footnotes

1. NIST SP 800-171 Rev. 2

2. DoD CMMC Program Guidance

3. 32 CFR Part 170

4. 32 CFR Part 170; Source: DoD CMMC Program Guidance