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

03.05.01User Identification, Authentication, and Re-Authentication

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

Independent summary of the official requirement

Requires uniquely identifying and authenticating system users, associating that unique identification with processes acting on behalf of those users, and re-authenticating users under organization-defined circumstances or situations.

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 user is one identifiable account, processes run under attributable identities, and there are defined moments — privilege elevation, session timeout, role change — where the system asks 'prove it again.' Shared logins and anonymous service processes are what this exists to end.

Across revisions

Combines the user-facing halves of Rev. 2's 3.5.1 and 3.5.2 and makes re-authentication an explicit, organization-defined element; device identification moves to its own requirement, 03.05.02.

Mapped practices

Brilliant at the Basics practices that support this requirement

Partial implementation supportModerate confidence

Why: Centralizing applications behind the identity provider — a step the MFA rollout forces — is what makes unique identification, authentication, and re-authentication enforceable in one place; session lifetime and sign-in frequency policy is where the re-authentication parameter gets implemented.

What this does not claim: The requirement covers every access path and adds organization-defined re-authentication circumstances the practice does not itself choose. Paths that never join the identity provider — local accounts, appliances — and the association of unique identities with running processes must be evaluated separately within the defined system boundary.

Practice-side activities
  • Move applications behind single sign-on as MFA enforcement expands
  • Configure session lifetime and re-authentication policy in the identity provider
Evidence this produces
  • SSO application register
  • Session and re-authentication policy exports

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
  • Centralize on one identity provider so unique identification is enforced in one place, and hunt the application-local accounts that bypass it.
  • Define the re-authentication circumstances explicitly — session lifetime, privileged actions, sensitive transactions — and let the identity platform enforce them rather than trusting habit.
  • Attribute service processes: named service accounts and managed identities, not scheduled jobs still running as a person who left last year.
What operating evidence looks likeRecords worth retaining, not a submission checklist
  • Identity-provider policy showing unique accounts plus session and re-authentication settings
  • An account listing free of shared logins, or with documented, owned exceptions

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