03.01.12 Remote access: requirements and evidence

What 03.01.12 remote access asks for and why it is hard

Requirement 03.01.12 asks you to govern every type of remote access to your CUI systems: define usage restrictions and configuration and connection requirements for each allowed type, authorize each type before any connection is made, and route remote sessions through managed access control points. It also requires you to authorize remote execution of privileged commands and remote access to security-relevant information. If a contract requires NIST SP 800-171 and your staff, contractors or vendors already administer systems from home, from a vendor's network or from a personal laptop, this requirement covers those paths too, not only the VPN your IT team set up.

The risk is straightforward. Every remote path that nobody has authorized is a way into the CUI environment that bypasses your boundary, your logging and your identity checks. Remote administration tools, vendor support sessions, SSH to a jump host, a remote desktop left open for a colleague and a personal device syncing a shared drive can each exist without a documented owner. An assessor will ask you to list the allowed types of remote access, show the configuration and connection requirements for each one, and show who approved it. If the answer is a shared spreadsheet or memory, the requirement is not met in practice even if a VPN policy exists.

This is hard because remote access accumulates informally. Teams add a tool to fix an outage, a vendor asks for a direct connection, and a manager approves a remote session for a single project that then runs for years. The work is to inventory those paths, decide which types you will allow, document their requirements, and then enforce the routing through managed points. Confirm with your assessor how they expect you to evidence the inventory and the authorizations, and confirm which of your remote administration and vendor paths fall under the privileged command and security-relevant information elements. Background only: NIST traces 03.01.12 to the SP 800-53 Rev. 5 controls AC-17, AC-17(3) and AC-17(4), which is useful when you map your existing control library, but the requirement itself is what you will be assessed on.

Which remote access paths fall under 03.01.12 remote access scope

Under 03.01.12, a connection counts as remote access when it reaches the system from outside its physical or logical boundary, whether the user is an employee, an administrator, a vendor or a cloud operator. The decision that matters most for each path is whether it ends inside the CUI enclave or only on a general network, because that answer sets the authorization, routing and logging work.

Employee VPN or zero-trust access

Staff connections through a VPN concentrator or zero-trust gateway are the most common remote path and the easiest to scope too broadly. Ask whether the gateway lands users on the CUI enclave or only on a corporate network that has no route into it. If it reaches the enclave, each allowed connection type needs documented usage and configuration requirements, an authorization step before the connection is made, and routing through the managed access point. Confirm that the gateway's allow rules are logged and reviewed.

Administrator SSH or console access

Administrators who connect over SSH, a remote desktop or an out-of-band console are running privileged commands, which 03.01.12 requires you to authorize separately. Decide whether these sessions reach security-relevant information or only application workloads, because that changes how tightly the session path must be controlled. A common design routes all administrator sessions through a single hardened jump host with named, non-shared accounts. Confirm that session activity is captured and that the list of authorized remote privileged commands is written down.

Vendor and managed service provider sessions

Vendors and managed service providers often hold persistent accounts for support, patching or monitoring. Decide whether the vendor's session reaches a CUI system or only a tool that touches one, and whether the account can be time-limited and tied to a named engagement. Each connection type needs authorization before use, and the vendor's access path must go through the same managed access point as employee traffic. Check the contract for who approves sessions and how quickly access is removed when the engagement ends.

Remote maintenance tools

Remote maintenance tools, such as vendor remote support software or remote hardware management interfaces, are assessed under 03.01.12 and also under 03.07 for nonlocal maintenance, so one session may need evidence for both families. NIST addresses withdrawn 03.13.07 through 03.01.12 together with 03.04.02 and 03.04.06, which means the allowed tools, their configuration baselines and their connection rules must be documented in one place. Decide which tools are permitted, which ports they use and whether they can be started only from a managed access point.

Cloud management consoles from home networks

A cloud management console is remote access when an employee opens it from a home network, even though the cloud platform itself is hosted by a provider. Decide whether the console can change the configuration, identity or storage of any system that holds CUI, because those actions reach the enclave even though the console runs elsewhere. Ask whether personal or unmanaged devices may open the console, and whether console sessions must pass through a managed access point with multi-factor authentication. Confirm these rules with the cloud provider's administrative settings.

