AC.L2-3.1.12 Control remote access: CMMC evidence and audit

What AC.L2-3.1.12 requires and why assessors score it heavily

AC.L2-3.1.12 asks a defense contractor to do two things: define which types of remote access the system permits, and monitor and control every remote access session. In practice, that means the organization must be able to name each remote path into a system that handles CUI, show who approved it, and prove that sessions over it are watched and can be ended. The requirement is worth 5 points under the CMMC scoring methodology, and because it is worth more than 1 point it cannot be placed on a POA&M. It must be MET before the organization can reach Conditional or Final Level 2 status, which is why assessors give it so much weight.

The risk is straightforward. A remote session that is authenticated and unmonitored is an entry point to CUI that bypasses the office network, the physical access controls and most of the perimeter reasoning the assessment relies on. Remote access is also harder to inventory than it looks. It spreads across a VPN concentrator, a jump host, cloud administrator consoles, hosted email, file sharing services, managed service provider tools and vendor support channels, often added one project at a time. An assessor will test whether the organization's list of permitted remote access types matches what actually exists, so a gateway that nobody documented is a finding waiting to happen.

Confirm the current status of the program before you plan around dates. On 13 July 2026 the Department of War suspended CMMC Phase II, so the timing for certification assessments has changed, and the DoW CIO About CMMC page is the place to check the latest position. The requirement itself does not change with the schedule. Any system that stores, processes or transmits CUI still needs the remote access definition, session monitoring and session control described in NIST SP 800-171 Rev. 2, and DFARS 252.204-7012 obligations remain in place. Plan the work now, and ask your assessor or implementation partner to confirm how the current status applies to your contracts.

Which remote access paths fall in scope for AC.L2-3.1.12

Scope for AC.L2-3.1.12 follows where CUI lives and who can reach it, not only the headquarters network. Each path below is a place where a remote session can touch CUI, so each needs a line in the system security plan before controls are designed.

VPN and gateway access to the CUI boundary

Every VPN concentrator, zero trust access proxy or remote desktop gateway that terminates into the CUI boundary is in scope. Assessors look for a defined list of permitted remote access types and evidence that each session is monitored and controlled. Check whether the gateway logs session start, end, user identity and source address, and whether those logs reach a central store. Record the gateway in the system security plan as an access point.

Administrator remote access

Administrators often reach servers, hypervisors and security tools from home networks or jump hosts, which makes their sessions the highest-impact remote paths. Document which privileged commands may run remotely and which sessions require additional approval. Confirm that administrator sessions are logged separately and that shared administrator accounts are not used for remote work.

Vendor and managed service provider access

Third parties that support the system through remote tools are remote users under the same requirement. Inventory each vendor account, the method it uses (such as a vendor VPN, screen sharing or a support portal) and the window in which access is granted. Confirm that you can see and end vendor sessions on demand, and that vendor activity appears in your own audit records.

Cloud email and hosted infrastructure holding CUI

The CMMC Assessment Guide Level 2 treats access to cloud-based email or server infrastructure as relevant when those environments contain CUI, so remote webmail and cloud administration consoles are in scope. Identify which hosted services store or process CUI, then list the sign-in paths to each. Confirm that session monitoring and termination settings apply to these services, not only to on-premises systems.

Remote desktop and SSH paths

Remote desktop and SSH sessions give interactive control of systems and are frequent gaps in inventories because they are set up for convenience. Search for open RDP and SSH listeners on boundary and internal systems, and remove any that are not documented. For each approved path, confirm that session logs capture the user, the target and the time, and that the approved configuration is recorded for assessors.

Mapping each path to the system security plan

Before you design controls, list every remote path in the system security plan with its owner, purpose, authentication method and the CUI it can reach. Assessors test the remote access management capability against that plan, so an unlisted path is a finding even if it is well secured. Review the list whenever a new tool, vendor or hosted service is added.

How an assessor tests remote access control

This table walks through the four NIST SP 800-171A assessment objectives for AC.L2-3.1.12, showing how an assessor tests each one, what evidence is requested and where organizations most often fall short. Read each row as a question the assessor will ask, then check that your documents and logs answer it in final form.

