Security Architecture Review Guide: Assessing Designs Before They Ship

Most serious security flaws are designed in long before a line of vulnerable code is written, and a design that trusts the wrong component cannot be fixed by scanning. A security architecture review examines a proposed system, or a significant change to an existing one, against agreed design principles and a threat model, and records what must change before it ships. This guide sets out how to run reviews that change designs rather than produce paperwork: when to trigger one, what evidence to ask for, which principles to test against (NCSC secure design principles and NIST SP 800-160 Vol. 1 Rev. 1), how to review service-to-service and non-human identity (NHI) authentication, and how to measure whether the process works. It is written for security architects, engineering leads and the risk owners who sign off designs.

Key takeaways

• Review the design, not the slide deck. Ask for a data flow diagram with trust boundaries, an identity and secrets inventory, and the deployment model; a review without them is an opinion.
• Use a published principle set as the yardstick. The five NCSC secure design principles and the 30 principles in Appendix E of NIST SP 800-160 Vol. 1 Rev. 1 give reviewers a shared, defensible vocabulary.
• Trigger on change, not on the calendar. New trust boundaries, new data classes, new external connections, new privileged identities and new AI agents should all trigger a review.
• Machine-to-machine authentication is where designs fail quietly. Every service call, pipeline and agent needs a named identity, a credential type, a scope, an owner and a rotation story.
• Findings need owners and a verification step. Track each required change to closure and confirm it in the built system, or the review has not reduced risk.

What a security architecture review is, and what it is not

A review is a structured assessment of a design against principles, requirements and threats, carried out while changes are still cheap. It sits between requirements and build in the lifecycle. NIST SP 800-160 Vol. 1 Rev. 1 places the relevant engineering work in its technical processes for system architecture definition (H.4) and design definition (H.5), and NIST SP 800-53 Rev. 5 expresses the same expectation as controls SA-8 (Security and Privacy Engineering Principles), SA-17 (Developer Security and Privacy Architecture and Design) and PL-8 (Security and Privacy Architectures).

The review consumes the threat model rather than replacing it: see the Threat Modelling Guide for running STRIDE sessions and the Security Requirements and Abuse Cases Guide for the requirements it checks against. Its distinct job is the decision: approve, approve with conditions, or send back.

When to trigger a review

A fixed annual review misses most risk, because risk enters with change. The OWASP Secure Product Design Cheat Sheet makes a useful split between Product Inception (a product being conceived or reinvented) and Product Design (continuous work close to the code), and notes that adding or removing connections signals inception-level change. Practical triggers:

• New trust boundary: exposing a service to the internet, a partner, a new tenant or a new network zone.
• New or more sensitive data: personal data, payment data, health data, credentials or model training data entering a component that did not hold it.
• New external dependency: a SaaS integration, third-party API, OAuth app, managed AI model or open source component with privileged reach.
• New privileged or non-human identity: a service account, workload identity, CI/CD credential or AI agent with write access to production.
• Architecture pattern change: moving to multi-tenant, serverless, event-driven, service mesh or agentic workflows.
• Exception to a standard: any deviation from the approved patterns, which should also go through the Security Exceptions and Risk Acceptance Guide process.

Scaling the depth of review

The OWASP cheat sheet warns that over-engineering and under-engineering both carry a real cost; tiering keeps review capacity on the designs that need it. Small organisations can run the same tiers with one architect and a published checklist; large ones usually add a review board for the deep tier and security champions for self-assessment.

The evidence pack: what to ask for

Reviews fail most often because the reviewer is shown a marketing-style diagram. Require a minimum design pack before booking the session:

1. Context: business purpose, users, data classification, availability needs and regulatory scope. NCSC's first principle is to establish the context before designing a system.
2. Data flow diagram with trust boundaries: processes, data stores, external entities and flows, with every boundary crossing marked. The OWASP Threat Modeling Cheat Sheet notes that boundaries often represent possible attack points.
3. Communication inventory: every inbound and outbound connection, including external services and any place a user can supply a URL. OWASP ASVS 5.0 requirement V13.1.1 asks for exactly this documentation.
4. Identity and secrets inventory: each human role and each non-human identity, its credential type, where it is stored, its permissions and its rotation schedule (ASVS V13.1.4 asks that critical secrets and their rotation schedule be documented).
5. Components: libraries, managed services and images, with maintenance status; whether they come from the approved paved road.
6. Deployment and administration model: environments, how administrators reach the system, break-glass access, and how updates are shipped.
7. Logging and detection plan: which security events are logged, where they go and who reviews them.
8. Threat model and open risks: STRIDE output or equivalent, with mitigations and anything the team already proposes to accept.

