AC.L2-3.1.13 Remote access confidentiality: requirements

What AC.L2-3.1.13 requires and why it cannot be deferred

If your remote access path can reach CUI, AC.L2-3.1.13 asks you to employ cryptographic mechanisms that protect the confidentiality of those remote access sessions. It is the Level 2 version of requirement 3.1.13 in NIST SP 800-171 Rev. 2, and the assessment objectives in NIST SP 800-171A break it into two parts: identifying the cryptographic mechanisms in use and implementing them so they actually protect the sessions. The Level 2 Assessment Guide also ties this cryptography to SC.L2-3.13.11, so the mechanisms you choose must be FIPS-validated. Your organization owns the control. An assessor, not your implementation partner, decides whether it is MET.

The reason this requirement cannot be deferred is its weight. Under the CMMC scoring methodology in 32 CFR 170.24, AC.L2-3.1.13 is worth 5 points, and 32 CFR 170.21 does not allow requirements of more than 1 point on a plan of action and milestones. It must be MET to reach Conditional or Final Level 2 status. Confirm the current status of the CMMC phases with your contracting officer and the DoW CIO's About CMMC page before you plan a date, because the schedule has changed and the scoring rules have not.

The difficulty is usually not the cipher. It is finding every remote path. Legacy VPN concentrators, vendor support tools, hosted administration consoles and jump hosts often sit outside the asset inventory because someone set them up for a single project. Start by listing every route into the CUI boundary, including what your managed service providers use, then record the mechanism and its configuration for each one. A path you cannot enumerate cannot be shown to be encrypted, and an assessor will test the paths you missed.

Which remote sessions fall under AC.L2-3.1.13

AC.L2-3.1.13 applies to every remote session that carries CUI, not only the sessions a team thinks of as VPN logins. The cards below cover the scoping decisions that change how much cryptography must be proven, and the questions to settle before an assessor asks.

Staff VPN and gateway access

Employees who reach CUI systems from home or travel usually connect through a VPN concentrator or access gateway. Every such tunnel is a remote session in scope for AC.L2-3.1.13. Confirm which gateway terminates these sessions, which protocol and cipher suites it negotiates, and whether the FIPS-validated cryptographic module that SC.L2-3.13.11 requires is the one actually doing the encryption. A gateway that is not inside the assessed boundary still needs its cryptography documented.

Administrator remote sessions

Administrators who manage servers holding CUI often connect from management workstations, jump hosts or bastion systems. These sessions carry the most sensitive commands and credentials, so assessors look at them closely. List every administrative entry point, the protocol used for each, and the configuration evidence that shows encryption is enabled and cannot be silently downgraded.

Remote desktop and SSH into hosted infrastructure

Remote desktop and SSH sessions into cloud or data center servers are often set up for convenience and forgotten during scoping. Each one that displays or transfers CUI, or that lets a user reach a system holding CUI, belongs in the inventory. Ask whether the session is tunneled through an encrypted channel, whether legacy unencrypted protocols remain enabled, and whether the host's configuration settings are captured as assessment evidence.

Third-party vendor and support sessions

Vendors who troubleshoot a platform, apply patches or run managed services often reach in through their own remote support tools. The key scoping question is whether that session crosses the assessed boundary and whether the vendor's tool uses FIPS-validated cryptography for CUI in transit. Document who initiates the session, who approves it, and how the session is recorded. Where the vendor cannot show validated cryptography, the session must be redesigned or removed.

Cloud and hosted service access

Users who open CUI in hosted collaboration tools, cloud file stores or hosted applications are running remote sessions even when no VPN is involved. The provider's transport encryption and the organization's own client settings both matter. Confirm which parts of the session the organization controls, what the provider documents about its cryptographic modules, and how the organization gathers that documentation for the assessment.

Remote sessions inside the boundary

Connections that look internal can still be remote when a user reaches the network from outside the office or from a different segment. Systems that relay sessions between enclaves, reverse proxies and remote monitoring agents all change how sessions are protected. Map each relay and proxy in the data flow, note whether it terminates encryption, and decide which device holds the keys. This mapping feeds directly into the system security plan.

How FIPS-validated cryptography applies to remote sessions

AC.L2-3.1.13 asks for cryptographic mechanisms that protect the confidentiality of remote access sessions, and the CMMC Assessment Guide Level 2 ties that cryptography to SC.L2-3.13.11. Because the encryption protects CUI in transit, it must meet the FIPS-validated criteria of SC.L2-3.13.11. In practice, that means the assessor will not accept an encrypted session on its own. The organization must show that the cryptographic module doing the work is FIPS-validated and that it is running in its validated mode. A protocol choice alone does not establish FIPS validation, whether the session uses TLS, SSH or an IPsec VPN.

