Deep Dive into Zero Trust

Earlier this month I wrote about what zero trust is and why it matters. This is the follow-up for the people who have to build it: what the parts are, how they fit together and what to do first.

The architecture, as NIST describes it

NIST Special Publication 800-207, published in 2020, is the standard reference. It splits every access decision into a few logical components:

  • The subject: a user, device or service asking for access.
  • The resource: the application, API, database or file being accessed.
  • The Policy Engine: decides whether this subject may access this resource right now, using everything it knows: identity, device state, location, time, the sensitivity of the resource and recent behavior.
  • The Policy Administrator: turns that decision into action, setting up or tearing down the session.
  • The Policy Enforcement Point: the gate in the path that actually allows or blocks the traffic. It might be an identity-aware proxy, an API gateway, a service mesh sidecar or a host firewall.

The engine and administrator together are often called the Policy Decision Point. Feeding them are data sources: the identity provider, the device management system, threat intelligence and activity logs.

The important idea is that the enforcement point sits in front of each resource, not at the edge of the network.

One request, end to end

Here's what that looks like when an engineer opens an internal dashboard from a laptop at home.

  1. The browser requests dashboard.internal.example.com. DNS points it at an identity-aware proxy, not at the dashboard itself. The dashboard doesn't accept connections from anywhere else.
  2. The proxy has no session for this user, so it redirects to the identity provider.
  3. The identity provider authenticates the user with a passkey or hardware security key, which can't be phished because it's bound to the real domain.
  4. The device proves itself. The laptop presents a device certificate issued when it was enrolled in device management, ideally with its private key held in the TPM so it can't be copied to another machine. The device management system reports that disk encryption is on, the OS is patched and the endpoint agent is running.
  5. The policy engine evaluates: is this user in a group allowed to use the dashboard, from a managed and healthy device, from a plausible location, at a plausible time? Yes, so it issues a short-lived token.
  6. The proxy forwards the request to the dashboard with the user's verified identity attached, and the dashboard can apply its own authorization on top.
  7. It keeps checking. The session lasts hours, not weeks. If the laptop falls out of compliance, the user is removed from the group, or the identity provider sees an impossible-travel login, the session is revoked.

Nothing in that flow depended on the laptop being "inside" any network.

Machines need identities too

Most traffic in a modern environment isn't people. It's services calling services, and zero trust applies to them just as much.

  • Mutual TLS. Each service gets its own certificate and presents it when it connects, and each side verifies the other. A compromised service can only reach what its own identity allows.
  • Workload identity. Projects like SPIFFE and its implementation SPIRE give every workload a cryptographic identity based on what it is and where it runs, rotated automatically, instead of long-lived passwords and API keys in configuration files.
  • Service meshes like Istio and Linkerd handle mTLS between services transparently, and can enforce which service may call which.
  • Cloud workload identity. AWS IAM roles, GCP service accounts and Azure managed identities issue short-lived credentials to workloads, so there are no static keys to leak.

Segmentation that follows the workload

Microsegmentation means each workload can only talk to what it needs.

  • Kubernetes NetworkPolicies, or Cilium's identity-aware policies, so pods can't reach arbitrary other pods.
  • Host firewalls with nftables or cloud security groups that allow specific flows, not whole subnets.
  • Default deny, then open what's needed, with every rule tied to a named service rather than an IP range someone will forget.

Where people go wrong

  • Buying a product called zero trust. It's an architecture and an operating model, not a box.
  • Ignoring legacy applications. That old app that only speaks NTLM or has no login at all is where attackers will go. Put it behind a proxy, or isolate it hard.
  • Forgetting break-glass access. If the identity provider is down, how does an administrator get in? Plan the emergency path before you need it, and audit it.
  • Making it miserable. If every request needs a new MFA prompt, people find workarounds. Strong, phishing-resistant authentication done once, with continuous device and session checks behind it, is both more secure and more pleasant.

A realistic order of work

CISA's Zero Trust Maturity Model organizes the work into five pillars: identity, devices, networks, applications and workloads, and data. In practice, this order works for most organizations:

  1. Identity first. One identity provider, phishing-resistant MFA for everyone, starting with administrators.
  2. Device inventory and health. You can't trust devices you don't know about.
  3. Put the most-used internal web apps behind an identity-aware proxy and off the VPN.
  4. Service identity and mTLS for new services, and for the most sensitive old ones.
  5. Segmentation, starting around your crown jewels: identity systems, backups, databases.
  6. Data classification and controls, once you know where the important data lives.

Each step stands on its own. You don't need to finish all six to get value. Every application moved behind real identity checks is one less thing an attacker gets for free by being on your network.

Since then

Added October 2026. Passkeys have become the default sign-in for more and more services since, which makes step one easier than it was in 2024. And the stream of exploited VPN appliances that made the case for this model in 2024 kept coming through 2025.