Everyone agrees, and almost nobody has finished

Why is a simple idea taking a decade?

The proposition takes one sentence: stop treating network position as evidence. Ask for proof at every request instead. Nobody in the field argues against it, which is unusual enough to be worth noticing, and the completion figures still sit at a sixth of the organisations that endorse it.

The reason is that the assumption being removed is load-bearing. Applications were written expecting that anything reaching them had already been vetted by the network, so they check identity thinly or not at all. File shares assume the same. Printers, cameras, building systems and industrial controllers assume it absolutely, because they were installed when a locked door and a cable were the security model. Removing the assumption means either replacing those things or wrapping each one, and both are projects rather than settings.

The second obstacle is more embarrassing and better documented. Around 78% of organisations manage access policy across more than two separate systems — an identity provider, a network product, a device manager, a cloud console, each with its own rules and its own idea of what a user is. The architecture depends on one consistent decision per request, and most estates cannot produce a single consistent answer about who anybody is.

Add a shortage of people who have done it before, and the pattern in the figures makes sense: broad agreement, partial deployment, and a self-assessed effectiveness of about six out of ten that has stopped improving. That plateau is where most programmes actually live, and describing it as failure is unfair — describing it as finished is worse.

What the word means on a price list

A term that describes an architecture is awkward to sell, so the market solved the problem by attaching it to products. Identity platforms, network access services, device managers, browser isolation, secure web gateways and several categories of appliance all carry the label, and each is describing a genuine part of the picture while implying it is the picture.

The useful question in a purchasing conversation is not whether something is zero trust. It is which specific assumption this product lets you stop making, and what remains true afterwards. A device-posture service lets you stop assuming a machine is healthy because it is domain-joined. An identity-aware proxy lets you stop assuming that reaching an application means being entitled to it. Neither lets you stop assuming both, and no single purchase does.

The other question worth asking is where the policy lives. Every product that enforces access also wants to be the place the rules are written, and an organisation that says yes four times has built the tool sprawl that the surveys identify as the principal obstacle. Choosing one place to express access policy and treating everything else as an enforcement point is duller than any product demonstration and matters considerably more.

A third question rarely gets asked and answers the other two. What does this thing do when it cannot reach the internet, or when the licence lapses, or when the supplier is acquired by somebody with different priorities? Access control is infrastructure now, not a subscription like a mailbox, and the practical test of any candidate is whether an organisation could migrate away from it in a quarter without rewriting every application behind it. Products that keep policy in an exportable form and speak ordinary standards pass that test. Products whose configuration exists only inside a console someone else operates do not, however capable the console.

None of which means the products are unnecessary. It means the architecture is the thing being bought and the products are components of it, and organisations that reverse that relationship end up with an expensive collection of enforcement points disagreeing with each other about who somebody is.

What does it actually stop?

Less than the brochures imply and more than the sceptics allow. The measured difference is roughly $1.76m per breach between organisations that have deployed it and those that have not, and the shape of that saving is worth understanding, because it is almost entirely about distance travelled rather than entry prevented.

An intrusion normally begins somewhere unglamorous: a laptop belonging to somebody in accounts, a forgotten server, a supplier account with a weak password. Under the old model that foothold was worth a great deal, since the machine sat inside and inside meant reachable. The intruder could scan, find a file server, reach a database, and locate the systems that mattered, none of which required defeating anything further. What the architecture removes is that second phase. The foothold still happens; it simply stops being worth as much, because the compromised laptop can reach exactly what its owner could reach and nothing beyond it.

That reframes several arguments. It explains why segmentation and identity work are worth more than another detection product for organisations that already own one. It explains why the benefit appears in the cost of incidents rather than their frequency. And it explains why the people running these programmes speak in terms of hours and reach — how long until containment, how many systems were touched — instead of counting attacks repelled, which nobody can count honestly.

The limit is equally clear, and pretending otherwise is how a deployment loses credibility internally. A genuine person, on a healthy machine, asking for something they are entitled to, will be granted it. If that person has been talked into acting against their employer, or a criminal is riding their session, every check returns the correct answer while the damage proceeds. The architecture narrows what an intruder inherits. It does not examine intentions, and no configuration of it ever will, which is a boundary worth stating aloud before a board rather than after an incident.

What does it feel like to work under it?

This is the question that decides whether a programme survives its second year, and it is usually answered by accident. Every condition in the exercise above lands on somebody: the sales team abroad, the contractor on a machine you do not administer, the executive whose telephone was bought personally, the engineer fixing something at four in the morning. None of them are edge cases; collectively they are a large fraction of the people who generate revenue.

Built well, the experience improves. Evidence gathered from the device does work that used to be done by making people wait for a tunnel, and a passenger on a train can open what they need without ceremony because the machine itself vouches for its own condition. Built badly, it becomes an apparatus for interrupting people — repeated prompts, approvals for routine tasks, and a refusal that never says which condition failed, which is the detail that turns a delay into a grievance.

The number that predicts success is therefore not coverage. It is how long a blocked person waits before somebody either grants an exception or explains why not. Organisations that measure this and hold it under an hour can tighten conditions almost indefinitely, because being stopped costs an inconvenience. Organisations where the answer is two days are quietly building a culture of workarounds: shared accounts, personal file services, a document mailed to a private address so it can be opened at home. Every one of those is a rational response to an unusable process, and each undoes more than the policy achieved.

Which returns to the ambiguous request in the exercise, the developer deploying a fix at four in the morning from a holiday. No rule settles that case, and a policy that only issues verdicts must either allow it or refuse it, both of which are sometimes wrong. What good deployments add is a third outcome: a way to ask, answered by a person, fast enough to be worth using. Designing that path is unglamorous beside an architecture diagram, and it is what separates the implementations people tolerate from the ones they route around.