Zero Trust Security: How to Actually Start (Without a Full Network Rebuild)

Zero trust security means no user, device or connection gets trusted by default. That includes ones already inside the office. Every request for a file, an app or a system gets checked. The check looks at identity, device health and context. It happens the moment the request is made, then again next time. The goal is simple. One stolen password or one infected laptop should never be enough to reach everything else a business owns.

Most articles explain the theory and stop there. This one focuses on what a business actually has to do to adopt zero trust security, and where that effort commonly goes wrong.

What zero trust security is not

This is worth clearing up first, since vendor marketing has blurred the term badly. The National Cyber Security Centre says it plainly. Zero trust security is not a product you buy off a shelf. It does not mean running fewer security tools. And it does not mean nobody is ever trusted. Trust still exists under a zero trust security model. It just has to be earned each time, not handed out once at login and left standing. The NCSC also says to keep existing controls, VPNs included, running until proven zero trust tools are in place.

The rule that replaces automatic trust

The NIST definition treats the network as already breached. Every access call gets made per request, not per session. In short, every service and data store is worth protecting, not just the obvious servers. Links get locked down whether they cross the internet or stay inside the building. Access is granted per session, based on live signals: who is asking, what device they are on, and whether that device looks healthy right now. Nothing gets waved through just because it started inside the network.

Why the old model stopped working

The term traces back to Forrester analyst John Kindervag. He described the problem in a 2010 report as a “chewy centre”: a hard perimeter, with almost unrestricted movement once someone got past it, according to Forrester’s own account. That design tolerated its weaknesses reasonably well when everyone worked from one office network.

It tolerates them far less well now. Staff log in from home. Contractors need short-term access. Applications sit across several cloud providers instead of one data centre. The NCSC compares the fix to airport security rather than a front door: prove your identity repeatedly, at every stage, instead of once on the way in. That repeated check is the core idea behind zero trust security.

A realistic starting checklist

The NCSC’s own design principles set out where to begin. It is not with a shopping list of software.

1. Map what you have. Users, devices, apps and the data they touch. Policy cannot cover what has not been identified.
2. Fix identity first. Strong, unique identification of users and services is the foundation everything else depends on.
3. Pick one high-value system to pilot. Not your oldest, most tangled legacy platform. Prove the approach somewhere manageable first.
4. Plan for what will not fit yet. Legacy systems that cannot support per-request checks need a gateway or segmentation strategy. Decide this early, not later.
5. Set a multi-year roadmap. Anyone promising a complete zero trust security rollout in a quarter is either overselling or underestimating the work.

What zero trust security looks like day to day

A business further along this path tends to share a few habits. Multi-factor authentication applies to everyone, not just admins. Devices get checked for basic health before they reach company data: are they patched, encrypted, and running live security software? The network is split up, so a hacked laptop in one team cannot simply reach another team’s servers. Access is scoped tightly to what each role needs, and checked on a schedule instead of piling up unchecked for years. Monitoring flags anything odd, such as a login from two countries within an hour.

Where businesses get this wrong

The most common mistake is buying tools before the identity and mapping work is done. That usually adds an expensive layer on top of the same access problem it was meant to fix. A close second is trying to convert every old system at once. It works better to contain the ones that cannot change yet. A quieter mistake is treating a zero trust security policy as finished once it is written. Nobody then tests whether it holds up against someone who actually tries to break it.

There is also a people problem that rarely makes the vendor slide decks. Staff used to broad, standing access tend to notice, and complain, when that access narrows to only what their role needs. Rolling out tighter policy without explaining why invites workarounds: shared logins, requests to “just add me to everything”, or shadow IT that quietly routes around the new controls. Treating the change as a communication project, not just a technical one, heads off most of that friction before it starts.

What this costs, in time and budget

Businesses researching this want a number, and there is no single honest figure to give. The cost depends on how much can reuse tools you already own. Most identity providers and endpoint tools now support the core checks. It also depends on how much needs fresh spend, and how many old systems need a gateway built around them rather than a simple upgrade.

The early stages, mapping assets and fixing identity, cost more in time and effort than in licence fees. The expensive part tends to arrive later. Older apps that were never built for per-request checks need replacing, or wrapping in a compatibility layer. Budget for a multi-year zero trust security programme, not a single line item. That way, the real cost will not come as a shock halfway through year one.

Testing whether zero trust security is real, not just documented

That last point matters more than any other. An internal penetration test starts from an assumed breach: a phished account or an infected device. The tester then tries to move sideways through the network, exactly as a real attacker would. If that gets further than your policy documents suggest it should, the model is not working yet, whatever the paperwork says.

A red team assessment goes a step further. It also checks whether anyone notices and reacts while the attack happens. Detection matters as much to zero trust security as the access rules do. Aardwolf Security scopes penetration testing work around the parts of your setup carrying the most risk, then reports honestly on what held and what did not. Getting in touch costs nothing but a conversation about where to start.

Frequently asked questions

Do I need to buy new software to start with zero trust security?

Not first. The groundwork, mapping assets and fixing identity, matters more than any single purchase and should come before tool shopping.

Can I keep my VPN while adopting zero trust security?

Yes. NCSC guidance recommends keeping VPNs and other existing controls running until equivalent zero trust protections are tested and proven.

How long should a realistic rollout take?

Years, typically. Most businesses phase it in, starting with identity, then a small number of priority systems, rather than one flat rollout across everything at once.

Is zero trust security achievable for a small or mid-sized business?

Yes, with proportionate tooling. The principles, strong identity, least privilege, per-session access, apply regardless of company size.

Does zero trust security overlap with Cyber Essentials or ISO 27001?

Substantially. Access control, authentication and monitoring requirements in both frameworks map closely onto zero trust practices. Neither one requires a full zero trust architecture by name, though.