Remote access to CUI repositories

Users who open CUI file shares, document management systems or collaboration sites from outside the office are using remote access to CUI, even when they never log into a server directly. Decide whether the path allows downloads, sync clients or printing to devices outside the managed boundary, since those choices determine where CUI can end up. Restrict the path to approved connection types, enforce authentication before the repository is reachable and log access to CUI records. Confirm which users have this path and whether it is limited to defined roles.

What changed for remote access between Rev. 2 and Rev. 3

Rev. 3 folded Rev. 2 requirements 3.1.14 and 3.1.15 into 03.01.12 Remote access, and NIST classifies that change as significant, meaning the Rev. 3 requirement carries more detail and foundational tasks than the Rev. 2 requirement it replaces. Rev. 2 treated routing remote sessions through managed access points (3.1.14) and authorizing remote execution of privileged commands and access to security-relevant information (3.1.15) as separate requirements. Under Rev. 3 those duties sit inside one requirement that also covers usage restrictions and configuration and connection requirements for each allowed type of remote access. NIST's change analysis workbook traces the mapping in detail, so the reader should check it line by line against their own evidence set.

For organizations that already mapped their Rev. 2 evidence to 3.1.14 and 3.1.15, the practical effect is that a single body of evidence must now show the combined requirement. A remote access policy that covers only the access points is no longer enough, and the same goes for a list of approved privileged remote commands with no matching configuration or connection standard. The assessor will look for a documented decision for each allowed remote access type, proof that authorization happens before the connection is made, records showing that traffic passes through the managed access control points, and evidence that remote privileged commands and security-relevant information are authorized. Review your existing system security plan and cross-reference each Rev. 3 determination statement to the artifacts that now answer it.

The version your contract names controls which set of requirements you must meet, and this matters more than the wording of any single control. CMMC Level 2 still assesses this practice as AC.L2-3.1.12, worth 5 points under the scoring methodology in 32 CFR 170.24, and under 32 CFR 170.21 that practice cannot be placed on a plan of action and milestones to reach Conditional status. Confirm with the contracting officer which revision of SP 800-171 your contract, solicitation and any DFARS clause reference, because DoD contracts currently name Rev. 2. Ask whether a Rev. 3 requirement would apply to your award before reorganizing evidence around it.

How an assessor tests 03.01.12 remote access

This table groups the nine SP 800-171A Rev. 3 determination statements for 03.01.12 by how the assessor gathers evidence: examining documents, interviewing staff and testing mechanisms. Read each row as what to have ready before the assessment and the gap assessors most often write up. The main takeaway is that every allowed remote access type needs its own documented authorization, configuration and monitoring trail.

Assessment method	Evidence the assessor requests	Common finding
Examine: access control policy and procedures	Policy naming each permitted remote access type, its approver, and the review date	Policy lists the VPN but omits vendor tunnels, remote administration consoles and virtual desktops
Examine: remote access procedures	Runbooks for granting, changing and revoking each access type, with sample tickets	Procedures cover requesting access but say nothing about revocation when people leave or change roles
Examine: configuration and connection requirements	Gateway and VPN configurations, MFA settings, allowed protocols and device requirements for each access type	Configuration baseline exists but does not match the access types or settings actually in use
Interview: personnel who manage remote connections	Staff explain how each access type is set up, approved and monitored, and who holds the keys	Administrators describe the corporate VPN only, while a separate team runs unmanaged vendor tunnels
Interview: information security personnel	Staff explain how remote sessions are routed through managed access points and how privileged remote commands are logged and reviewed	Security staff cannot say whether remote privileged commands or security-relevant data access are logged
Test: mechanisms that monitor and control remote access	Attempted connection through an unapproved path that is blocked, rule match logs, session logs and a sample of authorization records	Authorization is recorded only in chat or email and cannot be matched to connection logs

How to implement 03.01.12 remote access in order

