Lawrence GrayEvery network eventually gets breached in some form, whether through a phishing email, a leaked credential or an unpatched server. The organisations that survive that moment well are not the ones who prevented it outright; they are the ones whose network was built so that a single compromised account could not simply walk from one system to the next uncontested. That difference is what separates a contained incident from a company-wide crisis.
Trust was always the vulnerability
Traditional network security drew a hard line around the perimeter and assumed that anything inside it could be trusted. Firewalls kept the outside out, and once a device or user was on the internal network, they moved with minimal friction between systems. That model made sense when offices had a clear physical boundary and everyone worked from the same building on the same wired connection. It makes considerably less sense now, and attackers have learned to exploit exactly that outdated assumption, often faster than the businesses relying on it can adapt.
Zero trust replaces that assumption with continuous verification: every request is checked, every device is assessed, and no user or system is trusted simply because it is already inside the network boundary. Testing how well this actually holds up in practice is where internal network pen testing earns its keep, simulating what a compromised account can actually reach once it has a foothold, rather than trusting the architecture diagram at face value.
The gap between the diagram and reality
Plenty of organisations have adopted zero trust language without changing the underlying access model. They have bought a product with zero trust in its marketing, deployed it alongside the existing flat network, and declared the project complete. The uncomfortable truth only surfaces when someone actually tests whether a compromised laptop in the marketing department can reach the finance server, and finds that it still can, product or no product, marketing claims notwithstanding.
William Fieldhouse has run into this disconnect on more assessments than he can easily count.
“I have tested networks with a genuinely impressive zero trust product sitting on top of a network that still lets any device talk to any other device once it is past the login screen. The product was real. The trust boundaries it was supposed to enforce simply were not there yet. That gap is where every serious breach I have investigated actually spread.”
— William Fieldhouse, Director of Aardwolf Security Ltd
The lesson is not that the products are worthless, but that they only deliver on the promise once the underlying segmentation, identity verification and least-privilege access are genuinely in place. A product enforces policy; it does not invent the policy for you. Organisations that skip the design work and jump straight to the purchase order end up with expensive tools guarding boundaries that do not really exist, which is arguably worse than having no tool at all, since it breeds false confidence.
Assume breach, then prove your architecture holds
Building genuine zero trust starts with assuming a breach has already happened somewhere in your network today, and asking what an attacker could reach from that starting point. Segment aggressively, verify continuously, and grant access based on need rather than location. Pair that design work with Azure pen testing to validate the segmentation actually functions the way the architecture diagram claims, rather than discovering the gap during an actual incident. Contact Aardwolf Security to have your zero trust assumptions properly tested rather than taken on faith.
Karen Murphy
