Zero Trust Principles, Beyond the Buzzword
Few terms have been sold harder or understood less than Zero Trust. Strip away the marketing and it is a single, disciplined idea: the network location of a request tells you nothing about whether to trust it. Being "inside" the corporate network is not a credential. Every request — from any user, any device, anywhere — is verified on its own merits, every time. That one principle, taken seriously, reorganises how you build security.
The model Zero Trust replaces is the castle and moat: a hard perimeter, and soft, trusting interior. Get through the firewall — a VPN credential, a phishing foothold, a vulnerable edge device — and you are treated as trusted for everything behind it. Decades of breaches follow the same arc: attacker gets one foothold inside, then moves freely because the inside assumed the inside was safe. Zero Trust removes the assumption that made lateral movement easy.
The three things you verify
A Zero Trust decision is made per request, from three kinds of signal. Identity: who is this, proven with strong authentication, not just a password. Device: is the machine known, managed, and healthy — patched, encrypted, not flagged. Context: does this request make sense — the right time, place, and resource for this user, or an anomaly worth challenging. Trust is computed fresh from these each time, and it is never permanent.
It's a journey, and the seams are the risk
Nobody flips a switch to Zero Trust. It is an incremental migration — identity first, then device posture, then wrapping resources one at a time behind the enforcement point. The danger lives in the seams: the legacy application still reachable on the flat network, the service-to-service call that skips verification, the emergency access path someone left open. An architecture that verifies 90% of requests and trusts the network for the other 10% is only as strong as that 10%, because that is exactly where the attacker will go.
- Start with strong identity. Phishing-resistant authentication is the foundation; every other Zero Trust control assumes you actually know who is asking.
- Bring device posture into the decision. A valid identity on a compromised, unmanaged device is still a risk — the device signal is what catches it.
- Enforce least privilege per resource. Verifying every request is pointless if a verified request still grants broad access. Scope grants tightly and expire them.
- Hunt for the bypasses. The legacy system nobody migrated, the internal API with no auth, the flat VLAN in a branch office — those are where Zero Trust quietly isn’t.
- Pick one internal application and ask what happens if an attacker is already on your network but has no valid identity or healthy device. If they can still reach it, that app is still living in the castle-and-moat world.
- Look for the exceptions — the systems explicitly carved out of your Zero Trust rollout. Those documented gaps are the map an attacker would draw first.
Finding the seams where the network is still implicitly trusted — the bypass paths and un-migrated systems that undermine the whole model — is what our assessment hunts for, because Zero Trust fails at its weakest exception, not its strongest control.
Zero Trust is not a purchase; it is a principle you apply until the network stops being a source of trust. The vendors selling "a Zero Trust solution" are selling a component of a job that is mostly architecture and discipline. Get the principle right — verify explicitly, grant least privilege, assume breach — and the products slot into place. Get it wrong and you have bought expensive tools guarding a network you still, secretly, trust. And you cannot verify requests to systems you never knew were there.