3.5.1Give every user, process, and device an identity in Rev. 3

Reworded: 03.05.01 User Identification and Authentication. Gains organization-defined parameters.

Status as of 2026-09-08

Rev. 2 is what a contract requires today. DFARS 252.204-7012 and the CMMC rule at 32 CFR 170 point at NIST SP 800-171 Rev. 2, and a standing DoD class deviation keeps it there. NIST has published Rev. 3, but publishing a revision does not change an obligation. A move to Rev. 3 would arrive through the Department's reform process and formal rulemaking, a change to that deviation or an amendment to the rule, not through publication. The Department has published its organization-defined parameter values for Rev. 3 in preparation; that is groundwork, not adoption.

Side by side

Rev. 2 · in force 3.5.1 Identification

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

Assessment objectives · 800-171A

[a] system users are identified
[b] processes acting on behalf of users are identified
[c] devices accessing the system are identified

Rev. 3 · not adopted 03.05.01 User Identification and Authentication

a. Uniquely identify and authenticate system users, and associate that unique identification with processes acting on behalf of those users.

b. Re-authenticate users when [Assignment: organization-defined circumstances or situations requiring re-authentication].

Determination statements · 800-171A Rev. 3

03.05.01.a[01] system users are uniquely identified.
03.05.01.a[02] system users are authenticated.
03.05.01.a[03] processes acting on behalf of users are associated with uniquely identified and authenticated system users.
03.05.01.b users are reauthenticated when <A.03.05.01.ODP[01]: circumstances or situations>.

Organization-defined parameters

A.03.05.01.ODP[01] circumstances or situations that require re-authentication are defined.

Draws on Rev. 2 3.5.1.

Left: NIST SP 800-171 Rev. 2 and 800-171A, verbatim. Right: NIST SP 800-171 Rev. 3 and 800-171A Rev. 3, verbatim, with organization-defined blanks highlighted.

Word by word

The Rev. 2 requirement compared with its Rev. 3 successor. A mechanical comparison of the two verbatim texts, not an interpretation.

~~removed in Rev. 3~~ added in Rev. 3

Rev. 2 3.5.1 → Rev. 3 03.05.01 User Identification and Authentication

Uniquely identify and authenticate system users, and associate that unique identification with processes acting on behalf of those users. ~~and devices.~~ Re-authenticate users when [Assignment: organization-defined circumstances or situations requiring re-authentication].

9 words kept, 2 removed, 20 added. Rev. 3 statement labels omitted for the comparison.

What NIST says changed

New security requirement title
Aligned with SP 800-53, Rev 5 to provide more comprehensive detail on and foundational tasks for user identification, authentication, and re-authentication
Added new ODP: circumstances or situations requiring re-authentication

NIST, SP 800-171 Rev. 2 to Rev. 3 change analysis, class “Significant change”. At adoption, Bedrock files this under “Rework”.

NIST's Rev. 3 discussion for 03.05.01

System users include individuals (or system processes acting on behalf of individuals) who are authorized to access a system. Typically, individual identifiers are the usernames associated with the system accounts assigned to those individuals. Since system processes execute on behalf of groups and roles, organizations may require the unique identification of individuals in group accounts or the accountability of individual activity. The unique identification and authentication of users apply to all system accesses. Organizations use passwords, physical authenticators, biometrics, or some combination thereof to authenticate user identities. Organizations may re-authenticate individuals in certain situations, including when roles, authenticators, or credentials change; when the execution of privileged functions occurs; after a fixed time period; or periodically.

What this means for you now

Nothing changes in what you are assessed against until a class deviation or a published rule adopts Rev. 3. Keep meeting 3.5.1 as written in Rev. 2, and if you already choose a value for the parameters above in practice, write it down where your system security plan can find it.

Bedrock CMMC shows this same comparison against your own package, with your current status on the Rev. 2 side, so the day adoption lands the migration is a review, not a rewrite.

Back to the Rev. 2 vs Rev. 3 overview

Where this page's facts come from

Rev. 2 text and objectives: bedrock-cmmc-api@89b8e8e:migrations/004_reference_requirements.sql#Requirement.basicRequirement@rev2; bedrock-cmmc-api@89b8e8e:migrations/005_reference_objectives.sql#AssessmentObjective.description@rev2
Mapping and change class: bedrock-cmmc-api@89b8e8e:docs/reference/nist-800-171-rev3/normalized/r2_r3_transition_map.json#r2_to_r3
Rev. 3 03.05.01: bedrock-cmmc-api@89b8e8e:docs/reference/nist-800-171-rev3/normalized/rev3.json#requirements[]