Perimeter Thinking and Its Expiry Date

In May 2007 a group of corporate security officers published version 1.2 of a short document called the Jericho Forum Commandments. Four months earlier the same group had published a paper arguing the business rationale for what it called de-perimeterisation. Their claim was blunt: the corporate network boundary was already dissolving, the perimeter security model built around it was expiring, and enterprises should start designing for a world without a trusted inside. The industry spent the next decade buying bigger firewalls. It then rediscovered the same argument under a different name and called it zero trust.

The Model That Worked Until It Didn't

The classic perimeter security model was elegant and, for a period, correct. Draw a boundary around the corporate network. Place a firewall on it. Treat everything inside as trusted and everything outside as hostile. Grant access by connecting people to the inside — an office ethernet port, or a VPN tunnel that made a remote laptop behave as though it were in the building. The critical assumption is easy to state and was almost never examined: network location implies trustworthiness. If your packets originate inside, you are an authorised user doing legitimate work. That assumption produced flat internal networks, weak internal authentication, unencrypted internal traffic and administrative interfaces exposed to anyone who reached the LAN. Once an attacker was inside — through a stolen laptop, a phished credential, a compromised supplier connection or an unpatched edge device — there was very little standing between the entry point and the crown jewels. The 2007 retail breaches made that failure mode painfully concrete.

What Had Already Eroded the Edge by 2007

The Jericho Forum was not forecasting. It was describing conditions that already existed in its members' own organizations:

• Outsourcing and offshore delivery. Third-party teams in other countries needed production access to run the processes they had been contracted to run.
• Extranets and B2B integration. Suppliers, distributors and logistics partners had connections into internal systems.
• Mobile email. BlackBerry handsets meant corporate mail sat on devices that lived in coat pockets and taxis.
• Laptops. The endpoint had become portable, and it travelled with full access rights.
• Early SaaS. Business data was already being processed on infrastructure the company neither owned nor monitored.
• Mergers. Every acquisition connected another network of unknown hygiene to the trusted zone. Each of these punched a permanent hole in the boundary. The perimeter had not failed all at once; it had been perforated one business requirement at a time, and each hole was individually justified.

What the Commandments Actually Said

The document is barely three pages, and it holds up unusually well. Among its principles:

• The scope and level of protection should be specific and appropriate to the asset at risk, not uniform because uniformity is easier to administer.
• Security mechanisms must be pervasive, simple, scalable and easy to manage — unnecessary complexity is itself a threat.
• Assume context at your peril. Security solutions designed for one environment may not transfer to another.
• Devices must be able to maintain their security policy on an untrusted network, because they will spend much of their life on one.
• Security through obscurity is a flawed assumption; protocols need open peer review.
• Data should be protected by attributes travelling with it, rather than by the location where it happens to reside. Strip the 2007 vocabulary and you have the design brief for modern security architecture: identity-driven access, device posture, data-centric protection, least privilege, no implicit trust from network position. Microsoft's own security team has publicly credited the Commandments as a direct antecedent of zero trust.

Why It Took Thirteen Years

The ideas were right and the timing was impossible, for reasons that had almost nothing to do with the ideas. The enabling technology did not exist. Data-centric security requires strong identity, multi-factor authentication, device attestation and policy engines that evaluate context in real time. In 2007, multi-factor authentication meant hardware tokens for a handful of administrators, and directory infrastructure was built for machines on a LAN. Compliance frameworks were written around network zones. Auditors asked where the firewall was and how the cardholder network was segmented. An architecture with no perimeter was hard to evidence against a checklist that assumed one. Budgets were structured around appliances. A perimeter device is a capital purchase with a clear owner. An architectural principle is neither. Vendors sold what they had. The commercial incentive ran towards a stronger boundary, not towards abolishing the concept. What finally moved the industry was not argument. It was Google's post-intrusion rebuild of its internal access model, published as BeyondCorp; Forrester's packaging of the same logic as zero trust; the mass migration of workloads to cloud platforms with no network edge to defend; a global shift to remote work; formal codification in NIST's zero trust architecture guidance; and a run of severe compromises of the VPN and edge appliances that were supposed to be the perimeter itself. That last point deserves emphasis. The devices sold as the boundary have become one of the most reliably exploited classes of enterprise software. The perimeter did not merely stop helping; it became the way in.

What Defence in Depth Should Mean Now

Defence in depth was never wrong. It was implemented as concentric network rings when it should have been implemented as independent controls around assets.

• Identity is the control plane. Strong, phishing-resistant authentication for every user and every service, with conditional policy based on risk.
• Device posture matters more than device location. Managed, patched, encrypted and attested, or it gets restricted access regardless of which network it is on.
• Least privilege, granted just in time. Standing administrative access is the single largest amplifier of any initial compromise.
• Segment by workload, not by building. Blast radius is the metric that matters.
• Encrypt in transit internally, and control the keys for data at rest.
• Log centrally and assume breach. Detection quality determines whether an incident is contained or catastrophic.

The Mid-Market Version of This Work

Most organizations cannot rebuild their access architecture in a quarter, and do not need to. The high-yield sequence is consistent: Enforce multi-factor authentication everywhere, including service and administrative accounts. Inventory every third-party connection and give each one scoped, time-limited access. Separate administrative identities from daily-use accounts. Replace flat VPN access with per-application access where the tooling allows. Patch internet-facing appliances on a schedule measured in days. Then segment the internal network so that one compromised workstation does not reach the finance system. None of that is new thinking. It was written down, publicly, in 2007.

Common Questions

What is de-perimeterisation?

The recognition that the corporate network boundary no longer defines a trusted zone, and the resulting design approach of protecting data and services directly rather than relying on network location.

Is zero trust just a rebranding of the Jericho Forum's work?

Zero trust is the operational implementation of substantially the same principles, made practical by identity platforms, device management and cloud policy engines that did not exist when the Commandments were written.

Do we still need firewalls?

Yes. Perimeter controls remain useful for reducing exposure and containing lateral movement. The error is treating them as the primary trust boundary rather than as one layer among several.

Where should a security architecture review start?

With the assets, not the network diagram. Identify what would genuinely damage the business if exposed or unavailable, then work outward to the identities, devices, services and third parties that can reach it today.

---

Security Architecture Review — Outpace maps who and what can currently reach your critical systems, including third parties and standing administrative access, and sequences a realistic move from perimeter trust to identity-based control.