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

3.5.1User and device identification

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)

Identify system users, processes acting on behalf of users, and devices.

NIST SP 800-171 Rev. 2 — Protecting CUI in Nonfederal SystemsNIST SP 800-171A — Assessing Security Requirements for CUI
Independent interpretation

What this requirement is after

Before anything can be controlled, every user, process, and device touching the system needs a distinct identity. Shared logins, generic service identities, and unidentified devices make every downstream control unenforceable and every log unattributable.

Across revisions

Rev. 3 splits this scope: user identification moves into 03.05.01 (with re-authentication made explicit) and device identification becomes its own requirement, 03.05.02.

Mapped practices

Brilliant at the Basics practices that support this requirement

DependencyModerate confidence

Why: A reconciled inventory of devices, accounts, and applications is what makes 'identify every user, process, and device' checkable at all — the practice produces the reference list this requirement's coverage is measured against.

What this does not claim: The inventory itself identifies nothing at authentication time. It provides the evidence base for the requirement; the identification mechanisms are separate work, and coverage must be evaluated within the organization's defined system boundary.

Practice-side activities
  • Reconcile identity-store accounts against the personnel and asset lists on a cadence
  • Register machine identities and service principals alongside hardware assets
Evidence this produces
  • Reconciliation report between directory and inventory
  • Machine-identity register with owners

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
  • Enumerate every identity store in use — directory, cloud tenant, application-local accounts — before asserting anything about coverage.
  • Eliminate or explicitly register shared and generic accounts; where one must survive (a shop-floor kiosk, a lab bench), document who is accountable for it.
  • Extend identification to devices and service principals, not just people — machine identities are where this requirement is most often silently incomplete.
What operating evidence looks likeRecords worth retaining, not a submission checklist
  • An account listing per identity store with owner and purpose for every non-personal account
  • A device or machine-identity register reconciled against the asset inventory
  • A dated review showing shared accounts were found, justified, or removed

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