For decades, network security looked something like a medieval castle. You built thick walls (firewalls, VPNs, network segregation), and once someone made it past the gate you mostly trusted them. The crown jewels sat in the middle, protected by the assumption that anyone close enough to touch them must belong there.
That model is finished. It has been for years, but the past decade made it impossible to pretend otherwise.
Why the walls came down
Three things broke the perimeter, and none of them are reversing.
Your applications left the data centre. They're in AWS, Azure, three different SaaS platforms, and a vendor's environment you don't even have a contract with. The perimeter you spent years hardening now wraps around an empty building.
Your users left the office. They work from kitchens and trains and hotel lobbies, on devices you may or may not own. Routing everything through the corporate VPN turned out to be both a bottleneck and a single point of failure, and it did very little to stop a determined attacker anyway.
And attackers got better. Phishing a credential, compromising a contractor, slipping malware into a software update: every modern breach story features an attacker who got inside the perimeter and then moved sideways with almost no friction. Once they were in, the castle worked against the defender.
The uncomfortable conclusion: "inside the network" was never a meaningful safety property. It was just a guess that happened to hold for a while.
What Zero Trust actually means
Zero Trust, a term Forrester coined back in 2010, is the response to all of this. The shorthand is "never trust, always verify," which sounds glib until you sit with what it implies. Every request, whether internal or external, human or machine, on a corporate laptop or a personal phone, gets authenticated and authorised on its own merits. Network location stops being a trust signal. Identity becomes one.
A few principles do most of the work.
Assume breach. Design as though the attacker is already on your network. This isn't paranoia; it's planning for the world you actually live in. Once you assume breach, things like internal traffic encryption and microsegmentation stop feeling excessive and start feeling obvious.
Verify explicitly. Make access decisions on everything you know: who the user is, whether their device is healthy, where they're coming from, what they're trying to reach, whether the request looks anything like their normal behaviour. No single factor is enough.
Least privilege. Give the minimum access required, for the shortest sensible duration. When something does go wrong, and it eventually will, you want the damage to stay small.
What this looks like in practice
A Zero Trust architecture isn't a product you buy. It's a set of capabilities you assemble, usually over years.
Identity sits at the centre. Strong multi-factor authentication for everyone, not just admins. Single sign-on through an identity provider. Conditional access policies that consider context (user, device, location, risk) before letting a request through. Increasingly, passwordless authentication using FIDO2 keys or certificates, because passwords remain the weakest link in almost every breach you read about.
Devices become a trust signal. A managed laptop with full-disk encryption, current patches, and working endpoint protection is treated differently from a random tablet on a hotel Wi-Fi. BYOD doesn't have to mean unrestricted access; it usually means web-only access, virtual desktops, or some other form of containment.
The network itself becomes untrusted by default. Traffic between services is encrypted even inside your own environment. Microsegmentation limits what any compromised host can reach. A software-defined perimeter can make resources literally invisible to anyone not authorised to see them, which is a useful thing when reconnaissance is half of any serious attack.
Applications and APIs participate too. Every service authenticates the caller. Service-to-service traffic uses mutual TLS or signed tokens. The days of "the call came from inside the cluster, so it must be fine" are over.
And underneath all of this sits data: classified by sensitivity, encrypted at rest and in transit, monitored for unusual access patterns, with every read and write logged somewhere a security team can actually use.
The UK government angle
For anyone building services in UK government, this is no longer optional thinking. The National Cyber Security Centre publishes specific Zero Trust guidance, and it has become the expected starting point for new services. Existing services are increasingly being asked to show a credible path towards it. The US federal government has gone further and mandated adoption across agencies.
The practical implication for architects is that Zero Trust questions will be asked at design review, at assurance, at procurement. Showing up with a VPN diagram and a perimeter firewall and calling it a day no longer holds up.
Where to start
The biggest mistake is treating Zero Trust as a single project with a launch date. Nobody flips a switch and arrives. The teams making real progress pick their highest-risk areas, usually privileged access, admin tooling, or sensitive data stores, and apply Zero Trust thinking there first. They get identity, device posture, and least privilege right in one place, prove the model works, then expand outwards.
The castle is gone. What replaces it, done properly, is genuinely more secure and more workable than what came before. Getting there is years of patient work, not a weekend's worth of new firewall rules.