Zero Trust Architecture

A contractor's laptop is phished. The attacker opens the VPN client, authenticates with the stolen session, and now holds an address inside 10.0.0.0/8. From there a port scan finds an unpatched admin panel on a legacy service that has not been touched in two years. Nothing in this story required a sophisticated exploit — it required only that network position counted as trust. That is the assumption zero trust deletes.

The canonical tenets (NIST SP 800-207 is the citation an interviewer will respect) are short enough to state from memory:

1. Every access to a resource is authenticated and authorized per request — no access is granted merely by network location.
2. Access is least-privilege and dynamic, granted for the specific action, not a standing allowance.
3. Device and workload posture participate in the decision: a managed, patched machine is a different subject than an unknown one.
4. Traffic is logged and security posture enforced continuously — a session granted an hour ago is re-evaluated, not grandfathered.
5. All of this is driven by dynamic policy, not static network rules.

The replacement for the VPN is not 'a better VPN' — it is a different grant model. Compare the three regimes on the same axis:

Zero trust is also frequently misstated, so pin down what it does not claim. It does not mean the network stops mattering — segmentation still shrinks the space policy has to reason about; it just stops being evidence of trust. It does not mean MFA on everything forever; it means assurance proportional to risk, with step-up when the risk signal rises. And it does not mean perimeters are deleted: the edge still terminates TLS and runs the first enforcement point — it simply stops being the only one.

Two practical notes keep this from becoming a slogan. First, zero trust is not a product; it is a set of enforcement points plus a policy engine. A vendor selling 'zero trust' is selling one enforcement point — usually the last mile to a SaaS app — and the architecture question is always what happens to traffic the vendor does not mediate, east-west calls between your own services included. Second, migration is incremental: you do not rip out the VPN on a Friday. You broker access app by app (ZTNA for the admin panel first, since that is the exposure the phished laptop just demonstrated), then move service-to-service traffic under per-request policy, and decommission broad network grants when their last consumer is gone.

Expect the definitional question in interviews: how is zero trust different from defense in depth? Defense in Depth says stack independent controls at every layer. Zero trust says none of those layers may trust a request because of where it came from — it supplies the identity and policy machinery that makes each layer's decision specific. They compose; neither subsumes the other. What the phrase means operationally — deny by default, authenticate every request, evaluate posture, least privilege per action — is the part to be able to defend without quoting marketing.

Zero trust becomes real at one place: the decision made for a single request. That decision combines several signal families, each produced by a different authority, and it is made by a policy engine (the PDP — policy decision point) that is separate from the enforcement point (PEP) that actually admits or drops the traffic.

A policy reads like this (pseudo-policy — the syntax resembles Cedar or OPA/Rego flattened to English):

permit(request) when {
  request.subject.role        == 'payments-analyst' and
  request.subject.mfa         == 'fido2'            and
  request.device.managed      == true               and
  request.device.edr          == 'healthy'          and
  request.device.patch_age    < 14d                 and
  request.resource.env        != 'prod' or request.context.risk_score < 30
}
# default: deny, with a reason code attached to the audit record

Three properties of this design carry the weight. Deny by default: absence of an explicit permit is a denial, which means new resources are private until policy says otherwise — the opposite of the old model where a new subnet was reachable by default. Per-request, not per-session: a 5-minute access token is verified on every call, so a posture change (EDR goes unhealthy) or a risk spike (impossible travel) ends access within minutes rather than at the next VPN reconnect. Reasons on denials: every deny carries a structured reason code, which turns 'the app is broken' tickets into 'your device failed posture at 14:02' in one log lookup.

