CMMC Level 2 Practice 3.1.13: Employ cryptographic mechanisms to protect the confidentiality of remote access sessions

CMMC Level 2 Practice 3.1.13 requires you to encrypt remote access sessions so session contents cannot be read or altered in transit. Operationally, you must standardize approved remote access methods (VPN, TLS-based gateways, SSH), block insecure protocols, enforce strong crypto configurations, and retain evidence (configs, logs, and exceptions) that proves remote sessions into the CUI environment are always protected. ¹

Key takeaways:

• Treat this as a “no cleartext remote administration” rule for anything that can reach CUI systems. ¹
• Standardize approved tools and configurations, then technically block everything else (not just policy). ¹
• Auditors will look for proof: configs, enforcement points, and logs showing encrypted sessions in real operation. ²

The fastest way to operationalize the cmmc level 2 practice 3.1.13: employ cryptographic mechanisms to protect the confidentiality of remote access sessions requirement is to define what “remote access” means in your environment, list the only approved ways to do it, and then enforce encryption at the tool and network layers. This practice is mapped to NIST SP 800-171 Rev. 2 control 3.1.13, so assessors will expect you to show that remote sessions used for administration and user access are protected by cryptography end-to-end, not “encrypted somewhere in the path.” ¹

For most defense contractors handling CUI, the operational scope includes: remote workforce access to corporate networks, vendor/third-party support sessions, administrator access to servers and cloud consoles, and remote access into enclaves or segmented networks that store or process CUI. The hard part is rarely choosing a tool; it’s eliminating exceptions (legacy protocols, ad-hoc screen sharing, “temporary” firewall rules) and producing evidence that the encryption requirement is continuously met.

This page gives you a requirement-level implementation guide: what the requirement means, who it applies to, exactly what to configure and block, what evidence to keep, and how to structure ownership and ongoing control health checks aligned to CMMC expectations. ²

Regulatory text

Excerpt (mapped requirement): “CMMC Level 2 practice mapped to NIST SP 800-171 Rev. 2 requirement 3.1.13 (Employ cryptographic mechanisms to protect the confidentiality of remote access sessions).” ¹

Operator meaning: any remote access session that could expose CUI (or provide a path to systems that store/process/transmit CUI) must use cryptography that protects confidentiality in transit. In practice, that means your approved remote access methods must be encrypted (for example, VPN with strong encryption, TLS-based remote access portals, SSH for administration), and you must prevent users and admins from using insecure or weakly protected alternatives. ¹

Where this sits in CMMC: CMMC Level 2 aligns to NIST SP 800-171 requirements for protecting CUI in non-federal systems. You should plan to demonstrate implementation and ongoing operation during assessment under the CMMC Program. ^{3 2}

Plain-English interpretation

You must ensure that remote sessions are encrypted so eavesdroppers cannot read the session (credentials, commands, files, application data, screen contents). “Remote access” includes more than VPN. It includes:

• Admin protocols (SSH, RDP, WinRM, VNC, remote database admin tools)
• Web-based admin consoles and portals (HTTPS/TLS)
• Remote support tools and “screen share” products
• Cloud admin access paths if they administer CUI environments (browser to cloud console)
• API-based remote administration where applicable (TLS)

If the session crosses an untrusted network (internet, home ISP, hotel Wi‑Fi, cellular), or crosses internal segments where interception is plausible, encrypt it and be able to prove it.

Who it applies to

Entities: defense contractors and other federal contractors that handle CUI and are pursuing or maintaining CMMC Level 2 compliance. ^{3 2}

Operational context (systems/people):

• Employees connecting remotely to corporate or enclave environments that access CUI
• Administrators managing servers, endpoints, firewalls, hypervisors, identity systems, and CUI applications
• Third parties providing IT support, managed services, incident response, or application support with remote connectivity
• Cloud and SaaS administrators operating the CUI boundary or enclave

Scoping tip for assessors: tie scope to your CUI data flow and boundary. If a remote session can reach the CUI boundary, it belongs in scope for 3.1.13, even if the user claims they “weren’t working on CUI today.”

What you actually need to do (step-by-step)

1) Define and publish the approved remote access methods

Create an “Approved Remote Access Standard” that lists:

