Zero trust has become one of the most repeated phrases in security, and the repetition has blurred its meaning. At its core it is a simple and sensible idea. No user, device or network location should be trusted by default, and every request for access should be verified against policy. Vendors, however, have found that the label sells, and products of many kinds now carry it. The silent threat in the title is complacency. An organisation that buys a tool, declares itself zero trust and moves on has changed its vocabulary rather than its risk. This commentary argues that zero trust is a direction of travel, a long programme of changes to identity, devices, networks and data, and that its difficulty is the best reason to take it seriously.
Is zero trust truly scalable?
It can be, but not all at once. A policy decision for every request sounds expensive, and in a large organisation with thousands of applications, many of them old, it is. Legacy systems may not support modern authentication, and some cannot be changed. The practical answer is to start with the most valuable assets and the riskiest access paths, bring them under policy and extend outward. Policy engines can make decisions quickly if they are designed with caching and local enforcement, and standard protocols reduce the amount of custom integration. Segmentation can wrap legacy systems in a controlled gateway until they are replaced. Scale comes from prioritisation and from automation of the repetitive parts of policy management, not from attempting everything simultaneously.
How is continuous compliance maintained?
The word continuous is part of the philosophy. Trust is not granted once at login and assumed afterwards. Device health, user behaviour and the sensitivity of the resource are evaluated repeatedly, and access can be reduced or revoked when conditions change. This depends on monitoring that is wide enough to see what is happening and on policies that are written as code, version-controlled and tested, so that changes are reviewed and consistent. Automated evidence collection reduces the burden of audits by showing, at any moment, which controls are in place and which are failing. Without this discipline, policies drift away from reality and exceptions accumulate, until the architecture resembles the old trusted network with additional steps.
Authentication is the foundation
If every request depends on proving identity, the strength of that proof matters most. Passwords alone are weak, and one-time codes can be phished or relayed by attackers. Stronger options include phishing-resistant authenticators such as FIDO2 security keys and passkeys, device certificates that identify managed machines, and mutual TLS for services that need to authenticate one another. Authentication must also cover non-human identities, including service accounts and automated workloads, which often outnumber people and are poorly governed. Good practice pairs strong authentication with short-lived credentials, narrow permissions and monitoring of unusual use, so that stealing one secret gives an attacker as little as possible.
Why it matters
Attackers increasingly operate with valid credentials, which perimeter defences cannot distinguish from legitimate use. Zero trust offers a coherent response, provided it is pursued as a programme with clear priorities, measurable progress and honest assessment of what remains unprotected. Leaders who treat it as a finish line they have crossed will be surprised by incidents, while those who treat it as continuing work will find the gaps first.
Zero trust is not something you buy. It is something you keep doing.
