Zero Trust Architecture: When 'Trust But Verify' Became 'Never Trust'

Zero trust architecture has spent most of this decade as a slogan and is now, finally, becoming a specification. Standards bodies are circulating draft guidance, the large platform vendors have shipped the pieces, and the model that Google described publicly after rebuilding its own access controls has been copied enough times to know which parts generalise. Which means the honest question for a chief information officer this autumn is no longer whether the idea is sound. It is what the first eighteen months actually look like, and what it costs. The idea itself is a single sentence: stop granting access based on where a connection comes from. Everything else, the device posture checks, the per-application gateways, the identity-centred policy, follows from abandoning the assumption that being inside the network means anything.

What the perimeter model actually broke on

It is worth being precise about the failure, because the vendor version is vague. The castle-and-moat design was not defeated by a clever attack. It was defeated by the estate changing shape underneath it. Applications moved to providers outside the perimeter, so the perimeter stopped containing the things it was protecting. Staff worked from home, hotels and airports, so the perimeter stopped containing the users either. Acquisitions arrived with their own networks, which were merged by connecting them, which meant inheriting whatever was already living inside them. Contractors, auditors, integrators and managed service providers all needed access, and the only mechanism available was to let them in. And once inside, a connection could reach far more than its purpose required, because internal networks are almost always flat. So the perimeter still exists as equipment and expenditure while having largely stopped functioning as a control. Zero trust is the argument that the access decision should be made per request, on the basis of who is asking, what device they are asking from, what they are asking for and how sensitive it is, and that the answer should not improve merely because the request arrived over a corporate network.

The three prerequisites nobody sells you

Most failed programmes in this area fail before any technology is deployed, because three unglamorous foundations are missing. An authoritative identity. One directory that is genuinely the source of truth, with joiners, movers and leavers reflected quickly, groups that mean something, and privileged accounts separated from daily ones. If identity is scattered across four systems, a policy engine has nothing reliable to decide with. A device inventory with posture. You cannot condition access on device health without knowing which devices exist, who holds them, and whether they are patched, encrypted and running endpoint protection. Most organisations discover their inventory is an asset register maintained by finance for depreciation purposes. An application catalogue. What applications exist, who owns each, where each runs, who should be able to reach it, and how it authenticates. This is the piece that takes longest and cannot be bought. None of that is zero trust. All of it is the price of entry, and an organisation that spends its first year doing only these three things has spent the year well.

Sequence it where the pain already is

The programme framing that works is a series of finite projects, each with its own benefit, rather than an architecture transformation with a horizon of several years. Start with remote access, because replacing a full-tunnel virtual private network with per-application access removes the largest single over-grant in most estates: a contractor or a laptop gets one application rather than the whole internal network. Then third parties, because that population is externally controlled, high risk, and small enough to move quickly. Then privileged administrative access. Then the crown-jewel applications, individually. Then everything else, slowly, or never, because the last twenty per cent is rarely worth the cost. Run each as a project with an end date, a measurable reduction in what a compromised credential can reach, and a clear owner. Programmes described as multi-year journeys get cancelled in year two when the sponsor changes.

Practical Guidance for a Zero Trust Implementation Assessment

• Audit what your current remote access actually grants. Connect as a typical contractor and enumerate what is reachable. The result is usually the most persuasive slide in the business case.
• Fix identity before buying anything. One authoritative directory, prompt deprovisioning, separated administrative accounts, strong authentication for anyone privileged.
• Build the device inventory and define a minimum posture. Patched, encrypted, protected, managed. Decide now what happens to unmanaged and personal devices, because that decision shapes everything after it.
• Catalogue applications and assign owners. Nobody can write access policy for a system with no owner, and every estate has dozens.
• Replace remote access first, per application. Fastest visible risk reduction, and it retires an appliance whose licence you were going to renew anyway.
• Segment the network in parallel, coarsely. Full micro-segmentation is a multi-year exercise; separating servers from users, production from corporate, and payment systems from everything else is a quarter's work and stops most lateral movement.
• Log the access decisions and actually read them. The policy engine produces an audit trail of who reached what. That record is worth as much to your auditors as the control is to your security team.
• Map each step to the framework your regulator already uses. Translate the work into the control language you are examined against, or you will be asked to justify it twice.

The Regional Angle

