In many organisations, security enters the stage too late. The architecture is drawn, the structural choices are frozen, development is under way — and only as production approaches does an audit or a penetration test reveal what should have been decided months earlier. Then come the emergency patches: a firewall here, some encryption there, a compliance exception to hold the date.

This sequence is expensive and, above all, it protects poorly. Security isn’t a layer you stack on top: it’s a property of the system, one that follows from how it’s structured. Treating it by design means writing it into the architecture views, on a par with performance, availability or cost. Here’s what that actually changes.

The symptom: security as a terminal layer

The pattern is familiar. A project advances along its functional milestones. Security is seen as an end-of-line constraint, owned by a separate team, called in at the compliance review. By then, the room to manoeuvre is almost nil: changing an authentication model, re-segmenting a network or reworking how data flows means undoing decisions already set in concrete.

The result takes several forms. Workarounds documented as “debt to address later” — and never addressed. Controls added at the edge that create an illusion of protection without reducing the real attack surface. And a permanent tension between the project team, which wants to ship, and the security team, seen as the department that says no.

The root cause isn’t a lack of tools. It’s a problem of sequence: the security decision arrives after the architecture decision, when it should have been part of it.

Why security is an architecture decision

The most consequential security properties aren’t bought, they’re drawn. Three examples make this clear.

The attack surface is a direct consequence of structure. A monolith exposed as one block, a system split into services with clean boundaries, or a system where everything talks to everything do not carry the same exposure — and that is decided when you draw the components and their links, not afterward.

The blast radius of a compromise depends on segmentation. If an attacker who gains a foothold in one component can move laterally across the whole estate, that’s a question of network and identity architecture, not of a security product.

The flow of sensitive data — where it’s stored, where it transits, who can read it — is drawn in the data and flow views. Well-architected data is protectable; data that sprawls everywhere no longer is, whatever tooling you deploy.

In all three cases, security is determined by structural choices made very early. That is precisely the enterprise architect’s terrain: not to replace the CISO, but to bring their requirements into the design of the system, while they’re still negotiable.

Model the threat from the first views

Threat modelling is the exercise that anchors security in design. The idea is simple: before building, systematically ask what can go wrong? It needs no sophisticated tooling — a data flow diagram and a structured discussion are enough to start.

Four questions structure the exercise:

  • What are we building? Start from a data flow diagram: the components, the exchanges, the trust boundaries (where data crosses from a controlled zone into a less controlled one).
  • What can go wrong? For each flow and each boundary, enumerate the threats. A grid like STRIDE — spoofing, tampering, repudiation, information disclosure, denial of service, elevation of privilege — helps you miss nothing.
  • What will we do about it? To each credible threat, attach a response: a control, a design choice, or a deliberate decision to accept the risk.
  • Did we do a good job? Revalidate afterward, because architectures evolve and so do threats.

Run at the design stage, this exercise costs only a few workshops. Run after go-live, the same findings force heavy rework. The cost gap between “fix it on a diagram” and “fix it in production” is the best economic case for security by design.

Three architecture principles that do most of the work

Beyond modelling, a handful of structural principles carry most of a system’s resilience. They aren’t new; they’re simply invoked too often without actually being architected.

Segmentation and least privilege

To segment is to divide the system into zones whose communications are explicitly controlled, so that a compromise stays contained. Least privilege applies the same logic to rights: every component, every identity, every service holds only the access strictly required for its function.

These two principles answer an inescapable reality: you cannot guarantee that no breach will ever happen. The useful question is therefore not only “how do we prevent intrusion?” but “how far can an intruder go once inside?”. A well-segmented system turns a catastrophic compromise into a localised incident. That’s decided on the architecture diagram, by drawing the boundaries and the permitted flows.

Defence in depth

No control is infallible. Defence in depth means layering several independent lines, so that the failure of one isn’t enough to compromise the whole: authentication, authorisation, encryption, logging, monitoring. The architectural challenge is to ensure these layers are genuinely independent — a stack of controls that all share the same weak point isn’t defence in depth, only an illusion of thickness.

Don’t trust by default

The approach known as zero trust overturns an assumption long taken for granted: the idea that inside the network perimeter, everything is trustworthy. In a modern estate — distributed services, cloud, partners, mobility — that perimeter no longer really exists. The principle becomes: verify every access explicitly, whatever its origin, rather than presuming a request is legitimate because it comes “from the inside”. That’s a stance on identity and network architecture, not a product you install.

Sovereignty and data localisation

For organisations under strong regulatory requirements — public sector, healthcare, finance — security isn’t only about preventing intrusion. It also covers control over where data lives and which jurisdictions it falls under. These sovereignty requirements are architecture constraints too.

Where is a piece of data stored? Under which jurisdiction does the hosting provider fall? Which data may leave the territory and which may not? What dependencies on a single provider are you creating, and how reversible are they? These questions must be asked when you choose platforms and draw flows — not discovered during a compliance check.

Designing for sovereignty doesn’t mean giving up the cloud or managed services. It means making those choices explicit in the architecture: classifying data by sensitivity, tracing its circulation precisely, and documenting reversibility options. An architecture that makes the location and trajectory of sensitive data visible is an architecture that can prove its compliance — instead of hoping for it.

Write security into architecture governance

For security to be handled by design, it must stop being a one-off milestone and become a permanent dimension of architecture governance. A few concrete levers make this possible.

Formalised non-functional requirements. Confidentiality, integrity, availability, traceability, localisation requirements: these attributes must appear explicitly in the requirements, just like features. What isn’t written down won’t be arbitrated.

Checkpoints at the right moments. Rather than a single end-of-line security review, decision points at the architecture milestones — platform choice, flow design, identity model — where decisions are still reversible.

A shared language. The CISO reasons in risks, the architect in components and flows. The value of the enterprise architect is to bridge the two: translate a risk requirement into a design constraint, and make legible, for leadership, the trade-off between protection level, cost and agility.

A deliberate trade-off, not a false promise

Security by design isn’t the promise of an unbreakable system — no such promise exists. It’s the discipline of taking security decisions when they’re least costly and most effective: during design, on the diagram, while everything is still negotiable.

That requires a shift in posture. Security stops being the department that says no at the finish line and becomes one design criterion among others, arbitrated with eyes open. Some protections carry a cost in performance, complexity or agility; the goal isn’t to protect everything to the maximum, but to decide knowingly what you protect, against what, and at what price.

That is precisely the role of enterprise architecture: to make those trade-offs visible and explicit, instead of inheriting them once it’s too late to fix them.