Zero Trust Architecture

"Never trust, always verify." That's the core of zero trust in five words. It kills the castle-and-moat model of security — the idea that everything inside the corporate network is trusted and everything outside isn't. That model made sense when everyone sat in the same office, used company machines, and accessed on-prem servers. It doesn't survive contact with cloud, SaaS, remote work, and personal devices.

Why the Perimeter Died

The traditional model put a firewall at the edge, ran a VPN for remote access, and treated the internal network as a trusted zone. Once you were "in," you could reach basically everything.

The problem: the perimeter dissolved. Your applications run in three cloud providers. Your data lives in SaaS products you don't control. Your employees work from coffee shops on personal laptops. The "inside" and "outside" distinction doesn't map to anything real anymore.

Worse, the flat-network problem makes this actively dangerous. One phished employee connects via VPN, and the attacker is "inside" the trusted network. From there, lateral movement is trivial — scanning internal services, accessing shared drives, hopping from the compromised laptop to the database server with no additional checks. The VPN didn't protect anything; it just gave the attacker a longer tunnel.

Core Principles

Zero trust rests on three ideas:

Verify explicitly, every time. Every access request is authenticated and authorized based on all available data points — user identity, device health, location, time, resource sensitivity. Not just "are they on the VPN" but "is this a managed device, is the OS patched, does their role grant access to this specific resource, is this request anomalous?"

Least-privilege access. Grant the minimum permissions needed for the task at hand, and scope them in time. Just-in-time access that expires after an hour is better than standing admin privileges that last forever.

Assume breach. Design your systems as if the attacker is already inside. Segment aggressively. Encrypt internal traffic. Log everything. Minimize the blast radius of any single compromised component.

Building Blocks

Zero trust isn't a product. It's an architecture built from several components working together.

Strong identity as the new perimeter. If you can't verify who someone is with high confidence, nothing else matters. This means robust authentication (MFA at minimum, phishing-resistant methods like FIDO2/WebAuthn preferred), a centralized identity provider, and identity-based policy enforcement.

Device posture and health checks. Is this a managed device? Is the OS version current? Is the disk encrypted? Is endpoint detection running? A legitimate user on a compromised device is still a threat.

Per-request authorization. Every request to every resource gets evaluated against policy. Not "you logged in this morning, so you're good for 8 hours," but continuous, contextual evaluation. The policy can factor in the user, device, resource sensitivity, time, location, and behavioral signals.

Micro-segmentation. Instead of one flat network where everything can talk to everything, segment workloads so the payment service can only reach the payment database, not the HR system. If the payment service is compromised, the blast radius is contained.

Continuous verification. Authentication isn't a one-time gate at login. Sessions are re-evaluated. Step-up authentication kicks in for sensitive operations. Anomalous behavior triggers additional verification.

Comprehensive logging. You can't detect what you can't see. Every access decision, every denied request, every anomaly gets logged and fed into detection systems.

The Policy Engine Model

At the heart of a zero trust architecture sit two components: a policy engine (PE) that makes access decisions and a policy enforcement point (PEP) that executes them.

The PE takes in signals — who is requesting, from what device, to what resource, under what conditions — and evaluates them against defined policies. The PEP sits in front of every resource and blocks or allows requests based on the PE's decision.

This is where identity-aware proxies come in. Google's BeyondCorp, Cloudflare Access, and AWS Verified Access all implement this pattern. Instead of a VPN that dumps you onto a network, an identity-aware proxy sits in front of each application. Every request is authenticated and authorized before it reaches the application. The application never sees unauthenticated traffic.

What Zero Trust Is Not

It's not a product you buy. No vendor sells a "zero trust box." It's an architecture and a set of principles implemented across identity, device, network, application, and data layers. Vendors sell components that help — but deploying one product doesn't make you zero trust.

It's not purely a network thing. Network micro-segmentation is one piece, but zero trust spans identity, device management, application-level authorization, and data classification. If you micro-segment your network but still have standing admin privileges and no device health checks, you haven't achieved much.

Migration Reality

Nobody flips a switch and goes from perimeter security to zero trust overnight. It's incremental.

Start with the crown jewels. Identify your most sensitive systems and data. Put an identity-aware proxy in front of them. Require strong authentication and device health checks. Log everything. Once that works, expand to the next tier of systems.

Many organizations run hybrid for years — zero trust for critical internal applications, traditional VPN for legacy systems that can't be easily proxied. That's fine. Progress over perfection.

Real World: BeyondCorp

Google built BeyondCorp after Operation Aurora in 2009, a sophisticated nation-state attack that penetrated their corporate network. Their conclusion: the perimeter model had failed. They spent years rebuilding so that every internal application is accessible over the public internet, with every request authenticated and authorized by a proxy that evaluates identity, device state, and context.

The result: Google employees don't use a VPN. There is no privileged internal network. Access to a resource depends on who you are and the state of your device, not which network you're connected to. The network is treated as hostile, always.

This isn't theoretical. It's been in production at Google for over a decade, serving hundreds of thousands of employees. It works. It's also a multi-year investment that required rethinking identity, device management, application architecture, and operational processes.

Key Takeaways

• Zero trust replaces the failed perimeter model with "never trust, always verify" — every request is authenticated and authorized regardless of network location.
• The three core principles are: verify explicitly every time, enforce least-privilege access, and assume breach.
• Identity is the new perimeter. Strong authentication plus device health checks replace VPN-based network trust.
• Micro-segmentation contains blast radius by ensuring compromised components can't reach unrelated systems.
• Zero trust is an architecture, not a product. No single purchase gets you there.
• Migration is incremental — start with your most sensitive systems and expand outward.

Next up: Threat Modeling — systematically finding design flaws before you build them.