This sequence takes an organization from an unmanaged set of remote connections to a governed, approved and tested remote access capability for 03.01.12. Each step produces a record that an assessor can examine, interview against and test.

Inventory every remote access type
Start by listing every way a person or process can reach the system from outside its managed boundary, such as VPN, remote desktop, browser-based administration portals, vendor support tunnels and remote command-line sessions. Include access used by maintenance staff and third parties, because 03.07 maintenance and 03.01.20 external systems overlap with this list. The output is an access type register with an owner, the systems reached and the business reason for each type. The step is done when the register matches what network and identity logs actually show, not only what the team believes exists.
Write usage and configuration standards per access type
For each type in the register, write a standard that states who may use it, the permitted purposes, the required client or endpoint configuration, the connection settings (such as encryption and session limits) and the conditions for disabling it. A single enterprise-wide standard is acceptable only if it names each type and its settings separately. The output is one approved standard per access type, signed off by the information security owner. Ask the contracting agency which organization-defined parameters apply to this requirement, since values such as session limits may need to be assigned or confirmed with them.
Set the authorization process and approvers
Define how a user or device is authorized for each remote access type before the first connection, who approves it, and how approval is recorded and renewed. Name the approvers by role, separate the request from the approval where the organization can, and specify when authorization is withdrawn, such as on role change or departure. The output is an approval procedure and a record template that links each approved user and device to the access type and the approver. Confirm the process works in practice by asking a sample of staff to show their current approval for each type they use.
Route all allowed types through named access control points
Configure every approved remote access type so that connections pass through a small set of managed entry points, such as a VPN concentrator, identity-aware gateway or bastion host, where authentication and policy are enforced. Document each entry point, its owner and the access types it serves, and block direct routes that bypass it. Firewall rule sets, for example on OPNsense, can show that traffic from remote sources reaches internal systems only through these points. The output is an architecture diagram and a rule inventory that map each access type to its control point.
Restrict and log remote privileged commands and security access
Identify which remote sessions may run privileged commands or view security-relevant information, and limit those actions to named roles that have been authorized for them. Require the sessions to be logged so that each privileged command and each access to security-relevant data is attributable to a person. Coordinate this with 03.01.07 and 03.03 audit controls so the logs are retained and reviewed. The output is an authorization list of remote privileged functions and a sample of logged session records showing the user, command and time.
Test each access type and record the results
Run a test for each remote access type that attempts connections from outside the approved path, from unapproved devices and with an unauthorized account, and confirms that each is refused or logged. Interview the staff who manage remote connections to confirm they understand the standards and their duties. Record each test with date, tester, method, expected result, actual result and any remediation. The output is a test log and an interview note set that can be matched directly to the nine determination statements in SP 800-171A Rev. 3 for 03.01.12. Independent assessors, not the implementation partner, decide whether the evidence meets the requirement.

Which evidence passes a remote access assessment

An assessor testing 03.01.12 Remote access looks for proof that each allowed remote access type is defined, authorized before use, routed through managed access points and logged. The cards below cover the artifacts that prove this, and how to keep each one current between assessments so it reflects the system as it runs today.

Approved remote access policy and procedures

This is the governing document that says which remote access is permitted, who approves it, and how exceptions are handled. It supports the examine method for 03.01.12, where the assessor compares the written procedures with what staff actually do. Confirm the policy names the owner, the review cadence and the link to the system security plan. Between assessments, record each revision with a date and approver, and tie any change to a ticket so the policy history is traceable.

Register of allowed remote access types

The register lists every remote access method the organization allows, such as VPN, remote desktop, or privileged administration over a bastion, along with its configuration and connection requirements. Each entry should state the approved protocol, encryption, endpoint requirements and the systems it reaches. Export the register each quarter and compare it against the live inventory, flagging any method that appears in logs but not in the register.

Authorization records for each connection type

For each remote access type in the register, keep a dated record showing who authorized it, for which users or roles, and under what conditions. Assessors check that authorization happened before connections were made, so the record should predate the first session. Link every grant to an access request ticket, and review grants on the same quarterly cycle as the register so stale approvals are removed.

Configuration exports of access points

