What the Perimeter Was Actually For

Architecture · June 2, 2026 · 8 min read

The perimeter model is usually described in retrospect as an error of judgement — a naive belief that bad things live outside and good things live inside. That description is convenient, because it makes the replacement sound like a correction rather than a trade. It is also wrong. The perimeter was a sound engineering response to a specific constraint, and if you cannot name the constraint, you cannot tell whether your current programme has replaced the model or merely rebranded it.

An amortisation strategy

Authorisation is expensive to implement per application. Somebody has to decide what a caller is allowed to do, obtain evidence about who the caller is, keep that evidence fresh, and handle the case where the evidence is unavailable. Doing that once, for every application, in every language, maintained by every team, is a large recurring bill.

The perimeter avoided that bill. Put one control at the boundary, make it decide who gets in, and every application behind it can be written as though callers are already trustworthy. The cost of the access decision is paid once and shared across the estate. That is not naivety, it is amortisation, and for a long time the arithmetic was excellent.

The mechanism it relied on was substitution. The boundary device could not see who you were; it could see where your packets came from. So network location became a stand-in for identity — not because anyone believed an IP address was a person, but because in an estate of owned buildings, owned cables and owned machines, location correlated with identity closely enough to be useful. Cheap proxies that correlate well are the foundation of most working systems.

The correlation broke, and nothing announced it

Three shifts pulled the proxy apart, none of which was a security event.

The estate stopped being in one place. Applications moved to services somebody else operates, reachable from anywhere, which means the boundary no longer sits between the user and the thing they are using. A control that is not in the path is not a control.

The device stopped being owned. Contractors, personal phones, partner integrations and acquired subsidiaries all needed access, and every exception carved a hole through the boundary that was itself indistinguishable from legitimate traffic once it was on the inside.

And east–west traffic grew enormously. Service meshes, batch pipelines, replication, backup, monitoring — the overwhelming majority of connections in a modern estate never cross the boundary at all, so the overwhelming majority of connections were never inspected by the only thing making access decisions.

What makes this a genuinely hard failure is that none of it produced an error. The applications behind the boundary had no authorisation check to fail. They had been written on the assumption that the check already happened. When the assumption stopped holding, the systems that depended on it kept returning success.

The thing that actually failed was inheritance

It is worth being precise about the failure, because the imprecise version leads people to buy the wrong things.

The firewall did not fail. It still filters what it is told to filter. What failed was inheritance: the arrangement in which an application accepts a trust decision made elsewhere, earlier, by something that knew a source address and nothing else — not which human, not which device, not which session, not whether any of it was still true a minute later.

Inheritance has a second, worse property. A single successful entry converts into general access. An attacker who lands anywhere inside acquires the same inherited trust as everyone else inside, and the estate offers no further resistance because further resistance was the one thing the design deliberately economised away. Lateral movement is not a clever technique against a perimeter network; it is the network working as specified.

Relocation, not addition

The useful way to read zero trust is as a relocation of the access decision, not an extra layer around it. The check moves out of the boundary and into the request path, where it can see things the boundary never could: which principal, holding which credential, issued by which authority, from which device, at which moment, for which specific resource.

Everything that follows in this model is downstream of that move. A policy enforcement point exists because the decision now has to happen somewhere close to the resource. A policy decision point exists because you do not want that logic reimplemented in every enforcement point. Short credential lifetimes exist because a decision made in the request path is only as current as the evidence it was made with. Segmentation exists because the blast radius of a compromised principal should be bounded by what that principal legitimately needs.

Which means the bill comes back

Here is the part that the marketing consistently omits. The perimeter amortised the cost of authorisation. Removing the perimeter un-amortises it.

Every application now has to participate in the access decision, or sit behind something that participates on its behalf. Every service now needs an identity of its own rather than a network position. Somebody has to define what each principal may reach, keep those definitions accurate as the estate changes, and answer for the failure mode where the decision point is unavailable and the only choices are to fail closed and stop the business or fail open and become the thing you replaced.

This is a real cost, and it is the actual reason programmes stall. They stall because the second half is unglamorous and never finishes, not because the first half was hard.

Never trust, always verify is not a design

The slogan is not false. It is simply not actionable, and it should not be mistaken for architecture. It does not say what is verified, against which authority, how often, with what tolerance for staleness, or what happens when the authority cannot be reached. Those four questions are the entire design. A programme that has not answered them has adopted a posture, not a model.

The honest reframing is narrower and more useful: stop letting network position grant authority. That is the whole claim. Everything else — device signals, continuous evaluation, microsegmentation, workload identity — is machinery for making that claim survivable in a real estate.

A test that is hard to fake

There is one question that cuts through most of the ambiguity. If an attacker obtained a foothold on a managed laptop physically sitting on your corporate network, what would they gain that they would not gain from the same laptop in a café?

If the answer is “a great deal”, the perimeter is still load-bearing regardless of what the programme is called. If the answer is “essentially nothing — the same credential, the same policy, the same scoped access, evaluated the same way”, the relocation actually happened.

The second answer is expensive, and it is the only one worth anything.