Zero Trust As A Claim

Zero Trust as a Claim

"Zero trust" is not a product, a network topology, or a box you checked when you bought a ZTNA gateway. It is a property of every request: that the request is authenticated, authorized for the specific action, and evaluated on its own merits rather than trusted because of where it came from. Stated as a slogan it is marketing; stated as a claim it is falsifiable — and the useful move is always to falsify it, because the interesting answer is where implicit trust survived the architecture that was supposed to remove it.

The honest question is never "are we zero trust?" (unanswerable, unfalsifiable). It is "this request — trusted to do what, verified how, and re-verified when?" Ask it at each hop and the residual trust becomes visible.

The failure modes are all the same shape — trust that moved rather than disappeared:

• The perimeter that moved inward. The VPN / ZTNA gateway authenticates you once at the edge, and behind it the network is flat: reach one service and you reach them all. The castle wall got a better front door and the same open courtyard.
• Authentication mistaken for authorization. A service mesh gives every workload an mTLS identity and proves who is calling — and then authorizes nothing, so any authenticated workload can call any endpoint. Knowing the caller's name is not deciding what the caller may do.
• "It came from inside." An internal API, a message on the internal bus, a request from a trusted subnet — trusted because of its origin, which is precisely the implicit trust zero trust is defined against.

Composes with the library:

• authorization-surface-mapping — every request is an actor-resource-action cell that must be authorized; zero trust is that matrix enforced per request
• agent-trust-boundaries — instruction/authority comes from the verified channel, not from having reached the position; the same principle
• assume-breach-modeling — zero trust's premise is assume-breach; test it by assuming the caller is already compromised
• cloud-control-plane-reasoning — identity is the perimeter; a workload identity that is authenticated but over-authorized is the mesh failure in cloud form
• honest-degradation — "we have zero trust" is a WARN-worthy overclaim unless you can point at the per-request authorization; name what is actually enforced

Step 1 — Restate the claim as per-request verification, then hunt the exceptions

Take whatever "we do zero trust" means in this system and rewrite it as a testable claim: for each request between components, the receiver authenticates the caller, authorizes the specific action, and does not rely on network position. Now hunt every place that is not true:

• Which internal calls are authorized only by "you reached me"?
• Which trust boundaries are actually network boundaries in disguise (a subnet, a VPC, a "trusted zone")?
• Where does a single successful authentication grant broad, unre-verified access for a long session?

Each exception is a finding. The architecture diagram that says "zero trust" across the top is the claim; the exceptions are the truth.

Step 2 — Separate authenticated from authorized at every hop

The single most common zero-trust failure is stopping at identity. For each component that receives requests:

• Authentication — does it know who is calling (mTLS, signed token, verified identity)? Necessary, and where most "zero trust" implementations stop.
• Authorization — does it decide whether this caller may perform this action on this resource? This is the half that actually contains a breach, and the half a mesh or an API gateway frequently omits.

A system where every service authenticates and nothing authorizes is not zero trust; it is a well-labeled flat network. Route the authorization question through authorization-surface-mapping — the point is that it must be answered per request, not once at login.

Step 3 — Network position must grant nothing

Test the premise directly: assume the caller is inside — behind the VPN, on the trusted subnet, holding a valid workload identity, already on an internal host — and ask what that position grants that a verified authorization would not.

• If reaching the network buys access, trust is positional and the claim is false.
• "East-west" traffic (service-to-service) is where positional trust hides, because the perimeter mindset only ever guarded north-south. A breach's entire lateral movement lives in the east-west trust nobody removed.

The correct answer is that being inside grants nothing — every internal request is authorized as if it came from the internet.

Step 4 — Continuous, not once: re-verification and revocation

Zero trust is per-request and ongoing, not a one-time gate:

• Is trust re-evaluated as context changes (device posture, risk signals, session age), or granted once and held until an hour-long token expires?
• Can access be revoked mid-session, or does a compromised-but-still-valid credential ride until natural expiry (the gap credential-material-triage cares about)?
• A long-lived, broadly-scoped token issued at login and never re-checked is the "verify once, trust forever" pattern wearing zero-trust vocabulary.

Step 5 — State honestly what is enforced, and what is still implicit

Close with the falsifiable inventory, not the slogan: for the system in question, list where per-request authorization is genuinely enforced, and — the valuable part — where implicit trust remains (the flat segment behind the gateway, the mesh that only authenticates, the internal bus that trusts any publisher). "We are zero trust" is an overclaim; "north-south is per-request authorized; east-west authenticates but does not authorize; here is the residual implicit trust and its blast radius" is a defensible statement someone can act on. ABSTAIN from the label; report the enforcement.

The one-line test

If a request is trusted because of where it came from — the VPN, the subnet, the internal network, a valid identity with no check on the action — then the trust did not go to zero, it moved. Ask of every hop "trusted to do what, verified how, re-checked when," and the residual trust the diagram hid is your finding.