Then price the trade-offs, because interviewers probe them next. Latency: a synchronous PDP lookup per request must stay in single-digit milliseconds; the standard answers are caching decisions with a short TTL (30–60 seconds — bounded staleness you accept deliberately) and colocating the PDP with the enforcement point. Availability: fail-closed on an IdP outage means an outage, and pretending otherwise is a design smell. The pragmatic ladder is short-lived access tokens (5–15 minutes) verified locally against cached JWKS keys, a grace window that honors tokens already issued, and a sealed break-glass path that bypasses posture with loud alerting — bypass that is audited, rehearsed, and expires. Fail-open for writes is never on the ladder. Observability: log every decision, allow and deny — those records feed anomaly detection (a burst of denials is simultaneously a UX incident and a reconnaissance signal), and without them the policy engine is a black box you cannot tune.

Two refinements show up in production designs. The first is continuous evaluation versus per-request checking: some implementations re-evaluate posture for an active session and sever it mid-connection when signals degrade — an EDR that goes unhealthy at minute twelve ends the session rather than waiting for the next token refresh. That closes the gap between 'checked at request time' and 'checked thirty minutes ago' at the cost of stateful session tracking. The second is risk-tiered policy: identical requests carry different requirements depending on a risk score. The same analyst exporting the same report from the corporate network passes with an existing session factor; the same request from a hosting-provider ASN at 3 a.m. demands phishing-resistant MFA or is denied outright. Both refinements serve one goal: making the grant match the moment, not the user's general reputation.

The honest architectural statement: per-request verification costs latency, engineering, and a dependency on the IdP's health, and buys you a system where a stolen token dies in minutes and a compromised laptop reaches one application. That trade is the entire point.

Now the scenario that justifies all of the above. A dependency CVE gives an attacker remote code execution inside order-service. Everything that happens next was decided by your architecture, hours before the exploit.

In a flat network, the attacker's next moves are routine. They query the instance metadata service at 169.254.169.254 and steal the node's IAM role credentials. Those credentials reach the production database, enumerate every table, and — because the same role fronts several services — reach the billing service too. Outbound traffic is unrestricted, so exfiltration is a single curl. By the time an IDS rule fires, the blast radius is the account.

Under microsegmentation, each of those moves hits a wall designed for it:

The mechanism underneath is cryptographic service identity. Each workload receives a short-lived identity document (a SPIFFE ID is the standards-shaped answer: spiffe://prod/payments/order-service) and presents it over mTLS. Authorization then operates on those identities — order-service may call payments-api:charge and send to its queue, and nothing else. Network location contributes zero to the decision; the workload's cryptographic identity is the only credential that matters, which is precisely the zero trust tenet applied east-west.

Rollout is where designs succeed or die in practice. Enforcement on day one breaks the flow nobody documented, so run observe-only first: policies log would-deny for two weeks, you fix the legitimate flows the logs reveal, then enforce per service. Start with egress — it is the cheapest wall and the one that neuters exfiltration and metadata theft — then east-west for new services born inside the mesh, then migrate legacy. Choose the identity delivery path deliberately: a service mesh sidecars mTLS uniformly at the cost of an extra hop, memory, and an ops surface; in-library identity is lighter per service but means implementing it correctly in every language you run. Either way, note the combinatorics: pairwise service policies grow quadratically, so define tiers (edge → API → data) plus explicit exceptions, and refine only the hot paths that tiering leaves too permissive.

Three details decide whether the containment actually holds. Egress policy is only as good as its name-resolution path — a workload that can resolve and reach arbitrary DNS can tunnel out through a domain-fronting service, so DNS egress must flow through the same filtering proxy that handles TCP. Database access gets the same treatment: per-workload credentials issued with short TTLs instead of one shared service account, so the compromised pod's dump window is minutes, not months. And mTLS certificates have their own lifecycle — short-lived workload identity documents (hours, not months) fetched from the issuer mean a revoked workload stops presenting valid identity almost immediately, because the per-request promise is only as strong as the credential lifetime underneath it.

The interview close that ties the phase together: microsegmentation bounds the blast radius to one workload, one identity, one segment — and the identity tokens and policy machinery it runs on are exactly the machinery the next topic, Identity and Access Architecture, builds for humans, third parties, and services alike.