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

3.5.6 — Inactive identifier handling

3.5 Identification and Authentication · 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)

Disable identifiers after a defined period of inactivity.

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

Accounts that nobody has used in months are standing doors with nobody watching them. Identifiers are disabled automatically after a defined period of inactivity, so departures and role changes that slipped past process still get caught.

Across revisions

Rev. 3 withdraws the standalone requirement (03.05.06) and carries inactivity handling inside Identifier Management, 03.05.05.

Mapped practices

Brilliant at the Basics practices that support this requirement

Operational supportModerate confidence

Why: The practice's account-inventory reconciliation is the operational routine that surfaces dormant identifiers — the same accounts this requirement wants disabled after defined inactivity.

What this does not claim: Surfacing dormant accounts is not disabling them: the requirement needs a defined threshold and an enforcement mechanism, which the inventory practice does not itself configure. Provides evidence relevant to the requirement rather than implementing it.

Practice-side activities
  • Include a last-sign-in column in the account reconciliation
  • Feed dormant-account findings into an automated disablement sweep
Evidence this produces
  • Dormant-account findings from reconciliation runs
  • Records of accounts disabled as a result

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
  • Automate the sweep — an inactivity report someone runs 'when they remember' is the failure mode this requirement exists to prevent.
  • Exempt-list deliberately: break-glass and seasonal accounts need documented owners and review dates, not silent exclusion.
What operating evidence looks likeRecords worth retaining, not a submission checklist
  • The configured inactivity threshold and the automation that enforces it
  • Periodic reports of accounts disabled by the sweep, retained as operating evidence

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

Artifacts

Templates and worksheets with a mapped relationship

No artifact in the library names this requirement yet. The library index groups everything by category and practice.

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