What SC.L2-3.13.8 data in transit requires for CUI
If your organization handles Controlled Unclassified Information, every path that carries CUI between systems, users, service providers and external parties needs protection in transit. SC.L2-3.13.8 asks you to implement cryptographic mechanisms that prevent unauthorized disclosure of CUI during transmission. The only alternative the requirement allows is alternative physical safeguards that protect the data in transit instead. In practice, most organizations meet it with an encrypted tunnel such as TLS, and the CMMC Assessment Guide Level 2 names a TLS tunnel using the most current TLS version as the most common approach. Mutual authentication is considered the most secure option but is not required. The cryptography you choose must also satisfy SC.L2-3.13.11, which means FIPS-validated modules, not only approved algorithms.
SC.L2-3.13.8 carries 3 points in the CMMC Scoring Methodology, and it is worth more than 1 point, so it cannot go on a Plan of Action and Milestones. Under 32 CFR 170.21, it must be MET before you can reach Conditional or Final Level 2 status. An assessor tests it against three assessment objectives in NIST SP 800-171A: that you identified the cryptographic mechanisms or alternative physical safeguards intended to prevent disclosure of CUI, and that you implemented one or the other during transmission. Expect the assessor to ask for the documented design, the configuration of each transmission path and evidence that the configuration is in effect, not just written down.
The hard part is usually finding every path. Teams often document the external connections they know about, such as the web portal and email gateway, while internal flows between application servers, databases, backup jobs, directory services and monitoring tools stay unrecorded and sometimes run in cleartext. Legacy protocols such as older file transfer services, unencrypted LDAP binds and outdated TLS versions on appliances are common findings. Start by building an inventory of CUI transmission paths from your data flow diagrams and network captures, then confirm each one with the system owner. Ask your implementation partner or assessor which evidence they will accept for internal paths before you configure anything, and confirm the TLS and FIPS settings for each platform against its vendor documentation in your own environment.
Which transmission paths and systems fall under 3.13.8
Scope for SC.L2-3.13.8 follows where CUI actually travels, not where the network diagram draws a boundary. Each path below either gets cryptographic protection or a documented physical safeguard, and assessors will ask for the decision behind every one.
External connections to customers and subcontractors
Any link that carries CUI out of the organization, such as a portal upload, a secure API to a prime contractor or a subcontractor sFTP drop, is in scope. Inventory each external endpoint, the CUI it carries and the protocol and TLS version in use. Confirm that partner systems enforce the same standard, since your encryption only protects the part of the path you control.
Internal service-to-service traffic
Traffic between application tiers, databases, identity services and logging pipelines inside the CUI boundary is often overlooked. If a component handles CUI, the connection to it is in scope, even on a flat internal network. Map service calls from the application configuration and treat internal hops with the same TLS standard as external ones.
Email and file transfer
Email carries CUI when users attach files or write it into message bodies, and transfer tools move it between systems. Check whether mail servers offer opportunistic TLS that falls back to plaintext, and whether file transfer services enforce encryption on every session. Document any path that cannot be encrypted and decide, in writing, whether a physical safeguard applies.
Remote administration
Administrative sessions over SSH, RDP, web consoles or management APIs can expose CUI in screens, logs and transferred files. Administrators often connect from unmanaged networks, so these paths need the same protection as user traffic. Confirm which management protocols are enabled, disable legacy ones and record the cryptographic settings used for each.
Third-party SaaS and cloud links
CUI that leaves your environment for a hosted service crosses a path you do not operate. Identify each SaaS platform, cloud storage sync client and backup target that receives CUI, then ask the provider for its transport encryption settings and FIPS-validated status. Contracts and shared responsibility documents should state who owns each link, and the answer must be in writing before you rely on it.
Physical safeguards as a documented exception
The requirement allows alternative physical safeguards instead of cryptography, but only as a deliberate choice for a named path. Record the path, the physical protection applied, who controls it and how it is monitored. An undocumented assumption that a link is private will not satisfy the assessment objectives, which test the process as well as the outcome.
How an assessor tests data in transit against NIST SP 800-171A
This table walks through the three SP 800-171A assessment objectives for SC.L2-3.13.8 and shows what an assessor does, what they ask to see, and where organizations usually fall short. Read each row as a question the assessor will put to your environment, and gather the matching evidence before the assessment starts.
| Assessment element | What the assessor does | Evidence requested | Common findings |
|---|---|---|---|
| Objective 1: Cryptographic mechanisms identified | Interviews the system owner and reviews the transmission design to confirm which mechanisms protect CUI in transit | Data flow diagrams marking every CUI transmission path, and a list of the cryptographic mechanisms assigned to each path | Diagrams omit internal service-to-service traffic, so some CUI paths have no named mechanism |
| Objective 2: Alternative physical safeguards identified | Confirms whether any transmission relies on physical protection instead of cryptography, and reviews the documented process that makes that choice | Written description of the physical safeguard, its scope and the process that approves it, or a statement that none is used | Physical safeguards are assumed but never written down, so the claim cannot be tested |
| Objective 3: Mechanism or safeguard implemented during transmission | Tests configured endpoints, such as web, API, email, database and VPN services, and inspects captured sessions for the stated protection | Cipher suite and protocol settings from each endpoint, certificate inventory with issuers and expiry dates, and test results from an approved scanning method | Legacy protocol versions still enabled, weak cipher suites accepted, or certificates expired or issued by an unknown authority |
| Internal protocol coverage | Samples internal traffic between application tiers, databases, directories and management interfaces | Configuration showing encrypted internal connections, or documented justification for each plaintext protocol | Plaintext internal protocols such as unencrypted database or LDAP connections remain in use with no record of an exception |
| Documented exceptions | Checks whether any CUI transmission bypasses the stated mechanism and whether an approval exists | Exception register with owner, reason, risk acceptance and review date, reconciled against the design documents | Undocumented exceptions discovered during endpoint testing, or exceptions approved verbally only |
| TLS tunnel reference in the Assessment Guide | Compares the implementation with the Assessment Guide's description of a TLS tunnel using the most current TLS version, and notes that mutual authentication is recommended but not required | Protocol version settings, and confirmation that the cryptography also meets SC.L2-3.13.11 (FIPS-validated modules) | Current TLS version enabled but the underlying library is not a FIPS-validated module, which fails the linked cryptography requirement |
| Audit records of transmission controls | Reviews whether configuration changes to transmission settings are logged and reviewed | Change records for TLS and certificate settings, and logs showing who changed them and when | Cipher changes made on load balancers or proxies with no change record or review |
| Final-form evidence | Accepts only final evidence when scoring the objectives, so drafts do not count toward MET | Signed, dated and version-controlled diagrams, inventories and procedures in their current state | Draft architecture documents or outdated scan results presented as current proof |
How to implement encryption in transit in a CUI environment
This sequence takes a CUI environment from an inventory of every transmission path to a documented, enforced and evidenced configuration for SC.L2-3.13.8. Each step names the artifact it produces so an assessor can trace the requirement from design to running system.
Inventory every CUI transmission path
Start by listing every route CUI can take between systems, users and external parties. Include user access to applications, server-to-server calls, database connections, backup and replication traffic, email, file transfer, remote administration sessions, and links to cloud services and subcontractors. The system owner and network engineers should walk the data flow diagram together, because diagrams often omit service-to-service traffic. The step is done when the CUI data flow diagram and a transmission path register show each path, its endpoints, protocol and the component that carries it.
Decide cryptography or physical safeguards per path
For each path in the register, decide whether cryptographic mechanisms protect the CUI in transit or whether alternative physical safeguards do. SC.L2-3.13.8 allows either, but the decision must be recorded and it must be applied to each path, not to the environment as a whole. Most network paths between systems will use cryptography. Where a physical safeguard is claimed, such as a dedicated circuit within a controlled facility, document how that safeguard prevents disclosure and who verifies it. The output is a decision record per path that states the chosen safeguard and the reason for it.
Select FIPS-validated TLS configurations
For every path protected by cryptography, select a TLS configuration that the current CMMC Assessment Guide Level 2 describes as the most common approach: a TLS tunnel using the most current TLS version. Confirm that the cryptographic module performing the TLS handshake and bulk encryption holds a FIPS validation certificate, and that the validated module is the one enabled in production, not just an approved algorithm running in a general library. Record the module name, version and validation certificate number from the NIST Cryptographic Module Validation Program listing. Ask your vendor or integrator to confirm the validation status in writing, because validation applies to specific module versions and build configurations.
Enforce TLS on every endpoint
Apply the chosen configuration to each server, load balancer, proxy, application, database listener and client tool on the transmission paths. Disable cleartext listeners and fallback to older protocol versions, and restrict cipher suites to those the validated module supports. Use the configuration management process to deploy the settings so they are version-controlled and repeatable. Mutual authentication is the most secure option, but the assessment guide does not require it, so decide whether to use it per path. The output is the configuration baseline and a scan report from a TLS testing tool showing that each endpoint accepts only the approved versions and suites.
Manage certificates and cryptographic keys
Establish the certificate authority, issuance process and key storage that the TLS endpoints depend on. Internal CAs can be run with FreeIPA, which includes an integrated Dogtag-based certificate authority, and certificates for Kubernetes or OpenShift workloads can be issued and renewed by cert-manager from an issuer you select, such as a CA key pair or HashiCorp Vault. Store private keys in a managed secrets engine such as OpenBao's transit engine, which supports versioned keys and rotation. Key management is also covered by SC.L2-3.13.10 and the cryptography must meet SC.L2-3.13.11, so align these records with those requirements. The output is a certificate inventory with issuers, expiration dates, owners and a documented rotation procedure.
Test the paths and record the results
Verify that the configuration works on each path in practice. Test that connections succeed with approved protocols, fail when a client requests a disallowed version or cleartext, and that certificate validation rejects untrusted or expired certificates. Keep the test scripts, scan outputs and the date and person who ran each test, because assessors look for evidence that the mechanism is implemented during transmission, not only in design documents. Where a physical safeguard is the chosen control, collect the procedure and records that show it operates. The output is a transmission test record linked to each path in the register.
Document the control and keep the evidence current
Update the system security plan so it names each transmission path, the cryptographic mechanism or physical safeguard protecting it, the validated module, and the owner responsible for the configuration. Retain audit records that show TLS settings were changed, certificates were issued and renewed, and endpoints were scanned, because SP 800-171A includes audit records among the assessment objects for this requirement. Review the register and configuration after significant changes to systems, networks or cloud services. The output is a current system security plan section and a dated evidence folder that a C3PAO or the Department can review. Your own assessment team or an independent assessor should confirm that the evidence meets the objectives before you claim the requirement is MET.
How TLS, certificate authorities and key stores fit together
An encrypted transmission path for CUI has three moving parts: the endpoints that negotiate TLS, a certificate authority that issues the certificates those endpoints present, and a secrets engine or key store that holds the private keys behind them. When a client connects to a CUI application, the server presents a certificate, the two sides agree on a protocol version and cipher suite, and they derive session keys that protect the data in transit. The certificate proves the server's identity, and the private key is what makes the handshake work. If any of these parts is weak, the link is weak, so an assessor will look at all three together rather than at the TLS setting alone.
Mutual TLS, in which the client also presents a certificate, is optional under SC.L2-3.13.8 but stronger, because each side verifies the other before any CUI moves. The CMMC Assessment Guide Level 2 notes that the most common approach is a TLS tunnel using the most current TLS version and that mutual authentication is the most secure option but not required. Deciding whether to use it is a design choice you should record in the system security plan, along with who issues client certificates, how revocation works and how the client identity is logged. Identifying the CA and key store early also shapes the answer, because FreeIPA's integrated Dogtag-based certificate authority and cert-manager's issuers in Kubernetes or OpenShift can each issue these certificates from different trust roots.
Two related requirements decide whether this path passes. The cryptography must meet SC.L2-3.13.11, which means FIPS-validated modules, not just approved algorithms, so you need to confirm that the TLS libraries, load balancers and proxies in the path run on validated modules in their approved modes. Key handling falls under SC.L2-3.13.10, so the assessor will ask where private keys are generated, who can read them, how they rotate and what happens when one is compromised. OpenBao's transit engine can perform encryption and signing operations without exposing key material to applications, and cert-manager renews certificates before they expire. Confirm with each vendor which operations run in validated modules before you describe the path in your evidence.
Evidence that proves CUI is encrypted in transit
Assessors test SC.L2-3.13.8 by tracing where CUI moves, how each link is protected, and whether the protection is actually running. The cards below cover the artifacts that show this, from architecture to scan results, and how to keep them current between assessments.
Transmission architecture diagrams
Draw every path that carries CUI, including user sessions, API calls, replication jobs, backups, email gateways and administrative access. Mark each flow with the protocol, port and cryptographic mechanism used, and show the boundary devices and endpoints at each end. An assessor uses this diagram to decide which endpoints to test, so a flow missing from the diagram is a flow nobody checks. Confirm the diagram matches the system security plan and the current network, not the design from the original deployment.
TLS configuration exports from each endpoint
Export the effective TLS settings from every service that terminates CUI traffic: protocol versions enabled, cipher suites, certificate chain and key length. Collect the exports from the running configuration rather than the configuration template, since a reverse proxy or load balancer can override an application default. The most common approach described in the CMMC Assessment Guide is a TLS tunnel using the most current TLS version, so the export should show that version is the one negotiated. Record the date and the command used so the export can be reproduced.
Certificate inventory and renewal logs
Keep a current inventory of every certificate used for CUI transmission, with issuer, subject names, expiry date, the service that uses it and the owner responsible for renewal. Renewal logs show that certificates were replaced before expiry and that no service fell back to an untrusted certificate. Where cert-manager issues workloads' TLS certificates in Kubernetes or OpenShift, its renewal events and the Kubernetes Secrets it writes are the records to retain. An expired certificate on a CUI path is a finding an assessor can see directly.
Documented alternative physical safeguard decisions
Where the organization relies on physical protection instead of cryptography for a transmission path, document the decision, the path it covers, the physical controls that protect it and the procedure staff follow. Assessors test both the process for choosing this option and the safeguards in use, so a decision written after the fact will not satisfy the objective. Most CUI transmission paths in a defense contractor environment are encrypted, so confirm each exception is deliberate and reviewed rather than assumed. Ask your assessor early whether they expect this path to be tested.
Configuration scan and test results
Run scans of CUI-facing endpoints against the TLS policy you have defined and keep the reports with the date, scanner version, target list and findings. Pair scans with manual checks of mutual authentication where you use it, since mutual authentication is the more secure option even though it is not required. Record the remediation for each failed check and a re-test showing it is closed. Open scan failures on a CUI path are hard to explain in an assessment, so resolve or document them before the assessment window.
Keeping evidence current and final
Evidence counts only in final form, and an assessor will not accept a draft diagram or an unsigned procedure as proof that a requirement is met. Assign an owner to each artifact, set a review schedule, and record the date of each revision so the current version is easy to identify. Re-export TLS settings and re-run scans after every change to a CUI path, certificate renewal or cryptographic library upgrade. Confirm with your assessor which evidence dates they will accept for the assessment period.
What meeting 3.13.8 costs in money and effort
When the transport layer sits on managed cloud services, most of the cost is in configuration, certificate handling and evidence rather than in software licenses. The cloud provider bills for load balancers, gateways and managed certificates on a usage basis, and the organization pays its own staff or an implementation partner to confirm that every CUI path uses a current TLS configuration. Assessors will look at the configuration itself, so the provider's default settings are only a starting point.
- Service fees: Usage-based charges for managed load balancers, API gateways and certificate services. Confirm whether these recur monthly and whether your provider's CMMC environment carries a different price.
- Endpoint configuration: One-time effort to set minimum TLS versions, approved cipher suites and FIPS-validated modules where the service exposes them.
- Certificate operations: Recurring effort to track renewals, domain validation and certificate inventory, even when the provider automates issuance.
- Evidence upkeep: Recurring effort to export configuration baselines and cloud logs that show the transport settings in force during the assessment window.
- Assessor time: Paid to the independent assessor, and usually scaled to the number of systems and data flows in scope.
Ask the provider which cryptographic modules back each service and for documentation that shows FIPS validation status. Ask your implementation partner for a written scope that lists each transport path, and check whether the quote includes evidence capture or only configuration.
Self-hosted deployments carry more one-time engineering because the organization owns every hop: the reverse proxy, the application servers, the internal service mesh and the certificate authority that signs them. Open-source components such as cert-manager and FreeIPA carry no license fee, so the cost is staff time, hardware or virtual capacity, and the work of proving the configuration to an assessor. Recurring cost is mostly certificate lifecycle and patching.
- Tooling: Open-source licenses cost nothing to acquire, but hosting, backup and monitoring infrastructure are real line items. Confirm your own infrastructure costs with your finance and platform teams.
- Engineering time: One-time effort to configure TLS on every endpoint, disable legacy protocols, and document the cryptographic mechanisms in the system security plan.
- Certificate and key operations: Recurring effort to run an internal certificate authority, renew certificates and protect signing keys. cert-manager can automate renewal inside Kubernetes or OpenShift, and FreeIPA's Dogtag-based CA covers issuance for other hosts.
- Evidence upkeep: Recurring effort to keep configuration baselines, certificate inventories and scan results current, since assessors accept only final evidence.
- External testing: Optional one-time or periodic testing of exposed services, scoped and priced separately.
Ask for a written breakdown that separates one-time build effort from recurring operations, and confirm who holds the signing keys after the engagement ends.
Most defense contractors run a mixed model: a cloud environment for collaboration and email, with on-premises or private systems for engineering data. Costs stack across both sides, and the seams between them often generate the most assessor questions. The organization pays for two sets of configuration work, plus the effort to show that the data path between them is protected end to end.
- Duplicated configuration: Each environment needs its own TLS baseline, cipher policy and certificate inventory, so one-time effort roughly doubles unless the baseline is shared.
- Interconnect protection: One-time effort to secure site-to-site links, VPN tunnels or private connections, and recurring effort to monitor them.
- Key management split: Recurring effort to decide which system issues certificates for which environment, and to avoid two unmanaged trust stores.
- Evidence across boundaries: Recurring effort to show one consistent story in the assessment package, which adds time to evidence upkeep.
- Assessor time: Usually higher than a single-environment scope because the assessor samples more paths.
Before requesting a quote, list every system and data flow that carries CUI, and ask the provider to price each environment separately so you can compare the mixed model with a single-environment option.
Which open-source tools support encryption in transit
Can cert-manager handle TLS certificates for CUI traffic in Kubernetes?
Yes, cert-manager can create TLS certificates for workloads running in Kubernetes or OpenShift, and it renews them before they expire. It is licensed under Apache-2.0. It supports several issuers, including ACME (Let's Encrypt), a CA key pair, HashiCorp Vault, CyberArk and self-signed certificates, and it stores the resulting certificates in Kubernetes Secrets. For SC.L2-3.13.8, the question is not whether certificates are issued but whether the transport they protect uses cryptography that is FIPS-validated. Your team should confirm which issuer you use for CUI workloads, whether it is internal or public, and that the TLS libraries in those workloads run on a validated module. Evidence usually includes issuer configuration, certificate inventories and renewal records.
Does FreeIPA's certificate authority help with TLS for CUI systems?
FreeIPA includes an integrated certificate authority based on Dogtag, which issues and manages certificates for hosts, services and users. It is licensed under GPL-3.0-or-later. An internal CA lets you control which certificates are trusted on your network and keeps issuance records in one place, which assessors commonly ask to see. FreeIPA does not by itself establish that your transport is FIPS-validated. You need to confirm the cryptographic module used by the operating system, the web server and the client libraries, and document it in your system security plan. Ask an implementation partner to produce a certificate inventory and issuance log that ties each CUI-facing service to its certificate and approved cipher configuration.
How does OpenBao help with key management for encrypted CUI?
OpenBao, licensed under MPL-2.0, offers a transit secrets engine that encrypts and decrypts application data without storing that data, signs and verifies data, and supports versioned encryption keys with key rotation. These features support SC.L2-3.13.10 key management, which is closely tied to the cryptography in SC.L2-3.13.8. Transit encryption is useful when applications need to protect data they send across a network without handling key material directly. Before relying on it for CUI, confirm the FIPS-validation status of the module that performs the cryptography in your deployment, since that status depends on your build and configuration, not on the license. Keep rotation policies, key version history and access logs as evidence.
Do these open-source tools make a system compliant with SC.L2-3.13.8 on their own?
No. Tools support the control, but the organization owns the decision to protect CUI in transit and must show that the mechanism is implemented and working. A requirement is MET only when the assessment objectives are satisfied with evidence in final form. The mechanisms must be identified in the system security plan, applied to every transmission path carrying CUI, and tested. Alternative physical safeguards are also permitted under the requirement, but they must be documented and proven. An implementation partner can configure these tools, prepare the evidence and document the design, while an independent assessor evaluates the result. Ask any partner to show the scope of each transmission path they will cover.
What does it cost to deploy these tools for encryption in transit?
All three tools are open source, so there is no license fee for the software itself. Costs come from the work around them: architecture design, installation in your cloud account, data center or air-gapped network, configuration of TLS policies, integration with applications, testing and documentation. Some costs are one-time, such as initial deployment and evidence preparation, while others recur, such as certificate operations, key rotation, upgrades and monitoring. Costs rise with the number of services, transmission paths and existing systems that must be changed. DeployOpen plans and implements these systems under a fixed-scope written agreement, and a quote follows from that scope. Ask for a breakdown of labor, testing and documentation, and confirm who maintains the tools after handover.
Which open-source license terms matter when using these tools for CUI?
The three tools carry different licenses: cert-manager is Apache-2.0, FreeIPA is GPL-3.0-or-later, and OpenBao is MPL-2.0. Each permits use, but the obligations differ if you modify the code or distribute it. Permissive and weak copyleft terms usually affect how you share changes, not whether you can run the software inside a CUI environment. GPL terms can matter if you distribute modified builds to third parties. Have counsel review the license obligations for your specific deployment model, particularly if you package or redistribute the tools. License terms do not affect FIPS validation, which must be confirmed separately for the cryptographic module in use.
What should an engineer check before relying on these tools for TLS?
Start by listing every path that carries CUI, including internal service calls, administrative sessions and backup transfers. For each path, confirm the TLS version and cipher suites in use, and that the libraries and operating system use a FIPS-validated module in FIPS mode. Check that cert-manager or FreeIPA issues certificates with appropriate lifetimes and that renewals succeed in a test. Verify that OpenBao key rotation runs and that old key versions remain available only as needed. Confirm mutual authentication where your risk assessment calls for it, although the CMMC Assessment Guide notes it is not strictly required. Finally, capture configuration files, test results and logs in a form an assessor can review.
Can a small team run these tools without an outside partner?
A capable internal team can run these tools, particularly if they already operate Kubernetes, identity systems and secrets management. The harder work is usually the compliance side: mapping each transmission path to the requirement, confirming FIPS validation, writing the system security plan and producing evidence that holds up in an assessment. Outside help is a choice, not a requirement, and it is most useful for design review, configuration, documentation and testing. Any partner should work from a written scope that names deliverables and timelines. The independent assessor, not the partner, decides whether requirements are met. Decide early who will maintain certificates, keys and upgrades after the project ends.
Gaps that cause a NOT MET on 3.13.8
Most NOT MET findings on SC.L2-3.13.8 come from a few predictable gaps: traffic that was never encrypted, protocols nobody retired, safeguards that exist only in someone's head, and cryptography that cannot be proven. Each card below names one gap, why an assessor will flag it, and the check to close it before the assessment begins.
Internal traffic left in plaintext
Teams often encrypt the internet-facing edge and assume traffic inside the network is safe. SC.L2-3.13.8 covers CUI in transmission wherever it moves, including between application tiers, to databases, to backup targets and between management consoles. Inventory every flow that carries CUI, mark each one as encrypted or as protected by a documented alternative, and test the internal paths with packet capture or service configuration review. Close it by mapping each CUI data flow end to end.
Legacy TLS versions still enabled
A server that accepts older protocol versions alongside current TLS leaves a downgrade path open, and assessors test the configuration, not the policy document. The CMMC Assessment Guide describes the most common approach as a TLS tunnel using the most current TLS version. Scan every listener, load balancer and internal service, disable deprecated protocol versions and weak cipher suites, and keep the scan report as evidence. Close it by retiring legacy protocol versions on every endpoint.
Undocumented physical safeguard assumptions
The requirement allows alternative physical safeguards in place of cryptography, but only if the organization identifies them and implements them. Teams sometimes rely on a dedicated fiber run or a locked machine room without writing that down or showing that it protects CUI in transit. Document each physical safeguard, the path it covers, who owns it and how it is verified. Assessors test both the identification and the implementation. Close it by writing a procedure for each physical path and tying it to the system security plan.
Certificates expiring without monitoring
Encrypted channels fail silently when a certificate expires, and teams sometimes respond by disabling verification to restore service, which removes the protection the control depends on. Track every certificate in use, its issuer and its expiration date, and alert well before expiry. Automated renewal reduces the risk, but the renewal process itself must be tested and logged. Close it by building a certificate inventory with alerting and a documented renewal owner for each certificate.
Approved algorithms without validated modules
Using AES or a current TLS version does not satisfy the requirement on its own, because the cryptography must come from a FIPS-validated module. Many libraries and runtimes implement sound algorithms without that validation, and the gap only appears when an assessor asks for the module's validation certificate. Identify which library or crypto provider performs each TLS handshake, confirm its validation status and the mode it runs in, and record the configuration that enforces it. Close it by matching every TLS endpoint to a named FIPS-validated module.
Evidence that exists only as a claim
Assessors need evidence that shows the mechanism working on the systems in scope, and a diagram or a policy statement rarely meets that bar. For SC.L2-3.13.8, the useful artifacts are configuration exports, scan results, certificate inventories and transmission tests, each dated and tied to a system in the boundary. Ask each system owner which artifact proves their encrypted paths, and collect it in final form. Close it by defining one evidence item per CUI data flow before the assessment window.
Questions about cost, effort and outside help for data in transit
Can our team meet SC.L2-3.13.8 in-house without an outside partner?
Yes, many organizations do, provided they have staff who can inventory every path that carries CUI, configure current TLS on those paths, manage certificates, and collect evidence in final form. The requirement itself is narrow: implement cryptographic mechanisms to prevent unauthorized disclosure of CUI during transmission, or rely on alternative physical safeguards. The harder part is coverage. Teams usually miss internal service-to-service traffic, backup transfers, email relays, remote access tunnels and vendor connections. An outside partner can help with that discovery and with building the evidence set, but the organization still owns the controls and the final decision on scope.
What drives the cost and effort of meeting data in transit requirements?
Effort scales with the number of transmission paths that carry CUI, not with the requirement's 3 points. The main drivers are how many systems and services talk to each other, whether TLS is already enforced or must be retrofitted on legacy applications, how many certificate authorities and key stores are involved, and whether alternative physical safeguards are used for any link. Costs fall into two groups. One-time costs include the path inventory, configuration changes, certificate setup and documentation. Recurring costs include certificate renewal, protocol review as versions change, and periodic evidence collection. Ask any quote to separate these and to list the paths it covers.
What does the work need from our staff?
Plan for input from network engineering, system administrators, application owners and whoever runs the identity and certificate infrastructure. Network staff need to confirm which flows leave or enter the boundary and which carry CUI. Application owners must confirm which protocol versions and cipher settings their software supports. Identity and PKI staff decide how certificates are issued, stored and renewed. Someone accountable for compliance must confirm that the evidence reflects the final configuration. The number of hours depends on environment size and is not supplied here, so ask the partner to state the staff time it assumes in the written scope.
Can SC.L2-3.13.8 be placed on a plan of action and milestones?
No. SC.L2-3.13.8 carries 3 points, and under the CMMC scoring rules in 32 CFR 170.21(a)(2), a requirement worth more than 1 point cannot be placed on a POA&M. It must be MET for the organization to reach Conditional or Final Level 2 status. If the requirement is NOT MET, the score is reduced by its 3 points from the maximum of 110. Plan the work so the mechanisms and their evidence are complete before any assessment begins, and treat any open gap as a blocker to status rather than a deferred item.
How long does it take to prepare data in transit controls?
No general duration can be stated with confidence, because it depends on how many transmission paths carry CUI and how much of that traffic is already encrypted with current TLS. Ask the partner for a timeline tied to the written scope, with milestones for path inventory, configuration changes, certificate work and evidence capture. Also ask which steps depend on your own change windows or vendor cooperation, since those often set the critical path. Confirm the timeline with the partner and with your assessment sponsor before work starts.
What can an implementation partner not do for this requirement?
An implementation partner cannot issue the assessment result. DeployOpen prepares systems, configurations and evidence for assessment, including TLS settings, certificate management and documentation. It does not issue audit reports, attestations or certifications. For Level 2 certification assessments, the CMMC Accreditation Body, currently The Cyber AB, authorizes or accredits C3PAOs, and those independent assessors determine whether SC.L2-3.13.8 is MET. Self-assessments are performed by the organization itself. Keep the partner's preparation role separate from the assessor's judgment in all contracts and documents.
Which parts of the work can a partner take on, and which must stay with us?
A partner can usually take on path discovery, TLS configuration on platforms you approve, certificate authority setup and automation, testing of cipher and protocol settings, and evidence packaging. Your organization must keep ownership of the CUI boundary definition, the decision to use alternative physical safeguards, risk acceptance, and the System Security Plan. Ask any proposal to list each deliverable, the system it applies to, and who signs off. Fixed-scope engagements agree those items in writing before work begins.
What should we ask for in a quote for data in transit work?
Ask for the scope in writing: the list of systems and transmission paths covered, the protocols and minimum versions to be enforced, how mutual authentication is handled if chosen, and what evidence is delivered. Request separate line items for one-time setup and recurring activities such as certificate renewal and periodic review. Confirm which assumptions the price depends on, including staff time from your side and access windows. Also ask what is excluded, such as legacy systems that cannot support current TLS, and how changes to scope are priced. DeployOpen does not publish a price list; a quote follows from the written scope.
How DeployOpen scopes encryption in transit for CUI
This sequence turns SC.L2-3.13.8 into a written, bounded engagement in which DeployOpen maps every CUI transmission path, hardens the TLS, certificate and key workflows in the client's own environment, and hands the client's assessor evidence in final form. DeployOpen prepares the controls and evidence, while the client owns the controls and an independent assessor makes the determination.
Agree the transmission scope in writing
Before work starts, DeployOpen and the client agree in writing which systems, services, network paths and user connections are in scope for SC.L2-3.13.8, which CUI flows they carry, and which parts of the environment are excluded. Because most engagements are fixed-scope, the written scope fixes the deliverables and the boundary of the work. The client confirms the scope with its own compliance lead and, where the client has one, its assessor. The step is done when the signed scope lists each in-scope transmission path and its owner.
Map every CUI transmission path
DeployOpen works with the client's engineers to inventory how CUI moves between users, applications, servers, storage, backups, administrators and external parties. The map covers web and API traffic, database connections, file transfers, email relays, replication, monitoring feeds and any path where a service calls another service. Each path is recorded with its endpoints, protocol, the component that terminates encryption, and whether the traffic crosses a trust boundary. The step is done when the client can point to a current diagram and table that match what the systems actually do.
Decide protection for each path
For each mapped path, the team records whether it is protected by a cryptographic mechanism, by alternative physical safeguards, or both, which is the choice SC.L2-3.13.8 allows. Where cryptography is chosen, the design names the protocol, the current TLS version the platform supports, and whether mutual authentication is used. The CMMC Assessment Guide Level 2 describes TLS tunnels with the most current version as the most common approach, and mutual authentication as the most secure option, though not required. The cryptography must also satisfy SC.L2-3.13.11, so the design identifies the FIPS-validated module that performs it. The output is a decision record per path that the client approves.
Harden TLS and certificate workflows in place
DeployOpen implements or hardens the chosen configuration inside the client's own cloud accounts, data centers or air-gapped networks. Work typically covers disabling deprecated protocol versions and weak cipher suites, configuring reverse proxies and load balancers, and deploying an internal certificate authority where the environment needs one. Open-source components such as FreeIPA, which includes a Dogtag-based certificate authority, and cert-manager, which issues and renews TLS certificates for Kubernetes or OpenShift workloads from configured issuers, can support this work. The client confirms which issuers and trust anchors are allowed. The step is done when test connections show only the approved protocol versions and the certificates chain to the approved authority.
Set up key and secret management
Encryption in transit depends on keys and certificates that must be created, stored, rotated and revoked under control. DeployOpen configures how private keys are generated and stored, who may request certificates, how renewal happens, and how a compromised key is replaced. Where a secrets engine is used, OpenBao's transit secrets engine can manage versioned encryption keys with rotation, and cert-manager stores issued certificates in Kubernetes Secrets and renews them before expiry. Each key workflow is documented with its owner and its logs. The output is a key and certificate runbook and a list of accounts with rights to issue or export keys, which the client reviews.
Verify the configuration with tests
DeployOpen tests each in-scope path against the approved design. Tests check that connections negotiate only permitted protocol versions and ciphers, that certificates are valid and issued by the approved authority, that unencrypted listeners are closed, and that renewal and revocation behave as documented. Results are recorded with timestamps, the tool used and the system tested. Failed tests are fixed and retested before the step closes, and any residual gap is reported to the client in writing. The output is a test record for each path that the client can reproduce.
Assemble final-form evidence for the assessor
DeployOpen compiles the artifacts an assessor would review against the NIST SP 800-171A objectives for 3.13.8: the scope, the path map, the decision records, configuration baselines, test results, key and certificate runbooks, and audit records showing that the mechanisms operate. Under the CMMC rules, a requirement is MET only when evidence is in final form, not in draft, so each artifact is finalized, dated and approved by the client's owner. DeployOpen does not issue audit reports, attestations or certifications. The client's independent assessor decides whether the requirement is met, and the client remains responsible for its own controls. The step is done when the client's assessor has the final evidence package and the client has signed off on its contents.
Hand over and maintain the configuration
At closeout, DeployOpen hands over the configuration, runbooks, evidence index and open items to the client's operations team, and explains how changes to protocols, certificates and paths must be recorded. Ongoing support, upgrades and continuous testing are available as retainers, and those are scoped separately in writing. The client confirms that operators can rotate certificates, update the path map when systems change, and rerun the tests. The step is done when the client accepts the handover and the change process is in use.