Assessment objective	How the assessor tests it	Evidence requested	Common findings
Remote access sessions are permitted	Document review of remote access procedures, then interviews with administrators about who may connect and how	Remote access procedures and restrictions, remote access authorizations, configuration management plan	Procedures exist only as drafts, or authorizations cover some users but not contractors or service accounts
Permitted types of remote access are identified	Review of the system inventory and architecture, checked against what the technical environment actually allows	Configuration management plan, configuration settings for VPN, gateway and cloud access paths, system security plan	Undocumented access types such as legacy remote desktop, vendor tunnels or cloud email access paths that hold CUI but are missing from the documented list
Remote access sessions are controlled	Observation of a live connection attempt, plus technical testing of gateway and firewall settings that enforce authorization	Configuration settings for gateways, firewall rule sets and access policies, remote access authorizations	Rules allow broader access than the documented types, or a session can be opened outside the approved gateway
Remote access sessions are monitored	Technical testing that starts a session and checks whether the event appears in audit records, followed by review of log retention and review practice	Audit records showing session start, end and activity, log configuration, evidence of log review	Logs record logons but not session activity, logs are not retained or reviewed, or cloud and hosted access is not logged at all

How to implement remote access control step by step

This sequence takes an organization from an unknown set of remote paths to a tested, logged and documented remote access control that an assessor can trace for AC.L2-3.1.12. Each step produces an artifact that the next step depends on.

Inventory every remote access type and path
Start by listing every way a person, process or vendor can reach a system that stores, processes or transmits CUI. Include VPN concentrators, remote desktop and jump hosts, SSH, web portals, vendor support tunnels, administrative consoles, and access to cloud email and hosted infrastructure. Ask IT, security, engineering and managed service providers to contribute, because shadow tools often surface here. The output is an access type register with one row per path, its entry point, the systems it reaches, and whether CUI is in scope. The step is done when network and identity teams confirm the register matches what the firewall and identity logs actually show.
Define and document the permitted remote access types
Decide which remote access types are permitted, which are prohibited, and who owns each permitted type. For each one, record the business purpose, the authorized user groups, the approver, the conditions for use, and the review interval. Write this into a remote access standard that the system security plan can reference. Management approval should be recorded with a date and a named approver. The output is the remote access standard and an approval record. The step is done when every row in the access type register maps to either a permitted type with an owner or a documented retirement plan.
Route permitted sessions through managed access points
Configure the permitted types so that all remote sessions enter through a small number of managed access points, such as a VPN gateway, a bastion host or a virtual desktop broker. Disable or block direct inbound paths that bypass these points. In firewall and gateway policy, restrict each access type by source, destination, port and protocol, so only the approved flows exist. The output is gateway configuration records, exported rule sets and a network diagram showing the managed points. The step is done when a test from outside the boundary can reach CUI systems only through the approved points.
Enable session logging and monitoring
Turn on logging at each managed access point and at the systems that remote sessions reach. Record who connected, from where, when, which protocol was used, what was authorized, and when the session ended. Forward these records to a central store that administrators cannot silently edit. Define who reviews the logs, how often, and how alerts are raised for unusual sessions such as off-hours logons, new source addresses or repeated denials. The output is a logging configuration record, a log retention and review procedure, and a documented alert rule set. The step is done when a test session produces matching entries at every point it crosses.
Confirm cloud and hosted systems with CUI are covered
Check every cloud and hosted environment that holds CUI, including cloud-based email, file sharing, collaboration platforms and hosted servers. For each one, document how users reach it remotely, whether the access passes through the managed points, which identity controls apply, and where session records are kept. Remote access to these services counts even when the service runs outside the headquarters network, so record each path explicitly rather than assuming the provider's default settings apply. The output is a coverage table that lists each CUI-bearing cloud service, its remote access path, its logging source and its owner. The step is done when no CUI-bearing service is missing from the table.
Test the whole chain before the assessment
Run a structured test of the full chain. Attempt connections from permitted and unpermitted paths, confirm that unpermitted attempts fail, confirm that permitted sessions appear in logs with the expected fields, and confirm that alerts fire for the defined conditions. Repeat the test for cloud and hosted services in the coverage table. Keep the test plan, the raw results and any remediation records. Assessors may test the remote access management capability directly, so the test results should be reproducible by someone who did not write the configuration. The output is a test report with dated results and a remediation log. The step is done when every permitted path and every cloud service passes, and every failure has a recorded fix and retest.

