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

03.01.01Account Management

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

Independent summary of the official requirement

Aligned to SP 800-53 AC-2: define the account types the system allows and prohibits; create, enable, modify, disable, and remove accounts under documented procedures; and specify authorized users, group and role membership, and access authorizations for each account. Access is authorized before it is granted, account use is monitored, and accounts are disabled within organization-defined time periods when they expire, lose their user, violate policy, or sit inactive. Account managers are notified within organization-defined periods of terminations, transfers, and changed need-to-know, and accounts are reviewed on an organization-defined frequency.

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 SystemsNIST SP 800-171A Rev. 3 — Assessing Security Requirements for CUI
Independent interpretation

What this requirement is after

Every account now has a managed life: someone approves it, someone knows why it exists, and something disables it on a clock when the person leaves or stops using it. For a small contractor the work is less about tooling than about wiring HR events to the directory — the classic finding is the departed employee whose account kept working for months. Service and vendor accounts are where the lifecycle most often silently breaks.

Across revisions

Rev. 2's 3.1.1 (limit system access to authorized users, processes, and devices) splits in Rev. 3: the account lifecycle becomes this requirement while enforcement of the resulting authorizations becomes 03.01.02. The lifecycle mechanics — defined account types, disablement clocks, notifications, periodic review — are newly explicit and parameterized.

Mapped practices

Brilliant at the Basics practices that support this requirement

DependencyModerate confidence

Why: Account management presumes a trustworthy answer to 'what accounts exist, and for whom?' The practice's reconciled inventory of identities, devices, and applications is the reference list against which account creation, disablement clocks, and periodic reviews are checked.

What this does not claim: An inventory neither authorizes nor disables anything. The lifecycle mechanics this requirement asks for — defined account types, disablement within defined periods, notification flows, periodic reviews — are separate work that the inventory only makes checkable. It contributes the evidence base, not the account management itself.

Practice-side activities
  • Reconcile identity-store accounts against personnel and asset records on a cadence
  • Register service and vendor accounts with owner and purpose alongside hardware assets
Evidence this produces
  • Reconciliation reports between directory and inventory
  • Service-account register with owners and review dates

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: The practice's core activity — knowing and limiting who can touch production systems — is account management applied to the OT estate: named users, authorized accounts, and removal when access is no longer needed are the shared substance.

What this does not claim: Supports implementation of the requirement for OT scope only, and OT reality bends the mechanics: shared HMI operator accounts may be unavoidable for line operations, vendor accounts may be contractually managed, and disablement clocks must respect systems that cannot be touched mid-run. Each deviation needs documentation and a compensating measure, and the IT estate's accounts sit outside this practice entirely.

Practice-side activities
  • Enumerate accounts on HMIs, engineering workstations, and controllers with named owners
  • Document and time-bound vendor accounts; deactivate them between service windows
  • Fold OT accounts into the periodic access review with the plant leader present
Evidence this produces
  • OT account register with owners and purposes
  • Review records showing OT accounts validated or removed
  • Vendor-account activation and deactivation records

Where this holds: OT and production environments; the enterprise directory and business systems need their own account management.

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
  • Write down which account types you allow (individual, administrator, service, shared-by-exception) and which you prohibit — the requirement now asks for the decision, not just the behavior.
  • Wire terminations and transfers to account disablement with a defined clock; same-day disablement for departures is achievable even manually if the handoff from HR is reliable.
  • Automate the inactivity sweep and calendar the periodic account review — a review that happens 'when someone remembers' is the gap assessors find first.
  • Treat service and vendor accounts as first-class: an owner, a purpose, and a review date for each.
What operating evidence looks likeRecords worth retaining, not a submission checklist
  • The documented account-type and lifecycle procedure naming the defined disablement periods
  • Directory records showing accounts disabled within the defined period after departure or inactivity
  • Dated periodic account-review output with the actions taken

Suggested owners, derived from the mapped practices and artifacts: IT leader · Plant / OT leader. 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 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