• Approved tools (by name) for user access and for admin access
• Approved protocols (for example, IKEv2/IPsec, TLS 1.2+ where applicable, SSH)
• Prohibited protocols and conditions (for example, Telnet, FTP, HTTP admin pages; and any remote admin without encryption)
• Where each method is allowed (CUI enclave vs. corporate network vs. break-glass)

Keep this document short enough that engineers will follow it.

2) Enforce encryption in the remote access tooling

Implement technical enforcement for each access path:

VPN (user access):

• Require VPN for remote access into internal networks that host CUI systems.
• Configure strong encryption and disable weak options in your VPN stack.
• Enforce MFA and device posture where feasible (MFA also maps cleanly to broader access controls, even if 3.1.13 is about encryption).

TLS-based access (portals, ZTNA, web consoles):

• Ensure admin portals and apps use HTTPS only.
• Disable plaintext HTTP and weak TLS settings.
• Use valid certificates and centralized certificate management.

Admin access (SSH/RDP and management planes):

• Require SSH for Linux/Unix administration; disable Telnet.
• For Windows administration, require RDP with network-level protections and restrict where RDP can originate (for example, only from a jump host / bastion).
• Put administrative access behind a hardened bastion host with session logging where possible.

Remote support tools:

• Approve a short list; block all others.
• Require session encryption and enforce enterprise settings (no “personal account” usage for support access into CUI environments).

3) Block non-compliant remote access at the network and endpoint layers

Policy does not satisfy assessors if the network still permits cleartext admin traffic.

Minimum enforcement points:

• Firewall rules: deny inbound/outbound known insecure management ports/protocols.
• Web gateways / reverse proxies: redirect or block HTTP where HTTPS is required.
• Endpoint controls: block unauthorized remote control software and scripts that open tunnels.
• Conditional access: restrict admin consoles to trusted devices and networks.

4) Handle third-party access explicitly

Third parties frequently become the “exception channel.”

Set requirements for third parties:

• They must use your approved remote access path (your VPN, your bastion, your support tool).
• No direct access from their environment to your internal assets unless it’s documented, approved, and monitored.
• Time-bound access with approval and logging.

This connects naturally to third-party risk management: remote access is a high-impact integration point even when the third party is “just support.”

5) Create a control card (owner, triggers, run steps, exceptions)

Make the requirement auditable and repeatable:

• Control objective: remote access sessions are cryptographically protected.
• Owner: typically IT Security or Identity/Network Engineering; compliance owns oversight.
• Trigger events: new remote access tool, new site-to-site connection, new third party, major VPN/TLS changes.
• Operating cadence: ongoing enforcement plus periodic review.
• Exceptions: documented, time-bound, risk-accepted, with compensating controls.

Daydream is useful here as a system of record for the control card, exception workflow, and evidence bundle mapping, so audits don’t devolve into screenshot hunts. ²

6) Run recurring control health checks

Operational checks you can schedule:

• Confirm insecure protocols are blocked (sample testing and config review).
• Review remote access logs for non-approved tools/protocols.
• Validate certificate/TLS configuration drift for remote access portals.
• Confirm third-party access lists are current and tied to tickets/approvals.

Required evidence and artifacts to retain

Keep evidence that proves (1) design, (2) enforcement, and (3) operation:

Design artifacts

• Approved Remote Access Standard (tools/protocols/prohibitions)
• Network/security architecture diagram showing remote access paths into the CUI boundary
• Data flow or boundary statement tying remote access to CUI scope ³

Enforcement artifacts (technical)

• VPN configuration exports or screenshots showing encryption settings and allowed protocols
• Bastion/jump host configuration and access control settings
• Firewall rule excerpts showing blocks for insecure remote management
• Endpoint management policies blocking unauthorized remote tools
• TLS configuration evidence for portals (configs, security headers, certificate details)

Operational artifacts (proof it runs)

• Remote access logs (VPN auth logs, bastion logs, RDP/SSH logs where collected)
• Ticket/approval records for provisioning remote access (especially admins and third parties)
• Exception register with approvals, expiration dates, and compensating controls
• Periodic control health check results and remediation tracking to closure

Retention location matters. Store evidence in a controlled repository with access control and a clear naming convention by control and period. ²

Common exam/audit questions and hangups

Assessors and customer diligence teams tend to probe:

