1Overview
AC.L2-3.1.5 is the control that names least privilege directly and extends it to its most sensitive case: the privileged accounts and the security functions themselves. Where 3.1.2 asks that ordinary users be limited to the transactions their role requires, 3.1.5 turns the same principle on the administrators and on the tools that protect the environment, which are the accounts an attacker most wants and the functions a careless configuration most often leaves open.
The requirement is worth three points and is technically eligible for a plan of action, but it is a cornerstone rather than a detail, because privilege is where the consequences of a compromise are decided. A standard user account that is compromised can damage what that user could reach; a privileged account that is compromised can damage everything. Least privilege is the discipline of ensuring that accounts, and especially privileged ones, hold only the access their function genuinely requires, and that the powerful security functions are reserved to the few who administer them. The control is satisfied when privilege has been deliberately minimized rather than granted by default and left to accumulate.
Employ the principle of least privilege, including for specific security functions and privileged accounts.
The requirement singles out two things beyond ordinary access. "Specific security functions" are the capabilities that manage the protections themselves: configuring the firewall, managing accounts, altering audit settings, changing security configurations. "Privileged accounts" are the administrator and equivalent accounts that can perform those functions. Least privilege applied here means these powers are held by as few people as the work allows, are separated from those people's everyday accounts, and are not handed out broadly for convenience.
2The Assessment Objectives
NIST SP 800-171A decomposes 3.1.5 into four objectives, covering least privilege in general, the security functions specifically, the privileged accounts specifically, and the use of non-privileged access for non-privileged work.
Privileged accounts are identified. The organization knows which accounts hold elevated rights, across systems, so that privilege can be governed rather than merely present.
Access to privileged accounts is authorized in accordance with the principle of least privilege. Elevated rights are granted only to those whose role genuinely requires them, and no more broadly.
Security functions are identified. The organization has identified the functions that manage the protections, such as account management, audit configuration, and firewall administration.
Access to security functions is authorized in accordance with the principle of least privilege. The functions that manage the protections are reserved to the specific roles that require them, not to every administrator.
The four objectives move from the general to the specific and from accounts to functions. A shop can identify its privileged accounts and still fail objectives [c] and [d] if every administrator holds identical, undifferentiated power, because least privilege for security functions requires distinguishing the functions and reserving them. This is the control that turns the flat "administrator can do anything" model into a graded one.
3Failure Patterns
The failures are patterns of privilege granted for convenience and never reclaimed, and of powerful functions left available to everyone with any administrative role.
The proliferation of administrators
Administrative rights spread over time because granting them solves an immediate problem, and reclaiming them never becomes anyone's task. A shop that would name two people who need admin rights often has ten who hold them, and each additional privileged account is another full-consequence target. Objective [b] fails on the count alone, before any question of what those accounts can specifically do.
The administrator who works all day as an administrator
A single account used for both everyday work and administration means every email opened and every website visited carries the full weight of privileged access, so an ordinary compromise becomes a total one. Least privilege expects privileged accounts to be separate from the daily-use accounts of the same people, used only when elevation is genuinely needed. The single combined account is convenient and is exactly the pattern the control exists to end.
Undifferentiated administrative power
Where every administrator can do everything, including disabling the audit log, altering security configurations, and opening the firewall, objectives [c] and [d] cannot be met, because the security functions were never separated from general administration. The person who resets passwords should not necessarily be able to turn off logging, and in a flat model they can.
Service accounts with standing high privilege
Non-human accounts frequently hold broad rights they were given at setup and never had trimmed, and because no person logs into them, no one reviews them. A service account with domain administrator rights is a privileged account under objective [a] and a least-privilege failure under [b], and it is among the most common findings because these accounts are invisible in daily work.
4Ownership
This control is owned primarily by IT, because it concerns the structure of administrative access, but the decision to reduce standing privilege needs leadership backing, since it removes convenience from trusted technical staff.
| Role | Responsibility for this control |
|---|---|
| IT lead or system administrator | Identifies the privileged accounts and security functions, reduces standing administrative rights to those who require them, separates privileged accounts from daily-use accounts, and reserves the security functions to specific roles. Owns most of the evidence. |
| Security or compliance lead | Defines which functions count as security functions and which roles may perform them, and confirms that the graded model matches the access design rather than a flat administrator model. |
| Program lead | Owns the periodic review of privileged accounts, since privilege granted between reviews is what erodes the control, and retains the review records. |
| Executive sponsor | Supports the reduction of standing privilege, which is the organizational obstacle: capable staff accustomed to broad access will experience least privilege as friction, and the sponsor sustains the decision. |
5Tooling
Least privilege for administration is built with the same directory and endpoint tooling as the rest of the access controls, applied specifically to the privileged tier. The work is in reducing and separating, not in acquiring.
| Objectives | Tooling | What it provides |
|---|---|---|
| [a] | Active Directory privileged-group enumeration, PowerShell reporting | Reporting on membership of Domain Admins, Enterprise Admins, local administrators, and equivalent groups produces the identified list of privileged accounts, human and service. |
| [b] | Restricted administrative groups, separate admin accounts, Local Administrator Password Solution | Trimming privileged-group membership to those who require it, and issuing administrators a separate elevated account distinct from their daily-use account, enforces least privilege for the accounts. LAPS manages local admin passwords where local access is genuinely needed. |
| [c], [d] | Role-based administrative tiers, delegated control, Conditional Access for admin roles | Delegating specific administrative functions to specific roles, and separating security-function rights from general administration, produces the graded model. Tiered administration keeps the powerful security functions with the few roles that require them. |
| Reinforcing | Privileged access workstations or just-in-time elevation where available | Where the environment supports it, elevating privilege only when needed and from a controlled context further limits standing privilege, though it is a maturity step rather than a baseline expectation. |
The caveat is the familiar one sharpened by stakes. Every tool above is present in a standard Windows environment; what is missing is the decision to take administrative rights away from people who have grown used to holding them. The assessor tests objectives [b] and [d] by enumerating who holds privileged rights and asking whether a general administrator can alter the security functions, and a flat model where everyone is an administrator answers both questions the wrong way no matter how the policy reads.
6Evidence
The satisfied version of 3.1.5 shows the privileged accounts identified, the rights reduced to those who need them, and the security functions reserved to specific roles.
| Evidence | What it demonstrates |
|---|---|
| Privileged account inventory | Objective [a]. The list of accounts with elevated rights, human and service, and what each administers. |
| Privileged group membership exports | Objective [b]. Current membership of administrative groups, showing rights are held only by those whose role requires them. |
| Separation of admin and daily-use accounts | Objective [b]. Evidence that administrators use distinct elevated accounts rather than working all day with privilege. |
| Security-function role definition | Objectives [c], [d]. The documented set of security functions and the roles permitted to perform each. |
| Privileged access review records | Dated reviews of privileged accounts and rights, showing privilege is reclaimed as roles change rather than only granted. |
The evidence must describe the environment as it runs, because the assessor will enumerate the real privileged accounts and test whether a general administrator can reach a security function, and it must show review over time, since privilege that is granted but never re-examined drifts back toward the flat model the control exists to prevent. This control also reinforces several others: the reduced, identified privileged tier built here is what makes separation of duties, audit protection, and configuration control enforceable rather than nominal.
Reducing privilege is a decision before it is a configuration
The technical work of trimming administrative rights is quick; the hard part is deciding to do it and holding the line when trusted staff feel the friction. Working through which privileges are genuinely required, separating administrative accounts from daily use, and reserving the security functions is part of the onsite readiness work this practice does.
Start CMMC Readiness or call 802-335-26627Sources
- NIST Special Publication 800-171 Rev 2, Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations, requirement 3.1.5. csrc.nist.gov
- NIST Special Publication 800-171A, Assessing Security Requirements for Controlled Unclassified Information, assessment objectives 3.1.5[a] through 3.1.5[d]. csrc.nist.gov
- 32 CFR 170.21, Plan of Action and Milestones Requirements, governing which requirements may remain open at a Level 2 assessment. ecfr.gov