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

3.1.14 — Managed access control points

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)

Route remote access via managed access control points.

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

Remote access funnels through a small number of managed entry points — a VPN concentrator, a remote desktop gateway, a jump host — instead of scattering across per-machine back doors. Few doors, well watched, beats many doors nobody counts.

Across revisions

Withdrawn as a standalone slot in Rev. 3 (03.01.14); routing through managed access control points is carried inside the consolidated Remote Access requirement, 03.01.12.

Mapped practices

Brilliant at the Basics practices that support this requirement

Partial implementation supportModerate confidence

Why: A jump host in a controlled zone that all vendor and remote OT sessions must traverse is a managed access control point by definition — the practice's core architecture is the routing this requirement names.

What this does not claim: Covers the OT pathways only; the enterprise's own remote entry points need the same consolidation under separate work. The relationship also weakens wherever legacy links — modems, cellular gateways, vendor tunnels added at commissioning — still bypass the broker, which is precisely the population hardest to find and the reason the practice's pathway inventory must precede any coverage claim.

Practice-side activities
  • Establish the jump host in a DMZ or controlled zone and block remote paths that do not traverse it
  • Hunt and remove the bypass links: standing tunnels, modems, and cellular connections outside the broker
Evidence this produces
  • Firewall rules forcing remote OT access through the broker
  • The pathway inventory showing bypass links found and closed

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
  • Consolidate: block direct RDP, SSH, and vendor connections from the internet and route everything through the sanctioned entry points.
  • Treat vendor and OT access the same way — a brokered jump host in a controlled zone rather than tunnels that land directly on equipment.
What operating evidence looks likeRecords worth retaining, not a submission checklist
  • Firewall rules showing remote protocols reachable only via the managed points
  • An architecture diagram naming each access control point and what sits behind it

Suggested owners, derived from the mapped practices and artifacts: 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