This practice is more straightforward than AC.L2-3.1.12, but it still catches contractors because they assume encryption is automatic and never verify it. If someone connects to your VPN, is the tunnel actually encrypted? What cipher are they using? Can they downgrade to an unencrypted connection if they want? The assessor will ask these questions in different ways. The goal is to confirm that cryptography is not optional for your remote access. This practice supports SC.L2-3.13.8 (information in transit protection) and SC.L2-3.13.9 (cryptographic mechanisms).
Most contractors handle this reasonably well because modern VPN solutions, RDP gateways, and cloud access platforms encrypt by default. The gap is usually in older or misconfigured systems, or in not being able to articulate what’s actually happening. You need to know your encryption protocols and be able to show them.
What the assessor is actually evaluating
The assessor wants to see that you’ve thought about confidentiality and integrity during remote access, going beyond just authentication and authorization. They’ll ask which encryption protocols you use, which ones are disabled, and why you chose those settings. They’re checking that the choice was deliberate, not accidental.
The specific check is usually: “Can you show me the encryption settings for your VPN or remote access solution?” This is where a lot of contractors freeze. They’ve never looked at the crypto settings. Or they’ve never confirmed that weak ciphers are disabled. Or they think “it’s TLS, so it’s fine” without knowing which TLS version is actually in use.
If you’re using a modern solution (Cisco Meraki, Fortinet, cloud-based remote access), encryption is almost certainly enabled and reasonably configured out of the box. The assessor’s job is to confirm that you know what’s in place and why.
What a realistic SSP definition looks like
[Organization Name] employs cryptographic mechanisms to protect the confidentiality and integrity of all remote access sessions. The organization's VPN solution uses IPSec encryption with AES-256 for VPN tunnels. Remote Desktop Protocol connections are encrypted using TLS 1.2 or higher with at least 128-bit encryption. Web-based access to CUI systems requires HTTPS with TLS 1.2 or higher.
Weak ciphers (less than 128-bit) and insecure protocols (SSL 3.0, early TLS versions) are disabled on all remote access systems. Certificates used for TLS encryption are issued by the organization's internal certificate authority or a recognized public certification authority and are valid and appropriately configured with key lengths of at least 2048 bits (RSA) or equivalent strength.
The CIO conducts a semiannual review of remote access encryption settings to ensure they remain current with industry standards.
Notice the specificity: “AES-256 for VPN,” “TLS 1.2 or higher,” “128-bit encryption.” These are concrete, verifiable statements. The assessor can ask for evidence of each one. Also notice the certificate language: “2048 bits (RSA) or equivalent strength.” That’s the NIST language, and the assessor recognizes it.
The semiannual review is important. Encryption standards change. TLS 1.2 is solid now, but in five years it might not be. The SSP should acknowledge that encryption settings need periodic review.
How to present your evidence
- VPN configuration showing encryption protocol and cipher selection
- RDP Gateway or remote access solution settings showing TLS version and encryption
- Certificate details showing key length and validity (at least 2048-bit RSA)
- Disabled protocol list or hardening guide showing weak ciphers are removed
- Evidence of periodic review of encryption settings (dated audit record)
- Network trace or scanner output showing active sessions use strong encryption
Have these ready:
VPN configuration documentation. Pull up the actual VPN settings showing the encryption protocol. If it’s IPSec, show the encryption domain and algorithm. If it’s SSL/TLS, show the certificate binding and the protocol version. A screenshot of the VPN gateway administration interface is perfect.
Certificate details. The assessor might ask about the certificate used for TLS encryption. You don’t need to present the private key, but you should be able to show the public cert with its key length, issuer, and expiration date. “openssl x509 -in cert.pem -text -noout” or the Windows cert viewer will do. The key length should be at least 2048 bits for RSA.
Cipher and protocol configuration. If you’ve explicitly disabled weak protocols, show that configuration. It could be a screenshot from your VPN gateway showing which SSL/TLS versions are enabled. On Windows, it could be a registry check showing TLS 1.2 is enforced. The point is showing that you’ve thought about this beyond just accepting defaults.
Test or scan evidence. If you’ve done a TLS scan or security assessment confirming your remote access uses strong encryption, that’s good supporting evidence. Tools like nmap or specialized TLS scanners can confirm what protocols and ciphers are actually active.
Review documentation. If you’ve done a periodic review of encryption settings, include that record. Even a simple dated email saying “reviewed VPN encryption settings, confirmed AES-256 is in use, no weak protocols enabled” is sufficient.
Keep answers short. Show the evidence, don't describe it. Let the assessor drive. For more on how to present in the assessment room, see How to Present Evidence in the Assessment Room.
Common failures
"We use VPN so it's encrypted." Some VPN solutions can be configured with weak or no encryption. The assessor will ask specifically which encryption standard and which cipher. If you can't answer, that's a finding. Know your settings.
Old TLS versions enabled for backwards compatibility. "We support TLS 1.0 because some of our legacy systems need it." That's a problem if legacy systems are touching CUI. Upgrade the legacy systems or isolate them. TLS 1.0 is indefensible in 2026.
No certificate validation on the client side. RDP or VPN clients are configured to "ignore certificate warnings" or "accept any certificate." That eliminates the integrity protection and opens the door to man-in-the-middle attacks. Fix this. Make certificate validation mandatory.
Self-signed certificates with weak key length. 1024-bit RSA or smaller keys on a self-signed cert. The assessor will ask why and will be skeptical of the answer. Use 2048-bit minimum.
No evidence that encryption is actually active. The SSP says you use encryption, but you can't show logs or a test proving it. Be prepared to demonstrate an active session using the configured encryption, or show a protocol analyzer confirming encrypted traffic.
Clear, specific encryption protocols in your SSP. Screenshots showing those protocols are actually configured in your VPN, RDP gateway, or other remote access tools. A valid certificate with reasonable key length. Disabled weak protocols. Ideally, evidence that you've tested or verified the encryption is actually being used. This practice is straightforward when you've done your homework upfront.
Short, practical breakdowns of what assessors actually ask and how to answer. No compliance jargon, no sales pitch. Subscribe free on Substack.
If you use an MSP/MSSP
Your MSP or MSSP typically manages the remote access infrastructure and encryption settings. Your responsibility is to ensure the policy is defined and the settings are appropriate.
What’s on you (the contractor):
- Defining encryption requirements in your SSP (TLS version, cipher strength, certificate validity)
- Approving or requesting any changes to encryption settings
- Periodically verifying that encryption settings remain current
What’s on the MSP:
- Configuring encryption on the VPN, RDP gateway, and other remote access systems
- Maintaining certificates and ensuring they don’t expire
- Keeping encryption settings current with industry standards
- Providing evidence of the configured encryption (screenshots, test results)
The assessor will ask you (the contractor) “what encryption standards do you require?” You should be able to answer without looking at your MSP. Then the assessor will ask your MSP to show the actual configuration. If there’s a mismatch (you said TLS 1.2, they configured TLS 1.0), that’s a problem. Prevent this before the assessment with a quick verification call.
Assessors test encryption by checking your system configuration and asking you to explain what happens when someone connects remotely. You should know your TLS versions, cipher suites, and certificate validity period off the top of your head. Have screenshots of your remote access system configurations showing encryption is enforced. Be able to walk the assessor through a hypothetical remote session and describe what encryption protects the data in transit.
Send your MSP the encryption requirements from your SSP and ask them to confirm compliance two weeks before the assessment. Don't assume defaults are good enough. Have them show you screenshots of the VPN gateway, RDP configuration, and certificate details. If they're using weak ciphers or old protocols, fix it before the assessment room. The assessor will definitely check this practice, and it's an easy one to get wrong through inattention rather than incompetence.
This page covers AC.L2-3.1.13 from NIST SP 800-171 Rev 2 (3.1.13). The guidance here is based on experience in real CMMC assessments and is intended to help you prepare. It is not legal or compliance advice. Your organization’s situation is unique, and you should work with qualified professionals for formal assessment preparation.