Zero Trust: Never Trust, Always Verify

Zero trust is one of the most overused terms in security marketing, and one of the most useful ideas in security architecture. Stripped of the hype, it says something simple: being on the network should not grant anything. Every request is authenticated, authorized and evaluated on its own merits, every time.

What zero trust actually means

NIST Special Publication 800-207 defines zero trust as a set of principles that move defenses from static, network-based perimeters to users, assets and resources. It is not a product you can buy. It is a way of deciding who can access what, under which conditions, and for how long.

“Zero trust assumes there is no implicit trust granted to assets or user accounts based solely on their physical or network location.”

NIST SP 800-207

The core principles

• Verify explicitly: authenticate and authorize every request using identity, device health, location and behavior, not network position.
• Use least privilege: grant the minimum access needed, for the shortest time needed, and prefer just-in-time elevation over standing admin rights.
• Assume breach: design as if an attacker is already inside, segment aggressively, and encrypt traffic even on internal networks.
• Evaluate continuously: a session that was trustworthy at login can stop being trustworthy; re-check posture and risk while it is in use.

The architecture behind the slogan

NIST describes three logical components. The policy engine decides whether a request should be allowed. The policy administrator turns that decision into action, establishing or tearing down the session. The policy enforcement point sits in the request path, such as an identity-aware proxy, a service mesh sidecar or an API gateway, and lets traffic through only when told to.

The decision draws on signals: who the user is and how strongly they authenticated, whether the device is managed and patched, how sensitive the resource is, and whether the behavior looks normal. Good implementations make those signals cheap to collect and hard to forge.

allow if
  user.mfa == "phishing-resistant"
  and device.managed and device.patched_within_days <= 14
  and resource.sensitivity <= user.clearance
  and session.risk_score < threshold

Where to apply it

CISA's Zero Trust Maturity Model organizes the work into five pillars: identity, devices, networks, applications and workloads, and data. Three capabilities run across all of them: visibility and analytics, automation and orchestration, and governance. It is a useful way to see where you are strong and where trust is still implicit.

A phased roadmap

Nobody switches to zero trust over a weekend. The organizations that succeed treat it as a series of measurable steps, each of which reduces risk on its own.

1. Inventory identities, devices, applications and data flows. You cannot write policy for things you do not know exist.
2. Consolidate identity behind one provider and enforce phishing-resistant MFA, starting with privileged and remote access.
3. Establish device trust: only managed, healthy devices reach sensitive applications.
4. Put applications behind an identity-aware proxy and retire broad VPN access one application at a time.
5. Segment workloads so services can only talk to the services they need, with mutual TLS between them.
6. Classify data and tie the most sensitive access to stronger conditions and closer monitoring.

Common pitfalls

• Rebranding a VPN or firewall upgrade as zero trust while keeping implicit trust everywhere behind it.
• Stronger authentication at login, followed by long-lived sessions that are never re-evaluated.
• Forgetting machine identities: service accounts and API keys often hold more privilege than any human.
• Making the experience so painful that users route around it. Good zero trust should feel faster than the VPN it replaces.

Done well, zero trust shrinks the blast radius of every compromise. A stolen password stops being a skeleton key, and a single infected laptop stops being a path to the crown jewels.