Zero trust architecture and identity infrastructure

Objective 3.2 asks you to manage an architecture so that it protects the infrastructure, given a scenario. Zero trust appears twice in this exam: as a principle in Domain 1, and here as something you build. This lesson is the building half -- where access decisions are made, what they are based on, and the accounts underneath that the whole design depends on.

Why this matters

"Never trust, always verify" is easy to say and does nothing on its own. An organisation that has bought a product labelled zero trust and still lets anyone on the office network reach every file server has a slogan, not an architecture.

The exam tests whether you can tell the difference: given a design, can you say where the decision is made, what it is based on, and what a subject can reach once it is through? It also tests the identity plumbing beneath -- service accounts and accumulated privilege -- because a zero trust design that trusts an over-privileged service account has a hole exactly the shape of that account.

The lesson

Turning zero trust principles into architecture: where decisions are made and enforced

Lesson 4 set out the principle: stop granting trust because of network location, and evaluate every request on its own merits. The architecture that does that, described in NIST's zero trust guidance (SP 800-207), separates deciding from enforcing.

• The policy engine decides. It takes a request -- this user, on this device, wants this resource -- and evaluates it against policy and the signals available: identity, device health, location, time, behaviour, threat intelligence.
• The policy administrator acts on the decision: it tells the enforcement point to open or close the path, and issues or revokes the session's credentials.
• The policy enforcement point sits in the path between the subject and the resource and does what it is told -- allows, blocks or ends the session.

Engine and administrator form the control plane; the enforcement point and the traffic it carries form the data plane. The exam's favourite distinction is the simplest one: the engine decides, the enforcement point enforces. Something evaluating rules is the engine; something sitting in the traffic path is the enforcement point.

Behind the enforcement point is an implicit trust zone, where no further checks happen. Zero trust does not abolish it; it shrinks it. The practical test of any design is to ask what a subject can reach after it is allowed through. If the answer is "the whole internal network", the design is barely zero trust at all. If it is "one application, and a second request goes back to the policy engine", it is.

Authenticating every user on every request, not once at the door

The perimeter model authenticated once -- at the VPN or the login screen -- and trusted the session afterwards. Zero trust treats authentication as continuous:

• every access request is evaluated, not just the first one in a session;
• tokens are short-lived, so a stolen one stops working quickly, and sessions can be revoked centrally when risk changes;
• conditional or risk-based access adjusts the answer to the context: the same user on a managed laptop in a familiar location gets in, while an unfamiliar device in another country at 3am is challenged or refused;
• step-up authentication asks for a stronger factor when the request is more sensitive -- approving a payment rather than reading the intranet;
• multifactor authentication is the floor, and phishing-resistant methods such as passkeys and hardware security keys are preferred, because a continuously evaluated session is only as strong as the factor that opened it.

The single sign-on and identity provider that does this becomes the most critical system in the design. It must be highly available, tightly administered and heavily monitored, because every decision now depends on it.

Device health and inventory as conditions of access

A valid user on a compromised device is still a compromise. So in zero trust the device is a subject too.

Inventory comes first: you cannot judge the health of a device you do not know exists. Devices are enrolled in management, usually through mobile device or unified endpoint management, and identified by something harder to fake than a name, such as a device certificate. An unknown device is, by default, untrusted.

Health is then checked at access time and re-checked during the session:

• operating system and patch level within policy;
• endpoint protection installed, running and reporting;
• disk encryption on;
• no signs of jailbreaking or rooting on mobile devices;
• configuration matching the baseline.

The outcome does not have to be all or nothing. A healthy managed device gets full access; a personal device might get browser-only access with downloads blocked; a device that has fallen out of compliance is sent to remediation until it is patched. That graded answer is what makes device health practical rather than a source of constant lockouts.

Application-level access control, and why network location stops being a credential

In the perimeter model, being on the network was itself a credential: plug into the office, or connect to the VPN, and everything internal is reachable. Zero trust removes that. Network location grants nothing.

Instead, access is granted per application:

• a broker or enforcement point in front of each application admits only subjects that policy allows, so applications are not reachable at all -- not even visible -- to anyone else;
• microsegmentation limits which workloads can talk to which, so a compromised server cannot freely reach its neighbours;
• the application itself still enforces authorisation for what an admitted user may do inside it.

The payoff is blast radius. An attacker who steals a VPN credential in the old model gets a network to explore. In the new one, a stolen session reaches the applications that user was entitled to, from a device that passed the health check, for as long as the token lasts -- and every request leaves a log entry.

Group managed service accounts, least-privilege accounts, and privilege creep

Zero trust is about every subject, and many subjects are not people.

Service accounts run applications, scheduled tasks and integrations. Their classic weaknesses: passwords that never change because nobody knows what will break, passwords written in scripts, and far more rights than the service needs. In Active Directory, a group managed service account (gMSA) fixes the password problem. The directory generates a long, random password, rotates it automatically (every 30 days by default), and releases it only to the specific servers authorised to use the account. No human knows the password, so it cannot be phished, reused or left in a script. A gMSA still needs least privilege; automatic rotation does not limit what the account can do.

Least-privilege access accounts apply the same idea to people. Administrators get a separate administrative account used only for administration, never for email or browsing, so a phishing link opened from the daily account cannot exercise admin rights. Rights are scoped to the systems a role manages, and elevated access is granted just in time for a task rather than held permanently. Lesson 37 returns to just-in-time privilege, and lesson 36 to account types and access reviews.

Privilege creep is how least privilege decays. A person moves from finance to sales and keeps their finance access; a temporary project grant is never removed; an engineer collects rights over five years until their account can reach almost everything. Each grant was reasonable when made. The controls are:

• role-based provisioning, so a move removes the old role's rights as it adds the new;
• access reviews in which owners recertify who has what, and anything unconfirmed is removed;
• expiry dates on temporary grants;
• monitoring for accounts whose rights far exceed their peers'.

What to take into the exam

• The policy engine decides, the policy administrator relays, the policy enforcement point enforces; the smaller the implicit trust zone behind it, the better the design.
• Authentication is continuous: short-lived tokens, conditional access, step-up for sensitive actions, revocation when risk changes.
• Device inventory comes before device health; an unknown device is untrusted.
• Network location grants nothing; access is brokered per application.
• gMSAs remove the human-known, never-rotated service account password.
• Privilege creep is answered by role-based provisioning, access reviews and expiry dates.