Independent DIB implementation resource — not affiliated with or endorsed by the U.S. Department of WarView the official DoW campaign ↗
3.7.5OFFICIAL STATEMENT BELOWDERIVED REQUIREMENTPENDING NIST SME REVIEW

3.7.5Nonlocal maintenance authentication

3.7 Maintenance · 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)

Require multifactor authentication to establish nonlocal maintenance sessions via external network connections and terminate such connections when nonlocal maintenance is complete.

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

What this requirement is after

When a vendor or administrator maintains a system across an external network connection, the session must open with multifactor authentication and close when the work is done. The standing tunnel left up 'in case we need it' is precisely what this requirement prohibits.

Mapped practices

Brilliant at the Basics practices that support this requirement

Partial implementation supportHigh confidence

Why: Nonlocal maintenance sessions into production equipment are the vendor remote-access pathways this practice exists to govern, and its operating pattern matches the requirement's two clauses directly: sessions open through a brokered jump host with multifactor authentication, are enabled per engagement, and are disabled when the work ends rather than left standing.

What this does not claim: The practice governs pathways into OT; nonlocal maintenance of enterprise systems — vendor support tunnels into servers, RMM platforms, appliance consoles — is outside its scope and needs the same brokered treatment separately. The emergency-access procedure the practice rightly keeps for breakdowns must itself authenticate and terminate to the same standard, or it becomes the standing tunnel the requirement prohibits.

Practice-side activities
  • Route vendor maintenance through the brokered jump host with multifactor authentication at establishment
  • Enable access per engagement and disable it at completion, with the standing-access metric driven to zero
  • Coordinate pathway changes with operations and the vendor — a vendor cut off from a misbehaving system during a breakdown is a safety problem, not only a support problem
Evidence this produces
  • Broker configuration showing multifactor authentication required for entry
  • Session logs with establishment and termination times reconciled against work orders
  • The standing-access-outside-engagements count, at or trending to zero

Where this holds: Strongest for vendor and integrator maintenance of OT equipment; contributes nothing for the organization's IT-side nonlocal maintenance paths, which the requirement covers equally.

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: Where nonlocal maintenance sessions authenticate through the identity provider the practice governs — an administrator reaching servers over the VPN, a vendor account federated into the tenant — the practice's phishing-resistant multifactor enforcement covers the requirement's establishment clause for those paths.

What this does not claim: Covers only the paths that authenticate through the identity provider; vendor remote-support tools with their own authentication and appliance consoles reached directly bypass the enforcement entirely and are precisely where nonlocal maintenance tends to live. The requirement's second clause — terminating connections when maintenance is complete — is session lifecycle discipline the MFA rollout does not touch at all.

Practice-side activities
  • Bring vendor and maintenance accounts under identity-provider MFA enforcement where the tools permit it
  • Inventory the maintenance tools that authenticate outside the identity provider and flag them for separate treatment
Evidence this produces
  • Enforcement policy covering maintenance and vendor accounts
  • The list of maintenance paths outside the identity provider, each with an owner

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 every nonlocal maintenance path first: vendor remote-support tools, RMM platforms, appliance consoles reachable from outside. The pathway nobody wrote down is the one that fails this.
  • Broker sessions through a controlled entry point — a jump host or bastion — so multifactor authentication and session termination are enforced and evidenced in one place instead of per tool.
  • In OT, vendor links are commissioned and forgotten; per-engagement enablement with a written emergency-access procedure keeps support available without standing exposure.
What operating evidence looks likeRecords worth retaining, not a submission checklist
  • Broker or jump-host configuration showing multifactor authentication required
  • Session logs showing establishment and termination times per engagement
  • The nonlocal-maintenance pathway inventory with owners

Suggested owners, derived from the mapped practices and artifacts: OT / network administrator · Identity 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

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