For years, enterprise security was built around a relatively simple assumption: keep threats outside the network, and the people and systems inside can largely be trusted.
That model no longer reflects how modern organisations operate.
Cloud services, remote working, SaaS platforms, mobile devices, third-party suppliers, APIs and distributed applications have fundamentally changed the corporate environment. The traditional network perimeter has become increasingly difficult to define – and increasingly difficult to defend.
Having spent more than a decade penetration testing customer environments, I’ve seen why that matters in practice. Once you gain an initial foothold, the question quickly becomes: what does the environment trust me to do next?
As a penetration tester, that’s often where things get interesting.
Zero Trust is not a single security product or technology. It is an approach to security based on a straightforward principle: a user, device, application or connection should not automatically be trusted simply because it sits inside a particular network boundary.
Instead, access should be evaluated based on identity, context, device security, resource sensitivity and other relevant signals.
Moving Beyond the Traditional Network Perimeter
Traditional security architectures often concentrate defensive controls around the network perimeter. Firewalls, VPNs and network segmentation remain valuable technologies, but they were largely designed around an environment where employees, applications and infrastructure were predominantly located within corporate facilities.
That isn’t the environment most of us are dealing with today.
An employee might access corporate resources from a home office using a managed laptop. A contractor could be connecting from another country. Meanwhile, applications are communicating with cloud services and other applications hosted somewhere else entirely.
The distinction between “inside” and “outside” is no longer enough to determine whether something should be trusted.
Zero Trust shifts the focus from where a connection originates to a more important question: should this user, device or application have the access being requested in the first place?
Identity is Critical – But it isn't Enough
Identity is understandably central to Zero Trust.
Multi-factor authentication (MFA), privileged access management (PAM), single sign-on and strong identity governance can all make it significantly harder for an attacker to gain or abuse access.
But there’s an important distinction here: successfully proving someone’s identity doesn’t necessarily mean they should have access to everything available to that identity.
Strong authentication is only the starting point. Security teams also need to consider the device making the request, the sensitivity of the resource, the level of privilege required and whether the activity makes sense in context.
This is something that becomes very apparent when you’re penetration testing. If I obtain valid credentials during an assessment, I’m not going to stop and celebrate the fact that I’ve got a username and password. I want to know what they give me. What can I access? What trusts this account? And where can I go next?
That’s the distinction that matters.
What Happens After a Compromise?
No security architecture can guarantee that an organisation will never be breached.
As penetration testers, we work on the assumption that individual controls can fail. Credentials can be compromised. Devices can be breached. Vulnerabilities can exist.
So rather than stopping at How do we prevent compromise? I think security teams also need to ask: What happens if that control doesn’t work?
If I obtain access to one legitimate account, can I reach systems that have little relationship to that user’s role? Can I access administrative interfaces? Can I move laterally through the environment? Can that one identity provide a route towards more sensitive systems or data?
In other words: what is the potential blast radius of a single compromise?
This is where Zero Trust becomes particularly relevant. Authentication should be only one part of the decision. Access can be restricted according to role, device, application, resource and context.
This supports the principle of least privilege: users and systems receive only the access they genuinely require.
For security leaders, this changes how the success of Zero Trust should be considered. It isn’t simply about how many controls have been deployed. A more meaningful measure is how difficult you’ve made it for an attacker to turn one compromised identity, device or application into a much wider incident.
Trust Has a Habit of Accumulating
One misconception I’ve encountered over the years is that implementing Zero Trust simply means purchasing the right collection of security products. It doesn’t.
Technology is important, of course. But some of the weaknesses we identify during security testing aren’t caused by a missing product. They’re caused by the relationships between identities, permissions, devices and systems – and the trust that has built up between them over time.
And trust really does have a habit of accumulating.
People change roles. Projects finish. Someone gets temporary access to solve a problem. A third party is brought in for a piece of work. A new system is introduced. Six months later, nobody has gone back and removed some of that access.
Individually, those decisions may all have been completely reasonable at the time. The problem is what you’re left with several years later: a web of permissions and trust relationships that nobody deliberately designed, but which may provide exactly the route through the environment that an attacker is looking for.
These are governance and operational questions as much as technical ones. Zero Trust therefore requires collaboration between security, IT, identity teams, application owners, risk functions and business leadership.
You Can't Protect What You Don't Understand
Visibility is another important part of the equation.
One thing you learn fairly quickly in penetration testing is that the environment on paper and the environment you actually find aren’t always quite the same thing.
That isn’t necessarily because somebody has done something wrong. Enterprise environments evolve. Systems are added, integrations change, people move around the business and exceptions are made to solve legitimate problems.
But undocumented systems, unexpected connectivity, historic permissions and forgotten access paths can all create opportunities for an attacker.
Good visibility allows security teams to move beyond asking:
“Is this connection allowed?”
and start asking:
“Why is this connection occurring, and does it make sense in context?”
That is a much more useful security question.
Where Should Organisations Start with Zero Trust?
For most organisations I’ve worked with, implementing Zero Trust overnight wouldn’t be realistic – or particularly sensible.
Enterprise environments are complex. Trying to redesign everything simultaneously can create its own operational problems, and Zero Trust shouldn’t become an exercise in making it harder for people to do their jobs.
I think a more useful starting question is: Where would excessive trust hurt us most?
For one organisation, that might be privileged accounts. For another, it could be third-party access, remote connectivity, critical applications or sensitive data.
Practical priorities might include:
- reviewing privileged and administrative access;
- introducing phishing-resistant authentication for high-risk accounts;
- removing historic or unnecessary permissions;
- improving device compliance and management;
- segmenting critical systems and applications;
- reviewing third-party access; and
- strengthening monitoring around sensitive identities and resources.
Then build from there. I’ve never viewed Zero Trust as something an organisation can simply finish and tick off a list. Environments change too quickly for that.
The aim is to continually remove unnecessary trust and make it harder for one successful compromise to become something much bigger.
The Business Case For Zero Trust
Zero Trust is often discussed entirely in technical terms, but its implications extend beyond the security team.
A mature approach can help organisations manage the risks associated with remote working, cloud adoption, third-party access and increasingly complex technology environments.
At its heart, though, it also forces an organisation to answer a deceptively simple question:
Who should have access to what, under which circumstances, and why?
It’s a question that sounds straightforward until you try to answer it across a large, complex enterprise.
Being able to answer that clearly is valuable not only during a cyber incident, but during audits, regulatory reviews, mergers, technology migrations and everyday operational decision-making.
A Penetration Tester's Perspective on Zero Trust
For me, the most important shift required by Zero Trust isn’t about a particular technology.
It’s about removing the assumption that something should continue to be trusted simply because it has successfully crossed one security boundary.
That doesn’t mean treating every employee as a potential attacker. Nor does it mean creating so much friction that people can’t work effectively.
It means accepting something that penetration testing demonstrates time and again: legitimate credentials can be stolen, trusted devices can be compromised and approved applications can contain vulnerabilities.
After more than a decade in penetration testing, that’s perhaps the principle I think matters most: Don’t build security around the assumption that an attacker will never get in. Build it so that getting in isn’t enough.
If one account is compromised, how far can an attacker move? If one endpoint is breached, what trusts it? If a supplier’s credentials are stolen, what becomes accessible?
Because the real test of Zero Trust isn’t whether you can prevent every compromise. It’s how far an attacker can get when one happens.
The risks highlighted in this article show why penetration testing needs to reflect how attackers operate in the real world.
Find out how MTI’s CREST and The Cyber Scheme-accredited penetration testing team can help identify and address vulnerabilities before they’re exploited.
About The Author
Connor Hunt is a Senior IT Security Consultant in MTI Technology’s Penetration Testing team, helping organisations strengthen their security posture through penetration testing and web application security assessments.
With more than six years at MTI and over 10 years’ experience in penetration testing, Connor is a CHECK Team Leader specialising in web application testing and holds the Principal Cyber Security Professional qualification with the UK Cyber Security Council.