Least privilege — SY0-701

What it is

Least privilege is the security principle that each entity — a user, a program, or a process — is granted the minimum system resources and authorizations that the entity needs to perform its function, and nothing more. (NIST SP 800-53 Rev. 5 / NIST SP 800-171r3)

A complementary framing from NIST SP 800-12 Rev. 1 and CNSSI 4009-2015 emphasizes access privileges specifically: the system restricts a user's (or process's) privileges to the minimum necessary to accomplish assigned tasks.

Mental model

Think of access like keys on a key ring. A building maintenance worker needs keys to the mechanical room, the supply closet, and perhaps the loading dock — not the executive suite, not the server room, and not the safe. Handing out only the keys each role actually requires is least privilege in practice. Adding a key "just in case" violates the principle, even if the key is never used.

The key-ring frame also highlights what least privilege governs: authorizations and system resources (NIST SP 800-53 Rev. 5 language), not merely what a person knows — that distinction matters when the exam tests the boundary with need-to-know.

When to use it

Least privilege is frequently tested alongside need-to-know. The two principles overlap but are not the same, and choosing the wrong one is a reliable source of exam errors.

Dimension	Least privilege	Need-to-know
What it governs	System resources and authorizations — rights to act (execute, write, delete, administer)	Access to specific information — rights to read or receive particular data
Scope	Applies to users, programs, and processes across the system architecture (NIST SP 800-53 Rev. 5)	Applies to a prospective recipient of specific classified or official information (CNSSI 4009-2015)
Who decides	Enforced through the security architecture and access-control policy	Determined by an authorized holder of the information (CNSSI 4009-2015)
Typical control mechanism	Role-based permissions, privilege separation, privileged-account restrictions	Information compartmentalization, classification labels
Example	A web server process has write rights only to its own log directory, not the entire filesystem	An analyst is cleared for SECRET but may only read a specific compartment because their role requires it

When a scenario describes restricting what a user can do (execute commands, modify files, run services), lean toward least privilege. When the scenario describes restricting what information a user can see, lean toward need-to-know.

Common misconception

"Least privilege only applies to human users."

The NIST definitions are explicit that the principle covers users and processes and programs (NIST SP 800-12 Rev. 1; NIST SP 800-53 Rev. 5). A service account running a scheduled job, a containerized application, or an automated script must each operate under the minimum authorizations required for its function. Candidates who frame least privilege purely as a user-account concept will misread scenarios involving service accounts, application permissions, or process-level access and select answers that address only the human side of the problem.

A second, related trap: candidates sometimes equate least privilege with simply having a privileged account (NIST SP 800-53 Rev. 5: "an information system account with the authorizations of a privileged user"). A privileged account exists to perform functions that require elevated rights; least privilege means that even the privileged account holds only the minimum elevated rights needed for its assigned function — not unrestricted administrative access.

How it shows up on the exam

The cognitive target for this concept is application: given a scenario describing an access design decision or a misconfiguration, recognize whether least privilege is being followed or violated.

Signal phrases in scenario stems that point toward a least-privilege analysis:

• A service, process, or account that has "more access than needed" or "full administrative rights"
• A recommendation to "limit" or "restrict" what a user or process can do
• A post-incident finding that a compromised account had access well beyond its job function
• A design question about how to grant a contractor or application only the permissions required

Candidates often confuse least privilege with need-to-know (see the table above) or with separation of duties. Separation of duties distributes critical tasks across multiple entities to prevent any one entity from completing a sensitive action alone — a structurally different control from restricting what rights each entity holds.

When evaluating answer choices, ask: does this option describe the minimum authorizations and resources an entity needs to perform its function? That phrasing, drawn directly from NIST SP 800-53 Rev. 5, is the reliable test.

Related concepts

• Network segmentation — dividing a network into zones so that access between segments is controlled; enforces least privilege at the network layer
• Access control lists — the mechanism commonly used to implement least-privilege permissions on resources
• System hardening — removing unnecessary services, accounts, and permissions; operationalizes least privilege across the system baseline