Protecting CUI in transit is broader than enabling HTTPS on the company website. NIST SP 800-171 Rev. 2 requirement 3.13.8 calls for cryptographic mechanisms to prevent unauthorized disclosure of CUI during transmission unless otherwise protected by alternative physical safeguards. When cryptography is used to protect CUI confidentiality, 3.13.11 requires FIPS-validated cryptography.
For CMMC Level 2, the practical work is to enumerate every path where CUI moves: user-to-cloud, workstation-to-file server, remote user-to-enclave, application-to-application, email, managed file transfer, API, backup replication, administrative support, and transfers to customers or subcontractors. One unreviewed path can bypass an otherwise strong architecture.
The best evidence therefore begins with a transfer map and ends with protocol configuration and real connection samples. Saying 'we use TLS' is a starting point, not the complete control.
Create a CUI transfer-path inventory
List each business workflow that moves CUI and identify sender, receiver, protocol or mechanism, network path, authentication method, cryptographic protection, and responsible owner. Include internal transfers because CUI can cross untrusted or shared network segments even when it never leaves the company.
Cover automated transfers as well as human actions. APIs, synchronization agents, backup replication, SFTP jobs, integration middleware, EDI, database connections, and remote monitoring can transmit CUI without an employee clicking a send button. Review service accounts and machine identities used by those paths.
Mark prohibited channels explicitly. Personal email, consumer file sharing, unapproved messaging, plaintext FTP, or direct uploads to unmanaged services should not remain as undocumented alternatives. Where possible, enforce the prohibition through filtering, application control, DLP, firewall policy, or access restrictions.
- Sender and recipient
- Network boundary crossed
- Protocol/service and cryptographic termination point
- Intermediate gateway, proxy, archive, or relay
- Whether CUI persists at either endpoint
Distinguish cryptographic protection from physical safeguards
Requirement 3.13.8 allows an alternative when physical safeguards otherwise protect CUI during transmission. That does not mean every internal network is automatically a safe alternative. Document the path, physical boundary, access controls, cabling or network exposure, and threat assumptions when relying on physical protection rather than cryptography.
In modern mixed environments, cryptography is often simpler to sustain because traffic crosses Wi-Fi, remote access, cloud infrastructure, provider networks, or shared facilities. Use the architecture to make the decision rather than applying a blanket statement that 'internal traffic is trusted.'
If an unencrypted legacy protocol is required for a specialized asset, determine whether the protected physical path truly meets the alternative safeguard condition, whether a gateway or tunnel can add cryptographic protection, and how the exception is documented in the SSP and network diagram.
Validate the cryptographic implementation, not just the protocol label
A connection can display 'TLS' and still use an implementation or configuration that does not support the organization's CMMC claim. Identify the cryptographic module used by the endpoint, server, appliance, VPN, or application and map it to the relevant FIPS validation when that cryptography protects CUI confidentiality.
Check that the deployed configuration uses the intended mode and does not silently fall back to unapproved alternatives. Review protocol versions, certificate validation, client behavior, tunnel settings, and application configuration according to the technology. Preserve representative evidence such as configuration exports or validated connection details without exposing private keys.
Do not confuse a vendor statement that a product is 'FIPS capable' with proof that the specific deployed instance is using the validated module and required settings. Changes in product version, operating system, or cryptographic library can alter the implementation mapping.
Review the common channels and the destination together
For web and API traffic, verify the endpoints that actually carry CUI, not only the public marketing domain. For VPN and remote access, confirm the tunnel covers the traffic path and the relevant clients use approved configuration. For SFTP or managed file transfer, check server identity validation, account restriction, destination control, and logs in addition to encryption.
For email, examine the entire workflow: mailbox platform, message routing, attachment storage, external recipient controls, forwarding, and whether the approved solution protects CUI to the intended recipient. Opportunistic transport encryption between mail servers may not be equivalent to a controlled end-to-end business process for every CUI exchange.
For backups and replication, document whether data leaves the local facility or tenant, what transport mechanism protects it, and whether the receiving repository is part of the approved CUI architecture. Automated data movement is easy to overlook because it happens outside normal user workflows.
Check DNS names, certificates, and endpoint identity as part of the protected channel. Strong encryption to an attacker-controlled endpoint still discloses CUI. Managed clients should validate the intended service, administrators should know how certificates are issued or rotated, and users should not be trained to click through certificate warnings to complete a transfer. This is especially important for internal portals and appliances where self-signed or expired certificates can become normalized.
Encryption protects content from interception, but it does not make the wrong recipient authorized. Combine transmission protection with access control, recipient validation, approved-domain rules, customer or subcontractor handling procedures, and a method to prevent accidental use of personal accounts or unmanaged endpoints.
For external partners, document the agreed exchange method and onboarding process. If a subcontractor receives CUI, confirm the contractual and security responsibilities applicable to that relationship rather than assuming a secure file-transfer link alone resolves downstream handling requirements.
Keep a response path for misdirected transmissions. Users should know whom to contact, administrators should be able to preserve relevant logs, revoke shared links or access where technically possible, and determine whether the event triggers contractual incident reporting or another response obligation.
Review local staging on both ends of a transfer. An approved SFTP or portal exchange can be cryptographically protected in transit while the sender first places the file in an unmanaged desktop folder or the recipient automatically downloads it to an unapproved device. The transmission control should be analyzed with the at-rest and endpoint controls so a secure channel does not mask unsafe handling immediately before or after the transfer.
- Web/API sessions
- VPN or remote administration
- SFTP/managed file transfer
- Email and secure-message delivery
- Application-to-application integration
Demonstrate the control with a transfer matrix and live samples
Prepare a transfer matrix, network or data-flow diagram, approved protocol standard, configuration records, FIPS module mapping where relevant, recipient-control procedure, and representative connection logs. Align each artifact to a real CUI workflow such as engineering-file exchange, customer portal upload, or remote access to the enclave.
Test several paths. Capture a successful approved transfer and a blocked or technically prohibited path where practical. Verify that the receiving side is the intended service and that logs show the user or service identity, destination, time, and result. A live demonstration often reveals browser downloads, sync folders, or local staging copies that the diagram forgot.
Revisit the matrix after system changes. Moving from on-premises file transfer to a SaaS collaboration platform can change the protocol, storage location, identity system, logs, and external-service scoping at once. Update the SSP and evidence while the migration occurs instead of waiting for assessment preparation.
A short working check
- ✓Inventory every internal and external CUI transfer path
- ✓Document protocol, endpoint, owner, and protection method for each path
- ✓Justify any reliance on alternative physical safeguards
- ✓Map deployed cryptography to FIPS-validated modules where required
- ✓Review TLS, VPN, SFTP, email, API, and replication configurations separately
- ✓Control approved recipients and destinations
- ✓Keep logs and representative transfer evidence
- ✓Update data-flow documentation when transmission architecture changes
Common questions
Does CMMC require encryption for every internal CUI transmission?
Requirement 3.13.8 calls for cryptographic mechanisms to prevent unauthorized disclosure during transmission unless CUI is otherwise protected by alternative physical safeguards. A contractor relying on physical safeguards should document and be able to demonstrate that protection for the specific path.
Is HTTPS alone enough evidence for CUI in transit?
No. The contractor should show the actual CUI endpoint and path, configuration, cryptographic implementation where applicable, recipient controls, and representative operational evidence. A protocol label alone does not establish the full control.
When does the FIPS requirement apply?
Under 3.13.11, when cryptography is employed to protect the confidentiality of CUI, the organization should use FIPS-validated cryptography. Evidence should map the deployed mechanism to the validated module and configuration.
Can a VPN make an otherwise unapproved destination acceptable for CUI?
No. A protected tunnel addresses the transmission path, but the receiving endpoint or service still has to be authorized to handle the CUI and meet the applicable scope and safeguarding requirements.
Official sources used for this guide
Open the primary source before making a contract-specific decision. Regulations and program implementation can change.
