Least privilege and defense in depth: two principles, two different jobs

Least privilege and defense in depth are the first two principles a security decision reaches for, and they are not interchangeable. Least privilege asks who may do what: it constrains one identity — a person, a process acting for that person, or a system process — to the accesses its assigned organisational task requires (NIST SP 800-53, AC-6). Defense in depth asks what happens when a control fails: it places controls at different architectural layers so one failure does not become one compromise (SP 800-53, PL-8(1)). One principle bounds an identity, the other bounds a failure, and neither substitutes for accountability.

The model: two boundaries, drawn in different places

LEAST PRIVILEGE — the boundary is drawn around one identity
  identity (a user, or a process acting for a user)
      ↓ authorisation
  [ only the accesses needed for the assigned task ]  →  everything else denied

DEFENSE IN DEPTH — the boundary is drawn in layers around one asset
  layer 1 (administrative) → layer 2 (technical, ✗ fails) → layer 3 (physical / monitoring)
      ↓  the independent layer behind the one that failed still holds

Least privilege draws a boundary around an identity and decides which accesses cross it; the assigned task defines its width. Defense in depth draws its boundary in layers around an asset and decides what keeps protecting it when a layer stops working. The identity is the unit of the first principle, the failure the unit of the second.

What least privilege actually requires

The control has three subjects — users, processes acting on behalf of users, and system processes — and applying it is a sequence, not a setting:

1. Name the assigned organisational task for each identity: the duty, not the person.
2. Grant only the accesses that task needs, for users and for the processes that act for them.
3. Apply the same rule to system processes, which must run at privilege levels no higher than their function requires.
4. Create narrower processes, roles or accounts rather than widening an existing one, and review the privileges when the task changes.

SP 800-12 Rev. 1 states the same idea as granting users “only those accesses required to perform their duties”; its glossary, citing CNSSI-4009, defines it as granting each entity the minimum resources and authorizations its function needs.

The control enhancements show what running the principle costs: AC-6(2) requires non-privileged accounts for non-security work, AC-6(3) authorises network access to privileged commands only for a compelling operational need with the rationale documented, and AC-6(9) requires that the execution of privileged functions be logged.

What defense in depth actually requires

PL-8(1) is explicit: design the architecture using a defense-in-depth approach that allocates controls to defined locations and architectural layers, and that ensures those controls operate in a coordinated and mutually reinforcing way. Its stated purpose is that an adversary must overcome multiple controls, which raises the work factor and increases the likelihood of detection.

SP 800-12 Rev. 1 describes the same principle as multi-layered countermeasures combining administrative, technical and physical defenses — policies and procedures, firewalls and configuration settings, gates and guards. The layers are different kinds of control at different points in the path, not a stack of duplicates.

Two boundaries, two different jobs

	Least privilege (AC-6)	Defense in depth (PL-8(1))
Question it answers	Who may do what	What happens when a control fails
Unit it is drawn around	One identity (user, process, system process)	One asset or system
What it limits	The reach of an identity	How far one failure propagates
Failure it addresses	An over-privileged or compromised account	A single layer that stops working
What it needs to be reviewed	Privilege reviews; logging of privileged functions	Control allocation per layer; independence between layers

The two boundaries reinforce each other without replacing each other. Least privilege narrows what a compromised identity can reach; defense in depth makes a single control failure survivable. A system can hold both and still fail for lack of either — a tightly scoped account whose escalation path is unlogged, or many layers that share one flaw.

Two misconceptions this sheet corrects

“More layers always means better security.” SP 800-53 warns that failure-protection strategies built on replication of policy enforcement mechanisms can keep a system secure when one mechanism fails, but that “if the mechanisms are similar, however, the additional protection may be illusory, as the adversary can simply attack in series”. Layers help when their features differ, which reduces the possibility of attack repetition; the discussion also notes that increased complexity generally reduces trustworthiness.

“Least privilege means giving everyone a standard user account.” That is a symptom, not the principle. Least privilege applies to users, to processes acting for users and to system processes, and some duties legitimately require privileged access; the rule is to grant the accesses the task requires and to require a non-privileged account for the non-security part of the work (AC-6(2)).

Neither principle substitutes for accountability: a boundary is only as good as the record of who holds it and who approved it, which is why AC-6 pairs the principle with logging privileged functions and SP 800-12 Rev. 1 ties access control to user accountability.

What to remember

• Least privilege bounds one identity; defense in depth bounds one failure.
• Least privilege applies to users, processes acting for users and system processes, and is reviewed over time, not set once.
• Its enhancements show the cost: non-privileged accounts, restricted network access to privileged commands, logging of privileged functions.
• Defense in depth allocates controls to layers that must be coordinated and mutually reinforcing — independence, not a count of controls.

Level and prerequisites

L1 — fundamentals: the two principles and the decision each makes, with no procedure and no configuration. Prerequisites: none; the sheets on assets and dependencies and on ownership give “task”, “asset” and accountability their scope.

Where to go next

• Cybersecurity Governance — the area this sheet belongs to.
• The technical side — access control configuration, segmentation, logging pipelines — belongs to Networking and Server & Virtualization.

References

• NIST, Security and Privacy Controls for Information Systems and Organizations (SP 800-53 Rev. 5) — AC-6 Least Privilege, its discussion and control enhancements; PL-8(1) Defense in Depth; the failure-protection discussion on replicated mechanisms.
• NIST, An Introduction to Information Security (SP 800-12 Rev. 1) — the least privilege glossary entry (from CNSSI-4009), the access-control wording, and the description of defense in depth.
• NIST, The NIST Cybersecurity Framework (CSF) 2.0 (CSWP 29) — PR.AA-05, which names least privilege and separation of duties as part of access management.