Principle of Least Privilege and Zero Trust Explained

Here is a pattern I've seen in almost every company I've worked with, regardless of size. A new employee joins. To get them productive quickly, someone copies the permissions of a colleague — who was themselves copied from someone else, years ago. Over time people change roles and keep their old access. Contractors get admin rights "just for the migration" that nobody revokes. By year three, half the company can read the finance share and a dozen accounts can delete the production database. The fix is the principle of least privilege, and this post is about applying it to people, software and cloud.

None of this was decided. It accumulated. And when something goes wrong — a phished account, a disgruntled leaver, a bug in a script running with far more power than it needed — the blast radius is the whole company.

Authorisation is the foundation that governs this. Authentication (the previous post in this series) answers "who are you?" Authorisation answers "what are you allowed to do?", and the discipline that keeps the answer sane is the principle of least privilege.

Part 5 of 10 · Foundations of Infosec. Previous: Multi-Factor Authentication. Next: Cryptography Basics.

Key takeaways

The principle of least privilege: every user, service and program gets the minimum access needed — and no more.
Access accumulates through copied permissions and role changes; fix joiner–mover–leaver processes first.
Admin accounts need separation, just-in-time elevation and phishing-resistant MFA.
Zero trust is least privilege applied per request: being on the network grants nothing.

The principle of least privilege, stated properly

Jerome Saltzer and Michael Schroeder wrote it down in 1975, in a paper that remains one of the most cited in the field: every program and every user should operate using the least set of privileges necessary to complete the job. Not "reasonable" privileges. Not "the same as their peers". The least.

The principle applies to every layer:

People — an accountant needs the accounting system, not the source code repository.
Applications — a web app that only reads from a database should connect with a read-only account.
Services and cloud roles — a backup job needs to write to the backup bucket, not to administer the whole cloud account.
Network — a printer does not need to reach the internet.
Time — an engineer needs production access during an incident, not permanently.

The reason it matters is arithmetic. The damage an attacker can do is bounded by the privileges of whatever they've compromised. If your receptionist's account can only read the shared calendar, phishing the receptionist is a nuisance. If that account is in the "Everyone" group that has write access to every share, it's a catastrophe. Least privilege doesn't stop the phish; it makes the phish survivable.

Models for deciding

There are several established ways to structure authorisation decisions.

Discretionary access control (DAC) — the owner of a resource decides who can access it. This is how file permissions work on most operating systems and how sharing works in Google Drive or Dropbox. Flexible, and the source of most "why can everyone see this?" problems, because individual owners make individual decisions with no overall view.

Role-based access control (RBAC) — permissions attach to roles (Accountant, Support Agent, Developer), and people are assigned roles. NIST formalised the model in the early 1990s and it remains the workhorse of enterprise access control. The advantage is manageability: when someone changes job you change their role, and the permissions follow. The failure mode is role explosion — every exception becomes a new role until there are more roles than people.

Attribute-based access control (ABAC) — decisions are based on attributes of the user, the resource and the context: "an employee in Finance, on a managed device, during business hours, may read invoices for their own region." More expressive, harder to reason about, and increasingly what cloud policy languages look like.

Mandatory access control (MAC) — a central policy labels data and clearances and the system enforces them regardless of what owners want. Classic military model; in commercial settings it appears in things like SELinux and data-loss-prevention labelling.

Most organisations end up with RBAC for the bulk of access and ABAC-style conditions layered on for the sensitive edges. What matters more than the model is that there is a model — that someone can answer "why does this person have this permission?" with something other than "history".

The joiner–mover–leaver problem

The processes that break least privilege are boring, and they're the ones to fix first.

Joiners should receive access from a role template, not a copy of a colleague. Write down what a Support Agent gets. Provision that, exactly.

Movers are where accumulation happens. When someone changes role, their old access must be removed, not just new access added. This requires the HR event ("Sara moved to Marketing") to reach the people who manage access — which, in most companies, it doesn't. Connect the two.

Leavers are the highest-risk case and the most frequently mishandled. A departed employee's active account is a free credential for anyone who obtains it, and a live grievance if the parting was bad. The Verizon DBIR and countless incident reports feature ex-employee accounts as the way in. The fix is a single identity provider with single sign-on, so that disabling one account cuts everything downstream on the day they leave. If access is scattered across twenty SaaS tools with local logins, offboarding takes weeks and is never complete.

Then review. Quarterly, each manager confirms that each report's access is still needed. This is tedious, and it's the only mechanism that reverses accumulation. Tooling can generate the list; a human has to say yes or no.

Privileged access deserves special handling

