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.04.05OFFICIAL TITLEPENDING NIST SME REVIEW

03.04.05 — Access Restrictions for Change

03.04 Configuration Management · NIST SP 800-171 Rev. 3

Independent summary of the official requirement

Requires defining, documenting, approving, and enforcing the physical and logical access restrictions associated with changes to the system.

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

Only defined people, from defined places, with defined rights get to change systems — physically and logically. Change approval means little if anyone with domain credentials can modify the firewall anyway.

Mapped practices

Brilliant at the Basics practices that support this requirement

Governance supportModerate confidence

Why: Access restrictions for change start with someone deciding who may change what and writing it down — and the practice's review process makes exactly that decision for the OT estate, then keeps the record of who changed what under whose approval.

What this does not claim: Deciding and recording approvers is not enforcing physical and logical access restrictions: engineering-workstation lockdown, management-network isolation, and panel access hardware are implementation work outside this practice. Contributes the governance the requirement's enforcement relies on rather than the restrictions themselves.

Practice-side activities
  • Name the roles authorized to approve and to perform OT changes
  • Keep the change record as the audit trail attributing changes to authorized individuals
Evidence this produces
  • The documented approver and performer roles
  • Change records attributing changes to authorized individuals

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
  • Tie change rights to role: administrative interfaces reachable only from management networks or hardened workstations, production changes only by named roles.
  • Remember the physical half — server rooms, network closets, and control panels are change surfaces too.
What operating evidence looks likeRecords worth retaining, not a submission checklist
  • Documented change-access restrictions and the configuration enforcing them
  • Access lists for change-capable roles, reviewed on a cadence

Suggested owners, derived from the mapped practices and artifacts: Plant / OT leader · IT leader. Ownership is a named person in your organization, not a role on a website.

Artifacts

Templates and worksheets with a mapped relationship

RECORD · REVIEW A PACKAGE IS COMPLETED FOR EVERY CHANGE; THE TEMPLATE ITSELF IS REVIEWED ANNUALLY AND AFTER ANY CHANGE-RELATED INCIDENTChange Request and Validation Package
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