Least Privilege - Privileged Accounts is the privileged-account slice of least privilege, carved out of the general principle into its own requirement. Where Least Privilege (03.01.05) holds every user and process to the minimum access necessary, Least Privilege - Privileged Accounts (03.01.06) narrows the focus to the small population of accounts that carry elevated rights and answers two questions about them: who is allowed to hold a privileged account, and what those privileged users must do when they are not performing privileged work. Its sibling, Least Privilege - Privileged Functions (03.01.07), governs the functions themselves. Per the NIST discussion, privileged accounts are the ones granted elevated privileges to access resources (including security functions or security-relevant information) that are otherwise restricted, and are typically described as system administrator or super user accounts. As with the rest of the access control family, 03.01.06 defines the restriction and 03.01.02 Access Enforcement is where that restriction is actually applied.
A common difficulty with this requirement is treating "restrict privileged accounts" as the whole requirement and missing the second half. The requirement is not only about limiting who gets an administrator account. It also requires that the people who do hold those accounts stop using them for everyday, non-security work. The single most common violation is an administrator who reads email, browses the web, and writes documents while logged in with a domain administrator account. That behavior fails part b of this requirement even if the account population is perfectly restricted.
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.06 Least Privilege - Privileged Accounts. Only the formatting has been adjusted for readability. This requirement has two (2) lettered parts:
The source controls are AC-06(02) and AC-06(05) from NIST 800-53. Part a contains a bracketed assignment, which is the Organization-Defined Parameter (ODP): the personnel or roles allowed to hold privileged accounts. The NIST discussion explains the intent of both parts. Restricting privileged accounts to specific personnel or roles ensures that only those authorized users can access and manipulate security functions or security-relevant information. Requiring the use of non-privileged accounts when such access is not needed limits unauthorized access to and manipulation of security functions or security-relevant information. You can read the requirement directly at NIST 800-171 R3, 03.01.06 (p. 11).
One (1) value sits inside this requirement. Depending on your contract, your organization may be permitted to define it. Organizations in the DIB subject to CMMC are not, because the DoD has defined it as policy.
The value below comes 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 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.06 into three (3) assessment objectives: one (1) Organization-Defined Parameter (ODP) and two (2) determination statements. These AOs are:
The ODP is the parameter you have to nail down before the other two (2) objectives can be assessed. If you are a DoD contractor, do not treat it as an open question. Per the DoD-specified ODP value in ComplianceForge's NIST 800-171 R3 Transition Guide, the personnel or roles are set to "only defined and authorized personnel or administrative roles," so the population that may hold privileged accounts is not a free choice for DoD work. The full guidance on assessment methods and objects, is in NIST 800-171A R3, 03.01.06 (p. 12).
Examine: access control policy and procedures; procedures for least privilege; list of system-generated privileged accounts; list of system administration personnel; system audit records; system configuration settings; system security plan; list of system-generated security functions or security-relevant information assigned to system accounts or roles.
Interview: personnel with responsibilities for defining least privileges; personnel with information security responsibilities; system administrators.
Test: mechanisms for implementing least privilege functions.
03.01.06 maps from NIST 800-171 R2 requirement 3.1.6 (use non-privileged accounts or roles when accessing nonsecurity functions), and it also pulls in the privileged-account concept that R2 kept inside 3.1.5:
Mapped against the three (3) AOs, all three (3) are indirect (moderate effort), with no net-new AOs and none with no mapping. On the surface that reads like a clean carry-forward, but the count hides a restructuring. In R2, the idea of restricting privileged accounts lived in 3.1.5, the non-privileged-account-usage rule lived in 3.1.6, and the separation of user functionality from system management functionality lived in 3.13.3. R3 withdrew 3.13.3 and consolidated these threads into a single privileged-accounts requirement. That means the work is not brand new, but where it lives changed, so you should re-verify that your existing separation of privileged and non-privileged use still holds under the R3 wording rather than assuming your old 3.1.6 evidence covers it as-is.
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.06 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 following are issues teams may encounter rather than certainties. They are about the second half of the requirement and the consolidation from R2, 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.06 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.06 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.06 recording the ODP values you adopted.
With all three (3) AOs mapping indirectly and none net new, 03.01.06 is a moderate lift, but the restructuring from R2 means you should re-analyze rather than copy forward. A realistic sequence:
What value does the DoD require for the organization-defined parameter in NIST 800-171 R3 03.01.06? 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.06.a: only defined and authorized personnel or administrative roles.
How many assessment objectives does NIST 800-171 R3 03.01.06 have? NIST 800-171A R3 breaks 03.01.06 into three (3) assessment objectives: one (1) Organization-Defined Parameters (ODPs) and two (2) 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.06 come from? AC-06(02), AC-06(05).
Where does NIST 800-171 R3 03.01.06 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.06 Least Privilege - Privileged Accounts restricts who may hold a privileged account and requires those privileged users to drop to a non-privileged account for everyday, non-security work. It maps from R2 3.1.6 with all three (3) assessment objectives transitioning indirectly, so there is no net-new objective, but R3 pulled privileged accounts out of 3.1.5, withdrew 3.13.3, and consolidated the pieces here. The traps are stopping at "restrict the accounts" and missing the dual-account rule, and assuming the personnel-or-roles ODP is yours to set when DoD has specified it. Define the authorized population, restrict privileged accounts to it, require non-privileged accounts for non-security work, 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.
