The parts of zero trust that survived the budget

You can date the end of a hype cycle by the appearance of a document whose main purpose is correction. The NCSC published Demystifying Zero Trust on 29 October 2025, and its section headings read like a list of things British organisations spent five years getting wrong. Zero trust is not a quick fix. Zero trust is not a product. Zero trust means more security controls, not fewer. Zero trust doesn’t mean no trust. Zero trust and a VPN are not mutually exclusive. You do not complete zero trust.

The national technical authority does not write pages like that unless a great deal of money has already been spent on the misunderstanding.

What the idea actually was

The definition has been stable since NIST published Special Publication 800-207 in August 2020. Zero trust assumes no implicit trust is granted to assets or user accounts based solely on physical or network location or on who owns the device, and it treats authentication and authorisation as discrete functions performed before a session to a resource is established. The unit of protection moves from the network to the resource.

The NCSC’s own framing is a philosophy realised as an architecture, with seven design principles: know your architecture including users, devices, services and data; know your user, service and device identities; assess user behaviour and device and service health; use policies to authorise requests; authenticate and authorise everywhere; focus monitoring on users, devices and services; and do not trust any network, including your own.

Read that list carefully and notice what is not in it. There is no product category. There is no vendor. Six of the seven principles are inventory, identity and telemetry problems, which are exactly the problems large organisations are worst at and which no purchase resolves.

British government has published evidence of precisely that. The Government Cyber Action Plan, issued on 20 March 2026, records that the first year of GovAssure assessments found significant gaps across departments, with widespread low maturity in fundamental controls including asset management, protective monitoring and response planning. Two of those three map directly onto design principles one and six, knowing your architecture and focusing your monitoring. The third is what you need on the day both of them fail. An estate that cannot enumerate its own assets, or watch them, is not a candidate for continuously verifying every request against a policy engine. It is a candidate for finishing the inventory.

What went wrong in the middle years

Three failures recur, and each has a plain description in the current guidance.

The first was buying it. The NCSC is direct that zero trust is not something you can buy off the shelf and that misconceptions are not helped by vendors suggesting their products are zero trust. It calls it a strategic commitment and a significant undertaking. Organisations that bought a gateway and declared the programme delivered are the reason that sentence exists.

The second was treating VPN removal as the objective. The guidance says finding a replacement for your VPN should not be the goal of adopting zero trust, that the two are not mutually exclusive, and that a VPN provides specific controls a zero trust design may not, so you should identify what you actually depend on and remove it only once those controls have been replaced. A programme whose success measure was decommissioning a concentrator ended up optimising for the one artefact senior management could see.

The third, and most expensive, was removing old controls before the new ones were mature. The instruction is unambiguous: keep existing controls in place until the zero trust architecture is mature enough to provide equivalent or stronger protection, because migrating away too quickly creates gaps. That is a warning written from experience, and the experience was somebody’s incident.

There is also a straightforward cost sentence that ought to be quoted in more board papers. Zero trust, the NCSC says, can be costly, disruptive and resource-intensive, and pursued without a clear understanding of specific risks and objectives it can lead to wasted effort or even reduced effectiveness. Organisations are told to define the threat scenarios they are trying to address and to consider whether targeted controls could deliver similar benefits. That is the regulator-adjacent equivalent of saying most of you should not do all of this.

What teams kept

Strip out the branding and a consistent residue is visible in organisations that ran these programmes and are still running.

Identity became the control plane. Not as a slogan but as an operational fact: joiners, movers and leavers processes that actually complete, service accounts with owners, and a single place where an access decision is made. This is the part that delivered, and it delivered because it was overdue independently of the label.

Device health became a signal in the decision rather than a report nobody read. Whether a device is patched, encrypted and enrolled now influences whether a request succeeds, which is a small change with a large effect on the value of a stolen credential.

Administrative access got tiered. This is the least fashionable item on the list and the one with the clearest evidence behind it. The ICO’s £14 million penalty against Capita found no tiering model for administrative accounts, which allowed the attacker to escalate privileges, move laterally across multiple domains and compromise critical systems, and the regulator recorded that this had been flagged as a vulnerability on at least three separate occasions without being remedied. The ICO’s own remedial advice points at NCSC guidance on preventing lateral movement and applying least privilege. Neither the notice nor the advice uses the phrase zero trust. The controls have older names, and the names were never the problem.

Per-application access replaced network-level access for anything that could support it. And multi-factor authentication stopped being an exception granted to remote workers and became a property of every session.

What teams dropped

Microsegmentation everywhere. The idea survives in specific high-value zones and died as an estate-wide project, because the labour of defining and maintaining policy for every flow in a large enterprise exceeded any plausible risk reduction, and the policies rotted faster than they could be reviewed.

The end state. The NCSC’s phrasing is that you do not complete zero trust, and that full migration may require rearchitecting many systems over several years. Programmes with a completion date quietly became capability roadmaps, which is the honest form.

And the assumption that the estate would eventually be uniform. It will not.

The mixed estate is the permanent condition, not a phase

The NCSC has separate guidance on running a mixed estate because this is where every real organisation lives. Applications that do not support modern authentication standards such as SAML or OpenID Connect cannot mediate access through a policy engine and cannot verify every request, and the guidance names the consequence directly: increased risk of lateral movement. The available answer is a zero trust proxy acting as a policy enforcement point in front of the application, applying least privilege to something that has no idea any of this is happening.

For a British public body or a large insurer, that is not a transitional arrangement. There are line-of-business systems in this country that will be behind a proxy for the rest of their operational lives, because the vendor is gone, the integration is bespoke and the replacement business case has lost to a statutory cost pressure every year for a decade. Why those systems persist is the subject of councils run on systems nobody maintains.

Which reframes the whole question. Zero trust is not a destination the estate arrives at. It is a policy about what new things must do and a containment strategy for everything else, and the second half is where the budget goes.

How to tell whether a programme is real

Four questions, all answerable from evidence rather than a slide.

Can you name the threat scenarios the programme addresses, in the terms the NCSC asks for, or does the business case reduce to a compliance reference and a diagram? Does the inventory exist, given that the first design principle is knowing your architecture and almost nobody does? What proportion of the estate is actually behind a policy enforcement point, counted rather than estimated? And which control did you turn off, and what replaced it?

The last one is the important one. A programme that has removed nothing has probably added cost without reducing risk. A programme that has removed something without a documented replacement has done the thing the guidance explicitly warns against.

Related coverage of how attackers get the initial foothold that all of this is designed to contain sits in phishing got fluent and training did not, and the broader regulatory and incident picture is tracked under cybersecurity.