Least Privilege is the principle that everything else in access control leans on, not a single feature you enable. Where Account Management (03.01.01) decides who gets an account and Access Enforcement (03.01.02) applies the authorizations tied to that account, Least Privilege (03.01.05) decides how small those authorizations should be. It holds every user and process to only the access necessary to accomplish assigned tasks, nothing more. Per the NIST discussion, least privilege is applied to the development, implementation, and operation of the system, which means it is a design principle you carry through the whole lifecycle rather than a box you check at the end. Note the division of labor with its neighbors: 03.01.05 defines the minimum-necessary authorizations, and 03.01.02 is where those authorizations are actually enforced. Two related pieces that used to live inside this requirement in R2 now have their own homes in R3: least privilege for privileged accounts moved to 03.01.06, and least privilege for privileged functions moved to 03.01.07.
A common difficulty with this requirement is assuming it transitions as cleanly as the requirements before it. It does not. R3 added periodic privilege review and privilege removal as assessment objectives, added access authorization for security-relevant information, and attached three (3) Organization-Defined Parameters (ODPs). For organizations on Department of Defense (DoD) contracts, those ODPs are not yours to set. DoD has already specified their values, including a mandatory review frequency, so the "organization-defined" label does not mean you get to decide.
Where things stand for companies facing the transition from NIST 800-171 R2 to R3:
The following is reproduced verbatim from NIST 800-171 R3, requirement 03.01.05 Least Privilege. Only the formatting has been adjusted for readability. Unlike 03.01.02 and 03.01.03, this requirement has four (4) lettered parts:
The source controls are AC-06, AC-06(01), AC-06(07), and AU-09(04) from NIST 800-53. Two of the lettered parts contain bracketed assignments, which are the ODPs. The NIST discussion is specific about what the brackets mean in practice. 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. You can read the requirement directly at NIST 800-171 R3, 03.01.05 (p. 10).
Three (3) values sit inside this requirement. Depending on your contract, your organization may be permitted to define them. Organizations in the DIB subject to CMMC are not, because the DoD has defined them as policy.
The values below come from Attachment A of the DoD Chief Information Officer (CIO) memorandum dated 10 April 2025 (signed David W. McKeown). The memo identifies each parameter by requirement sub-part, while NIST 800-171A R3 identifies the same parameter by ODP number. Both identifiers appear below so you can match your System Security Plan (SSP) language to either document.
The assigned value for 03.01.05.b.01, quoted from the memo:
at a minimum and if applicable: establishing system accounts and assigning privileges, configuring access authorizations, configuring settings for events to be audited, establishing vulnerability scanning parameters, establishing intrusion detection parameters, and managing audit information
The assigned value for 03.01.05.b.02, quoted from the memo:
at a minimum and if applicable: threat and vulnerability information, filtering rules for routers or firewalls, configuration parameters for security services, cryptographic key management information, security architecture, access control lists, and audit information
The memo states that its values "will be updated as necessary," so confirm against the current version before writing them into policy.
NIST 800-171A R3 breaks 03.01.05 into eight (8) assessment objectives. Unlike 03.01.03 and 03.01.04, this requirement has three (3) Organization-Defined Parameters (ODPs) in addition to five (5) determination statements. These AOs are:
The three (3) ODPs are the pivot point. If you are a DoD contractor, do not treat them as open questions. Per the DoD-specified ODP values in ComplianceForge's NIST 800-171 R3 Transition Guide, the security functions (ODP[01]) and security-relevant information (ODP[02]) are set to the NIST discussion lists "at a minimum and if applicable," and the review frequency (ODP[03]) is set to at least every twelve (12) months. That means the periodic privilege review in A.03.01.05.c is a hard annual floor for DoD work, not a schedule you invent. The full guidance on assessment methods and objects, is in NIST 800-171A R3, 03.01.05 (p. 11).
Examine: access control policy and procedures; procedures for least privilege; list of assigned access authorizations (i.e., privileges); system configuration settings; system audit records; list of security functions (implemented in hardware, software, and firmware); security-relevant information for which access must be explicitly authorized; list of system-generated roles or classes of users and assigned privileges; validation reviews of privileges assigned to roles or classes of users; records of privilege removals or reassignments for roles or classes of users; system security plan; system design documentation.
Interview: personnel with responsibilities for defining least privileges; personnel with information security responsibilities; system administrators.
Test: mechanisms for implementing least privilege functions; mechanisms for implementing reviews of user privileges.
03.01.05 maps from NIST 800-171 R2 requirement 3.1.5 (employ the principle of least privilege, including for specific security functions and privileged accounts):
Mapped against the eight (8) AOs, one (1) is direct (minimal effort), two (2) are indirect (moderate effort), two (2) have no clear mapping, and three (3) are net new, with the last two (2) categories both counting as significant effort. This is not the clean transition that 03.01.03 or 03.01.04 was. R2 3.1.5 bundled three ideas into one requirement: base least privilege, least privilege for security functions, and least privilege for privileged accounts. R3 pulled privileged accounts out into 03.01.06 and privileged functions into 03.01.07, kept base least privilege here, and then expanded it. The periodic review of privileges (A.03.01.05.c), the reassignment or removal of privileges (A.03.01.05.d), and access authorization for security-relevant information (A.03.01.05.b[02]) are genuinely new obligations, not reworded old ones. As ComplianceForge's NIST 800-171 R3 Transition Guide notes in its "Logical Access Control / Account Management" analysis, R3 also dropped the R2 AO that required privileged accounts to be identified (3.1.5[a]) and assumes that identification already exists, even though no R3 AO explicitly requires you to document it.
Source Controls in NIST 800-53 R5:
Secure Controls Framework (SCF) Crosswalk
Organizations running a single control set across multiple frameworks can satisfy 03.01.05 through the following SCF controls:
The crosswalks from NIST 800-171 R3 and NIST 800-171A R3 to the SCF are available at no cost through the SCF Set Theory Relationship Mapping (STRM): https://securecontrolsframework.com/start-here/set-theory-relationship-mapping-strm. The STRM also carries the relationship type for each mapping (Equal, Subset Of, Intersects With), which tells you whether an SCF control fully satisfies the requirement or only part of it. Mapping above taken from SCF 2026.3.
The pitfalls cluster around the net-new objectives and the ODPs, each of which needs documented evidence of due diligence and due care such as policies, standards, procedures, and configuration screenshots:
Reasonable objective evidence for an assessment is often subjective. The following examples of evidence to address NIST 800-171 R3 03.01.05 are sourced from the SCF Evidence Request List (ERL), available at https://securecontrolsframework.com/free-content/scf-download. These ERL artifacts are mapped to NIST 800-171 R3 03.01.05 through SCF controls. They establish a starting point for discussions on what an organization needs to have for evidence of due diligence and due care to withstand external scrutiny by an assessor or regulator.
Alongside these, keep the System Security Plan (SSP) narrative for 03.01.05 recording the ODP values you adopted.
With five (5) of the eight (8) AOs in the significant-effort category (two with no clear mapping and three net new), 03.01.05 is a heavier lift than the requirements before it. Budget for new process, not just new documentation. A realistic sequence:
What value does the DoD require for the first parameter in NIST 800-171 R3 03.01.05? R3 leaves the value to the organization. For the DIB, the DoD set it in the 10 April 2025 memorandum under ODP identifier 03.01.05.b.01: at a minimum and if applicable: establishing system accounts and assigning privileges, configuring access authorizations, configuring settings for events to be audited, establishing vulnerability scanning parameters, establishing intrusion detection parameters, and managing audit information.
How many assessment objectives does NIST 800-171 R3 03.01.05 have? NIST 800-171A R3 breaks 03.01.05 into eight (8) assessment objectives: three (3) Organization-Defined Parameters (ODPs) and five (5) determination statements. An assessor works through each one separately, so each needs its own evidence.
Which NIST 800-53 R5 controls does NIST 800-171 R3 03.01.05 come from? AC-06, AC-06(01), AC-06(07), AU-09(04).
Where does NIST 800-171 R3 03.01.05 sit in the NIST 800-171 R3 Kill Chain? Phase 13, Identity & Access Management (IAM). The Kill Chain is a phased model for sequencing R3 implementation, and it assigns this requirement to that phase.
03.01.05 Least Privilege holds every user and process to the minimum access necessary and then makes you prove you keep it that way over time. It maps from R2 3.1.5, but only one assessment objective transitions directly, two transition indirectly, and five are significant effort because they either have no clear R2 mapping or are net new. The traps are treating it as a clean carry-forward, missing the new periodic review and removal objectives, and assuming the three (3) ODPs are yours to set when DoD has already specified them. Set the ODPs to the values your contract requires, scope authorizations to least privilege, authorize security functions and security-relevant information separately, then run a dated review-and-removal cycle at least annually and enforce all of it through 03.01.02.
Authoritative sources:
Authoritative sources:
This guide reproduces U.S. Government text from NIST 800-171 R3 and NIST 800-171A R3 and references the DoD ODP memorandum of 10 April 2025. It is educational, not legal or assessment advice. Last reviewed: 2026-09-22.