Open-source tools that produce remote access evidence

Remote access evidence for AC.L2-3.1.12 comes from several layers: the perimeter that decides which paths exist, the web layer that inspects traffic, the file platform that records user events, and the secrets layer that records administrative API calls. The four tools below each cover one layer. None of them decides the policy, so the organization still has to define the permitted remote access types and confirm each tool's logs meet its own session-level needs.

OPNsense for path control

OPNsense is a stateful packet filter under the BSD-2-Clause license. Its rules pass, block or reject traffic by source, destination, port and protocol, and aliases group addresses so that the permitted remote access paths are written once and reviewed as a set. Enabling per-rule logging records each rule match, which gives an assessor a trace of which remote paths were actually used. Confirm that the logs capture the user identity your remote access gateway applies, since a firewall log alone usually shows addresses, not people.

Coraza for web traffic

Coraza is a web application firewall under the Apache-2.0 license. It is compatible with ModSecurity SecLang rulesets and the OWASP Core Rule Set, and integrates with Caddy, HAProxy, Traefik and Nginx. For remote access, it inspects HTTP traffic to web services that expose CUI, such as a portal reached from outside the boundary, and can block injection and cross-site scripting attempts. Confirm which proxy you will place it behind, and that its audit output reaches the same log store as your other remote access records.

Nextcloud admin_audit for file events

The admin_audit app in Nextcloud, licensed AGPL-3.0-only, writes additional event information to audit.log in the data directory, or to a path you set with logfile_audit. When CUI is stored in Nextcloud and users reach it from remote locations, these entries show who accessed or changed files and account settings. Confirm the events you need are enabled, that the log path is protected from non-administrative users, and that the file is shipped to the central log system so it survives a compromised server.

OpenBao audit devices for API calls

OpenBao audit devices, licensed MPL-2.0, keep a detailed JSON log of every API request and response, including errors. Most sensitive values are hashed with HMAC-SHA256. When administrators reach secrets or infrastructure APIs remotely, this log shows the sequence of their calls, which supports an assessor's review of privileged remote activity. Confirm that the hashing meets your requirements for sensitive values, that at least one audit device is enabled, and that the log is retained and reviewed outside the system it records.

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

This table breaks down the cost components of meeting AC.L2-3.1.12, who is paid for each, whether it is one-time or recurring, and what drives it up or down. Use it to structure a quote request and to see where self-hosted open source reduces license spend while labor remains.

Cost component	Who is paid or who carries it	One-time or recurring	What drives the cost
Remote access gateway and firewall	Vendor license or hardware purchase, or no license cost when self-hosted open source such as OPNsense is used	Hardware is one-time; licenses and support are usually recurring	Number of remote paths, throughput, high availability design, and whether commercial support is bought
Engineering to configure remote paths	Internal staff or an implementation partner under a fixed-scope written agreement	One-time, with later change work	Number of remote entry points, cloud footprint, and how many access types must be permitted and documented
Session logging and log storage	Storage and retention cost paid to the infrastructure owner or cloud provider; labor to configure audit logs	Storage is recurring; configuration is one-time	Retention period, volume of sessions, and whether logs cover cloud email and hosted systems holding CUI
Log review and monitoring	Internal security staff or a managed service provider	Recurring	Session volume, alert tuning, and staff capacity to review remote session records
Policy and procedure writing	Internal compliance or security staff, or an implementation partner	One-time, with periodic review	Number of remote access types defined, approval workflows, and how many systems are in scope
Implementation partner fees	Paid to DeployOpen or another partner under a written, fixed scope	One-time for build; retainers may be recurring	Scope of systems, number of gateways, integration with identity and logging, and handover to internal staff
External assessment fees	Paid to an independent assessor or certification body; not paid to the implementation partner	Assessment is periodic	Scope size, evidence readiness, and whether assessment is self-run or third-party

Evidence that passes AC.L2-3.1.12 and how to keep it current

Assessors test AC.L2-3.1.12 by reviewing what you documented, what you configured and what the system recorded. The cards below cover the artifacts that connect those three, and the routines that keep them accurate after the assessment ends.

Remote access procedures and restrictions

