What Zero Trust Actually Is

Previously, at Meridian Utilities

Two minutes of catch-up, then we build. Meridian is a fictional regional water-and-electric utility (~1,400 staff). Last year it modernized: the field-service app was rebuilt on a managed platform with directory sign-in, the old .NET monolith now runs in containers, the Oracle database sits on a small fenced Kubernetes cluster, reporting data lives in a governed lake, and the pipelines deploy through golden paths. (That story is its own training — Cloud Modernization Patterns — but nothing here requires it.)

Now the CISO asks the question this training answers: “We modernized. Are we actually secure? The board keeps saying Zero Trust — what would that concretely mean for us?”

And the first, most valuable thing you can do is kill the most common wrong answer.

Zero Trust is not the MFA mandate

Ask ten organizations what Zero Trust means and several will say some version of “we rolled out MFA — phishing-resistant, even.” That belief is common enough that you’ll find it embedded in real governance documents. It mistakes one implementation detail of one pillar for the architecture.

Here is the actual definition, from the document every other document stands on — NIST SP 800-207, Zero Trust Architecture. Its tenets, compressed:

1. Everything is a resource   - data, services, devices, not "the network"
2. Location grants nothing    - being on the LAN/VPN confers zero trust,
                                and all communication is encrypted/secured
                                wherever it runs
3. Access is per-session      - trust is not carried over from last time
4. Policy is dynamic          - decisions weigh identity + device state +
                                context, not identity alone
5. Assume nothing is clean    - monitor and measure the integrity of every
                                asset, continuously
6. AuthN/AuthZ are strictly   - enforced before access, re-evaluated during it
   enforced and dynamic
7. Collect, learn, improve    - telemetry from everything feeds the policy

Notice what MFA is in this list: a strong way to satisfy part of tenet 6. Necessary. Nowhere near sufficient. Tenets 2, 4, and 5 are where the architecture lives — and they’re the ones the “ZT = MFA” belief silently drops.

The one diagram: PDP and PEP

800-207’s engine model is two boxes, and once you see them you’ll see them everywhere:

                 ┌────────────────────────────┐
   signals ────► │  POLICY DECISION POINT     │  identity, device posture,
   (identity,    │  (policy engine + admin)   │  risk, location, data
    device,      └────────────┬───────────────┘  sensitivity → ALLOW /
    risk...)                  │ decision           DENY / STEP-UP
                 ┌────────────▼───────────────┐
   subject ────► │  POLICY ENFORCEMENT POINT  │ ───► resource
                 │  (the gate in the path)    │
                 └────────────────────────────┘

The PDP decides; the PEP sits in the request path and enforces. Real products map cleanly: a conditional-access engine is a PDP; the sign-in flow, a ZTNA gateway, an app proxy, or a service-mesh sidecar are PEPs. (One disclosure up front: this training’s concrete examples use the Microsoft stack — Meridian’s platform — as the reference implementation; every pattern is stated so it maps onto any major provider’s equivalent.) A mature Zero Trust estate is many PEPs consulting a coherent PDP with rich signals — which is why buying any single product is never “doing Zero Trust.”

Prompt first: map your own flows

Your artifact for this lesson — run this against your real environment (or Meridian’s, described above):

Map these three access flows onto the NIST 800-207 model. For each, identify:
the subject, the resource, every PEP in the path, the PDP consulted, and the
SIGNALS the decision actually uses today (identity? device state? location?
risk? none?). Then flag where the flow violates a tenet - especially places
where network location silently grants access (tenet 2) or where a decision
made once is trusted indefinitely (tenets 3/6).

Flow 1: field technician opens the dispatch app from a company tablet in a truck
Flow 2: an admin RDPs to a jump box, then to the historian server
Flow 3: the nightly job that copies billing extracts to the reporting lake

The output is a table of gaps, and it is usually humbling: flow 2 tends to reveal that once you’re on the jump box, location is doing all the trusting (tenet 2 violation); flow 3 tends to reveal a service account whose “session” has lasted four years (tenet 3). Those findings are the training’s to-do list — every later lesson closes one of them.

💬Why the misconception survives

“ZT = MFA” persists because MFA is the visible, budgetable, announcable part — and because a federal memo made phishing-resistant MFA mandatory, so it’s what got audited. But the memo (Lesson 1.2 maps it) is one pillar’s floor, not the architecture’s ceiling. The test that cuts through: ask “when a valid, MFA’d user’s laptop gets compromised at 2 p.m., what stops the attacker at 2:05?” If the answer involves device signals, session re-evaluation, and segmentation — that’s Zero Trust. If the answer is “…they authenticated,” that’s an identity project wearing a slogan.

KNOWLEDGE CHECK

Meridian's IT director says: 'We finished phishing-resistant MFA for all staff last quarter — so we've implemented Zero Trust.' Using 800-207's tenets, what is the accurate assessment?

Key takeaway

Zero Trust is 800-207’s tenets running through a PDP/PEP fabric: nothing trusted for its location, every access decided per-session from live signals, everything monitored, humans and machines alike. MFA is one signal. Map your flows, find where location or time is doing the trusting, and you have the program’s worklist — next, the federal map that tells you what “done” is graded against.

What you'll learn

Previously, at Meridian Utilities

Zero Trust is not the MFA mandate

The one diagram: PDP and PEP

Prompt first: map your own flows

Key takeaway