Principles to review against

A review needs a yardstick that the engineering team can see in advance. Two public sets work well together: NCSC's five secure design principles as the top-level structure, and the NIST SP 800-160 Vol. 1 Rev. 1 Appendix E principles for depth.

NCSC's guidance on making compromise difficult is notably concrete: transform or validate complex inbound content, push read-only data subsets to staging areas rather than exposing business systems, keep privileged administration on separate devices or bastion hosts away from email and browsing, and attribute actions to individuals rather than shared groups. Each of these converts directly into a review question with a yes or no answer.

Applying STRIDE at review time

Walk each trust boundary crossing with the six STRIDE categories as prompts: Spoofing (authentication), Tampering (integrity), Repudiation (non-repudiation), Information disclosure (confidentiality), Denial of service (availability) and Elevation of privilege (authorisation). The reviewer's job is not to redo the threat model but to test that each high-risk crossing has a named control and that the control is actually in the design. For AI agents, extend this with the agent-specific threats in the AI Agent Threat Modelling Guide.

Reviewing service-to-service and NHI authentication

Modern designs are dominated by machine-to-machine calls: microservices, data pipelines, CI/CD, SaaS integrations and AI agents calling tools. NIST SP 800-207A frames access control in cloud-native systems around application and service identities rather than IP addresses and network location, enforced through API gateways, sidecar proxies and an application identity infrastructure such as SPIFFE. NIST SP 800-53 covers the same ground in IA-9 (Service Identification and Authentication), and ASVS 5.0 V13.2.1 to V13.2.3 require that back-end communications are authenticated, run with least necessary privilege, and never use default credentials.

The Dropbox Sign breach shows why the "admin and automation paths" row matters: an attacker who reached an automated system configuration tool used a back-end service account with production privileges to read the customer database, exposing API keys, OAuth tokens and MFA details. A review asking "what can this automation identity reach?" would have flagged that path. For implementation patterns see the Workload Identity Federation Guide, the mTLS Guide, the SPIFFE and SPIRE Guide and the OAuth Token Exchange and Delegation Guide.

Agentic architecture review

AI agents combine an untrusted input channel (prompts, retrieved documents, tool output) with real credentials. Add these questions for any agentic design: which identity does the agent act as, and is it distinct from the user and from other agents; which tools can it call and with what scope; which actions need human approval; what limits apply to spend, volume and destructive operations; how is the agent stopped; and are prompts, tool definitions and retrieval settings under change control. See the Zero Trust for AI Agents Guide and the AI Security Architecture Reference Guide.

Running the review: a step-by-step process

1. Intake and tiering: the team submits a short request describing the change; security assigns a tier using the triggers above within two working days.
2. Design pack check: confirm the evidence pack is complete before scheduling. Return incomplete packs rather than reviewing guesses.
3. Pre-read: the reviewer walks the data flow diagram, marks each boundary crossing and identity, and drafts questions against the principle table.
4. Review session: walk the flows end to end with the engineers who will build it. Record decisions in the session, not afterwards.
5. Findings and decision: classify each finding as a required change (blocks go-live), a recommended change, or a risk to accept with a named owner and expiry. Give one of three outcomes: approved, approved with conditions, or not approved.
6. Track to closure: raise required changes as tickets in the team's own backlog, linked to the review record.
7. Verify in the build: before release, confirm required changes exist in the running system, for example by checking that an endpoint now rejects unauthenticated calls or that a static key was replaced by federation. Use targeted tests from the Penetration Testing Guide for high-risk items.
8. Feed back into patterns: recurring findings become paved-road patterns or standards, so the next team does not repeat them.

