Zero Trust and Segmentation
Zero trust is not a product category. It is the decision to stop treating "inside the network" as a reason to trust, and to authorise every request on its own evidence.
The premise
The perimeter model assumes: inside = trusted, outside = hostile. That breaks when users work from anywhere, services run in three clouds, and one phished laptop is inside.
Zero trust replaces location with identity + device + policy:
Allow = f(who, what device, what service, what data, what context)
Every request is authenticated, authorised, logged, and least-privileged — regardless of which network it arrives from.
The five practical pillars
| Pillar | What it means | Concrete first step |
|---|---|---|
| Identity | Strong, phishing-resistant auth for humans and services | MFA, SSO, no shared accounts |
| Device | Posture is part of authorisation | Device inventory, disk encryption, patching |
| Network | Micro-segmentation, no implicit lateral trust | Default-deny between workloads |
| Application | Per-app access, not network access | Reverse proxy instead of VPN-in |
| Data | Classify and control, not just encrypt | Know where sensitive data lives |
Segmentation, done properly
| Approach | Mechanism | Strength |
|---|---|---|
| VLAN + ACL | L3 boundaries, stateless rules | Cheap, coarse, easy to bypass with routing mistakes |
| Firewall zones | Stateful policy between zones | Good default for enterprise |
| Micro-segmentation | Per-workload policy (security groups, mesh, host agents) | Fine-grained; needs identity and inventory |
| Service mesh mTLS | Cryptographic workload identity | Strong; adds operational weight |
| Air gaps | Physical separation | Strongest, most expensive, worst ergonomics |
The point of segmentation is not tidiness. It is bounded blast radius: a compromised host should reach its dependencies and nothing else.
What "default deny" actually requires
- An inventory of every flow that must exist.
- Identity for both ends of each flow (IP is not identity).
- Policy expressed in intent, version-controlled.
- Monitoring of denies, because the first thing default-deny does is break something real.
- An exception process with an owner and an expiry.
Without (1) and (2), default-deny becomes a list of hundreds of IP pairs that nobody can review, which is how segmentation projects fail.
The identity part is the hard part
Network controls are the easy half. The difficult questions:
- Do service accounts have their own identity, or do they all use one shared credential?
- Can a workload prove what it is without a human in the loop (SPIFFE, cloud IAM roles, mTLS certs)?
- Is the identity provider itself segmented, and what happens when it is down?
- Are privileged actions just-in-time and logged, or standing?
Where it goes wrong
- Vendor rebranding sold as strategy. A "zero trust" appliance in front of a flat network is a perimeter with better marketing.
- Segmentation with permit-any inter-VLAN routing. The VLAN exists; the policy does not.
- Policy by IP in a world of autoscaling. IPs change hourly; rules rot within days.
- Breaking the identity provider. Centralising everything on one IdP without a break-glass path turns an IdP outage into a total outage.
- Default-deny deployed without flow inventory. The outage is blamed on "zero trust" and the project is rolled back.
- Assuming VPN equals zero trust. A VPN grants network access; zero trust grants application access. They answer different questions.
- No break-glass access. When the policy engine is down, someone needs a documented, audited way in.
Related Notes
- Network Security Fundamentals — the threat model
- Firewalls And ACLs — enforcement points
- VPNs And Tunnels — why VPN-in is not the same as zero trust
- Overlays SDN VXLAN — policy in overlay networks