Security Reference Architecture

Overview

This reference architecture defines the capabilities an organisation needs to protect its people, systems and data, and the components that deliver them. Unlike the Integration and Data Platform architectures — each of which follows a path that data travels — security has no single flow. It is a set of controls applied across every other architecture, so this model is organised by what is being protected rather than by where data moves.

Every access decision in the architecture resolves through one control plane, described first. The layers that follow are the asset classes that control plane protects, and the cross-cutting layers are the disciplines that govern, watch and restore them.

This model is a synthesis, drawing on SABSA's layered abstraction, the Open Security Architecture capability model, NIST SP 800-207 and NIST CSF 2.0. See the Influences section below for what each contributed. The layer names, component definitions and examples are our own.

The Control Plane: Policy Decision and Enforcement

Zero Trust is not a product tier — it is the decision that every request is evaluated on its merits rather than trusted because of where it came from. Three logical components make that possible, and separating them is what distinguishes an architecture from an application with roles in it.

PE + PA together form the Policy Decision Point. The PDP/PEP split is the single most useful idea in this architecture: the decision is made centrally and consistently, while enforcement happens locally and close to the resource.

Component Model Layers

1. Identity & Access Layer

Establishes who or what is making a request, and what they are permitted to do. The foundation every other layer depends on — a compromised identity bypasses most other controls.

2. Endpoint & Device Trust Layer

Establishes whether the device carrying a request is in a state fit to be trusted. Posture is half of what makes conditional access meaningful; without it, Zero Trust reduces to identity alone.

3. Network & Infrastructure Layer

Controls reachability. Modern practice moves from a hardened perimeter towards identity-aware access and segmentation that limits how far an intruder can travel.

4. Application & API Layer

Secures what the organisation builds and exposes. Split between assurance activities before deployment and protection at runtime.

5. Data Protection Layer

Protects the data itself, so that a control failure elsewhere does not automatically become a disclosure.

6. Cloud Platform Layer

Secures the control plane of the cloud itself. Most cloud incidents originate in configuration rather than in exploitation of a vulnerability.

7. AI & Autonomous Agents Layer

Secures AI systems and the agents acting on their output. The newest layer and the least settled — the threat model differs from conventional application security because the input itself can carry instructions.

Cross-Cutting Layers

These span every layer above. The first three establish the conditions under which controls are chosen; the last two operate them once systems are live.

Governance, Risk & Compliance

Establishes what the organisation is trying to achieve, what it is prepared to tolerate, and how it demonstrates both.

People & Insider Risk

Addresses the fact that most incidents involve a person — through error, coercion or intent — rather than a purely technical failure.

Supply Chain & Third-Party Risk

Extends assurance to software and organisations outside the boundary, which increasingly carry the same access as employees.

Detection & Security Operations

Assumes prevention will sometimes fail, and shortens the time between that happening and someone knowing.

Response, Continuity & Recovery

Limits damage once something has happened, and restores service afterwards.

---

Framework Alignment

Each layer maps to the NIST CSF 2.0 functions, so the architecture can be presented either as a technical model or as an assurance story:

Influences

No single framework produced this model. Each of the following contributed something the others did not, and the synthesis — along with all layer names, component definitions and examples — is ours.

SABSA — layered abstraction

SABSA descends through six layers: Contextual → Conceptual → Logical → Physical → Component → Operational, each a different reader's view of the same architecture. That progression is the reason this library is split the way it is, and not only for security:

The Logical layer is the one this document is really written at. SABSA's How cell asks for security services specified and catalogued as "common re-usable building blocks" — entity authentication, confidentiality protection, integrity protection, non-repudiation, system assurance — named and defined before any product is chosen. That is exactly what a component row is, and it is why the EXAMPLES column is deliberately a list of illustrations rather than a recommendation.

Reading the rest of that row is also what added two components to the Identity & Access layer. The Where cell asks for security domain definitions and their inter-domain associations, and the When cell for the security processing cycle — registration, login, session management. An earlier draft had the physical expressions of both (micro-segmentation, PAM time-bounding) without ever naming the logical model behind them.

The useful discipline SABSA imposes is that a control should trace back to a business reason. A pattern that cannot answer "which capability does this serve" is a tool choice, not an architecture.

Open Security Architecture — capability grouping

The OSA Security Capability Model (CC BY-SA 4.0) groups security capability into foundation, protection and operation phases, and explicitly defers implementation detail to a companion pattern catalogue. That grouping shaped how the layers below are ordered — governance and supply chain as preconditions, asset classes in the middle, detection and recovery around the outside — and confirmed that separating a capability model from a pattern catalogue is a sound structure rather than an idiosyncrasy of this site.

Reading OSA also surfaced two areas an earlier draft of this architecture had missed entirely: endpoint and device trust, without which conditional access reduces to identity alone, and AI and autonomous agents, where the threat model genuinely differs because the input itself can carry instructions.

NIST SP 800-207 — the control plane

The Policy Engine / Policy Administrator / Policy Enforcement Point decomposition, and the PDP/PEP split described above, come from NIST SP 800-207. It supplies the mechanism by which access decisions are actually made and enforced — the part most capability models leave abstract.

NIST CSF 2.0 — the assurance overlay

CSF 2.0 provides the six lifecycle functions — Govern, Identify, Protect, Detect, Respond, Recover — that each layer is mapped to above. This is what lets the same architecture be presented to an engineering audience as a technical model and to an audit or board audience as coverage against a recognised standard.

Others

OWASP informs the application and API layer, particularly the API Top 10 risks that API threat protection is meant to address. CIS Benchmarks underpin the configuration-hardening component. ISO 27001 Annex A is one of the control catalogues the governance layer maps to.

---

Both NIST publications are US Government works in the public domain. OSA is published under CC BY-SA 4.0 and is credited above; this document is an independently written synthesis rather than an adaptation of it, and reproduces none of its text, capability identifiers or catalogue. SABSA is a trademark of The SABSA Institute and is referenced descriptively.