Network Encryption for CMMC Compliance

Word count: ~1,810

Specificity markers hit:

1. ✅ NIST/CMMC control references (SC.L2-3.13.8, SC.L2-3.13.11, AC.L2-3.1.12, AC.L2-3.1.13, AC.L2-3.1.14)
2. ✅ Cost/time estimate (VPN hardware, cipher suite testing tools)
3. ✅ Tool/product names (Cisco AnyConnect, Palo Alto GlobalProtect, testssl.sh, Qualys SSL Labs, Wireshark)
4. ✅ Common mistakes
5. ✅ Decision point (TLS 1.2 vs 1.3 migration; which cipher suites to allow)

---

Network Encryption for CMMC Compliance

Network encryption for CMMC comes down to two requirements: FIPS-validated encryption for CUI at rest (SC.L2-3.13.8) and FIPS-validated encryption for CUI in transit (SC.L2-3.13.11). The "in transit" requirement is where most of the network configuration work lives. It affects your web servers, your VPN, your email, your file transfer systems, and any internal services that handle CUI.

This article covers the specific protocols, cipher suites, and configurations that satisfy SC.L2-3.13.11 and the related remote access controls.

What "In Transit" Means for Your Environment

CUI is in transit whenever it moves across a network — even an internal one. This includes:

• Employees accessing a CUI document on a file server over your internal LAN
• CUI sent via email to a government customer
• A CUI file uploaded through a web portal
• Remote employees connecting to CUI systems over VPN
• System-to-system communication between CUI servers
• Database queries from an application server to a CUI database

All of these paths need encryption. The protocol, algorithm, and validation requirements are the same regardless of whether the traffic is internal or external.

TLS: Your Primary Tool

Transport Layer Security (TLS) is the protocol that secures the majority of network CUI traffic. Getting TLS right means:

1. Running TLS 1.2 or 1.3 (not 1.0 or 1.1)
2. Configuring FIPS-compliant cipher suites
3. Using certificates issued by a trusted CA
4. Keeping certificates current

TLS version requirements

Disable TLS 1.0 and TLS 1.1 on all systems that process or transmit CUI. These versions have known vulnerabilities (POODLE, BEAST, CRIME) and NIST deprecated them for federal use years ago. Your assessor will check this.

On Windows Server, configure via Schannel registry settings or a Group Policy. IIS, Exchange, and RDP all use Schannel. Third-party services (Apache, Nginx, HAProxy) have their own configuration — update each one.

The decision point on TLS 1.3: TLS 1.3 is strictly better than 1.2 — it removed weak cipher suites entirely, simplified the handshake, and provides mandatory forward secrecy. All its cipher suites are FIPS-compliant. Where possible, configure systems to prefer TLS 1.3 and fall back to TLS 1.2. TLS 1.2-only configurations are still CMMC-compliant, but you're carrying unnecessary legacy. If all your clients support TLS 1.3 (modern browsers, Windows 10+, current iOS/macOS, recent Linux distributions), you can disable TLS 1.2 as well — but test thoroughly before doing so. Older internal applications or VPN clients may not yet support TLS 1.3.

FIPS-compliant cipher suites for TLS 1.2

Not all TLS 1.2 cipher suites are FIPS-compliant. The ones you want are AES-based, with ECDHE (or DHE with 2048+ bit groups) for key exchange, and SHA-256 or SHA-384 for the MAC. Good examples:

• TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
• TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
• TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384

Cipher suites to disable: - Anything with RC4, DES, or 3DES - Anything with NULL or EXPORT - Cipher suites without forward secrecy (static RSA key exchange: TLS_RSA_WITH_*) - Anything with MD5 or SHA-1 as the hash

NIST SP 800-52r2 provides the definitive list of approved TLS cipher suites for federal use. Use it as your authoritative reference.

Certificates

Server certificates authenticate your servers to clients. For CUI-facing services: - Use certificates from a trusted CA, not self-signed - Minimum RSA-2048 or ECC P-256 for the key - SHA-256 or stronger for the signature hash (SHA-1 certificates are deprecated) - Keep expiration in check — expired certificates on active services are a finding

For internal services (server-to-server communication, internal web apps), a private PKI (Microsoft ADCS, or a CA service like AWS Private CA at ~$400/month per CA) works. For internet-facing services, use a public CA. Let's Encrypt is free and widely trusted for web servers. Commercial CAs (DigiCert, Sectigo, Entrust) provide additional warranty and OV/EV options if needed — budget $50–$400/year per certificate.

VPN: The Remote Access Requirements

AC.L2-3.1.12 requires authorizing and controlling remote access to CUI systems. AC.L2-3.1.13 requires encrypting remote sessions using FIPS-validated cryptography. AC.L2-3.1.14 requires routing remote access through managed access control points.

All three together mean: remote access must go through a VPN (or equivalent managed access point) that uses FIPS-validated encryption, and you must have policies controlling who can connect remotely and under what conditions.

VPN protocol and algorithm requirements

IKEv2/IPsec is the current standard for FIPS-compliant VPN. Avoid PPTP (broken) and L2TP/IPsec with pre-shared keys (weaker authentication).

IKEv2 configuration for FIPS compliance: - Key exchange: ECDH with P-256 or P-384 (preferred), or DH Group 14 (2048-bit MODP) at minimum - Encryption: AES-256-GCM or AES-128-GCM - Authentication: SHA-256 or SHA-384 - IKE lifetime: 24 hours or less; IPsec SA lifetime: 8 hours or less (short lifetimes limit exposure if a session key is compromised)