This is the written standard that names each permitted type of remote access, such as VPN, virtual desktop, administrative shell or access to cloud email, and states who may use it and under what conditions. Assessors compare it against the live environment, so every path in the gateway configuration should appear here. Check that the document covers cloud-hosted email and hosted infrastructure that holds CUI, not only connections back to the headquarters network.

Configuration management plan entries

Remote access paths should have entries in your configuration management plan and baseline, recording the approved settings for each gateway, firewall rule set and session policy. These entries show that remote access is managed as part of the system baseline rather than set up ad hoc. Confirm that the plan's version and approval history match the configuration currently running.

Signed remote access authorizations

Each user, role or device allowed to connect remotely needs an authorization record signed by the person who has authority to grant it. Keep the signed version, not a draft or an unsigned spreadsheet, and link each authorization to a named account or group. Review the list when roles change, because an authorization for a former employee or contractor is a finding waiting to happen.

Gateway and firewall configuration exports

Export the current rule sets from remote access gateways and firewalls and store them with a date and the name of the person who exported them. The exports should show permitted sources, destinations, ports, protocols and the logging setting for each rule. Compare the export against the procedures document, since a rule that allows an unlisted remote path is the most common gap between paper and practice.

Session start, end and activity logs

Audit records should show when each remote session began and ended, which account opened it, from where, and what privileged activity occurred during it. Confirm that logs from the gateway, the application (for example, the Nextcloud audit log) and any secrets platform are retained together and time-synchronized, so one session can be traced across systems. Test a sample session end to end before the assessment.

Final-form evidence and a recurring review cadence

An assessor will not accept a draft as evidence for AC.L2-3.1.12, so each artifact needs a final version, an approval date and an owner. Set a recurring review, at a cadence your governance process defines, that samples remote sessions from the logs, reconciles them against authorizations and records the result. Require a change record for each new remote path before it goes live, so the procedures, the baseline and the gateway configuration are updated together.

Who does what for remote access control: your team, a partner and the assessor

Your organization owns the control. Under CMMC, the organization must decide which types of remote access are permitted, approve who may use them, and keep the policy current. Those decisions belong to you, and an assessor will ask who made them and when. Day-to-day monitoring is also yours, because an assessor expects the organization to show that someone reviews remote session records and acts on anything unusual.

Permitted access types: Define each remote access method, such as VPN, a managed gateway, or cloud email from an approved device, and record why each one is allowed.
Approvals: Keep written authorizations that name the users, roles and systems each remote access path covers.
Policy and procedures: Maintain the remote access policy and the procedures that describe how sessions are started, monitored and ended.
Daily log review: Assign a named role to review remote session logs on a set schedule and record the results.
Scope of cloud access: Confirm which cloud email and hosted systems holding CUI count as remote access points in your boundary.

Before any assessment, confirm that each authorization, policy and review record is final and dated, since drafts do not satisfy the assessment objectives.

What organizations ask about remote access control under CMMC

How much effort does monitoring and controlling remote access take under CMMC Level 2?

Effort depends mainly on how many remote paths exist and how much of each one is already logged. Most organizations have more remote entry points than they expect: VPN concentrators, remote desktop gateways, vendor support tunnels, administrator jump hosts and cloud consoles reached from home networks. Each path must be identified, tied to a defined access type, placed behind a managed control point, and logged per session. The work splits into one-time design (defining permitted remote access types, documenting procedures and authorizations, and configuring gateways and log forwarding) and recurring operation (reviewing session logs, revalidating authorizations and testing that sessions are terminated and recorded). Ask any consultant to price the path inventory and the log pipeline separately, because those two items usually drive the total.

Can our internal team handle remote access readiness without an outside partner?

Yes, many teams handle it in-house, provided they have people who understand network architecture, identity systems and log management, and who can produce evidence in final form. The requirement is assessed against the objectives in NIST SP 800-171A, and a requirement is met only when every applicable objective is satisfied with finished evidence rather than drafts. Internal teams often struggle less with the technology and more with the paperwork: keeping remote access procedures current, showing that authorizations match real access, and producing configuration evidence that an assessor can reproduce. An outside implementation partner can prepare gateways, logging and documentation, but the organization still owns its controls. Only an independent assessor, such as a C3PAO for Level 2 certification, can issue a certification result.

What does the organization need to provide before remote access work can start?