Piloting and rollback: introduce the process with two or three volunteer teams for a quarter, measure turnaround and finding quality, then extend. If review demand overwhelms capacity, roll back to mandatory reviews for the deep tier only and self-assessment elsewhere, rather than letting a queue build that teams learn to bypass.

Decision guidance and trade-offs

• Central board or embedded architects: a central board gives consistency and a clear record, but becomes a bottleneck above a few dozen reviews per quarter. Embedded architects or trained security champions scale better but drift without shared checklists and sampling.
• Gate or advisory: make the deep tier a release gate; keep lower tiers advisory with sampling. A universal gate tends to produce rubber-stamping.
• Document-heavy or conversation-led: a short structured pack plus a working session usually finds more than a long template completed alone.
• Accept or fix: accept a risk only when the owner can state impact, likelihood and an expiry; otherwise fix. NIST CSF 2.0 ID.RA-04 and ID.RA-05 describe the expected analysis.
• Small organisations: adopt the NCSC principles as the checklist, require a data flow diagram and an identity inventory for anything internet-facing, and focus the scarce review time on authentication and data exposure.

Detection and measurement

Measure whether reviews change designs and whether those changes hold in production:

• Coverage: percentage of releases that met a trigger and received the right tier of review.
• Turnaround: median days from complete design pack to decision, by tier.
• Required-change closure: percentage of blocking findings verified as fixed before go-live.
• Escaped design flaws: penetration test or incident findings whose root cause was a design decision in a reviewed system.
• Static NHI credentials introduced: new long-lived keys or passwords approved per quarter, trending down as federation patterns spread.
• Expired risk acceptances: accepted design risks past their review date.

In production, check the review's assumptions continuously: alert when a reviewed service gains new internet exposure, when a new non-human identity appears in a production account, or when an identity's permissions expand beyond those approved.

Common failure patterns

• Reviewing an idealised diagram: the drawing omits the admin path, the debug endpoint or the batch job, which is where the attacker goes.
• Unauthenticated internal APIs: designs that treat "internal" as trusted. In the McKinsey AI platform incident, researchers reported 22 of more than 200 documented endpoints accepted requests without authentication, and one of them was injectable.
• Shared and over-privileged service accounts: one identity for many services makes least privilege impossible and attribution meaningless.
• Findings without verification: the review report says "use mTLS", nobody checks, and the service ships with plain HTTP between tiers.
• Review too late: held a week before launch, when the only realistic outcome is a risk acceptance.
• No re-review on change: the approved design drifts as new integrations and agents are bolted on without crossing any trigger.

Framework mapping

Practitioner checklist

• Publish review triggers and three review tiers, with the principle set reviewers will use.
• Require a minimum design pack: context, data flow diagram with trust boundaries, communication inventory, identity and secrets inventory, admin model, logging plan.
• Consume the team's threat model and test each high-risk boundary crossing for a named control.
• For every non-human identity, record owner, credential type, storage, scope and rotation; prefer federated short-lived credentials.
• Check that automation, configuration and deployment tools cannot reach production data they do not need.
• Add agent-specific questions for any design where an AI agent holds credentials or takes actions.
• Issue one of three decisions and raise required changes as tickets in the team's backlog.
• Verify required changes in the built system before release.
• Give every accepted risk an owner and expiry, and review expired acceptances monthly.
• Turn recurring findings into paved-road patterns and report the six metrics quarterly.

Standards and references

• NCSC: Secure design principles
• NIST: SP 800-160 Vol. 1 Rev. 1, Engineering Trustworthy Secure Systems
• NIST: SP 800-207A, A Zero Trust Architecture Model for Access Control in Cloud-Native Applications in Multi-Cloud Environments
• NIST: SP 800-53 Rev. 5
• OWASP: Application Security Verification Standard 5.0
• OWASP: Secure Product Design Cheat Sheet
• OWASP: Threat Modeling Cheat Sheet
• Microsoft Learn: Threat Modeling Tool threats (STRIDE)

Related NHI Mgmt Group resources: Threat Modelling Guide · Secure Software Development Lifecycle (SSDLC) Guide · Service Account Security Guide · Secrets Management Guide · Privacy by Design Guide for Engineering Teams