Least Privilege and Defense in Depth Explained

What is the principle of least privilege?

The principle of least privilege says that every identity (a person, a service account, a script, a device) should be granted the minimum permissions required to perform its legitimate function, and nothing beyond that. NIST defines it in its security glossary as the principle that a security architecture should be designed so that each entity is granted the minimum system resources and authorizations that the entity needs to perform its function.

The reasoning is about blast radius. Accounts get phished, laptops get stolen, scripts get hijacked and employees make mistakes. You cannot prevent every one of those events, but you can decide in advance how much each compromised identity could possibly do. An intern account that can only read one shared folder is a contained problem. An intern account with domain administrator rights is a catastrophe waiting for a bad day.

Least privilege has two dimensions that are easy to forget. The first is scope: which resources and actions are allowed. The second is time: privileges that are only needed occasionally (for example, an engineer approving a production change) should be granted temporarily and then removed, rather than held permanently. This second idea is often called just-in-time access.

What are real examples of least privilege?

File permissions on Linux

On a Linux server, a web application usually runs as a dedicated low-privilege user rather than as root. That user can read the application files and write only to a specific upload or log directory. If an attacker finds a flaw in the application, they inherit that narrow account, not the whole machine. A typical permission such as chmod 640 on a configuration file (owner can read and write, group can read, everyone else gets nothing) is least privilege in one command.

sudo and role-based access control

Instead of sharing the root password, administrators use sudo to run specific commands with elevated rights, and every use is logged. Role-based access control (RBAC) generalizes the idea: you define roles such as helpdesk, database operator or auditor, attach exactly the permissions each job needs, and assign people to roles instead of handing out individual permissions. When someone changes jobs, you change the role assignment, which prevents the slow buildup of unneeded access known as privilege creep.

IAM policies on AWS and Google Cloud

Cloud platforms make least privilege explicit. The AWS IAM documentation recommends granting least-privilege permissions, and a common way to get there is to start with a narrow policy and expand only when something legitimate is denied. A policy that allows read access to a single storage bucket is least privilege. A policy that allows every action on every resource is the opposite. Google Cloud's IAM guidance follows the same approach: prefer narrowly scoped roles at the lowest practical level of the resource hierarchy rather than broad basic roles. If you want the Google Cloud details, read our GCP IAM explained guide, and for how responsibility is divided between a provider and a customer, see the AWS shared responsibility model.

Network access

Least privilege applies to networks too. A database server should accept connections only from the application servers that need it, on the single port they use, rather than from the entire internal network. A firewall rule set that ends with an implicit deny, followed by only the specific allowed flows, is the network version of the same discipline. If you want a refresher on which ports and protocols those flows use, see TCP vs UDP explained.

What is defense in depth?

Defense in depth is a security strategy that uses multiple, overlapping controls of different kinds to protect an asset, so that the failure or bypass of any one control does not result in a breach. NIST describes it as an information security strategy that integrates people, technology and operations capabilities to establish variable barriers across multiple layers and dimensions of an organization.

The key word is independent. Five firewalls from the same vendor with the same misconfiguration are not five layers. Real depth mixes control types (preventive, detective and corrective) and control owners, so that a single mistake, a single zero-day vulnerability or a single stolen credential cannot defeat everything at once.

A castle is the classic analogy: a moat, a wall, a gatehouse, guards on the walls and a locked keep. Attackers have to defeat each in turn, and defenders get multiple chances to notice and respond. The digital equivalent has fewer stone walls but the same logic.

What are the layers of defense in depth?

Different textbooks draw the layers slightly differently, and exams usually accept any sensible grouping. The five-layer view below is the one most useful for study, with people and policy wrapped around all of it.

Identity controls such as multi-factor authentication (MFA) sit across several of these layers. MFA is not a magic fix, but it means that a stolen password alone no longer opens the door, which is exactly the kind of independent backstop defense in depth is meant to provide.

Walking an attack through the layers

Imagine a phishing email that steals an employee's password. With only one layer, that is game over. With depth, the attacker next hits MFA, which blocks the login. If they somehow pass it, network segmentation means the employee's laptop cannot reach the finance database at all. If it could, database permissions allow that user to read only a few tables. Endpoint protection and logging may flag unusual behavior along the way, and encrypted backups mean even a destructive attack is recoverable. Each layer is imperfect, but the probability that all fail at once is far lower than the chance that any one does.

How do least privilege and defense in depth work together?

Think of defense in depth as the number of walls and least privilege as how thick each wall is. A layered design with generous permissions at every layer is depth in name only, because an attacker who gets one set of credentials can walk straight through. A tight, least-privilege design with only one layer fails completely the moment that layer is breached. You want both.

