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

03.05.05 — Identifier Management

03.05 Identification and Authentication · NIST SP 800-171 Rev. 3

Independent summary of the official requirement

Requires receiving authorization from organizational personnel or roles before assigning identifiers to individuals, groups, roles, services, or devices; selecting and assigning those identifiers; preventing identifier reuse for an organization-defined time period; and managing individual identifiers by uniquely identifying each individual with an organization-defined characteristic, such as contractor status.

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

Identifiers — usernames, service names, device names — get a managed lifecycle: assignment is authorized, names are chosen deliberately, retired identifiers are not recycled while logs and file ownership still point at them, and the directory can tell an employee from a contractor at a glance.

Across revisions

Consolidates Rev. 2's identifier handling: reuse prevention (3.5.5) carries in directly, the dormant-identifier concern behind 3.5.6 is absorbed into lifecycle management rather than standing alone, and authorization plus an individual-status characteristic are new explicit elements.

Mapped practices

Brilliant at the Basics practices that support this requirement

Operational supportModerate confidence

Why: The practice's account-inventory reconciliation is the routine that keeps identifier management honest — surfacing dormant identifiers, unowned service accounts, and departures that slipped past process, which is the population every lifecycle decision in this requirement acts on.

What this does not claim: Surfacing identifiers is not authorizing, assigning, or quarantining them: the requirement's authorization step, reuse-prevention period, and individual-status characteristic are procedure and directory work the inventory does not perform. Provides the checkable population and operating evidence rather than implementing the requirement.

Practice-side activities
  • Reconcile directory identifiers against personnel and asset lists on a cadence
  • Include last-sign-in and ownership columns so dormant and orphaned identifiers surface
Evidence this produces
  • Reconciliation reports with dormant-identifier findings
  • Records of lifecycle actions taken on those findings

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
  • Fold identifier authorization into onboarding: the same approval that creates an account is the record this element wants.
  • Never reusing identifiers is easier than tracking a quarantine period, and it keeps forensics and attribution clean indefinitely.
  • Carry the status characteristic in the directory — a contractor/employee attribute or naming convention — so access reviews can see it without a lookup.
What operating evidence looks likeRecords worth retaining, not a submission checklist
  • Provisioning records showing authorization before assignment
  • The written identifier rules: format, reuse period, status characteristic
  • Directory samples showing retired identifiers held rather than recycled

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 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