Configuration exports from VPN concentrators, gateways and firewall rules show whether remote access is enforced as written. Export the relevant settings, such as allowed protocols, authentication requirements and rules on the access point, and store each export with a timestamp. OPNsense rule sets can be exported and reviewed for pass, block and reject rules that match the register. Compare each export with the last one and require a change ticket for every difference.

Logs showing sessions routed through managed points

Logs demonstrate that remote sessions actually pass through the authorized access control points rather than bypassing them. Retain logs of session start, source, destination, user and authentication result, and check a sample of sessions against the register. OPNsense can log each rule match for review in the live log view, which helps show the routing in practice. Confirm retention periods with your own policy and review logs on a set schedule, recording the reviewer and findings.

Records of authorized privileged remote commands

03.01.12 also covers remote execution of privileged commands and remote access to security-relevant information. Keep records that show which privileged commands were run remotely, by whom, and whether that activity was approved for that user. Session recordings or command logs tied to a named change or incident ticket are strong evidence. Review these records against the authorization list each quarter, and escalate any privileged remote command that has no matching approval.

What meeting 03.01.12 remote access costs in money and effort

This table compares the cost components of meeting 03.01.12 remote access, showing who is paid, whether each cost is one-time or recurring, what drives it up, and how to reduce it. No price or effort figure is supplied for this requirement, so use the drivers as the basis for a written quote. The main takeaway is that the number of remote access types and managed access points sets most of the cost.

Cost component	One-time or recurring, and who is paid	What drives it	How to keep it down
Tooling or licenses	Recurring for commercial VPN, gateway or MFA licenses, paid to the vendor. One-time for setup if self-hosted.	Number of users and remote access types, and whether the vendor prices per seat or per gateway.	Use self-hosted open-source access points such as OPNsense for firewall rules and authentik for MFA, which removes per-seat license spend for those components. Confirm feature fit with each vendor first.
Engineering time to configure access points	One-time, paid to the implementation partner or internal staff.	Count of remote access types, the number of managed access points, and the need for session logging and routing through those points.	Inventory each remote access type before scoping. Standardize configuration templates so each access point is built the same way.
Policy and procedure writing	One-time for the initial documents, then periodic review. Paid to internal staff, counsel or a consultant.	Number of allowed remote access types that need their own usage and connection requirements, and how many roles approve them.	Write one remote access standard with a table of approved access types, then reference it from the system security plan.
Authorization workflow	One-time to design, recurring to operate. Paid to internal staff.	How many requests arrive each period and whether authorization is done before each connection or once per role.	Pre-approve defined roles for defined access types and record the approvals in the access management tooling.
Evidence upkeep	Recurring, paid to internal staff. Covers access logs, configuration exports and connection records.	Log volume, retention settings, how often configurations change, and how many access points must be sampled.	Automate exports of firewall rules and MFA enrollment records. Keep a dated change log for each access point.
External testing or review	Recurring or per engagement, paid to a security testing firm or consultant if you buy one.	Scope of remote access testing, number of access points tested, and whether remote privileged commands are included.	Scope tests to the managed access points and the remote privileged command paths. Ask for the test method and the evidence each test produces.
Assessor or auditor effort	Recurring with each assessment, paid to the assessor. DeployOpen prepares evidence but does not issue assessment results.	Number of remote access types, the sample of connections an assessor selects, and the completeness of the system security plan.	Prepare a single evidence package that maps each remote access type to its configuration, authorization and monitoring records before the assessor arrives.

Which open-source tools produce remote access evidence

Remote access under 03.01.12 is proven through a chain of records: who was authorized, which path they used, what they were allowed to do, and how they proved their identity. The four tools below each cover one link in that chain, and none of them proves compliance on its own. Confirm what each one records in your own setup before you plan the assessment evidence.

Network path enforcement with OPNsense

OPNsense (BSD-2-Clause) is a stateful packet filter whose rules pass, block or reject traffic by source, destination, port and protocol. Aliases group the addresses of authorized remote access endpoints and management networks, so the rule set can show that remote sessions reach only managed access control points. Each rule can log its matches, which are visible in the live log view. Confirm that your retention period and log export meet the assessor's need to review historical remote sessions, since the live view alone may not cover a full assessment window.