Administrative privilege — domain admin, cloud root, database superuser — is a different category of risk and deserves different controls:

Separate accounts. Admins have a normal account for email and browsing and a separate admin account used only for admin tasks. Phishing the normal account then gains nothing privileged.
Just-in-time elevation. Admin rights are granted for a task and expire after hours, not held permanently. Cloud providers all offer this now (AWS IAM Identity Center, Azure PIM, Google's temporary elevated access), and privileged access management tools do it on-premises.
Phishing-resistant MFA on every privileged account, without exception.
No shared admin accounts. "The root password everyone knows" defeats accountability entirely. If a break-glass account must exist, its password is sealed, its use is alarmed, and it's rotated after every use.
Logging of every privileged action, shipped somewhere the admin can't edit.

Microsoft's own guidance on this — the tiered administration model, now framed as "privileged access strategy" — is worth reading even if you're not a Microsoft shop, because the reasoning about why admin credentials must never touch lower-trust systems is universal.

Zero trust, without the marketing

You'll have heard the phrase "zero trust". It has been so thoroughly adopted by vendors that it's now used to sell almost anything. The underlying idea is simple and directly descends from least privilege.

The traditional model was the castle: a hard perimeter, and inside the perimeter, broad trust. Once you were on the corporate network, you could reach most things. That model failed for two reasons — attackers who got in (through phishing, a VPN flaw, a contractor's laptop) had free movement, and the perimeter itself dissolved as people worked from anywhere on cloud services the company didn't host.

Zero trust, as NIST defines it in SP 800-207, replaces location-based trust with per-request decisions: every access to a resource is authenticated, authorised and evaluated against policy, regardless of where the request originates. Being "on the network" grants nothing. The principles are:

Verify explicitly — every request, using all available signals (identity, device health, location, behaviour).
Use least privilege — just-enough, just-in-time access.
Assume breach — design as though the attacker is already inside, and minimise what they can reach.

Google's BeyondCorp, which the company built after the 2009 Operation Aurora intrusion and published from 2014, is the canonical worked example: employees access internal applications from any network through an access proxy that checks identity and device state on every request, with no VPN at all.

For a smaller organisation, zero trust is less a product than a direction of travel: put everything behind single sign-on with MFA; check device health before granting access to sensitive systems; segment the network so a compromised laptop can't see the servers; and stop treating "inside the office" as a security boundary. You can get most of the benefit with the identity provider and cloud tools you already pay for.

Least privilege in code and cloud

Everything above applies to software, and the failures there are particularly consequential because they scale.

In the cloud, over-privileged roles are the standard finding of every audit I've seen. A function that needs to read one bucket gets s3:*. A CI pipeline gets account-wide admin because that made the first deployment work. Cloud providers publish tooling to detect unused permissions (AWS IAM Access Analyzer, GCP's recommender) precisely because the problem is universal. Use it, and treat every wildcard in a policy as a defect.

In applications, the corresponding failure is broken access control — the number-one category in the OWASP Top 10 since 2021. It looks like: changing the ID in a URL and seeing someone else's order; an admin endpoint that checks you're logged in but not that you're an admin; a mobile app that hides a button the API still happily serves. The fix is architectural: authorisation checks live server-side, at every entry point, by default deny, and are tested as deliberately as features are.

Where to begin

If your organisation has never seriously done this, the sequence that works is:

Consolidate identity. One identity provider, single sign-on everywhere it's supported, MFA on. Everything else depends on this.
Fix leavers first. Make "disable the SSO account" a same-day step in offboarding, and audit for accounts of people who have already left. You will find some.
Separate admin accounts and put phishing-resistant MFA on them.
Define roles for the five or six job types you actually have, provision joiners from them, and rebuild existing users' access to match. This is the slow part; do it team by team.
Review quarterly. Managers confirm access; anything unconfirmed is removed.
Then look at cloud roles, network segmentation and application authorisation with the same lens.

None of this is glamorous. All of it is the difference between an incident that costs an afternoon and one that costs the company. Saltzer and Schroeder wrote the principle down half a century ago; it has not been improved on since, only ignored.

Further reading

Jerome H. Saltzer and Michael D. Schroeder, "The Protection of Information in Computer Systems", Proceedings of the IEEE (1975)
NIST SP 800-207 — Zero Trust Architecture (2020)
David Ferraiolo and Richard Kuhn, "Role-Based Access Controls", NIST (1992)
Rory Ward and Betsy Beyer, "BeyondCorp: A New Approach to Enterprise Security", ;login: (2014)
OWASP Top 10 (2021) — A01: Broken Access Control
Microsoft, Securing privileged access documentation

This series