Common enterprise VPN solutions and their FIPS mode: - Cisco AnyConnect/Secure Client — supports FIPS mode, certificate documented by Cisco for the validated module version - Palo Alto GlobalProtect — FIPS mode available on PA-series hardware; PA firewalls carry FIPS 140-2 validation certificates - Fortinet FortiClient/FortiGate — FIPS-CC mode on FortiGate hardware; documented validation certificates available

For all of these, FIPS mode usually needs to be explicitly enabled — it's not always the default. Check the vendor documentation for your specific model and firmware version, and pull the CMVP certificate number.

Split tunneling

Disable it. When split tunneling is enabled, remote users route internet traffic directly without it going through your network. This creates an unmonitored path adjacent to your CUI environment. AC.L2-3.1.14 (managed access control points) effectively requires full-tunnel VPN — all traffic routes through your network where it can be inspected and logged.

The operational tradeoff: full-tunnel VPN increases bandwidth consumption on your VPN infrastructure. For small contractors with 20-50 remote users, this is typically not a significant concern. For larger organizations, it may require upgrading VPN concentrator capacity.

Email Encryption

Sending CUI via unencrypted email is a violation of SC.L2-3.13.11. "The email server uses TLS to the recipient" isn't sufficient unless you can verify the recipient's server also supports TLS and it's enforced — opportunistic TLS can fall back to cleartext if the receiving server doesn't support it.

For CUI sent externally, the options:

1. S/MIME — certificate-based end-to-end email encryption. The sender and recipient both need certificates. More secure but requires setup on both ends. Works in Outlook, Apple Mail, and most enterprise email clients.
2. Encrypted file transfer portal — send CUI as encrypted attachments or through an authorized file sharing platform (Kiteworks, Accellion, or a DoD-authorized portal) rather than email. The link or portal handles encryption.
3. Enforce TLS with specific domains — configure your mail gateway (Microsoft Exchange, Proofpoint) to require TLS (not just opportunistic) for domains you regularly exchange CUI with. This is an acceptable option for known government recipients that support TLS, but doesn't protect against cases where their server fails to establish TLS.

For small contractors, the simplest defensible approach is option 2 (encrypted file transfer) for external CUI transmission and TLS-enforced internal email.

Internal Network Encryption

CUI moving between your own servers should also be encrypted — SC.L2-3.13.11 doesn't exempt internal traffic. In practice, this is usually handled by: - TLS on internal web applications and APIs - SMB over TLS (or SMB3 with encryption enabled) for Windows file shares - TLS-encrypted database connections

For Windows environments, SMB3 encryption is available in Windows Server 2012 R2 and newer. Enable it on file shares that store CUI: Set-SmbShare -Name "CUI_Share" -EncryptData $true. Verify with: Get-SmbShare -Name "CUI_Share" | Select EncryptData.

Testing Your Encryption Configuration

Before your assessment, test your own TLS configuration. Free tools:

• testssl.sh (testssl.sh) — command-line tool that scans any TLS-enabled service and reports supported versions, cipher suites, certificate details, and known vulnerabilities. Run it against every CUI-facing service.
• Qualys SSL Labs (ssllabs.com/ssltest) — web-based scanner for internet-facing HTTPS services. Shows a grade and detailed findings. Aim for A or A+.
• Wireshark — network capture tool. If you want to verify that a specific connection is actually encrypted and using the right cipher suite, capture and inspect the handshake.

Run testssl.sh or Qualys SSL Labs at least two weeks before your assessment. Finding a weak cipher suite or misconfigured TLS the day before assessment is avoidable.

Common Mistakes

Mistake 1: TLS 1.0 or 1.1 still enabled. Common on older servers, VoIP gateways, printers, and embedded systems that haven't been updated. A scan with testssl.sh will find it. Fix it before the assessment.

Mistake 2: Cipher suite configuration at the application level but not the OS level. An Nginx server might be configured for strong cipher suites, but if the underlying OS Schannel allows weak suites, other applications on the same server may negotiate weak connections. Configure at the OS level and verify at the application level.

Mistake 3: VPN with pre-shared key authentication. IKEv2 with PSK (pre-shared key) is weaker than certificate-based authentication. Move to certificate authentication for VPN — issue device certificates from your internal CA and use those for VPN authentication rather than a shared password.

Mistake 4: Forgotten services. The CUI file server is TLS-configured. But what about the backup agent communicating with the backup server? The monitoring agent phoning home to the SIEM? The database replication traffic? Run a network scan to find services you haven't thought about.

What Your Assessor Expects

For SC.L2-3.13.11, your assessor will: - Ask which services transmit CUI and how - Test TLS configuration on identified services (or review testssl.sh output if you provide it) - Review VPN configuration for FIPS-compliant algorithm selection - Ask to see the CMVP certificate number for your VPN's cryptographic module - Verify split tunneling is disabled - Review your email CUI transmission procedures

Evidence package: - TLS configuration for all CUI-transmitting services (screenshots or configuration exports) - VPN configuration documentation with algorithm selection - CMVP certificate numbers for cryptographic modules - VPN policy showing authentication requirements and session timeout - Email encryption policy or secure file transfer platform documentation

---

For the broader network security controls that surround encrypted traffic, see Network Configuration for CUI: The Controls That Matter. For key management underlying these encryption implementations, see PKI and Key Management for CMMC.

Got specific questions about CMMC? Our expert is available around the clock — no waiting, no sales pitch.

Got Questions? Ask our CMMC Expert →

Prefer email? Reach us at ix@isegrim-x.com