1Overview
AC.L2-3.1.12 opens the remote-access cluster of the Access Control family, and it carries the maximum five-point weight and cannot sit on a plan of action. It requires that remote access to the environment be both controlled, permitted only through approved means, and monitored, visible in a record that shows who connected, from where, and when.
Remote access is where the boundary of a CUI environment extends beyond the building, and it is the path an outside attacker most wants, because a working remote credential reaches the environment without ever passing a locked door or a badge reader. The control asks the organization to decide how remote access is allowed to happen and to route it exclusively through that path, and then to watch that path closely enough to see who is using it. In a world where engineers, administrators, and outside support all connect from elsewhere, this control governs the single most exposed entry into the environment.
Monitor and control remote access sessions.
The requirement has two verbs, and both carry weight. "Control" means remote access happens only through the approved mechanism, with the ad hoc and unmanaged paths closed. "Monitor" means the remote sessions are logged and observable, so their use can be reviewed and a misuse noticed. This control sets the terms that the following remote-access requirements build on: the encryption of 3.1.13, the managed access points of 3.1.14, and the authorization of privileged remote commands in 3.1.15 all presume that remote access is first controlled and monitored here.
2The Assessment Objectives
NIST SP 800-171A decomposes 3.1.12 into four objectives: permit remote access, identify the permitted types, control those sessions, and monitor them.
Remote access sessions are permitted. The organization has defined which remote access is allowed and by what means, so that permitted access is distinguished from everything else.
The types of permitted remote access are identified. The organization knows and has documented the specific remote access types it allows, so control and monitoring have a defined subject.
Remote access sessions are controlled. The permitted sessions are routed through the approved mechanism and unapproved paths are blocked, so remote access happens only by the sanctioned route.
Remote access sessions are monitored. The permitted sessions are logged so their use is visible and reviewable.
The four objectives move from permitting to identifying to controlling to monitoring. The most common gap is at objectives [c] and [d], where an organization may have a sanctioned remote path but neither forces all remote access onto it nor keeps a usable log of the sessions, so control exists without monitoring or the reverse.
3Failure Patterns
The failures are about unmanaged remote paths and about sessions that happen without a record, both of which turn the most exposed entry into the environment into an invisible one.
The tangle of remote tools
Different people install different remote tools over time, a consumer remote-desktop utility here, a personal VPN there, a vendor's own connection tool for support, and none of them is the sanctioned path. Objectives [a] and [b] fail because there is no single defined method, and every extra tool is another entry that is neither controlled nor watched.
Vendor and support access outside the boundary
Outside support connects through the vendor's own remote software on the vendor's schedule, often with standing access, and those sessions are invisible to the organization's monitoring. This is a frequent and serious gap, because third-party remote access is both powerful and unwatched, and it fails the control on the connections that most warrant scrutiny.
Remote access that is controlled but not monitored
An organization may route all remote access through a proper VPN and still fail the monitoring half, because the VPN logs are not retained or reviewed. Control without monitoring meets only part of the requirement, since the record that would reveal a compromised credential or an unusual connection is not there when it is needed.
Monitoring without control
The reverse also occurs: sessions are logged, but the organization does not actually confine remote access to the approved path, so the logs record only the sanctioned connections while the unmanaged ones proceed unseen. Both verbs of the requirement have to hold at once.
4Ownership
This control is owned by IT, with a specific responsibility to bring third-party and vendor remote access under the same control and monitoring as internal access, which is where ownership most often breaks down.
| Role | Responsibility for this control |
|---|---|
| IT and network lead | Defines the permitted remote access method, routes all remote access through it, blocks the unmanaged paths, and ensures sessions are logged and the logs retained. Owns the technical evidence. |
| Security or compliance lead | Confirms the permitted remote access types are documented and that both control and monitoring are in place, and reviews the remote session logs. |
| Vendor and contract managers | Ensure outside support connects through the organization's controlled and monitored path rather than the vendor's own tools, and that standing vendor access is removed when not in use. |
| Program lead | Includes remote access in periodic review, checking for new tools and new vendor connections, and retains the records of permitted methods and reviews. |
5Tooling
The control is built with a managed remote access service and the logging around it, applied so that all remote access, including vendor access, runs through the controlled and monitored path.
| Objectives | Tooling | What it provides |
|---|---|---|
| [a], [b] | A defined VPN or remote access gateway, documented in the access policy | The single permitted remote access method and the documented list of permitted types, giving control and monitoring a defined subject. |
| [c] control | Managed VPN or Zero Trust access, firewall rules blocking unmanaged paths, Conditional Access | Forcing remote access onto the approved path and blocking consumer remote tools and ad hoc connections, so control is real rather than nominal. |
| [d] monitor | VPN and gateway connection logs, sign-in logs, forwarding to a SIEM | Recording who connected, from where, and when, and retaining and reviewing those records so remote use is visible. |
| Vendor access | A controlled vendor access path, just-in-time or supervised remote support | Bringing third-party support through the organization's monitored path rather than the vendor's own tools, with access granted when needed and removed after. |
The caveat is that both verbs must hold and that vendor access is the usual blind spot. A managed VPN satisfies control, but without retained and reviewed logs it does not satisfy monitoring, and a well-monitored internal path means little if the vendor still connects through their own unwatched tool. The assessor tests objectives [c] and [d] by asking to see the permitted remote path enforced and the session logs that show it in use, and specifically by asking how outside support connects.
6Evidence
The satisfied version of 3.1.12 shows the defined permitted remote access, the enforcement that confines access to it, and the monitoring record of the sessions.
| Evidence | What it demonstrates |
|---|---|
| Remote access policy and permitted types | Objectives [a], [b]. The defined remote access method and the documented list of permitted remote access types. |
| Remote access enforcement configuration | Objective [c]. The VPN or gateway configuration and the rules that block unmanaged remote paths. |
| Remote session logs | Objective [d]. Connection records showing who connected, from where, and when, retained for review. |
| Log review records | Objective [d]. Evidence the remote session logs are actually reviewed, not merely collected. |
| Vendor access arrangement | Objectives [a], [c], [d]. The controlled and monitored path through which outside support connects. |
The evidence must show both control and monitoring, since either alone fails the requirement, and it must account for vendor access explicitly, because that is where the assessor will look for the gap. Session logs that are retained and reviewed are the clearest demonstration of the monitoring half, and a documented, enforced single remote path is the clearest demonstration of control.
Vendor remote access is the usual blind spot
Most shops can point to a VPN; fewer can show that every remote connection, including the software vendor who dials in for support, runs through a path they control and watch. Consolidating remote access onto one monitored path and bringing vendor connections into it 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.12. csrc.nist.gov
- NIST Special Publication 800-171A, Assessing Security Requirements for Controlled Unclassified Information, assessment objectives 3.1.12[a] through 3.1.12[d]. 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