least privilege
termStands for: principle of least privilege (PoLP)
Giving each user or process only the access it needs to do its job, and no more.
The principle of least privilege shrinks the blast radius of any compromise: an account that can do little is worth little to an attacker. It is simple to state and endlessly hard to maintain, which is why access reviews exist. The statement is Saltzer and Schroeder's, from The Protection of Information in Computer Systems: "Every program and every user of the system should operate using the least set of privileges necessary to complete the job", with the observation that "the military security rule of 'need-to-know' is an example of this principle"; it is one of their eight design principles. NIST's glossary gives the modern wording from SP 800-53: "the principle that a security architecture is designed so that each entity is granted the minimum system resources and authorizations that the entity needs to perform its function", and the catalogue's control AC-6 requires organisations to "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". The enhancement that keeps it true over time is AC-6(7), a periodic review of assigned privileges, because privileges that were necessary once accumulate into privilege creep.
Least privilege is the oldest rule in access control and the one most often stated and least often kept. The canonical statement is Saltzer and Schroeder's, in The Protection of Information in Computer Systems, the paper presented at the Fourth ACM Symposium on Operating System Principles in October 1973 and published in Communications of the ACM in July 1974, in the web edition cited. Their principle (f) reads: "Every program and every user of the system should operate using the least set of privileges necessary to complete the job." They explain that it limits the damage an accident or an error can do and reduces the number of potential interactions among privileged programs, and they add that "the military security rule of 'need-to-know' is an example of this principle". It sits in a list of eight: economy of mechanism, fail-safe defaults, complete mediation, open design, separation of privilege, least privilege, least common mechanism and psychological acceptability, and the separation of duties entry picks up the one before it.
The modern definitions keep the sense. NIST's glossary gives, from CNSSI 4009 by way of SP 800-12, "a security principle that a system should restrict the access privileges of users (or processes acting on behalf of users) to the minimum necessary to accomplish assigned tasks", and from SP 800-53 Rev. 5, "the principle that a security architecture is designed so that each entity is granted the minimum system resources and authorizations that the entity needs to perform its function". The control catalogue turns the principle into a requirement in AC-6: "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", and its discussion extends the rule to system processes, which should "operate at privilege levels no higher than necessary", and tells organisations to create additional processes, roles and accounts where that is what least privilege needs.
The principle shrinks the blast radius of any compromise: an account that can do little is worth little to an attacker, a process that can write only its own files cannot encrypt everyone else's, and a network device administrator whose TACACS+ authorisation stops at show commands cannot be tricked into changing a route. It is simple to state and endlessly hard to maintain, because the privileges a person needs change with every project, transfer and emergency, and each change adds and few remove. That is the subject of the privilege creep entry, and the catalogue's answer is AC-6(7), Review of User Privileges: "Review the privileges assigned to roles or classes of users to validate the need for such privileges" at a defined frequency, and "reassign or remove privileges, if necessary, to correctly reflect organizational mission and business needs", because, in the control's discussion, "the need for certain assigned user privileges may change over time". AC-2(3) adds the housekeeping, disabling accounts that have expired, are no longer associated with a person, violate policy or have been inactive, which the catalogue says "supports the concepts of least privilege and least functionality which reduce the attack surface of the system".
In practice least privilege is implemented through the models the neighbouring entries describe: roles that bundle what a job needs and nothing else, attributes that add conditions, separation of duties that keeps dangerous combinations apart, and the AAA protocols that enforce the result at a port, a device or an application. The question to ask of any grant is the one Saltzer and Schroeder asked: is this the least set of privileges necessary to complete the job, and when the job ends, who takes it away.
Also known as: least-privilege, polp, principle of least privilege, need-to-know, minimum necessary access
Sources
- Saltzer and Schroeder, The Protection of Information in Computer Systems (Communications of the ACM 17(7), July 1974, per the web edition read): design principle (f), least privilege, and the need-to-know example (read 2026-10-06)
- NIST CSRC glossary, least privilege: the CNSSI 4009, SP 800-53 Rev. 5 and SP 800-171r3 definitions (read 2026-10-06)
- NIST SP 800-53 Rev. 5 control catalogue, OSCAL edition 5.2.0: AC-6 Least Privilege and its discussion, AC-6(7) Review of User Privileges, AC-2(3) Disable Accounts (read 2026-10-06)