Four regional realities change the sequencing here, and the first is the most distinctive. The Gulf runs on contracted labour and outsourced functions to an extent that few other markets do. Facilities management, manpower supply, security services, IT support, accounting, engineering secondments: in a typical regional group, a substantial minority of the people using corporate systems are not employed by the company at all. They are onboarded quickly, they often share devices and sometimes accounts, they leave at the end of a contract without an exit process, and they are frequently issued the same network access as permanent staff because that is the only access model that exists. This population is the strongest possible argument for per-application access, and it is where a regional programme should begin. The security benefit is obvious, and the administrative benefit is larger than expected, because per-application access finally makes it possible to know what a departing contractor could reach. Second, the framework question. Regulated entities here are examined against established regional control frameworks, the central bank cyber security requirements in Saudi Arabia and the national information assurance standards in the Emirates among them, and those frameworks were written in the language of network zones, boundary protection and defence in depth. A zero trust design can satisfy them comfortably, but only if you do the translation explicitly and document how an identity and device-based control achieves the objective the control was written for. Regional examiners are increasingly familiar with the model; the assessor you get may not be. Prepare the mapping before the examination rather than during it. Third, network shape. Regional family groups and conglomerates typically grew by adding entities, each connected into a shared corporate network so that group finance and group information technology could reach them. The result is a single flat network spanning legally separate companies with genuinely different risk profiles, which is a segmentation problem, a data protection problem and, in several jurisdictions now, a tax and substance problem as well. Separating entities from one another is often the highest-value segmentation available here and it has benefits well beyond security. Fourth, money and timing. Perimeter hardware in this region tends to be bought outright on a refresh cycle rather than consumed as a service, and a chief financial officer looking at three years of remaining depreciation on a firewall estate will resist an argument that the perimeter no longer matters. Do not make that argument. Zero trust does not require decommissioning the perimeter, it requires that it stop being the basis of access decisions, and the right moment for the commercial conversation is the next refresh rather than the middle of an asset's life.

The objection worth taking seriously

The sharpest objection is that zero trust is a rebrand. Network access control, least privilege, strong authentication and segmentation have all been standard advice for fifteen years. Putting a name on the combination has generated an enormous amount of vendor marketing and very little that could not have been described in existing language, and the practical effect has been to let organisations buy a product and declare an architecture. The second objection is capability, not concept. A model developed by a company with thousands of engineers, complete control of its endpoint fleet and applications it wrote itself does not transfer cleanly to a mid-market group running packaged software, contractor laptops and three systems whose owners left in 2016. Telling that organisation to condition every request on device posture describes a destination with no road to it. The third objection is concentration, and it is the one I find hardest to dismiss. Zero trust makes the identity provider the single point on which everything depends. Compromise it, or lose it to an outage, and you have not distributed risk, you have relocated it into one system with far more consequence than the firewall ever had. All three deserve a straight answer. On the rebrand: the label is doing real work, because it forces the access decision to be evaluated per request rather than inherited from a network position, and that reframing is why segmentation and least privilege are finally getting funded after fifteen years of being recommended. On capability: the answer is sequencing, which is why the programme should begin with remote access and third parties rather than with an architecture diagram. On concentration: it is correct, and it means the identity platform needs hardware-backed authentication for administrators, tested break-glass access, its own monitoring and a documented outage procedure. A dependency you have identified and hardened is a better position than a perimeter everyone has quietly stopped believing in.

Common Questions

Can we do this without replacing our network?

Yes. The first two phases, per-application remote access and third-party access, sit alongside the existing network. Coarse segmentation can usually be done with equipment already in place.

How long does it take?

The foundations take six to twelve months for a mid-market organisation. Remote access replacement is a quarter. Full coverage of internal applications takes years and is rarely completed, which is acceptable if the highest-value applications are done first.

Does this remove the need for a virtual private network?

For most user access, eventually yes, and that is the clearest cost offset in the business case. Expect to keep some tunnelled access for legacy systems and network administration for a long time.

What should we expect over the next twelve months?

Expect formal standards guidance to be published and then cited in tenders, which will move the term from marketing into procurement language. Expect identity-centred access products to be bundled into the platform subscriptions many organisations already hold, changing the economics for mid-market buyers. And expect regional regulators to begin acknowledging identity and device-based controls explicitly in their frameworks, which will make the mapping exercise easier than it is today.

---

Zero Trust Implementation Assessment — we show you what your remote access actually grants today, then sequence the work into finite projects that reduce that number, starting with your contractors.