This post gives a practical, step-by-step implementation path to meet CMMC 2.0 / NIST SP 800-171 Rev.2 control AC.L2-3.1.13 (protecting Controlled Unclassified Information (CUI) during remote sessions using end-to-end encryption), with specific technical settings, small-business scenarios, and verification tips you can apply right away.
Why this matters: AC.L2-3.1.13 requires that remote access sessions that carry or expose CUI are encrypted end-to-end to prevent interception, manipulation, or disclosure. Failure to implement proper session encryption can lead to data exfiltration, supply-chain compromises, contract loss, penalties, and failure during a CMMC assessment. The goals are confidentiality, integrity, and auditability for all remote sessions involving CUI.
Implementation overview
Treat "end-to-end" as: strong session-layer encryption from the remote client to the service endpoint, authenticated endpoints, and cryptographic protections for any session recordings or intermediate hops (jump hosts). The main building blocks are: a validated PKI or trusted TLS certificates, accepted modern protocols (TLS 1.2/1.3, SSH protocol 2, IKEv2/IPsec), mututal authentication where feasible, client/device verification (MFA, device posture), per-session keys (Perfect Forward Secrecy), and robust logging and key lifecycle management.
Step-by-step implementation
1) Inventory and classify remote access paths
Start by inventorying all remote access flows that could handle CUI: RDP to servers, SSH to bastion hosts, Remote Support tools (TeamViewer, AnyDesk), VPN connections, browser-based admin consoles, and cloud management portals. For each flow record protocol, endpoints, whether a public internet hop exists, and who is authorized. Example for a small business: MSP remote support to bookkeeping workstation (CUI present) should be flagged and subject to stricter controls than a contractor’s read-only dashboard.
2) Select approved protocols and crypto parameters
Only allow modern, standards-based crypto: TLS 1.2 or 1.3 (prefer 1.3 where available), SSH protocol 2, and IKEv2/IPsec for VPN. Disable SSLv2/3/TLS1.0/TLS1.1. Require Perfect Forward Secrecy (PFS) ciphers: for TLS prefer ECDHE suites (e.g., TLS_AES_256_GCM_SHA384 for TLS 1.3 or ECDHE-RSA-AES256-GCM-SHA384 for TLS 1.2) and disable RC4, 3DES, and weak RSA key exchanges. For SSH use Ciphers aes256-ctr,aes192-ctr,aes128-ctr and KexAlgorithms curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256; set MACs to hmac-sha2-512,hmac-sha2-256. These selections satisfy cryptographic strength expectations for AC.L2-3.1.13.
3) Configure endpoints and access infrastructure (examples)
Linux SSH server example (sshd_config): enforce Protocol 2, Ciphers aes256-ctr,aes192-ctr,aes128-ctr, KexAlgorithms curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256, MACs hmac-sha2-512,hmac-sha2-256, PermitRootLogin no, and PasswordAuthentication no (use keys). For Windows RDP, require Network Level Authentication (NLA), publish RDP through an RD Gateway or RD Web Access using an organizational TLS certificate, and use group policy to enforce TLS 1.2 and restrict weak cipher suites. For VPNs prefer IKEv2 with AES-GCM and SHA2 HMAC; for TLS VPNs (OpenVPN) use TLS 1.2/1.3 with ECDHE and server-auth certs. For web management consoles, enforce HSTS, use server-side TLS 1.3, and disable HTTP fallback. If you must support remote support tools, use only enterprise editions that provide per-session encryption keys, audit logs, and session approval—avoid consumer versions.
4) Certificate management and key protection
Use an enterprise PKI or a vetted public CA for externally facing endpoints. Implement automated issuance/renewal (ACME or internal automation), maintain CRL and OCSP responders for revocation, and store private keys in a Hardware Security Module (HSM) or cloud KMS (AWS KMS, Azure Key Vault) for high-value servers. Rotate server certificates at least annually and keys when an incident or suspected compromise occurs. For client authentication consider certificate-based client TLS or SSH key pairs stored in smartcards or TPM-backed key stores to strengthen authentication and provide non-repudiation.
5) Session controls, multi-factor, logging, and session recording encryption
Enforce MFA for all remote sessions that can access CUI (e.g., Windows Hello for Business, smartcard, or TOTP). Implement access controls to restrict who can initiate sessions and require Just-In-Time (JIT) access or step-up authentication for privileged sessions. Capture detailed session logs: connection start/stop, user, source IP, certificate thumbprint, and session metadata. If recording sessions (for training/forensics), encrypt recordings at rest with AES-256-GCM and protect encryption keys via your KMS; include integrity checks and retain logs per contract and CUI retention requirements. Forward logs to a SIEM for real-time alerting and long-term retention to support assessments.
6) Test, validate, and document
Run active tests and scans: TLS scanners (Qualys SSL Labs or nmap --script ssl-enum-ciphers), SSH fingerprint audits, and VPN configuration checks. Conduct penetration tests or tabletop exercises that simulate interception or MitM attempts to validate end-to-end confidentiality. Document configurations (sshd_config, GPO settings, VPN profiles), certificate lifecycle procedures, and incident response steps tied to a remote-session compromise. For small businesses, include the MSP in these exercises if they access CUI; require proof of their cryptographic controls in your vendor assessment.
Practical small-business scenarios: (1) An accounting firm with remote bookkeepers — publish a single RD Gateway with a public certificate, require client certificates + MFA, and route all support through a logged and proxied jump host; (2) A manufacturer uses an MSP to update OT systems — require the MSP to use a bastion host with per-session ephemeral credentials, no direct RDP to controllers, and recorded sessions encrypted in your KMS; (3) A dev team uses SSH — enforce key-based auth stored in hardware tokens, restrict keys to repositories, and integrate with an enterprise SSO/bastion to centralize logging.
Compliance tips and best practices: maintain a written mapping that ties each remote-access flow to AC.L2-3.1.13 evidence (configs, certs, logs), use central configuration management (Ansible, SCCM) to enforce crypto settings, disable split-tunneling on VPNs that carry CUI, include certificate checks in your monitoring (alert on expiring certs and unexpected thumbprints), and require vendors to operate under a secure remote access policy that mirrors your controls. Plan for continuous monitoring because cryptographic standards evolve — schedule annual reviews of cipher suites and key lengths.
Summary: To meet AC.L2-3.1.13 you must design remote access so that CUI is protected by strong, end-to-end cryptography, authenticated endpoints, controlled access, and auditable logging. Follow the steps above: inventory access paths, choose modern protocols and robust cipher suites, configure endpoints and gateways correctly, protect and rotate keys, enforce MFA and session controls, and test and document everything. For small businesses, prioritize a single hardened access gateway, strict vendor controls, and automated certificate/key management to reduce risk and make assessments straightforward.