Authorization and login proof with authentik

The authentik (MIT) authenticator validation stage checks enrolled second factors during login. Supported factors include TOTP apps, WebAuthn and FIDO2 passkeys, Duo, SMS codes, email codes and static recovery codes. Its records show which factor was presented at each remote login, which supports authorization before connection. Confirm which factors your policy permits, because SMS and email codes and static recovery codes may be weaker than phishing-resistant options, and confirm that recovery code use is logged and reviewed.

Directory-based OTP with FreeIPA

FreeIPA (GPL-3.0-or-later) supports two-factor authentication with HOTP (RFC 4226) and TOTP (RFC 6238) tokens, including software tokens enrolled by QR code and hardware tokens such as YubiKeys. It can also proxy OTP checks to an existing RADIUS server during migration, which helps when remote access gateways still depend on RADIUS. Confirm whether your chosen setup stores token enrollment and authentication events in a form you can export, and whether HOTP tokens are permitted in your remote access policy, since the design page describes them as available options rather than a recommendation.

Web-facing access points with Coraza

Coraza (Apache-2.0) is a web application firewall compatible with ModSecurity SecLang rulesets and the OWASP Core Rule Set. It inspects requests to web-facing remote access points, such as portals and administrative consoles, for attacks including SQL injection, cross-site scripting and code injection. It integrates with Caddy, HAProxy, Traefik and Nginx. Confirm which rule set version and tuning your team applies, because rule exclusions for legitimate traffic create documented decisions an assessor will ask about. Coraza does not record who was authorized to use the portal, so pair its logs with identity records.

Who owns, implements and assesses remote access controls

Your organization owns the requirement. Under 03.01.12, the organization must decide which types of remote access are allowed, set the usage, configuration and connection requirements for each type, and authorize each type before anyone connects. Those decisions belong to accountable staff, not to a contractor, because the organization carries the risk of any remote session that reaches CUI.

Policy and procedures: Maintain the access control policy and the remote access procedures that the assessor will examine first.
Approval of each access type: Record who authorized VPN, remote administration, vendor access and any other allowed type, and the date of approval.
Log review: Assign staff to review remote access logs at a defined frequency and to act on anomalies.
Privileged remote commands: Decide which remote privileged commands and access to security-relevant information are authorized, and by whom.
Staff time: Budget internal time for these reviews, which recur for as long as the system holds CUI.

Before engaging anyone, confirm that a named owner can explain every allowed remote access type and point to the approval record for each one.

Common questions about 03.01.12 remote access

How much effort does remote access take for a small team?

For a small team, the effort is usually concentrated in writing down each allowed type of remote access, its configuration and connection rules, and who may approve it, then proving those rules are enforced. Most of the work is documentation and verification rather than new hardware. The main cost drivers are how many remote access methods exist today (VPN, remote desktop, vendor portals, administrative shells), how many systems hold CUI, and whether logs and approvals already exist. Ask any partner to break the quote into discovery, configuration, evidence collection and assessor support, and confirm with your contracting agency which parts of your system security plan they expect you to produce.

Does a VPN alone satisfy requirement 03.01.12?

No. A VPN is one way to route remote access through a managed control point, but 03.01.12 also requires you to define usage restrictions and configuration and connection requirements for each allowed type of remote access, authorize each type before connections are made, and authorize remote execution of privileged commands and remote access to security-relevant information. An assessor will look for the policy, the approvals and the logs that show the VPN is the enforced path. A firewall such as OPNsense can pass, block or log traffic by source, destination, port and protocol, which supports the control point, and an identity layer such as authentik or FreeIPA can enforce second factors, but neither replaces the written rules. Confirm the exact evidence expectations with your assessor.

How does Rev. 2 requirement 3.1.14 and 3.1.15 evidence carry over?

