Independent DIB implementation resource — not affiliated with or endorsed by the U.S. Department of WarView the official DoW campaign ↗
Brilliant at the BasicsDIB Resource Center
03.01.12OFFICIAL TITLEPENDING NIST SME REVIEW

03.01.12 — Remote Access

03.01 Access Control · NIST SP 800-171 Rev. 3

Independent summary of the official requirement

Requires establishing usage restrictions, configuration requirements, and connection requirements for each allowed type of remote system access; authorizing each type before connections are established; routing remote access through authorized and managed access control points; and authorizing the remote execution of privileged commands and remote access to security-relevant information (aligned to SP 800-53 AC-17). It is the consolidated successor to all four of Rev. 2's remote-access requirements.

Rev. 3 requirement text is multi-part and parameterized with organization-defined values, so this site summarizes rather than reproduces it. The summary is independent — read the official publication for the binding wording.

NIST SP 800-171 Rev. 3 — Protecting CUI in Nonfederal Systems ↗NIST SP 800-171A Rev. 3 — Assessing Security Requirements for CUI ↗
Independent interpretation

What this requirement is after

Every way into the environment from outside — VPN, remote desktop, vendor support tunnels, admin portals from home — gets defined rules, explicit authorization, and a managed choke point; nothing remotes in around the side. Remote admin work is authorized specifically, not inherited from having a VPN account. The usual small-contractor gaps are the vendor's permanent remote-support install and a firewall management port exposed to the internet.

Across revisions

Rev. 3 folds Rev. 2's four remote-access requirements into this single parent: 3.1.12 (session monitoring and control), 3.1.13 (cryptographic session confidentiality), 3.1.14 (managed access control points), and 3.1.15 (authorization of remote privileged commands and security-relevant access). Cryptographic protection of sessions continues through the connection requirements defined here and the consolidated transmission-confidentiality requirement, 03.13.08.

Mapped practices

Brilliant at the Basics practices that support this requirement

Partial implementation supportModerate confidence

Why: Phishing-resistant multifactor authentication hardens the front door of exactly the paths this requirement governs — the practice's rollout starts with remote access, and stolen credentials are how remote access is most often abused.

What this does not claim: Authentication strength is one attribute of a remote-access architecture, and not the one this requirement chiefly names. Usage restrictions per access type, authorization before connection, routing through managed access control points, and specific authorization of remote privileged work are untouched by an MFA rollout and need their own implementation. May partially address the requirement at most.

Practice-side activities
  • Enforce phishing-resistant factors on VPN, remote desktop gateways, and cloud admin portals first
  • Block legacy authentication on remote paths so the second factor cannot be bypassed
Evidence this produces
  • Identity-provider policy showing MFA enforced on remote-access applications
  • Sign-in logs for remote paths demonstrating factor enforcement

Review status: Pending NIST SME review · Reviewed by Brilliant at the Basics editorial — practitioner-authored; NIST SME review pending · updated 2026-08-06

Direct implementation supportHigh confidence

Why: Brokered, logged, time-bound vendor pathways are the consolidated remote-access requirement in operation: the broker is the managed access control point, the time-bound grant is authorization before connection, and vendor maintenance work is remote privileged execution authorized case by case.

What this does not claim: Supports implementation of the requirement for the OT vendor pathway; it does not carry the whole scope. Workforce remote access to business systems, admin portals, and the per-type usage-restriction documentation the requirement opens with all sit outside this practice, and the organization-defined parameters still have to be written. Session encryption depends on the broker's configuration, not on the pathway pattern alone.

Practice-side activities
  • Route all vendor access through a broker or jump host with session recording enabled
  • Grant vendor access per engagement with automatic expiry
  • Review vendor session logs after each service window
Evidence this produces
  • Broker configuration and session recordings
  • Time-bound vendor access grants with expiry records
  • Post-session review notes

Where this holds: Strongest for OT and vendor maintenance access; enterprise workforce remote access needs parallel treatment.

Review status: Pending NIST SME review · Reviewed by Brilliant at the Basics editorial — practitioner-authored; NIST SME review pending · updated 2026-08-06

Doing the work

Implementation considerations and evidence

Implementation considerationsIndependent guidance — tailor to your environment
  • Inventory the remote access types actually in use — workforce VPN, RDP, vendor tools, admin portals — write usage and configuration requirements for each, and retire the undocumented ones.
  • Force every path through managed access control points (VPN concentrator, ZTNA broker, bastion host) and remove direct exposure of management interfaces.
  • Gate remote privileged work specifically: separate authorization, stronger authentication, and session recording where feasible.
  • Carry session encryption and monitoring into the connection requirements you write for each access type; those Rev. 2 expectations did not lapse with the renumbering.
What operating evidence looks likeRecords worth retaining, not a submission checklist
  • The per-type remote access standard with usage restrictions and connection requirements
  • Network architecture or configuration showing remote paths routed through the managed control points
  • Authorization records for remote privileged access, with session logs

Suggested owners, derived from the mapped practices and artifacts: Identity administrator · OT / network administrator · Network admin. Ownership is a named person in your organization, not a role on a website.

Artifacts

Templates and worksheets with a mapped relationship

INVENTORY · REVIEW QUARTERLYRemote Access Pathway Inventory
The other revision

Where this came from in Rev. 2

Provenance

Sources and review status

Primary sourcesNIST SP 800-171 Rev. 3 — Protecting CUI in Nonfederal Systems · NIST SP 800-171A Rev. 3 — Assessing Security Requirements for CUI
Review statusPending NIST SME review
Content version1.0
Updated