Security Architecture

Security Architecture is the EA domain that defines how the enterprise protects its information, systems, and users. The dissolution of the corporate perimeter — driven by cloud, SaaS, remote work, and now AI — has made traditional perimeter security obsolete and elevated security architecture to a first-class EA concern.

The dominant paradigm shift is to zero trust: never trust, always verify, assuming breach and minimising the blast radius of any compromise. Zero trust replaces the 'trusted inside, untrusted outside' model with one where every access decision is authenticated, authorised, and encrypted, regardless of network location. Identity — of users and workloads — becomes the new perimeter.

This page covers zero trust, defence in depth, secure-by-design principles, the shift-left movement, supply chain security, and how security architecture extends to AI systems.

The traditional security model assumed a trusted internal network protected by a perimeter firewall. Cloud, SaaS, remote work, and partner integration dissolved that perimeter: users and workloads are everywhere, and 'inside the network' no longer means 'trusted'. The model that replaced it is zero trust, formalised in NIST SP 800-207.

Zero trust's core principles: never trust, always verify; assume breach; least-privilege access; and explicit, per-request authorisation. Every access — user to application, service to service, service to data — is authenticated and authorised, regardless of network location. The network is no longer a trust boundary; identity and context are.

Implementing zero trust requires identity-aware access (workforce and workload identity), microsegmentation (limit lateral movement), encrypted traffic everywhere (even inside), and continuous verification (not just authentication at the edge). It is an architecture, not a product — and it touches every layer the EA governs.

Defence in depth layers controls so no single failure is catastrophic: network controls, identity controls, application controls, data controls, and monitoring each provide independent protection. The mindset shift is 'assume breach' — design as if an attacker is already inside, so the architecture limits what they can do.

Assume-breach design changes architecture decisions. It is why microsegmentation matters (a compromised service cannot reach others), why least privilege matters (a compromised identity has minimal access), and why encryption-at-rest matters (stolen data is unreadable). Each layer assumes the previous may have fallen.

The discipline is to make the layers independent — a control that depends on another control provides no additional protection if the first falls. Independent layers of defence, each viable on its own, are what give defence in depth its value. Layered controls that all depend on the same identity provider, for example, collapse to a single point of failure.

Secure by design makes security a property of the architecture, not a post-deployment scan. It means threat modeling at design time, choosing secure defaults (encryption on, least privilege on), and building security controls into the reference architecture so conformant solutions are secure by construction.

Threat modeling — systematically identifying threats against a design using frameworks like STRIDE (Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege) — is the core secure-by-design practice. Done at design time, it shapes the architecture; done after deployment, it produces a list of gaps that are expensive to fix.

Secure defaults are the multiplier. If the reference architecture's golden path enables encryption, least privilege, secrets management, and logging by default, most solutions will be secure without deliberate effort. If the default is insecure and teams must opt in to security, most will ship insecure. Defaults shape outcomes more than policies do.

Shift-left moves security earlier — into design (threat modeling) and into the pipeline (automated scanning). Static application security testing (SAST), software composition analysis (SCA), secret scanning, and container image scanning run in CI, catching vulnerabilities before they reach production. Infrastructure-as-code scanning catches misconfigured cloud resources before deployment.

The goal is not to replace human review but to automate the routine so humans focus on the architectural. A pipeline that blocks on a critical vulnerability or a known-exploited dependency makes secure delivery the default; a pipeline that does not scan ships vulnerabilities and discovers them later, expensively.

Shift-left also means security tooling integrated into developer workflows, not gated behind a separate security team's portal. Developers fix what they find immediately; security teams focus on architecture, threat modeling, and incident response. This division of labour scales security in a way that end-of-pipeline security review cannot.

Modern software is mostly composed, not written — open-source dependencies, base images, and third-party packages dominate. Securing the supply chain means knowing what is in your software, where it came from, and whether it is trustworthy. The Software Bill of Materials (SBOM) — a machine-readable inventory of components — has become a baseline expectation.

Supply chain attacks (compromised dependencies, malicious packages, build-system compromise) are among the highest-impact threats because a single compromise reaches many downstream users. Defences include verified provenance (signed artifacts), dependency pinning and vetting, private package mirrors, and build-pipeline hardening (SLSA levels).

EA's role is to make supply chain security a reference-architecture concern: mandated SBOMs, approved package sources, image registries with scanning, and build pipelines meeting a defined integrity level. An enterprise that treats supply chain as each team's problem gets inconsistent protection; one that governs it at the platform level gets consistent, auditable protection.

AI introduces new security surfaces: models can be poisoned, prompted to leak, or used to exfiltrate training data. Agents can be tricked into taking harmful actions via tool-call manipulation. Security architecture must extend to cover these — model integrity, prompt-injection defences, data-class-aware retrieval, and agent authorisation.

The zero-trust principle extends naturally: never trust model output unconditionally, always verify (especially before an agent takes an irreversible action), and least privilege for agent tool access. An agent with unrestricted tool access is a security incident waiting to happen; an agent with narrowly-scoped, approved-tool access and human approval gates for irreversible actions is governable.

AI security is also where security architecture meets AI governance: model approval, training-data classification, output filtering, and audit logging are as much security controls as they are compliance controls. Embedding them in the reference architecture makes AI secure by construction rather than bolt-on — the same shift-left principle applied to a new surface.