1Overview
AC.L2-3.1.13 requires that remote access sessions be protected with cryptography, so that the traffic between a remote user and the environment cannot be read as it crosses the networks in between. It is the confidentiality half of remote access, following directly from the control and monitoring established in 3.1.12: once remote access is confined to an approved path, this control requires that the path be encrypted.
The reasoning is that remote access traverses networks the organization does not own, home connections, coffee-shop wireless, hotel networks, the open internet, any of which may be observed. Without encryption, credentials and CUI moving across that distance are exposed to anyone positioned to watch the traffic. The control is usually satisfied by the same mechanism that provides the approved remote path, a properly configured VPN or an encrypted remote gateway, because a modern remote access solution encrypts by default. The work is confirming that the encryption is genuinely in force, is strong, and covers every remote path, rather than assuming it because a VPN is present.
Employ cryptographic mechanisms to protect the confidentiality of remote access sessions.
The requirement names cryptographic mechanisms and the confidentiality of the session, which together mean that the remote connection is encrypted end to end across the untrusted networks it crosses. For an environment that handles CUI, the strength of that cryptography matters, and this control connects closely to the FIPS-validated cryptography requirement at 3.13.11, since encryption protecting CUI is expected to use validated mechanisms. A remote path that is encrypted with a weak or non-validated method may satisfy the letter of this control while failing the cryptographic requirements elsewhere in the framework.
2The Assessment Objectives
NIST SP 800-171A decomposes 3.1.13 into two objectives: the cryptographic mechanism is identified, and it is implemented on the remote access paths.
Cryptographic mechanisms to protect the confidentiality of remote access sessions are identified. The organization has determined the cryptography that will protect its remote sessions.
Cryptographic mechanisms to protect the confidentiality of remote access sessions are implemented. The identified cryptography is in force on the remote access paths.
The two objectives separate identification from implementation: the organization identifies the cryptographic mechanism, then confirms it is actually protecting the sessions. Satisfaction turns on verifying the encryption is real and strong across every remote path, since the presence of a VPN does not by itself prove that its encryption is enabled, current, and applied everywhere.
3Failure Patterns
The failures are about remote paths that are not actually encrypted, encryption that is weaker than the CUI warrants, and paths that were never brought under the encrypted method at all.
The unencrypted remote path
A remote access tool that carries traffic in the clear, or a legacy protocol used for remote administration without a secure tunnel, exposes the session directly. This is the plain failure of the control, and it usually appears not as a missing VPN but as a secondary remote path, a management interface, a legacy tool, that was never routed through the encrypted method.
Weak or outdated cryptography
A VPN configured years ago may still permit outdated protocols or weak ciphers that are no longer adequate, so the session is encrypted in name but not in strength. For CUI, the cryptography is expected to be strong and validated, and a remote path using a deprecated cipher suite fails to meet that standard even though it is technically encrypted.
The non-validated mechanism
Because this control pairs with the FIPS-validated cryptography requirement, a remote path protected by encryption that is not validated can satisfy the appearance of confidentiality while failing the validation standard the framework applies to CUI. The encryption has to be both strong and, where CUI is in play, of a validated kind.
The forgotten secondary path
The main VPN may be encrypted correctly while a vendor's remote tool, a cloud administration console, or a backup remote method carries sessions outside it. As with the control-and-monitor requirement, the gap is usually the path that was not consolidated onto the approved encrypted method.
4Ownership
This is an IT-owned technical control, closely tied to the remote access method itself, whose main demand is verifying encryption strength and coverage rather than merely deploying a VPN.
| Role | Responsibility for this control |
|---|---|
| IT and network lead | Configures and verifies strong, validated encryption on the remote access method, confirms it covers every remote path, and removes weak protocols and ciphers. Owns the configuration evidence. |
| Security or compliance lead | Confirms the cryptography meets the strength and validation expectations that apply to CUI, connecting this control to the FIPS-validated cryptography requirement. |
| Vendor and contract managers | Ensure third-party remote access uses the organization's encrypted path rather than an unverified vendor method. |
| Program lead | Includes remote encryption in periodic review, since ciphers age and new remote paths appear, and retains the configuration records. |
5Tooling
The control is delivered by the encryption built into the remote access method, and the work is verifying that encryption is strong, validated, and universal across remote paths.
| Objective | Tooling | What it provides |
|---|---|---|
| [b] primary path | VPN or encrypted remote gateway with strong protocol configuration | The encrypted tunnel that protects the confidentiality of remote sessions, configured to use current, strong protocols and ciphers. |
| [a] validation | FIPS-validated cryptographic modules and cipher configuration | Encryption of a validated kind where CUI is protected, aligning this control with the framework's cryptographic validation requirement. |
| [b] coverage | Consolidation of remote paths, secure management protocols | Bringing secondary and management remote paths onto the encrypted method and replacing legacy clear-text protocols with secure equivalents. |
| Verification | Configuration review, cipher and protocol scanning | Confirming the negotiated encryption is strong and validated in practice, not merely available, across every remote path. |
The caveat is that presence is not proof. A VPN can be deployed and still negotiate a weak cipher, permit an outdated protocol, or leave a secondary path unencrypted, so the control is verified by examining the encryption actually in force rather than by the existence of the tool. The assessor confirms the objective by reviewing the remote access encryption configuration and, where relevant, the validation of the cryptographic mechanism.
6Evidence
The satisfied version of 3.1.13 shows the cryptographic mechanism identified, in force, strong, and covering every remote path.
| Evidence | What it demonstrates |
|---|---|
| Remote access encryption configuration | Objective [b]. The protocol and cipher settings on the VPN or gateway showing strong encryption in force. |
| Cryptographic validation record | Objective [a]. Evidence the cryptography is validated where CUI is protected, tied to the FIPS requirement. |
| Remote path inventory | Objective [a]. The set of remote access paths, showing each is covered by the encrypted method. |
| Cipher and protocol verification | Objective [b]. Scan or review output confirming weak protocols are disabled and strong ones enforced. |
| Vendor remote encryption | Objective [b]. Confirmation that third-party remote access uses the encrypted path. |
The evidence should demonstrate the encryption actually negotiated rather than merely configured, because a permitted weak cipher can undercut an otherwise sound setup, and it should account for every remote path including vendor and management access. Configuration and verification together, showing strong validated encryption enforced everywhere remote access occurs, are the clearest demonstration of the control.
A VPN is not proof of strong encryption
The presence of a VPN is easy to show; confirming it negotiates strong, validated encryption on every remote path, with no weak cipher left enabled and no vendor tool outside the tunnel, takes a closer look. Verifying the cryptography actually in force across remote access is part of the onsite readiness work this practice does.
Start CMMC Readiness or call 802-335-26627Sources
- NIST Special Publication 800-171 Rev 2, Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations, requirement 3.1.13. csrc.nist.gov
- NIST Special Publication 800-171A, Assessing Security Requirements for Controlled Unclassified Information, assessment objectives 3.1.13[a] and 3.1.13[b]. csrc.nist.gov
- 32 CFR 170.21, Plan of Action and Milestones Requirements, governing which requirements may remain open at a Level 2 assessment. ecfr.gov