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
3.1.12OFFICIAL STATEMENT BELOWDERIVED REQUIREMENTPENDING NIST SME REVIEW

3.1.12 — Remote access monitoring and control

3.1 Access Control · NIST SP 800-171 Rev. 2 · The heading label is this site's navigational shorthand; the official language is the statement below.

Official requirement statement (verbatim)

Monitor and control remote access sessions.

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

What this requirement is after

Every way into the system from outside — VPN, remote desktop gateways, vendor support tools — is known, authorized, and observable. The failure mode is not usually the sanctioned VPN; it is the remote support tool someone installed to fix a printer that now accepts connections from anywhere.

Across revisions

Rev. 3 consolidates 3.1.12 through 3.1.15 into a single Remote Access requirement (03.01.12) covering usage restrictions, authorization, encryption, access control points, and privileged remote work.

Mapped practices

Brilliant at the Basics practices that support this requirement

Partial implementation supportModerate confidence

Why: Controlling remote access sessions begins with who can open one, and the practice puts phishing-resistant MFA on remote entry points first — its stated priority order — closing the credential-theft path that makes remote access the leading intrusion vector.

What this does not claim: Authentication strength addresses the control half for the sanctioned pathways only. The requirement's monitoring half — session logging, visibility, someone reviewing — is not produced by MFA, and unauthorized remote pathways that bypass the identity provider entirely must be found and closed by separate work.

Practice-side activities
  • Enforce phishing-resistant MFA on VPN, remote desktop gateways, and remote portals before the general workforce rollout
  • Block legacy authentication on remote entry points so no path accepts a bare password
Evidence this produces
  • Enforcement policy exports scoped to remote access applications
  • Remote sign-in logs showing MFA required across sampled sessions

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

Partial implementation supportModerate confidence

Why: Brokered, logged, time-bound remote access is this requirement's substance enacted for OT: every vendor and off-site pathway inventoried, sessions arriving through a monitored broker, and session records reviewed.

What this does not claim: This mapping applies only to OT components that process, store, or transmit CUI, or that provide security protection for those components — organizational scoping determines applicability. The practice also covers OT and vendor pathways only; workforce remote access into the corporate IT estate, which the requirement equally covers, is outside its scope.

Practice-side activities
  • Inventory every remote and vendor pathway into OT, including modems and cellular links, and disable the unowned ones
  • Route remaining pathways through a brokered jump host with session logging
  • Enable access per session or window and disable it afterward
Evidence this produces
  • The remote-pathway inventory with owner and business reason per path
  • Broker session logs and the review records against them

Where this holds: Holds only where OT systems fall within the organization's CUI boundary.

Review status: Technical review complete · Reviewed by inDirectIT practitioner review — CUI security and NIST SP 800-171 engineering · updated 2026-08-06

Doing the work

Implementation considerations and evidence

Implementation considerationsIndependent guidance — tailor to your environment
  • Inventory the remote access pathways that actually exist, including vendor tools and anything listening from the internet, then eliminate the ones you did not choose.
  • Log remote sessions somewhere central — who connected, from where, for how long — and give someone the job of looking.
  • Constrain what remote sessions can reach rather than dropping them onto the flat network.
What operating evidence looks likeRecords worth retaining, not a submission checklist
  • A remote-pathway inventory with an owner and purpose per path
  • Session logs for the sanctioned pathways over a sampled period
  • Records of unauthorized remote tools found and removed

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 lands in Rev. 3

Provenance

Sources and review status

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