Three inputs decide whether the work moves quickly. First, an asset and path inventory: every system that holds or processes CUI, every remote entry point into it, and every cloud service where CUI is stored, such as hosted email or server infrastructure. Second, named access owners who can approve which remote access types are permitted, which roles may use them and which privileged commands may run remotely. Third, log retention decisions: how long session records are kept, where they are stored, who can read them and how they are protected. Without these, engineers end up guessing at scope and authorizations, which adds rework late in the project. Ask your partner to list these inputs in the written scope before work begins.

How long does remote access readiness work take?

The duration depends on scope, not on a fixed rule. A single gateway with a small, well-documented user group is a much smaller job than a multi-site environment with several VPNs, vendor tunnels and cloud administration paths. The sequence is usually inventory, design of permitted access types, configuration of gateways and session logging, documentation of procedures and authorizations, and then a dry run against the assessment objectives. Each step can stall on approvals or on evidence gaps. No supplied timeline applies to every organization, so ask for a schedule tied to named deliverables in the written scope, and confirm which phase of CMMC program implementation applies to your contracts before committing to a target date.

Does a cloud email tenant holding CUI count as remote access?

Yes, it can. CMMC guidance on Level 2 states that remote access is not limited to connections back to a headquarters network. Access to cloud-based email or server infrastructure is also relevant when those environments contain CUI. That means a user signing in to a hosted mailbox from outside the corporate network, or an administrator managing a hosted server from a home office, falls within the scope of AC.L2-3.1.12. The practical steps are to list the cloud services that hold CUI, define which remote access types are permitted to each, enforce those rules through conditional access or equivalent controls, and log sessions. Confirm the exact configuration with your cloud provider and your assessor, because shared responsibility terms differ between platforms.

Can a POA&M cover the remote access requirement if we are not finished?

No. Under the CMMC Scoring Methodology, AC.L2-3.1.12 is worth 5 points, and because it is worth more than 1 point, the rule does not allow it on a Plan of Action and Milestones. It must be MET to reach Conditional or Final Level 2 status. If the requirement is NOT MET, the score drops by 5 from the maximum of 110. Plan remote access work early so that gateways, session logging and documented authorizations are finished and producing evidence before any assessment. Confirm current status requirements with your contracting officer and the latest program guidance, because implementation timing for CMMC has changed recently.

What session logs will an assessor expect to see for remote access?

Assessors look for records that show each remote session was authorized, which access type was used, who initiated it, when it started and ended, and whether it was monitored and controlled. SP 800-171A lists remote access procedures, configuration settings, remote access authorizations and audit records as potential evidence. In practice, engineers configure the remote access gateway to log session start and stop events, forward those logs to a central store and retain them according to the retention decision made earlier. Open-source options exist for parts of this chain. For example, OPNsense can log each firewall rule match for review, and OpenBao can produce detailed audit logs of API requests. Confirm that each tool produces the fields your assessor needs before relying on it as evidence.

How DeployOpen scopes and prepares remote access controls for assessment

DeployOpen plans and implements self-hosted open-source platforms inside your own infrastructure, including the remote access gateways, session logging and evidence that AC.L2-3.1.12 Control remote access requires. Your organization owns its controls and the assessment decision, while DeployOpen prepares the systems and evidence for an independent assessor to review.

How we scope

Inventory every remote path into systems that process, store or transmit CUI, including cloud email and hosted infrastructure.
Define the permitted remote access types and the owner who authorizes each one in writing.
Agree the fixed scope, deliverables and timeline in writing before any implementation work starts.

How we build

Configure the remote access gateway so only the defined access types are permitted and every session is monitored and controlled.
Set rule-level logging on firewall policies and session audit logging on applications so remote activity is recorded.
Test that unauthorized remote paths are blocked and that session termination and logging behave as the documented configuration states.

How we hand over

Document the configuration, remote access procedures, authorizations and audit record locations in a form your assessor can trace.
Provide test results showing each permitted access type working and each restricted path failing, mapped to the assessment objectives.
Walk your team through operating the gateway and reviewing logs so evidence stays current after handover.

How we support

Offer ongoing support, upgrades and continuous testing of the remote access stack as a retainer.
Re-test the configuration after platform upgrades, new remote access methods or changes to the CUI boundary.
Confirm with your assessor which evidence formats and retention periods they expect before the assessment begins.

AC.L2-3.1.12 Control remote access