Because every real estate is a layered fossil record: decisions made in the past, built with the means of the past, to control the threats of the past — and they are still running next to the modern cloud systems.

The discipline grew with the cyber systems themselves, and two facts about that growth shape today's work:

1. Security was a challenge from the very beginning. IT development has always led with new capabilities, functions and application fields; security has almost always arrived afterwards, as an additive step. That pattern has not changed, which is why "bolt-on" is the normal starting condition rather than an aberration.
2. The possibilities changed radically, and quickly. Cyber technology turns over faster than almost any other engineering field — but not every participant turns over with it. What you inherit is a structure grown over time and over the means available at each point in time.

So the everyday situation is a collision: legacy systems that cannot simply be migrated must interact with modern web systems; old security ideas mix with new ones; a decision that was entirely reasonable in 1998 sits inside an estate facing 2026's threat landscape.

That gives the practical lesson of the whole chapter: the ability to deal with old and new at once is essential for a good cyber security architect. Someone who only knows the modern answer cannot secure the half of the estate that cannot receive it — and someone who only knows the old answer cannot secure the half that has left the perimeter.

Tip: the eras that follow are not a museum tour. Each one is still in production somewhere in the estate you are being asked to fix.

Go deeper:

• Wikipedia — Legacy system — why the past is still running: the cost, risk and lost-knowledge reasons old systems never get replaced.

A deliberately minimal yardstick: looking at a cyber system, only (i) good actors, (ii) performing good actions, (iii) under desired states of the environment are permissible.

* Only good actors, doing good actions, in a desired environment — three questions any design must answer. *

It is built up in three steps, each of which is a question you must answer about any real system:

1. Fix the actors, interactions and services. An actor is the acting role — a person, or a service acting on behalf of something — and it triggers an interaction on a service. "Service" (S) here is any kind of cyber device whatsoever: a machine, a server, a piece of software, a web service, an IoT device, an application, a resource.
2. Fix the system boundary of the cyber system under consideration: a technically and organisationally unambiguous delimitation of what is in and what is out.
3. Distinguish good from bad — good actors from bad ones, good interactions from bad ones — and classify the environment into desired and undesired states.

The model's value is that it is independent of era and technology, so it can be used to compare approaches that look nothing alike. Every security approach in the history that follows can be graded against the same three clauses, and each one turns out to cover some clauses well and leave others open: perimeter security is largely about interactions and environment, AAA is almost entirely about actors, and so on.

Its practical use is as a review checklist. Put any design in front of it and ask: how do you know this actor is good? how do you know this action is good? how do you know the environment is in a desired state? Anything you cannot answer is where the design's real risk sits.

Tip: "only good actors, doing good things, in a good environment" sounds trivially obvious — which is the point. Almost no real system can demonstrate all three, and the gaps are the architecture's agenda.

Go deeper:

• Wikipedia — Zero trust architecture — a modern model built on the same move: stop assuming, verify each element explicitly.