3.1.5Give people the least access they need in Rev. 3
Reworded: 03.01.05 Least Privilege. 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.1.5 Least Privilege
Assessment objectives · 800-171A
- [a] privileged accounts are identified
- [b] access to privileged accounts is authorized in accordance with the principle of least privilege
- [c] security functions are identified
- [d] access to security functions is authorized in accordance with the principle of least privilege
Rev. 3 · not adopted 03.01.05 Least Privilege
a. Allow only authorized system access for users (or processes acting on behalf of users) that is necessary to accomplish assigned organizational tasks.
b. Authorize access to [Assignment: organization-defined security functions] and [Assignment: organization-defined security-relevant information].
c. Review the privileges assigned to roles or classes of users [Assignment: organization-defined frequency] to validate the need for such privileges.
d. Reassign or remove privileges, as necessary.
Determination statements · 800-171A Rev. 3
- 03.01.05.a system access for users (or processes acting on behalf of users) is authorized only when necessary to accomplish assigned organizational tasks.
- 03.01.05.b[01] access to <A.03.01.05.ODP[01]: security functions> is authorized.
- 03.01.05.b[02] access to <A.03.01.05.ODP[02]: security-relevant information> is authorized.
- 03.01.05.c the privileges assigned to roles or classes of users are reviewed <A.03.01.05.ODP[03]: frequency> to validate the need for such privileges.
- 03.01.05.d privileges are reassigned or removed, as necessary.
Organization-defined parameters
- A.03.01.05.ODP[01] security functions for authorized access are defined.
- A.03.01.05.ODP[02] security-relevant information for authorized access is defined.
- A.03.01.05.ODP[03] the frequency at which to review the privileges assigned to roles or classes of users is defined.
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.1.5 → Rev. 3 03.01.05 Least Privilege
4 words kept, 10 removed, 56 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 to implement least privilege
- Added new ODP: security functions in which to authorize access
- Added new ODP: security-relevant informationin which to authorize access
- Added new ODP: frequency to review privileges assigned to roles/classes of users
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.01.05
Organizations employ the principle of least privilege for specific duties and authorized access for users and system processes. Least privilege is applied to the development, implementation, and operation of the system. Organizations consider creating additional processes, roles, and system accounts to achieve least privilege. Security functions include establishing system accounts and assigning privileges, installing software, configuring access authorizations, configuring settings for events to be audited, establishing vulnerability scanning parameters, establishing intrusion detection parameters, and managing audit information. Security-relevant information includes threat and vulnerability information, filtering rules for routers or firewalls, configuration parameters for security services, security architecture, cryptographic key management information, access control lists, and audit information.
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.1.5 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.
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.01.05
- bedrock-cmmc-api@89b8e8e:docs/reference/nist-800-171-rev3/normalized/rev3.json#requirements[]