Zero Trust Without the Product Catalogue

Zero trust has been marketed hard enough that the term now mostly signals a purchase. The underlying idea is simpler and older than the product category: stop treating network location as evidence of trustworthiness.

That is an architectural position rather than a technology, and most of the work involved is identity and inventory rather than anything you can install.

What the perimeter model actually assumed

Traditional network security assumed that inside the firewall was safe and outside was not. That was always an approximation and became untenable once applications moved to cloud services, staff worked from anywhere, and contractors and vendors needed access to specific systems.

The observable failure is lateral movement. An attacker who obtains any foothold — one phished credential, one vulnerable device — finds that the internal network trusts them. Most significant breaches follow this shape: modest initial access, extensive movement afterwards.

Zero trust says the network grants nothing. Every request is authenticated and authorised on its own merits, regardless of origin.

Identity is the actual project

If network position no longer grants access, identity must, which means your identity infrastructure becomes load-bearing in a way it probably is not today.

That requires a single authoritative source of who exists, complete coverage of applications behind it — including the legacy one with local accounts — and phishing-resistant authentication. It also requires the same rigour for non-human identities: service accounts, automation, machine-to-machine access. Those are frequently the weakest part, holding standing privileges with credentials that were set once and never rotated.

Organisations that stall usually stall here. The controls are understood; the inventory work of finding every application and every service account is tedious and unavoidable.

Segmentation, at a realistic granularity

Limiting lateral movement means workloads can only reach what they need. The aspiration is per-workload policy; the practical version is usually coarser, because writing exact policy for every service requires knowing what talks to what, which most organisations do not.

The useful sequence is to observe traffic first, in a monitoring mode, then write policy from what you see, then enforce. Attempting to write policy from architecture diagrams produces outages, because the diagrams omit the connections nobody documented.

Where machine learning genuinely contributes

The honest answer is anomaly detection on access patterns, and it is a supporting signal rather than a decision-maker.

Behavioural baselines — this account normally accesses these systems, from these locations, at these hours — can flag deviations that rules would miss. A credential used successfully but atypically is exactly what a stolen credential looks like, and no static rule expresses that well.

The limitation is precision. Behaviour changes for innocent reasons constantly: new project, new role, travel, a genuine change in working hours. A system that blocks on anomaly will block legitimate work often enough to be switched off. What works is graduated response — increase authentication requirements, log more, alert an analyst — rather than a binary decision.

The other genuine contribution is triage: ranking a large alert volume so investigators reach real cases sooner. That is valuable and unglamorous, and it does not require the model to be right, only to be better than arrival order.

Device posture, honestly assessed

Zero trust models usually include device health in the access decision — patched, encrypted, managed. That works well for corporate devices and becomes contentious for personal ones.

Requiring management agents on personal devices raises legitimate privacy objections and is frequently resisted. The workable compromise is tiering access by device: managed devices reach sensitive systems, unmanaged ones reach a limited set through a browser with no local data. That is a policy decision with real trade-offs rather than a technical one, and it needs deciding explicitly.

Legacy applications are where the exceptions accumulate

Every zero trust programme meets an application that cannot participate: it authenticates locally, has no modern protocol support, and cannot be modified because the vendor is gone or the source is lost.

The temptation is a permanent exception, and exceptions are where attackers go. The better options are an authenticating proxy in front of it, network isolation so tight that reaching it requires passing a controlled point, or an accepted decommissioning date with a named owner.

What matters is that the exception is recorded, time-bound and reviewed rather than granted once and forgotten. Most organisations discover during an incident that their exception list is longer than anyone believed.

The user experience decides whether it survives

Zero trust implemented badly means constant re-authentication, and staff respond by finding routes around it — shared accounts, saved credentials, work moved to unmanaged tools.

Done well it is frequently less intrusive than what it replaced, because single sign-on with a hardware key is faster than remembering distinct passwords, and step-up authentication only appears for genuinely sensitive actions.

Treating friction as a design constraint rather than evidence of rigour is what separates programmes that hold from those quietly abandoned after a year.

A sequence that tends to work

Consolidate identity and get phishing-resistant authentication everywhere, including the applications that were skipped last time. Inventory service accounts and remove standing privilege. Observe network traffic before writing segmentation policy. Add behavioural monitoring as a signal feeding graduated response, not as a gate.

Notice that only the last of those is a product purchase. Programmes that begin with the purchase generally discover that the identity work was the prerequisite, and do it afterwards at greater cost.

What it does not solve

Zero trust reduces lateral movement. It does not prevent initial access, protect against a compromised administrator, or help with a vulnerability in an application that a legitimate user is entitled to reach.

Worth being clear about that internally, because a programme sold as eliminating breach risk will be judged against a promise it was never able to keep.