Start by inventorying every component that terminates or initiates a remote session: VPN concentrators, remote desktop gateways, bastion hosts, SSH clients and servers, and web portals serving CUI. For each one, record the cryptographic library or module it calls, the exact software version, and the validation certificate that covers that version and its platform. Validation attaches to a specific module version on a specific operating environment, so a certificate for an older release or a different platform does not carry over. Confirm the status with the module vendor and against the NIST validation listing for your exact version, and keep the certificate number in the System Security Plan. Note that a validation status can change, so the check needs to be repeated, not filed once.

Then verify that the validated mode is enabled in the configuration, not only that the protocol is in use. Many products negotiate TLS or SSH while still allowing non-validated algorithms or a fallback library. Look for an explicit FIPS mode setting or a FIPS-only cipher and algorithm policy, and confirm it is active on the running system. Assessors typically compare the configuration files and the running settings against the cryptographic documentation and may test the session directly, so the captured configuration, the version output and the test results must match what is deployed. If a component cannot run in a validated mode, it cannot protect CUI in that path, and the remote access design has to change before the requirement can be MET.

How an assessor tests AC.L2-3.1.13

This table maps each assessment object an assessor may examine for AC.L2-3.1.13 to the test approach, the evidence requested and the findings that most often stop a requirement from being MET. Read it as a checklist: every row should have matching documentation and a live configuration you can show before the assessment begins.

Assessment object	How the assessor tests it	Evidence requested	Common findings
Remote access procedures	Reads the procedures and interviews administrators to confirm the documented remote paths match how staff actually connect	Remote access procedure, list of approved remote access methods, approval records for each path	Undocumented remote path such as a vendor tunnel or a legacy VPN left enabled after a migration
Cryptographic mechanism documentation	Checks that each mechanism protecting remote sessions is named, scoped and tied to the CUI boundary	Cryptographic inventory listing protocol, version, cipher suites and the systems each session reaches	Inventory covers the VPN concentrator but not the jump host or the web-based administration console
Cryptographic module validation	Confirms the modules used for remote sessions are FIPS-validated, as SC.L2-3.13.11 requires for CUI protection	Module validation certificate references, and the configured FIPS-validated mode for each component	Validated mode is not enabled, or the product is only FIPS-compatible without a validation covering the deployed version
Configuration settings	Compares live settings with the documented configuration, often by reviewing exported config files	Exported configuration showing protocol versions, cipher and key settings, and disabled weak options	Legacy protocol versions or weak ciphers remain available as fallbacks even though the policy forbids them
Audit records	Samples session logs and confirms encrypted sessions are recorded with the protocol in use	Remote session logs, gateway logs and change records for cryptographic settings	Logs do not record the negotiated protocol, so the assessor cannot confirm encryption for past sessions
Live remote sessions	Initiates or observes a remote session and inspects the negotiated protection during the session	Demonstration of an active session with the protocol and cipher displayed, and the approved mode in use	Session negotiates an unvalidated cipher or falls back to an older protocol under certain client settings
Interaction with configuration changes	Asks how changes to remote access components are tested and approved before they reach production	Change tickets for cryptographic updates and evidence of post-change verification	Gateway upgrades reset the FIPS setting and nobody rechecks it until the next assessment

How to implement encrypted remote access step by step

This sequence takes an organization from an unknown set of remote paths to a documented, tested and logged configuration in which every remote session that carries CUI uses FIPS-validated cryptography. Each step produces an artifact that an assessor can trace back to AC.L2-3.1.13.

