IAM Chapter 9: Shrink the Zone

Part of the IAM study series.

Zero Trust isn't "trust nothing". It's no implicit trust from network location.

1. What It Actually Claims

Castle and moat: one check at the lobby. Everything behind it (office, PLM, SAP, the file server, HR, backups, the domain controllers) is open, and nobody checks the corridor. Once an attacker is inside, the moat protects them.

Zero Trust: a guard on every door. It's the same check, but passing one puts you in that room only, and a request from Toulouse and one from a café get identical scrutiny.

Location tells you nothing. It was never evidence; it was a proxy we used because it was easy to measure.

Three things it isn't:

• Not a product. Every vendor sells "a Zero Trust solution". It's an architectural stance you migrate toward.
• Not "remove the VPN". Removing it without replacing the control leaves you worse off.
• Not new, mostly. Say this plainly in a steering committee: it's controls you already have, re-sequenced. Exactly one demand in it is genuinely new (section 4).

Location as a trust signal ("inside, so skip MFA"): never. That turns the network into a credential with no expiry and no rotation, shared by every device. Location as a risk signal (one input among several, never alone enough to waive a control): fine, and useful.

2. The Implicit Trust Zone, and Its Two Dimensions

Trust here means one thing: proceeding without verifying. The implicit trust zone is whatever sits behind an enforcement point. Implicit is the important word. Nobody decided to trust you in there, and nobody wrote a policy saying anyone on the internal network may reach PLM. It falls out of where the check happens to sit, which is why it appears in no architecture document and plenty of incident reports.

The zone has two dimensions: how much is behind the enforcement point, and how long before re-check.

You never reach zero. There's always a last enforcement point with something behind it, at minimum the inside of the application, where functions don't re-authorise you after login. NIST says so explicitly: "Zero Trust" is aspirational shorthand, and the honest goal is to shrink the zones.

So the design question isn't "are we Zero Trust?" It's where are our enforcement points, and how much (in space and in time) sits behind each one?

Did the proxy actually shrink it? Three questions:

1. After it says yes, what can I reach? Some "access proxies" authenticate you and then drop you onto a network segment. That's a better-looking VPN. Test: can I reach app B, which I never asked for?
2. Per request, or once per session? If it evaluates at session start then forwards freely for 8h, the real-time check happened once.
3. What still doesn't go through it? East-west traffic, admin paths, the three legacy apps that kept the VPN alive "for a few cases". The weakest path defines the zone. A proxy in front of 60% with a VPN carrying the rest is a second door to the same room.

3. NIST SP 800-207: The Architecture, Under New Names

The request hits an enforcement point (your PEP), which sits in front of the resource. Behind it, NIST splits the decision point in two:

• Policy Engine (PE): decides. This is your PDP.
• Policy Administrator (PA): acts. It issues, and tears down, the session.

Feeding the PE: the identity system, device posture, threat intel, activity logs, PKI, the SIEM. Every one of those is a PIP under another name, with the same freshness-vs-latency trade-off from Chapter 6.

Why the PE/PA split does real work. In Chapter 6's ABAC, the PDP answered a question and the conversation ended. Here something owns the live session and can reach back into it. You can't revoke mid-session unless some component's job is to go and kill the connection. That's the PA, and it's why this model can support continuous evaluation at all.

4. Continuous Evaluation: The One Genuinely New Demand

Everything underneath is built on the opposite assumption. A JWT is self-contained and verified offline precisely so the resource never calls the issuer. A Kerberos ticket is valid until it expires, so the KDC isn't in the path. A session cookie exists so you don't re-authenticate. The entire performance model of modern authentication is "decide once, then don't call back".

Decide once: John's token is issued at 09:00 and valid until 17:00. At 10:00 John is terminated, and nothing happens. The directory is correct; the session simply never asks again.

Continuous Access Evaluation (CAE): the IdP pushes the event and the resource has subscribed, so the session is rejected immediately. The token didn't expire; it was invalidated out of band. Signals include account disabled, password reset, risk raised, and device non-compliant.

"We set a 15-minute token." Then it's silent refresh, silent refresh, silent refresh, against a 14-day refresh token. The real window is the refresh token, unless refresh re-evaluates. Ask: what gets checked at refresh, and how long does the refresh token live?

Why not just use very short tokens? It works, and it costs you. 5-minute tokens mean roughly 12× the IdP traffic, and the IdP becomes a hard dependency on the critical path of every request. You've traded a security window for an availability risk.

The catch with CAE is participation. The resource server must implement it: receive the event and act. It works between Entra and M365; it doesn't work with an arbitrary SaaS app that validates a JWT and moves on. The interoperability effort is the Shared Signals Framework / CAEP at the OpenID Foundation.

What you can actually ship: tier token lifetimes by risk instead of chasing CAE everywhere. 8 hours for low-risk apps, 15 minutes for admin sessions and export-controlled views. That's Chapter 8's reversibility rule, applied to time.

Be honest in a steering committee: continuous evaluation is the least-delivered part of Zero Trust. Most estates have a good front door and nothing continuous behind it.

5. Device Trust, and the Order to Do This In

Identity tells you who. It doesn't tell you what they're typing on. A valid credential on a compromised laptop is a compromised session: Chapter 8's tiering argument, arriving at the access decision.

Evaluate whether the device is known and enrolled, managed, compliant (patch level, disk encryption, EDR), and healthy right now, not at last check-in.

Device state is self-reported. An agent says the device is compliant; a compromised device says the same thing. Hardware-backed attestation via the TPM is meaningfully stronger. Insist on it for anything Tier 0.

The unmanaged population is the real problem. At Skyline, the supplier engineers on Engine X are both the most interesting population and the one whose laptops you'll never manage. There are three answers, in descending cost: issue a managed device; VDI or an isolated browser so no data lands locally; or restrict what unmanaged devices can do (view-only, no download, no print). The third is what most organisations do, and it pairs with export control, because preventing the data from landing is what you wanted anyway.

The order:

1. Identity first: strong phishing-resistant auth, one IdP. Everything downstream starts here, so getting it wrong invalidates what's built on top.
2. Inventory.
3. Apps off the VPN.
4. Add device signals.
5. Segment what's left.
6. Retire the VPN: last, not first. Removing it early just forces exceptions that become permanent.

What breaks, predictably: the legacy long tail that can't speak modern auth, which sets your end date. Service-to-service and batch traffic, with no user and often no agent, which needs workload identity (Chapter 7) and is almost always missing from the plan. And factory and OT systems that can't be touched at all.

The framing for a steering committee: a three-to-five-year architectural direction, not a programme with a completion date. Measure the percentage of access flowing through an identity-aware enforcement point, not "are we Zero Trust yet?", which has no answer.

What Breaks in Practice

🔴 CHECKPOINT: Study Notes

← Previous: The Border Is the Person · Back to the series start · Next: One Page →