Rev. 3 withdrew 3.1.14 and 3.1.15 and folded them into 03.01.12, so evidence you built for those Rev. 2 requirements generally still applies, but it must now cover the consolidated scope. Rev. 2 assessments under CMMC Level 2 still use the 110 Rev. 2 requirements, so if your contract is governed by Rev. 2, you should keep the AC.L2-3.1.12, 3.1.14 and 3.1.15 evidence mapped separately. Because the rules for which revision applies are changing, confirm the current revision with your contracting officer before reorganizing your records. Ask your partner to show how old evidence maps to the new structure, and identify any gaps the consolidated wording creates.

Does vendor and contractor remote access have to follow the same rules?

Yes, when those parties connect to a system that handles CUI. Remote access is defined by the connection, not by who is connecting, so a vendor support session, a managed service provider's administrative tunnel or a contractor's remote desktop must go through the same authorized types, the same managed access point and the same approval and logging. Many organizations overlook third-party tunnels and shared jump accounts. Include them in your inventory of remote access types, and check how 03.01.20 (external systems) and 03.17 (supply chain) interact with your agreements. Confirm with your assessor how they want external connections documented.

What does the work need from our own staff?

Your staff need to supply the knowledge the assessment cannot be built without: an accurate list of systems, who administers them, how people connect today, which remote tools are in use, and who approves access. Expect time from system administrators for configuration reviews, from someone who owns the access policy for approvals, and from whoever handles incident and log review. Ask the implementation partner to list every person and meeting they expect, the decisions they need you to make (such as which remote access types are allowed), and the artifacts you must review before sign-off. Clear ownership on your side is often the factor that most affects the schedule.

Can our own team handle remote access compliance in-house?

Often yes, if you have engineers who can configure your firewall, identity provider and logging stack, and someone who can write a defensible policy and maintain evidence over time. The decision depends on whether you can staff those roles now and keep them staffed, because 03.01.12 evidence must be current at assessment, not only at the start. Outside help is most useful for scoping, for reviewing your procedures against the assessment methods in SP 800-171A, and for preparing systems and evidence before an independent assessment. It does not replace the organization's ownership of controls, and an independent assessor is still required for any formal assessment outcome.

How should we scope a fixed-scope remote access engagement?

Start by listing every allowed remote access type, the systems in scope for CUI, and the identity and logging tools already in use. Then write the deliverables in terms an assessor can test: the remote access policy, the configuration and connection requirements per type, the authorization workflow, the control point configuration, and the evidence set. A fixed-scope agreement should name the systems covered, the number of access types, the people who approve work, what is excluded (such as your assessor's fees or your ongoing monitoring) and how changes to scope are priced. Fixed-scope engagements are agreed in writing before work starts, so ask for that document to list each deliverable and acceptance step.

How DeployOpen works on this

DeployOpen plans and implements self-hosted open-source platforms inside your own infrastructure, so remote access controls for 03.01.12 can be scoped to your actual remote paths. We prepare the systems, configuration and evidence, while your organization owns the policy, the authorizations and the assessment outcome.

How we scope

Inventory every remote access type your organization allows, such as VPN, remote administration and vendor sessions.
Define the usage, configuration and connection requirements for each type in a written scope.
Confirm which managed access control points remote sessions must route through before any build starts.
Agree in writing which privileged commands and security-relevant information remote users may reach.

How we build

Configure OPNsense rules to pass remote traffic only from approved sources, ports and protocols, with aliases for groups.
Enable rule match logging so remote access attempts can be reviewed in the live log view.
Set up authentik authenticator validation so enrolled second factors are checked at every remote login.
Place a web application firewall such as Coraza in front of browser-based remote administration interfaces where applicable.

How we hand over

Deliver the remote access configuration, rule sets and authorization records as documented, versioned artifacts.
Map each determination statement for 03.01.12 to the specific configuration, log or procedure that shows it.
Provide test results for remote session routing and blocked connection attempts, for your assessor to examine.
Document operating procedures so your staff can authorize, review and revoke remote access after handover.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after the fixed-scope work ends.
Retest remote access paths after changes to firewall rules, identity providers or remote access tooling.
Confirm with your auditor or assessor which evidence formats they accept before the assessment begins.

03.01.12 Remote access