Inventory every remote access path
List every way a person, process or vendor can reach a system that stores, processes or transmits CUI from outside the assessed boundary. Include VPN concentrators, remote desktop and SSH gateways, administrative consoles, web portals, cloud management planes and vendor support tunnels. The output is a remote access inventory that names each path, its owner, the systems it reaches and the protocol it uses. Confirm the inventory with network and identity teams, because undocumented paths are a common gap found during assessment preparation.
Confirm FIPS-validated cryptographic modules
For each path, identify the cryptographic module that performs the encryption and check whether it is FIPS-validated and whether the validation covers the version and configuration in use. The governing criteria for this cryptography come from SC.L2-3.13.11, so the module is a requirement in its own right, not a preference. Record the module name, version, validation reference and the vendor's statement of how to run it in approved mode. Where a vendor cannot show validation for the deployed version, treat the path as open until the gap is resolved. Ask the vendor to confirm this in writing.
Configure validated mode on each gateway
Enable the approved or validated mode on each remote access service and disable protocol versions, cipher suites and key exchange methods that the module does not approve. The person doing this is usually the platform or network engineer, with the security team reviewing the settings. The output is a configuration baseline per gateway that lists the enforced protocols, ciphers, certificate requirements and any fallback behavior. Keep these settings in version control so changes are visible and reviewable.
Restrict access to approved gateways
Confirm that remote sessions can reach CUI systems only through the defined gateways, and that firewall rules block direct connections from outside networks to internal CUI hosts. In a self-hosted environment, OPNsense rules can pass or block traffic by source, destination, port and protocol, and aliases can group the approved gateways and administrator networks. The output is a rule set export and a short mapping showing which inventory entries each rule permits. Any path not on the inventory should have no rule at all.
Document the cryptographic configuration
Write the configuration into the system security plan or its supporting documentation so that an assessor can compare documented intent with observed settings. The document should name each remote path, the cryptographic module and its validation status, the enforced protocols and ciphers, key and certificate management responsibilities and the owner who approves changes. Assessors look for this documentation alongside the configuration evidence, so both should be dated and consistent. Where a service provider hosts part of the path, document which party controls each setting.
Test that weaker sessions are refused
Attempt connections using protocol versions, ciphers and configurations that the baseline prohibits, and confirm each attempt fails. Also attempt a connection without encryption where the service offers that option. Run the same tests from an approved remote location and from an unapproved one to confirm both the encryption rule and the access rule hold. The output is a dated test record listing each attempt, the expected result, the observed result and the tester. Retain the scan or command output that supports each result.
Confirm session logging and review
Verify that the gateways record remote sessions, including the user, source, time, duration and outcome, and that the records reach the central audit store. Check that failed negotiation attempts and blocked connections also produce entries. The output is a sample of session records and a short statement of who reviews them and how often. Assessors often ask for proof that logs were reviewed, not just that they exist, so keep a record of the review. Confirm retention periods and the audit requirements in AU with the team that owns logging.

Evidence that satisfies AC.L2-3.1.13

Assessors test AC.L2-3.1.13 by tracing each remote access path to a cryptographic mechanism and checking that the mechanism is configured as documented. The five artifacts below connect those steps, and each one must exist in final form when the assessment begins, because a requirement is met only with final evidence and drafts do not count.

Remote access path inventory

A current list of every route that carries remote sessions into the environment that handles CUI, including VPN concentrators, jump hosts, administrative consoles and hosted portals. For each path, record the endpoints, the owner and the encryption mechanism that protects it. Assessors start here, so an inventory that omits one path undermines every later artifact. Review it whenever a gateway is added, moved or retired, and tie each change to a dated approval.

Cryptographic mechanism documentation

A document that names each cryptographic mechanism protecting remote sessions, its version, and the validation certificate for the cryptographic module that performs the work. This is where the FIPS-validated requirement of SC.L2-3.13.11 becomes checkable. Confirm module validation status against the current NIST listing, not an older copy, and record the date you checked it. Update the document when a library, gateway or certificate changes.

Configuration exports in validated mode

Exported settings from each remote access gateway showing that FIPS-validated mode is on, that only approved protocol versions and cipher suites are enabled, and that weaker options are disabled. Export the configuration directly from the device or service, then store it with the date and the name of the administrator who ran the export. Repeat the export after each change so the file matches the running system.

Test results for refused weak sessions

Records of tests showing that the gateways reject sessions that use disallowed protocols, weak ciphers or unvalidated modules. Each test should state the connection attempted, the expected result, the observed result and the tester. Run the tests after configuration changes and keep failed attempts that were fixed, because they show the control working. Test results from a planned exercise are stronger than a single screenshot.

Audit records of remote sessions

Logs that record remote session establishment, the protocol and cipher negotiated, the authenticated identity and the session end. Assessors use these records to confirm that encrypted sessions occurred as documented and that refused attempts were captured. Confirm that logs are retained and protected under the audit requirements, and sample them periodically so you can show a real session trail rather than a configuration claim.

What meeting AC.L2-3.1.13 costs in money and effort

This table breaks down the cost components of protecting remote access sessions for AC.L2-3.1.13, showing who is paid, whether each cost is one-time or recurring, and what moves it up or down. AC.L2-3.1.13 carries 5 of the 110 points, so a NOT MET result cannot sit on a POA&M, and no public price figures are supplied here, so use the rows to build a written scope and request a quote.