How do these relate to the CIA triad, zero trust and separation of duties?

The CIA triad. Both ideas are means to an end. Least privilege mostly protects confidentiality (people cannot see what they should not) and integrity (people cannot change what they should not). Defense in depth protects all three pillars, because layers include redundancy and backups for availability as well. If the triad is not second nature yet, start with our CIA triad explained guide.

Need-to-know. Least privilege limits what actions an identity can perform, while need-to-know limits which information a person may see based on their duties. Someone can be cleared for sensitive data in general and still have no need to know about a specific project. Permissions should reflect both.

Separation of duties. This control splits a sensitive process so that no single person can complete it alone, for example one employee creates a vendor payment and another approves it. NIST lists it alongside least privilege in its access control family. Least privilege asks "what is the smallest role?" and separation of duties asks "can one role do the whole risky thing?"

Zero trust. Zero trust architecture, described in NIST SP 800-207, drops the assumption that anything inside the network perimeter is trustworthy. Every request is authenticated and authorized, access is granted per resource with least privilege, and trust is re-evaluated continuously. It is best understood as a modern way to build defense in depth where the network location alone no longer counts as a layer you can rely on. CISA publishes a Zero Trust Maturity Model that organizes the journey into pillars.

What are the most common implementation mistakes?

• Granting wildcard permissions to get things working. Allowing every action on every resource is quick, and then it never gets tightened.
• Privilege creep. People change roles and keep old access. Without periodic access reviews, permissions only ever grow.
• Shared and standing admin accounts. If five people share one admin login, you lose accountability, and a permanently elevated account is a permanent target.
• Service accounts with human-level power. Applications and automation often run with far more rights than they use, and their credentials are rarely rotated.
• Everyday work done as an administrator. Reading email and browsing as an admin account turns every phishing click into a privileged compromise.
• Layers that share one weakness. If your firewall, VPN and application all trust the same single sign-on account without MFA, that account is a single point of failure.
• Relying on the perimeter alone. A flat internal network lets an intruder move laterally unchecked once they are inside.
• Security controls without monitoring. Layers that nobody watches only delay an attacker; they do not detect one.
• Forgetting offboarding. Accounts and keys belonging to departed staff or retired systems stay valid long after they are needed.
• Over-correcting. Permissions so tight that people share passwords or build workarounds make the system less secure. Good least privilege includes a fast, audited way to request more access.

How do the exams test least privilege and defense in depth?

These two principles are foundational enough that they rarely appear as a bare definition. They appear inside scenarios: pick the control that reduces exposure, pick the layer that failed, or pick the access setting that follows policy. Exact objective wording changes between exam versions, so always check the current official exam objectives or exam guide before you finalize your study plan.

For deeper exam-specific planning, see the CCST Cybersecurity exam guide, the quick-review CCST Cybersecurity cheat sheet, and the AWS Cloud Practitioner exam guide. If you are choosing between the two entry points into security, compare them in CCST Cybersecurity vs Security+, and if you are weighing the cost, read is CCST Cybersecurity worth it. You can also practice network topics on the CompTIA Network+ practice exam and the AWS Cloud Practitioner practice exam.

What are the classic exam traps?

• "Most secure" is not always "correct." The right answer is usually the control that satisfies the requirement with the minimum access, not the most restrictive option imaginable.
• Layers must be different, not duplicated. Two identical firewalls do not equal defense in depth. Look for the answer that adds a different kind of control.
• Least privilege versus separation of duties. If the stem is about one person completing a whole sensitive process alone, the answer is separation of duties, not least privilege.
• Least privilege versus need-to-know. Actions on systems point to least privilege; visibility of information points to need-to-know.
• Zero trust is not "trust nothing, do nothing." It means verify every request explicitly rather than trusting by network location.
• Privilege creep is a least-privilege failure. If a long-serving employee has accumulated unneeded access, the fix is an access review, not a new firewall.
• Defense in depth includes detective and corrective controls. Logging, alerting and backups count as layers, not only preventive controls.

Practice questions

Try each one before opening the answer.

More scenario drills with explanations are in the CCST Cybersecurity practice exam, and the full question bank covers every domain.

Frequently asked questions

Sources and further reading

• NIST Computer Security Resource Center glossary: least privilege
• NIST Computer Security Resource Center glossary: defense in depth
• NIST Computer Security Resource Center glossary: separation of duty
• NIST SP 800-53 Rev. 5: Security and Privacy Controls (access control family, including AC-5 and AC-6)
• NIST SP 800-207: Zero Trust Architecture
• CISA Zero Trust Maturity Model
• AWS documentation: Security best practices in IAM
• Google Cloud documentation: Use IAM securely