A zero trust architecture is a genuine, well-defined security model, formalised by NIST and adapted for the UK by NCSC. It is also one of the most misused terms in security marketing. Plenty of products get sold under that name while implementing only a fraction of what the actual standard describes. Here is what zero trust genuinely requires, and where the marketing gets ahead of the substance.
Table of Contents
What the zero trust architecture standard actually says
NIST’s definition is precise, if unglamorous. Zero trust assumes the network is already compromised. Access decisions get built around users, devices and policy, not network location. NCSC’s version is just as direct: the network is assumed hostile, and every request is verified against an access policy. Neither definition mentions a specific product. Neither describes a single control you can buy and install.
That gap between the standard and the marketing is where most confusion lives.
Where the marketing gets ahead of the substance
Search for “zero trust” and most of what comes back is a vendor pitch. A single sign-on product. A network access broker. An endpoint agent. Each of these can genuinely support pieces of a zero trust architecture. None of them, bought alone, delivers the architecture NIST actually describes, which spans identity, device health, policy enforcement and continuous monitoring working together.
Buy one product and call the job finished, and you have implemented a fragment while believing you covered the whole model. That gap between “we bought zero trust” and “we built a zero trust architecture” is exactly where real exposure hides.
NCSC’s eight principles, stripped of the sales pitch
| Principle | What it actually asks of you |
|---|---|
| Know your architecture | An honest inventory, not a slide deck |
| Know your identities | Every user, service and device uniquely identifiable |
| Assess behaviour and health | Real signals feeding real decisions |
| Use policies to authorise | Written rules, actually enforced |
| Authenticate everywhere | No exceptions for “trusted” internal traffic |
| Focus monitoring correctly | Watch entities, not just perimeter traffic |
| Trust no network | Including the one you own |
| Choose capable services | Verify vendor claims against this list, not the other way round |
Read that list honestly and it becomes clear why no single product covers it. It spans identity management, device posture, policy design and monitoring discipline, which is organisational work as much as technical work.
Why the old perimeter model quietly failed
Nobody designed the perimeter model to fail. It made reasonable sense when work happened inside a building with a defined network edge. Remote work, cloud services and contractor access dissolved that edge gradually enough that a lot of businesses never formally noticed. The firewall is still there. It just stopped mapping to where the actual risk sits.
That gradual failure matters because it explains why zero trust is not optional theatre. Lateral movement and privilege escalation are the techniques that turn one compromised account into a full breach. Both depend entirely on that old assumption: get past the edge, and the rest is easy. Zero trust removes the easy part.
What genuine progress actually looks like
Not a big-bang product rollout. NCSC frames this as a gradual architectural direction, and the businesses that make real progress tend to follow that advice. Start with identity, since almost every other principle depends on knowing who or what is making a request. Add device health checks next. Extend policy enforcement to your highest-value systems before your least important ones. Legacy systems that cannot support any of this get flagged honestly, not quietly ignored because fixing them is inconvenient.
Where compliance frameworks fit into all of this
Cyber Essentials, ISO 27001 and PCI DSS all expect access control and least privilege in some form, and it is tempting to treat zero trust as a shortcut to ticking those boxes. It is not quite that simple. None of these frameworks mandate the full NIST specification, and passing an audit built around a partial implementation does not mean the underlying architecture would hold up under a genuine attempt to bypass it. Treat compliance as a useful checkpoint along the way, not the definition of done.
Proving it actually works
A design document describing zero trust proves nothing on its own. It does not confirm whether verification genuinely holds under a real attempt to bypass it. An internal network penetration test is what actually answers that question. Can a compromised account move or escalate? Does the architecture do what its documentation claims? Our guide on judging a provider’s penetration testing methodology covers what a tester should be doing here. Do not take the “zero trust” label at face value.
What a genuine zero trust architecture costs versus a partial one
The honest answer is that a genuine architecture costs more than a single product. It costs more in money and, especially, in organisational effort. It means an identity system, device health checks, policy design and monitoring, coordinated rather than bolted together. A partial implementation looks cheaper upfront. It also creates a false sense of security, and the gaps it leaves open tend to get found by an attacker instead of a tester.
That is not an argument against starting small. It is an argument against calling a small start the finished job, since the gap between the two is exactly where an attacker looks first.
Frequently asked questions
Can we just buy a product labelled “zero trust” and be done?
No. A single product typically covers one or two of NCSC’s eight principles at most. Genuine zero trust spans identity, policy, monitoring and device health working together, which no single purchase delivers.
Is this only relevant to large enterprises?
The full specification was written with complex environments in mind. But the underlying principle, verify every request rather than trusting network location, applies at any size. Smaller businesses can apply it through strong authentication and access reviews without enterprise tooling.
How long does a genuine implementation take?
Years, for anything beyond a small business, not months. NCSC treats it as an ongoing architectural direction. Vendors promising a fast, complete rollout are usually describing their product’s scope, not the full architecture, so ask specifically which of the eight principles their timeline actually covers.
Does this replace the need for a firewall?
No. A firewall still controls what reaches your network from outside. Zero trust addresses a different question: what happens to every request once it arrives, regardless of source. The two work together, one filtering traffic at the edge and the other verifying everything that gets through.
What is the clearest sign an implementation is only partial?
Legacy systems still granting access based on network location alone. If anything on your estate skips verification because it is “internal,” the architecture is not actually zero trust yet. That holds true whatever the label on the dashboard says. Finding those exceptions honestly, rather than quietly excluding them from scope, is what separates real progress from a compliance exercise.
Aardwolf Security’s internal testing is built to answer one question directly: would your architecture genuinely hold up under a real attempt to move or escalate, rather than just on paper? Get in touch to talk it through, or see our full penetration testing services.
Subscribe to our newsletter
Honest updates, straight to your inbox. Unsubscribe any time.