Cost component	Who is paid or who bears it	One-time or recurring	What drives it up or down
VPN or gateway licensing	Software vendor or subscription provider, if a commercial product is chosen	Usually recurring, often per user or per concurrent session	Number of remote paths, number of users, vendor access needs. Open-source gateways can remove this line but add engineering effort.
Cryptographic module licensing	Vendor of any FIPS-validated module or hardware that the organization buys	Often recurring for support, sometimes one-time for hardware	Confirm the module's FIPS validation status and version in the current NIST validation listing before buying. Existing hardware can reduce spend.
Engineering time for configuration and testing	Internal staff or an implementation partner under a written scope	One-time for initial build, then recurring for changes	Number of remote access paths, number of gateways, complexity of existing identity and network设置. Fixed-scope work lets the buyer compare quotes.
Evidence upkeep	Internal compliance or security staff	Recurring	Frequency of configuration changes, number of systems in scope, and whether logs and configuration records are kept current for the assessor.
External testing or review	Independent security testing firm or consultant, chosen by the organization	Often one-time per assessment cycle, plus retests after fixes	Scope of TLS and VPN configuration testing, and whether testers verify cryptographic mechanisms in addition to documentation.
Assessor effort	Certified assessor organization paid by the organization for Level 2 certification assessments	One-time per assessment, repeated per cycle	Number of remote access paths the assessor must sample, and how well the evidence is organized before the assessment begins.
Open-source license spend	No license fee for the open-source components themselves; staff and support are still paid	Engineering and support costs recur	Choice of self-hosted components and whether the organization has in-house skills to operate them. Confirm each component's FIPS status separately.

Which open-source tools support remote access evidence

None of the tools below encrypts a remote session by itself on the strength of this card alone. Each one produces evidence or protects a neighboring layer, and assessors will still expect a FIPS-validated encrypted remote access path that you can show end to end. Confirm each capability and module validation in your own environment before you write it into the system security plan.

OPNsense rule and log evidence

OPNsense is a stateful packet filter (BSD-2-Clause) whose rules pass, block or reject traffic by source, destination, port and protocol. For AC.L2-3.1.13, its value is evidence: rules that permit only the remote access gateway and its approved ports, and logs of rule matches that show which sessions reached the boundary. It does not terminate or encrypt a VPN session on its own. Confirm which VPN and cipher options your deployment uses and whether the cryptographic module has FIPS validation.

Coraza web traffic protection

Coraza (Apache-2.0) is a web application firewall compatible with ModSecurity SecLang rulesets and the OWASP Core Rule Set. It inspects web traffic for attacks such as SQL injection, cross-site scripting and code injection, and integrates with Caddy, HAProxy, Traefik and Nginx. It does not encrypt remote sessions. Its evidence supports integrity and attack defense for web-facing remote access, so pair it with TLS configured on the proxy and document the cipher settings separately.

Nextcloud server-side encryption limits

Nextcloud (AGPL-3.0-only) offers server-side encryption that protects file contents at rest on local and external storage, with keys kept on the server. It does not encrypt file names or folder structure, and it does not protect the session that carries files to a user. If Nextcloud holds CUI and is reached remotely, the at-rest encryption belongs in your SC evidence, while the transport encryption must come from the access path. Ask the assessor to see both, and confirm the encryption mode and key handling in your build.

OpenBao transit engine scope

OpenBao (MPL-2.0) provides a transit secrets engine that encrypts and decrypts application data without storing it, signs and verifies data, and supports versioned keys with rotation. It is useful for protecting application-layer data and managing keys that other systems use. It does not encrypt remote access sessions. Its evidence supports key management questions, so document which keys it holds, who can use them, and whether its cryptographic operations run in a FIPS-validated module in your environment.

Who owns the controls, who prepares evidence, and who assesses

Your organization owns requirement AC.L2-3.1.13 in full. No partner or assessor can accept that responsibility for you. Your leadership sets the remote access policy, decides which cryptographic mechanisms protect remote sessions that carry CUI, and approves the configuration that results. Someone on your staff must be able to explain why each remote path is encrypted and how that protection is kept in place over time.

Policy owner: Documents which remote access methods are permitted and states that their sessions must be encrypted.
Cryptography decision: Selects the mechanisms and confirms they use FIPS-validated cryptography, as SC.L2-3.13.11 requires for CUI protection.
Configuration approval: Signs off on gateway, VPN and application settings before they carry CUI.
Evidence custodian: Keeps configuration exports, audit records and procedures in final form and under change control.
Ongoing operation: Reviews remote access after every change to the gateway, certificates or cipher settings.

Before an assessment, confirm that a named person can show the policy, the cryptographic decision and the current configuration without help from the partner.

Questions buyers ask about AC.L2-3.1.13

How much effort does encrypting remote access sessions take?

