What Is a Security Architecture Review and How to Run One
Retool's new app builder is where AI-generated code ships safely
Building apps with AI is easy. Getting them to production safely is another story.
Security architecture reviews catch the problems that penetration tests find in production, but earlier and cheaper. A design decision to use JWT tokens for session management without considering algorithm confusion attacks, a microservice architecture where every service has production database access, a third-party OAuth integration without proper token validation: these are all design-level flaws that a security architecture review surfaces before a line of code is written.
A penetration test of the same system finds the same issues: but after months of engineering work to build the vulnerable architecture, and now requires months more to rearchitect.
When to Run a Security Architecture Review
Trigger events for a security architecture review:
- New system being designed from scratch
- Significant new feature that changes the trust model (adding an API to an internal-only system, introducing third-party data access, changing authentication method)
- Migration between deployment models (on-premises to cloud, monolith to microservices)
- Integration of a third-party service that handles sensitive data
- System handling a new data type or sensitivity classification
- Significant scale change (a system expected to serve 100 users now serving 100,000: adversarial interest changes)
When NOT to wait:
- Starting a penetration test: run the architecture review first. A pentest finds implementation bugs; an architecture review finds design flaws. Both are needed; the architecture review should come first so the penetration tester is not rediscovering design issues.
- After a breach: do a post-incident architecture review of affected systems, but the pre-implementation review is the goal.
Who should run it:
- Security architects or application security engineers with system design experience
- A security champion from the development team who knows the codebase
- For critical systems, an external security consultant provides independence
- The review should include the system's architect and a senior developer: they know the design intent
The Review Process: Five Domains
Domain 1: Authentication and Identity
Questions to answer:
- How does a user or service prove its identity to this system?
- What authentication protocols are used (OAuth 2.0, SAML, mTLS, API keys)?
- Where are session tokens generated, stored, and validated?
- What is the token lifetime and rotation policy?
- How are privileged actions (admin operations, account changes) handled differently?
- Is MFA required for privileged access?
Common failures found:
- Sessions tokens stored in localStorage (XSS risk)
- JWT algorithm confusion (HS256 vs RS256)
- Insufficient token expiry (tokens valid for days or weeks)
- Authentication bypass via mass assignment or parameter manipulation
- Admin functionality accessible to authenticated users who should not have it
Domain 2: Authorization and Access Control
Questions to answer:
- How does the system determine what an authenticated user is allowed to do?
- Is authorization checked at every layer (API, database, service)?
- Are authorization checks client-side only (bypassable) or server-side?
- How is multi-tenancy isolation enforced?
- Can a user access another user's resources by changing an ID in the URL or request body?
Common failures found:
- Missing authorization checks on API endpoints (IDOR: Insecure Direct Object Reference)
- Relying on frontend route guards with no server-side enforcement
- Privilege escalation via parameter manipulation
- Service-to-service calls that assume trust without verifying caller identity
Domain 3: Data Flows and Trust Boundaries
Create a data flow diagram:
User browser → [HTTPS] → WAF → [HTTPS] → Load Balancer →
[HTTP internal] → Application Server → [SQL/TLS] → Database
→ [HTTPS] → Third-party API
→ [AMQP] → Message Queue
For each boundary, ask:
- Is data validated and sanitized when it crosses from untrusted to trusted?
- Is the data encrypted in transit across this boundary?
- Does the receiving component need all the data it receives, or should it be filtered?
- What happens if a component on the untrusted side is compromised?
Domain 4: Secrets and Cryptography
Questions to answer:
- How are secrets (API keys, database passwords, TLS private keys) stored and accessed?
- Are secrets in environment variables, config files, or a secrets manager?
- What cryptographic algorithms are used for data at rest and in transit?
- Are there any custom cryptographic implementations? (red flag: use standard libraries)
- How are cryptographic keys managed and rotated?
Common failures:
- Secrets in code repositories or config files
- MD5 or SHA-1 for password hashing (should be bcrypt, scrypt, or Argon2)
- Hard-coded encryption keys
- Self-signed certificates in production
- No certificate pinning for high-security mobile apps
Domain 5: Network Architecture and Segmentation
Review the network diagram:
- What services are internet-facing vs. internal only?
- Can a compromised frontend service reach the database directly?
- Are management interfaces (SSH, RDP, admin consoles) isolated from production traffic?
- Does the architecture allow lateral movement between services that should not communicate?
- Are all external integrations going through a gateway with logging?
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
STRIDE Threat Modeling During the Review
STRIDE is a systematic way to brainstorm threats against each component and trust boundary in the architecture:
S: Spoofing: Can an attacker impersonate a legitimate user, service, or component?
- Can an attacker forge a session token?
- Can an internal service impersonate another internal service?
- Is the API caller's identity verified, or just that they have a valid token?
T: Tampering: Can an attacker modify data in transit or at rest?
- Is data integrity verified end-to-end?
- Can an API request parameter be manipulated to change a different user's data?
- Are database writes validated server-side or only client-side?
R: Repudiation: Can an attacker deny performing an action?
- Is there a tamper-evident audit log of all sensitive actions?
- Are logs stored where the attacker (if they compromise the application server) can delete them?
I: Information Disclosure: Can an attacker access data they should not?
- Do error messages reveal internal system information (stack traces, file paths, SQL queries)?
- Are verbose debug endpoints accessible in production?
- Does the API return more data than the requesting user needs (over-fetching)?
D: Denial of Service: Can an attacker make the system unavailable?
- Are API endpoints rate-limited?
- Can an unauthenticated user trigger computationally expensive operations?
- Is there a maximum request size limit to prevent request body attacks?
E: Elevation of Privilege: Can a low-privilege user gain higher privileges?
- Can a regular user invoke admin-only API endpoints by changing a parameter?
- Can a user escalate to admin by modifying their own profile (role field)?
- Are JWT claims validated server-side before granting access?
Document findings as attacker-centric scenarios:
Finding: JWT Algorithm Confusion
Component: Authentication Service / API Gateway
STRIDE: Spoofing, Elevation of Privilege
Scenario: An attacker who knows the service uses RS256 JWT verification
can downgrade to HS256 and forge a token signed with the public key.
This grants them arbitrary user or admin access.
Recommendation: Pin the algorithm in the JWT library configuration;
reject tokens with alg=HS256 unconditionally.
Severity: Critical
Fix timing: Before deployment
Review Output: What Useful Documentation Looks Like
A security architecture review produces a report that enables the engineering team to remediate findings. Useful reports:
Finding format:
## FINDING-003: Missing Authorization on /api/admin/users Endpoint
**Severity:** High
**Component:** User Management API
**STRIDE Category:** Elevation of Privilege
**Description:**
The /api/admin/users endpoint returns the complete list of all user accounts
and their roles. The endpoint requires authentication (valid JWT) but does
not verify that the authenticated user has the 'admin' role.
**Attack scenario:**
Any authenticated regular user can enumerate all user accounts by calling
GET /api/admin/users with their own valid session token. They can then use
this information for targeted attacks or view PII for all users.
**Evidence:**
Architecture diagram shows the authorization middleware is applied at the
route level but not at the individual endpoint level for admin routes.
**Recommendation:**
Add a requireRole('admin') middleware to all /api/admin/* routes at the
router level, not individually per endpoint, to prevent future admin
endpoints from being added without authorization.
**Fix timing:** Before deployment
**Effort:** Low (1-2 hours)
Review summary dashboard:
Findings by severity:
Critical: 2 (must fix before deployment)
High: 5 (fix before deployment or document accepted risk)
Medium: 8 (fix within 30 days)
Low: 12 (fix in next sprint or document as accepted risk)
Info: 6 (recommendations, not vulnerabilities)
Domains with highest density of findings:
1. Authorization (8 findings): server-side enforcement gaps
2. Secrets management (4 findings): hardcoded secrets, no rotation
3. Input validation (3 findings): insufficient server-side validation
Tracking remediation: Findings should be tracked in the team's issue tracker (Jira, GitHub Issues, Linear) as individual tickets: not just in the report document. The review is not complete until Critical and High findings are resolved or have documented accepted risk with CISO sign-off.
The bottom line
A security architecture review catches design-level flaws before implementation: at 1/30th the cost of fixing the same issues in production. Review five domains: authentication (token design, session management), authorization (server-side enforcement, IDOR prevention), data flows and trust boundaries (validation at each crossing), secrets and cryptography (secrets management, algorithm choices), and network segmentation. Apply STRIDE threat modeling to each component. Document findings in a format that maps directly to actionable tickets, with severity ratings that indicate fix timing. The review is complete when Critical and High findings are resolved or accepted risk is documented.
Frequently asked questions
What is a security architecture review?
A security architecture review evaluates a system's design for security weaknesses before implementation: examining authentication model, authorization controls, trust boundaries, data flows, cryptographic choices, and threat model. It catches design-level flaws when they cost the least to fix (before code is written), unlike a penetration test that finds implementation vulnerabilities in deployed systems.
How do you run a security architecture review?
Five steps: collect design documentation (architecture diagrams, data flow diagrams, API specs), review each of five domains (authentication, authorization, data flows and trust boundaries, secrets and cryptography, network segmentation), apply STRIDE threat modeling to each component and trust boundary, document findings with attacker-centric scenarios and specific recommendations, and track remediation in your issue tracker. Schedule the review at the design phase: before implementation begins.
What is a secure design principle and what are the most important ones?
Secure design principles are architecture guidelines that reduce vulnerability risk regardless of implementation details. The most important: least privilege (grant only permissions required for the specific function); defense in depth (multiple independent security controls so no single failure causes a breach); fail secure (when a component fails, default to denying access rather than allowing it); separation of privilege (require multiple conditions to be met before granting access); complete mediation (check authorization on every access request, not just the first); and minimize attack surface (disable or remove features not needed for the core function). These principles are from the original Saltzer and Schroeder (1975) secure design framework and remain applicable to modern cloud-native architectures.
When is a security architecture review required versus optional?
Required: any new system that handles regulated data (PII, PHI, PCI, or classified information); any new authentication or authorization system; any system with internet-facing APIs; any system with privileged access to production infrastructure; and any acquisition target before integration. Optional but strongly recommended: significant refactors of existing systems, migration from on-premises to cloud, and new third-party integrations. The key question is: if this system is compromised, what data or systems can an attacker access? If the answer includes anything critical, a security architecture review is warranted. The CISA Secure by Design principles provide a practitioner framework for what to check.
What is the difference between a security architecture review and a penetration test?
A security architecture review analyzes design documentation to identify design-level security weaknesses before a system is built or while it can still be redesigned. It finds issues like a missing authentication layer, insufficient authorization controls in the data model, or an insecure trust boundary. It does not require a running system. A penetration test is performed against a running system and validates whether identified vulnerabilities are actually exploitable: it confirms what is broken, not what is designed wrong. Both are necessary and complement each other: architecture reviews catch design flaws early (cheap to fix), penetration tests confirm implementation correctness (validates the build). Performing only penetration tests means design-level flaws survive into production.
How do you run a security architecture review for a system that is already in production and has no design documentation?
Reviewing production systems without documentation requires reverse-engineering the architecture from its implementation. Start with network discovery: use network flow data, firewall rule analysis, and traffic captures to map all inbound and outbound connections. This produces an actual data flow diagram rather than an intended one -- production systems often have undocumented integrations. Interview the system owner and lead developer with structured questions: what data does this system store, who can access it, how does authentication work, what external services does it call, and what happens when it fails? These interviews often surface undocumented components. Review the infrastructure-as-code or cloud console directly: IAM permissions, security groups, database configurations, and load balancer rules tell you the actual access control model. For applications, review the authentication and authorization logic in the codebase -- look for places where authorization checks are missing or inconsistent. Document what you find as the 'as-is' architecture before identifying gaps. Compare the as-is architecture against your security requirements or a threat model for the system type (web application, data pipeline, API gateway). Findings from a post-production architecture review are typically harder to remediate than findings from a pre-build review -- prioritize by risk and negotiate remediation timelines with the product team based on actual exploitability.
Sources & references
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, daily, no spam.
Unsubscribe anytime. We never sell your data.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals every morning.
Win a $2,495 Black Hat pass.
Full-access to Black Hat USA 2026 in Las Vegas. Subscribe free to enter.