Privileged access
Least privilege
Grant only the access a task needs, for people, admins and workloads alike. What SP 800-53 AC-6 and AC-5 actually ask for, and how to keep it true over time.
Least privilege means each user, and each process acting for a user, gets only the access needed for the task it is assigned. Nothing more, and for no longer than needed. The idea is old and simple. Applying it is hard because access tends to grow quietly over time. This page covers what NIST SP 800-53 Rev. 5 actually asks for (AC-6 and its enhancements, plus AC-5 separation of duties), how the principle applies to people, administrators and workloads, and how to keep it true after the first cleanup.
What the control says
The base control in SP 800-53 Rev. 5 is AC-6, Least Privilege:
Employ the principle of least privilege, allowing only authorized accesses for users (or processes acting on behalf of users) that are necessary to accomplish assigned organizational tasks.
Two things in the AC-6 discussion matter in practice. First, the principle covers system processes, not just people. Processes should run "at privilege levels no higher than necessary". Second, NIST expects you to create more accounts and roles where that is what it takes: organizations "consider the creation of additional processes, roles, and accounts as necessary to achieve least privilege". One account per human that does everything is the opposite of that.
SP 800-207 (Zero Trust Architecture) makes the same point about where to start. Its initial focus is restricting resources to those who need them and granting "only the minimum privileges (e.g., read, write, delete) needed to perform the mission".
The AC-6 enhancements, one by one
AC-6 has ten enhancements. The seven below are the ones that shape privileged access day to day. The wording is paraphrased from the Rev. 5 text, and the bracketed values are yours to define.
| Enhancement | What it asks for | What it looks like in practice |
|---|---|---|
| AC-6(1) Authorize access to security functions | Explicitly authorize named individuals or roles to use defined security functions and security-relevant information. | A written list of who may create accounts, change permissions, edit audit settings, firewall rules or key-management material. |
| AC-6(2) Non-privileged access for nonsecurity functions | Users who hold security functions use non-privileged accounts or roles for everything else. | Administrators read email and browse the web from a normal account. They switch to a separate admin account, or an elevated role, only for admin work. |
| AC-6(3) Network access to privileged commands | Allow network (non-local) access to defined privileged commands only for compelling operational needs, and record the rationale in the security plan. | Remote administration paths are an exception you justify, not the default. |
| AC-6(5) Privileged accounts | Restrict privileged accounts to defined personnel or roles. | Day-to-day users cannot hold superuser or administrator accounts. |
| AC-6(7) Review of user privileges | Review assigned privileges at a defined frequency to confirm they are still needed, then reassign or remove them. | Periodic access reviews. See access reviews. |
| AC-6(9) Log use of privileged functions | Log the execution of privileged functions. | Admin actions produce audit records that someone can search and alert on. |
| AC-6(10) Prohibit non-privileged users from executing privileged functions | Prevent non-privileged users from executing privileged functions, such as disabling security controls, creating accounts or managing cryptographic keys. | Enforced by access enforcement (AC-3), not by trusting users to behave. |
The other three are AC-6(4), separate processing domains (for example, virtualization that allows finer-grained privilege); AC-6(6), which prohibits privileged access by non-organizational users; and AC-6(8), which prevents defined software from running at a higher privilege level than the user who runs it.
Separation of duties (AC-5)
Separation of duties is the companion principle. AC-5 asks you to identify and document the duties that need to be separated, and to define access authorizations that support that separation. Its discussion gives a concrete example: the people who administer access control functions should not also administer audit functions. Otherwise one person could grant themselves access and then erase the record.
Some actions are risky enough that no single person should be able to perform them at all. For those, SP 800-53 has AC-3(2), Dual Authorization ("two-person control"): defined privileged commands require approval by two authorized individuals. The AC-3(2) discussion notes the trade-off: organizations consider the risk of dual authorization where immediate responses are necessary to ensure public and environmental safety.
Typical duties to separate:
- Requesting access versus approving it.
- Writing code versus approving it for production, and deploying it.
- Administering a system versus administering its audit logs.
- Creating a payee or vendor versus releasing a payment to it.
Applying it to humans, admins and workloads
Ordinary users
Start from the job, not the person. Define what a role needs to read, change and approve. Grant that through groups or roles, never by copying "the same access as Alice". Copied access carries over every exception Alice ever had.
Administrators
Administrators are where least privilege pays off most, because their accounts are what attackers want. Three patterns follow directly from the controls above:
- Separate accounts or roles (AC-6(2)): a normal identity for daily work and a distinct privileged identity or role for admin work. See privileged accounts.
- Scoped admin roles (AC-6(1), AC-6(5)): a help-desk role that can reset passwords for ordinary users is not a global administrator. Most platforms offer narrower built-in roles than people use.
- Time-bound elevation: privilege that exists only while it is in use. See just-in-time access.
Workloads and service identities
AC-6 explicitly covers processes. A deployment pipeline that can modify every resource in an account, a database user with owner rights for an application that only reads, or a cloud role with a wildcard action are least-privilege failures. They are also the ones scanners rarely flag. Scope workload permissions to specific actions on specific resources, and give each workload its own identity so a compromise stays contained. See service accounts and secrets.
Role-based versus attribute-based access
SP 800-53 names both models. AC-2(7) asks you to administer privileged user accounts "in accordance with" either a role-based or an attribute-based access scheme. AC-3(7) and AC-3(13) define each one as an enforcement policy.
| Role-based (RBAC) | Attribute-based (ABAC) | |
|---|---|---|
| Decision input | The roles assigned to the subject. | Attributes of the subject, the action, the resource and the environment (for example time of day or location). |
| Strength | Easy to understand and review. Privileges are attached to roles, not to each user (AC-3(7) discussion). | Expresses context that roles cannot: "only during an approved change window", "only for records in your own region". |
| Typical failure | Roles grow too broad. AC-3(7) warns that RBAC can raise risk if role members get access beyond what they need. | Policies become hard to read and review, and attribute quality becomes a security dependency. |
Most real systems combine the two: roles for the coarse grant, attributes or conditions to narrow it. AC-2(6), dynamic privilege management, describes the attribute-driven end of this: privileges that change at runtime based on rules, including immediate revocation.
Entitlement creep
Entitlement creep is the slow growth of a person's access as they change jobs, join projects and receive one-off grants that nobody removes. It is the main way a well-designed role model decays. The figure shows the classic case: a mover who keeps the old role.
The controls that counter creep are spread across AC-2 and AC-6:
- AC-2 h: notify account managers within a defined period when users are transferred or their need-to-know changes, so access is adjusted on the move, not at the next review.
- AC-2(7)(d): revoke access when privileged role assignments are no longer appropriate.
- AC-6(7): review privileges periodically and remove what can no longer be justified.
- AC-2(3): disable accounts that are expired, no longer associated with a user, in violation of policy, or inactive beyond a defined period.
A practical rule that follows from these (a common practice, not a NIST requirement): on a transfer, remove the old role by default and let the new manager request anything that is still needed.
Checklist
- Every role has a written purpose and an owner, and grants are made through roles or groups, not by copying another user.
- Administrators use a separate account or an explicit elevated role for privileged work (AC-6(2)).
- The list of people allowed to perform security functions is explicit and short (AC-6(1), AC-6(5)).
- Duties that must be separated are documented, and access rules enforce them (AC-5). The most dangerous actions require two people (AC-3(2)).
- Privileged actions are logged and the logs are reviewed (AC-6(9)).
- Transfers trigger access changes, not just new grants (AC-2 h).
- Privileges are reviewed on a defined schedule, with the riskiest reviewed most often (AC-6(7)).
- Each workload has its own identity with permissions scoped to the actions and resources it uses.
For a printable version, use the least privilege checklist.
Sources
- NIST SP 800-53 Rev. 5: Security and Privacy Controls for Information Systems and Organizations, NIST. Public domain (U.S. government work).
- NIST SP 800-207: Zero Trust Architecture, NIST. Public domain (U.S. government work).