The effort depends mostly on how many remote access paths the system has and how much of the cryptography is already standardized. A single, well-documented VPN gateway with modern settings is usually a smaller job than a mix of vendor portals, jump hosts and direct administrative tools, each with its own encryption settings. Effort rises when teams must inventory every path, confirm that each one uses FIPS-validated cryptography under SC.L2-3.13.11, document the configuration, and collect audit records showing the settings are in force. Ask any provider to break its quote into inventory, configuration, validation checks and evidence preparation so you can see where the time goes.

Can our team implement AC.L2-3.1.13 without outside help?

Yes, an internal team can do this if it has engineers who understand the remote access stack, the FIPS validation status of each cryptographic module, and how to produce configuration evidence. Outside help is most useful when the team lacks that cryptography and configuration experience, or when it needs an independent view before an assessment. DeployOpen can plan, implement and document the remote access encryption in your own infrastructure under a fixed-scope agreement, and can run security testing against the result. The organization still owns the control, and only an independent assessor can issue the assessment outcome.

How long does this work take to complete?

Duration depends on scope: the number of remote access paths, the state of current configurations, whether cryptographic modules must be replaced, and how much evidence must be gathered and reviewed. No duration figure is supplied for this requirement, so do not rely on a generic estimate. Ask the provider for a written schedule tied to a defined scope, and confirm which parts depend on your change control windows, vendor responses or staff availability. Assessment scheduling is a separate step and is controlled by the assessment body, not by the implementation work.

What do our IT and security staff need to provide?

The work needs staff who can give accurate, current information about the environment. Typically this includes:

An inventory of every remote access method, including VPN, remote desktop, administrative shells and cloud consoles reached from outside the network.
Access to the gateway, identity and logging configuration, plus the change records that show how settings were approved.
Named owners who can approve changes and confirm which cryptographic modules are in use and whether they are FIPS-validated.
Time from the people who will operate the environment afterward, so runbooks and evidence collection are practical for them.

Does a VPN alone meet the remote access confidentiality requirement?

A VPN can satisfy the requirement only if the tunnel uses cryptography that meets SC.L2-3.13.11, is configured and documented, and covers every remote session that carries CUI. Having a VPN does not prove that. Assessors look at which protocols and ciphers are permitted, whether the cryptographic modules are FIPS-validated, whether unencrypted fallbacks are disabled, and whether remote access that bypasses the VPN, such as a web portal or direct SSH, is also encrypted. Confirm the exact cryptographic module and version with your vendor, since validation status applies to specific module builds.

How does this requirement relate to SC.L2-3.13.11 and FIPS validation?

AC.L2-3.1.13 requires that remote access sessions be encrypted to protect CUI confidentiality. The CMMC Assessment Guide Level 2 states that this cryptography must meet the criteria of SC.L2-3.13.11, which calls for FIPS-validated cryptography. In practice, the same modules that protect remote sessions must be shown to be FIPS-validated and configured in an approved mode. Check the validation certificate for each module against the exact version you run, and keep the configuration records that show the approved mode is enabled. Both requirements are assessed against the same underlying evidence, so plan them together.

How DeployOpen scopes and prepares encrypted remote access evidence

DeployOpen works on AC.L2-3.1.13 as an implementation partner: we help you identify the remote access paths that carry CUI, configure the cryptographic mechanisms that protect those sessions, and prepare the documentation and configuration evidence an assessor will review. Your organization owns the control and its outcome, and only an independent assessor can judge whether the requirement is met.

How we scope

Inventory every remote access path that carries CUI, including VPN, remote administration and hosted portals.
Confirm which cryptographic mechanisms each path uses and whether they are FIPS-validated under SC.L2-3.13.11.
Agree the written, fixed scope with deliverables and timelines before any configuration work begins.

How we build

Configure remote access gateways and firewall rules in your environment so only approved encrypted sessions are permitted.
Set session encryption and key handling settings, and record each configuration value for assessor review.
Test each remote path to confirm sessions are encrypted end to end and that unencrypted fallback is blocked.

How we hand over

Deliver configuration documentation that names each cryptographic mechanism, its version and its validation status.
Provide retained configuration exports and audit records that show the settings in force during the assessment period.
Walk your team through the evidence so your staff can explain how each remote session is protected.

How we support

Offer ongoing support as a retainer to review configuration drift after upgrades or certificate and key changes.
Re-verify remote access encryption whenever gateways, clients or cryptographic libraries change.
Coordinate with your assessor and C3PAO or auditor on evidence questions, while they make the final determination.

AC.L2-3.1.13 Remote access confidentiality