• “Show me the approved remote access methods and how you block everything else.” ¹
• “How do admins access servers that store or process CUI? Walk me through the path.”
• “Do third parties ever remote in? Show the technical path and logs.”
• “Is RDP exposed anywhere? If it exists, is it restricted to a bastion and encrypted?”
• “Do you allow split tunneling on VPN? If yes, what’s the risk decision and compensating control?”

Hangups you can preempt:

• Shadow IT remote support tools installed by power users
• Legacy devices that require weak protocols
• “Temporary” firewall changes that became permanent
• Cloud consoles accessed from unmanaged devices

Frequent implementation mistakes and how to avoid them

1. Relying on policy while the network still permits insecure access.
   Fix: enforce deny rules and application controls; test from an external network.

2. Assuming “we use VPN” covers all remote access.
   Fix: inventory all remote administration channels (RDP, SSH, web admin, remote support, cloud consoles) and tie each to an approved encrypted method.

3. Allowing third parties to connect directly to internal systems.
   Fix: route third-party access through your controlled entry points (VPN/bastion/managed support tool) with time-bound approvals.

4. Weak TLS settings on internal admin portals.
   Fix: standardize TLS configurations, manage certificates centrally, and monitor for drift.

5. No owner and no operating cadence.
   Fix: assign an accountable owner, document trigger events, and run periodic health checks with tracked remediation. ³

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this specific practice, so this page does not cite case outcomes.

Operational risk is straightforward: remote sessions often carry credentials and privileged commands. If sessions are unencrypted or weakly protected, interception can lead to credential theft, lateral movement into the CUI boundary, and loss of CUI confidentiality. Under the CMMC Program, you should expect to demonstrate consistent implementation aligned to NIST SP 800-171 requirements during assessment. ^{3 2 1}

Practical 30/60/90-day execution plan

First 30 days (stabilize scope and block obvious gaps)

• Confirm CUI boundary and list all remote access paths that can reach it.
• Publish the approved remote access standard (tools and prohibited protocols).
• Implement quick wins: block cleartext protocols at firewalls, disable HTTP admin endpoints, remove/ban unauthorized remote tools.
• Stand up the control card: owner, triggers, exceptions, and evidence bundle.

Days 31–60 (standardize and instrument)

• Consolidate remote access into a small set of approved solutions (VPN + bastion + approved support tool).
• Add logging and central collection for VPN and bastion sessions.
• Build third-party remote access procedures: onboarding, approvals, time-bounds, and offboarding.
• Document configurations and capture baseline evidence for assessment.

Days 61–90 (prove sustained operation)

• Run a control health check cycle and close findings with change records.
• Validate encryption posture for TLS endpoints and admin channels (config review plus practical testing).
• Operationalize exception management with expirations and review.
• Prepare an assessor-ready walkthrough: “user remote access,” “admin remote access,” and “third-party remote access,” each with configs and logs.

Frequently Asked Questions

Does VPN satisfy CMMC Level 2 Practice 3.1.13 by itself?

Only for traffic that actually goes through the VPN. You still need to address other remote access paths like admin portals, remote support tools, and direct RDP/SSH exposure. ¹

Are SSH and HTTPS considered “cryptographic mechanisms” for this requirement?

Yes, when properly configured, SSH and TLS (HTTPS) are common cryptographic mechanisms that protect session confidentiality. The assessor focus is that encryption is enforced and weak or plaintext alternatives are blocked. ¹

What about RDP for Windows administration?

RDP can be part of a compliant design if you restrict it tightly (for example, only via a bastion/jump host) and keep it off the public internet. You must be able to show the protected access path and supporting configurations/logs. ¹

Do third-party support sessions fall under this requirement?

Yes, if a third party remotely accesses your environment in a way that could expose CUI or provide a path to CUI systems. Route them through approved encrypted methods and retain logs and approvals. ¹

How do we prove compliance to an assessor without flooding them with screenshots?

Build a minimum evidence bundle: one approved standard, key configurations for each remote access method, and representative logs showing encrypted remote sessions in operation. Keep it organized by control and date so you can produce it quickly. ²

We have a legacy system that only supports weak remote access. What’s the least-bad approach?

Put it behind a controlled jump host or gateway that enforces encryption on the remote leg, restrict access to a small admin group, and document a time-bound exception with a modernization plan. Keep compensating control evidence and the exception approval. ²

Footnotes

1. NIST SP 800-171 Rev. 2

2. DoD CMMC Program Guidance

3. 32 CFR Part 170