The Thing That Nobody Knew Was There 

I’ve spent most of my career focusing on penetration testing, red teaming, and vulnerability research and I’m often asked to share “war stories” and different ways I was able to break into organisations. Honestly, it was rarely anything to do with a clever chain of exploits. It was, mostly, due to the things that people didn’t know existed. I can’t tell you how many times there was a test server or a device that was made available 2 years prior for a project that was now over, that gave me some kind of initial access into an environment. Most of the time the box that we “popped” sat outside of policies because nobody knew it existed. 

All enterprise organisations have policies that are well intentioned and work in a good number of cases. The problem is that they only work on the estate that an organisation knows exists. Policies don’t work on things nobody knows about.  

Most of my time has been spent navigating that gap between policy and reality to find ways to break into organisations and help them identify where they need to improve. AI has made this a wider problem, and made it matter a lot more. It’s also why I get uneasy when “never trust, always verify” is said as if it settles everything. It’s 100% the right principle but nobody is asking, “verify against what”? 

We’ve Tried This Before

“Never trust, always verify” isn’t new. Network access control (NAC) was chasing a version of it long before anyone said Zero Trust. I consider somebody that is named on the original NAC patent a friend, and the intent was right: don’t let something onto the network just because it’s plugged in, you need to check it first. 

The issue is it didn’t work in practice. The idea itself wasn’t wrong; there was just simply nothing reliable to check against. Nobody had agreed what should be on the network in the first place, so every exception, unknown device, every single “we’ll sort that one out later” chipped away at it until the policy described an ideal network rather than anything real.  

I saw the exact same thing when I led the Transport Cyber Security division at NCC Group. When we first started testing the early connected cars the first platforms saw safety-critical features and infotainment simply sat together. It wasn’t until CAN gateways arrived that we saw real work go into separating them. Nobody designed it to be dangerous, but nobody had properly mapped what was talking to what, and why. 

Zero Trust is the better version of both ideas, because it’s honest about what verification needs. Every trust decision rests on data and context. What is this thing, who owns it, how much does it matter, what should it be talking to, and is any of that still true today? If you can’t answer those, you aren’t verifying, it’s all just assumption. 

AI Has Taken Away the Margin for Error

For years, organisations got away with an inventory that was roughly right. Things changed slowly enough that an annual review or a scramble before an audit would close most of the gaps. But AI has removed that now. AI tools, agents, and the integrations behind them are being connected faster than anyone can review them. We have machine identities being granted access with some of them moving on to provisioning connections of their own, and a lot are not being classified. Each one of these things is a trust decision that Zero Trust is supposed to make, about something that nobody has looked at. 

This isn’t a philosophical problem that we need to think hard about, we just need to be taking things more seriously. If an agent is acting on someone’s behalf, you need to know the same things you’d want to know about a laptop e.g. what it is, who owns it, what it can reach, and whether it should still be able to. The questions haven’t changed but there are just far more places to ask, and the answers go stale much quicker. 

Those answers are the intelligence layer Zero Trust has always needed. A continuously maintained view that IT and Security both trust and every policy decision can draw upon. AI doesn’t change what that layer has to contain, it changes how often it must be right.

Buying Enforcement Before You Know the Estate

This is where most programmes go wrong, and it’s an ordering issue. The parts of Zero Trust that can enforce, the policy engines, ZTNA platforms and segmentation rules, are the visible parts, so they end of up being bought first. Then the team finds out the data underneath can’t support them. 

Getting the order right takes planning more than purchasing. It means deciding what matters most, who is accountable for it, and what good looks like. It means keeping that picture current because a policy written against last quarter’s estate is enforcing rules on something that no longer exists.  

In practice this looks like IT having one inventory and security tooling showing another. Nobody owns reconciling the two

The Guidance Has Caught up With Practitioners

What’s encouraging is that official guidance now says what practitioners have known for a long time. The NSA’s Zero Trust Implementation Guideline series put discovery first i.e. visibility of assets, users, applications, data and access. CISA’s Zero Trust Maturity Model rests all five of its pillars on the same foundation. NIST SP 800-207 assumed it from the start. You need to know what you’re verifying against before you build anything that verifies. 

In Europe it is moving from guidance to law. NIS2 treats access control and asset management as a single measure. DORA requires financial entities to keep a classified inventory of their IT assets and third parties. The EU AI Act adds another layer about knowing which of your AI systems fall into which risk category. Again, three different rulesets and one starting point, you need an accurate, current view of what’s in your estate and the ability to show it.  

Where I’ve Landed

I’ve looked at this problem from the attacker’s side, from building my own security product which Lansweeper acquired, and now from within Lansweeper. My view is a simple one. “Never trust, always verify” is the right principle, but it doesn’t work on its own. Zero Trust fails when the decisions it depends on are made on assumptions, and AI is multiplying the assumptions.  

If you’re early in Zero Trust, or feel stuck in it, I’d ask one uncomfortable question before buying anything else. Could IT and Security agree on a single list of what’s in your estate today, and would that list still be right next month once the next round of AI tools has been connected? 

If the answer is no, that’s your first project. It’s also why I do the work I do. Knowing what you’re verifying against is the part of Zero Trust everything else rests on.