Zero trust and least privilege, as principles rather than products

In SY0-801, objective 1.1 treats zero trust and least privilege as principles sitting inside a defence-in-depth design. The previous lesson built that frame and filled it with CIA, AAA and non-repudiation; this one adds the two ideas that decide how far a single failure can spread. The architecture that puts zero trust into practice -- the components that make and enforce access decisions -- is examined separately in objective 3.2, and honeypots and other deception tools now belong to the mitigations in 4.1.

Why this matters

"Zero trust" is printed on more product boxes than almost any other phrase in security, which makes it easy to revise as a slogan and hard to answer precisely. The exam asks the precise version: what does the principle actually require, what does it argue against, and which option in a list genuinely applies it rather than just carrying the name.

Least privilege is the older idea and the more examinable one in everyday scenarios. Whenever a question describes an account, a service or a person with more access than their job needs, least privilege is the principle being broken -- and it is often the answer even when the scenario looks like it is about something else.

The lesson

Why the perimeter model fails once the attacker is already inside

The traditional model draws a boundary, puts controls on it, and treats everything inside as trusted. It fails for three reasons the exam expects you to be able to state.

• There is no longer one inside. Staff work from home, workloads run in several clouds, and partners have connections into your estate. The perimeter encloses a fraction of what matters.
• The first compromise is usually a person, not the firewall. Phishing or a stolen credential delivers an attacker into the trusted zone, where the perimeter controls are behind them and pointing the wrong way.
• Lateral movement is cheap once inside. Flat internal networks, shared administrator passwords and services that trust any internal address mean one workstation can become the whole domain.

The underlying mistake is treating network location as evidence of trustworthiness. Being on the office network says where a request came from; it says nothing about who sent it, whether their device is healthy, or whether they should be doing what they are asking to do.

Never trust, always verify: what the principle demands of every single request

Zero trust replaces trust-by-location with a decision made per request, on evidence. Stated as principles, it asks for the following.

• No implicit trust. Being inside the network, having logged in an hour ago, or being a known server earns nothing by itself. Each access request is authenticated and authorised on its own merits.
• Decide on more than identity. Who is asking matters, but so does what they are asking from (a managed, patched device or an unknown one), where and when, and what they are asking to reach. The same user can be allowed from a company laptop and refused from a personal tablet.
• Keep checking. Trust is not granted once for the day. Sessions are re-evaluated, and a change in risk -- a device falling out of compliance, an unusual location -- can withdraw access mid-session.
• Assume breach. Design as though an attacker is already present somewhere, so that the question becomes "how little can they reach?" rather than "how do we keep them out?".
• Protect every connection. Traffic is encrypted and authenticated inside the network as well as across the internet, because "internal" is no longer a safe place.
• Watch everything. Every decision and every access is logged, so that the next decision can use what was learned from the last.

NIST's guidance on zero trust architecture, SP 800-207, is the usual reference for these principles, and it frames them the same way: protect resources rather than network segments, and grant access per session based on dynamic policy.

Notice how much of that is familiar. Authentication and authorisation are the first two As from the previous lesson; logging is the third. Zero trust is not a new set of controls so much as a rule about when they apply: always, to every request, with no exceptions for being on the right side of a firewall.

Least privilege as a principle, and the standing access it argues against

Least privilege means every user, process, service account and device gets the minimum access needed for its task, for the minimum time, and nothing more.

The thing it argues against is standing access -- privilege that exists all the time whether or not it is being used. An administrator account that is always administrator, a service account with domain-wide rights because that made installation easier, a contractor whose access outlived the contract. Each is harmless until it is stolen or misused, and then its whole scope becomes the attacker's.

Least privilege in practice looks like:

• role-based permissions sized to the job, not copied from the last person who held it;
• separate accounts for administrative work, so that reading email and browsing the web never happen with administrator rights;
• just-in-time elevation, where higher privilege is requested, approved and granted for a fixed period, then removed automatically;
• regular access reviews, because privilege accumulates as people change roles -- the drift known as privilege creep, which Domain 3 returns to;
• the same discipline for non-human identities -- service accounts, API keys and automation get scoped, short-lived credentials too.

On the exam, least privilege is the answer when the damage in a scenario was larger than it needed to be: the compromised account could reach far more than its owner ever used. It is a principle about limiting blast radius, not about preventing the compromise in the first place.

How zero trust and least privilege sit inside a defence-in-depth design

The two principles do different jobs, and they combine.

• Zero trust governs the decision. Every request is checked, with context, every time.
• Least privilege governs the answer. When the request is allowed, what it is allowed to reach is as small as possible.

A design using only one of them has a gap. Zero trust without least privilege checks every request carefully and then grants each one far too much. Least privilege without zero trust sizes permissions well and then trusts whoever turns up from the internal network holding them.

In defence-in-depth terms, both make the layers independent. Segmenting a network so that a compromised laptop cannot talk directly to the database servers, requiring fresh authentication for sensitive applications, and limiting each service account to the one system it serves all mean that defeating one control no longer opens the next. The attacker who phishes one user gets that user's narrow access, on that device, for that session -- and every attempt to reach further is another check that can fail and another log line that can be noticed.

Telling a zero trust principle from a product with zero trust on the box

Exam options, like vendor brochures, sometimes offer a product where a principle is needed. Some tests to apply:

• Does it remove implicit trust, or just move it? A VPN that authenticates a user once and then places them on the full internal network has moved the perimeter to the user's laptop. It has not removed trust by location.
• Is the decision per request, with context? If access depends only on a password checked at the start of the day, it is not zero trust whatever the label says.
• Does it shrink what is reachable? A design that still allows any authenticated user to reach every application fails the least-privilege half.
• Is it a property of the whole design, or one box? Zero trust is achieved by identity, device health, application-level access control, segmentation and monitoring working together. No single appliance delivers it, and an option claiming that one purchase "implements zero trust" should make you suspicious.

The architectural pieces that do this work -- how user authentication, device health and inventory, and per-application access control fit together -- are taught in the zero trust architecture lesson under objective 3.2. For 1.1, the skill is recognising the principle and spotting its absence.

What to take into the exam

• The perimeter model's flaw is treating network location as proof of trust.
• Zero trust: no implicit trust, decide per request on identity plus context, keep re-evaluating, assume breach, log everything.
• Least privilege: minimum access, minimum time; it targets standing access and limits blast radius rather than preventing the first compromise.
• Zero trust decides whether to allow a request; least privilege decides how much the allowed request can reach. Defence in depth needs both.
• A product is not a principle. Ask whether trust by location was removed and whether reachable scope shrank.