Reviewed September 2026Secure-by-design

Find dangerous design assumptions before they become expensive production vulnerabilities.

Threat modeling is a structured way to ask what the system is protecting, who or what can interact with it, where trust changes, how an attacker could abuse intended functionality, which controls reduce those paths, and what evidence will show the design works. It is most valuable when performed while architecture can still change.

NIST’s Secure Software Development Framework calls for secure development practices across the lifecycle, while CISA’s Secure by Design work emphasizes shifting security responsibility upstream into product design and defaults. This guide turns those principles into a repeatable architecture-review workflow.

Review triggers

Threat-model changes that introduce new trust, privilege, data, or exposure.

Require architecture review for new internet-facing services, new authentication or authorization models, privileged workflows, sensitive-data processing, cross-tenant designs, external integrations, major cloud migrations, new public APIs, payment or identity flows, new administrative planes, AI or automation that can take consequential actions, and material changes to existing trust boundaries.

Use lighter review for low-risk changes and deeper review for systems with high consequence. The process should help teams ship safely rather than force every change through the same committee. A small internal tool with no sensitive data does not need the same modeling depth as a public multi-tenant platform handling regulated records.

Repeat the model when architecture changes materially. A threat model from launch does not remain current after adding mobile clients, federated identity, third-party APIs, new cloud regions, public sharing, service accounts, or administrative automation.

System model

Draw enough of the system to make trust visible.

Actors and identities

Identify end users, administrators, service identities, third parties, support personnel, automation, external systems, and unauthenticated actors. Record how each authenticates and what authority it can exercise.

Data flows

Map sensitive and security-relevant data from creation through processing, storage, transfer, export, logging, analytics, backup, and deletion. Mark where classification, ownership, or legal obligations change.

Trust boundaries

Mark transitions between browser and service, public internet and internal network, tenant and tenant, workload and control plane, user and administrator, application and database, service and supplier, managed and unmanaged device, and production and non-production environments.

High-value components

Identify identity providers, key stores, secrets, administrative APIs, deployment systems, security tooling, payment services, data stores, backup systems, and other components whose compromise would create disproportionate impact.

Threat discovery

Ask how intended features can be abused, not only which CVEs might exist.

Use structured categories such as spoofing, tampering, repudiation, information disclosure, denial of service, and elevation of privilege if they help the team reason consistently. Also use abuse cases tied to the product: cross-tenant access, invitation abuse, password reset takeover, payment manipulation, object enumeration, bulk export, malicious file processing, webhook abuse, SSRF, excessive automation, admin impersonation, or logging suppression.

Consider the attacker’s starting position. What can an unauthenticated user do? What changes if the attacker controls a normal account, a compromised endpoint, a vendor account, a service credential, an administrator session, or an internal network position? Different starting assumptions reveal different trust failures.

Model failure conditions as well as malicious activity. What happens if the identity provider is unavailable, the logging pipeline fails, a vendor API returns corrupted data, a queue replays requests, a backup is stale, or a policy engine cannot be reached? Security controls that fail open can create attack paths during outages.

Control design

Attach controls to specific attack paths and security outcomes.

Identity and authorization

Define authentication strength, session handling, tenant binding, least privilege, privileged elevation, service identity, object-level authorization, delegation, and recovery. Authorization should derive from trusted server-side context rather than attacker-controlled identifiers.

Data protection

Define encryption, key ownership, classification, retention, export, masking, logging redaction, backup, and deletion. Protect sensitive data in temporary stores and telemetry as well as primary databases.

Input and integration boundaries

Validate untrusted input, constrain outbound requests, authenticate webhooks, protect parsers and file processors, validate redirect destinations, restrict dangerous protocols, and define trust requirements for third-party APIs.

Detection and recovery

Decide which abuse paths must generate logs or alerts, what context responders need, how compromised identities or integrations are revoked, and how the service returns to a trusted state after a security event.

Architecture review

Record decisions, unresolved risk, and verification—not just comments on a diagram.

For each material threat, document whether the design prevents it, detects it, limits consequence, transfers responsibility, accepts residual risk, or needs additional work. Assign an owner and target milestone for unresolved items.

Make important design decisions durable. Record why a particular authentication model, network boundary, tenant-isolation mechanism, encryption design, administrative workflow, external dependency, or logging architecture was chosen. Future teams need to understand the security assumptions before changing them.

Escalate risks that exceed the team’s authority. Product engineers should not silently accept organization-level legal, safety, privacy, or business-continuity consequences simply because a launch date is approaching.

Verification

Turn threat-model assumptions into tests and observable evidence.

Authorization: automated tests for cross-user, cross-role, and cross-tenant access, including negative cases.
Identity: tests for session expiration, MFA requirements, recovery, privilege elevation, and token revocation.
Input boundaries: security tests for parsers, redirects, SSRF controls, file handling, injection, and webhook verification.
Configuration: deployment-policy checks for public exposure, encryption, logging, secrets, network rules, and secure defaults.
Detection: simulated abuse that proves high-value security events reach the expected monitoring and investigation path.
Recovery: exercises for compromised credentials, failed dependencies, rollback, backup restoration, and administrative lockout.

Program measures

Measure design-risk closure and verification quality.

Review coverage

High-risk projects and material architecture changes receiving threat modeling before production deployment.

Unresolved design risk

Threat-model findings still open at release, segmented by consequence, owner, and approved acceptance.

Verification linkage

Material threats with a corresponding automated test, security test, configuration check, detection test, or recovery exercise.

Recurrence

Production vulnerabilities or incidents caused by threat classes already identified in prior models, indicating weak remediation or poor reuse of lessons.

90-day implementation

Make threat modeling a lightweight engineering habit before making it a large governance process.

Days 1–30

Define review triggers, a one-page threat-model template, trust-boundary conventions, risk escalation, and a pilot group of high-impact services.

Days 31–60

Run facilitated models on pilot systems, convert threats into backlog items and tests, document architecture decisions, and create reusable threat patterns for identity, data, APIs, and integrations.

Days 61–90

Integrate modeling into design review, measure open design risk and verification coverage, train engineering leads to facilitate lighter reviews, and feed production incidents back into the threat library.

Primary sources

Anchor architecture review in secure-development and secure-by-design guidance.

Continue learning

Related guides after Threat Modeling & Security Architecture Review

Follow the next implementation topic without returning to search.

Turn Threat Modeling & Security Architecture Review Guide | Zeph Tech into a decision-ready next step.

Use the source-backed research to pressure-test assumptions, then build a reusable evaluation brief before you compare products, scope implementation, or request a fit review.

Build an evaluation brief Browse the research archive Explore the full resource library See where ZephCMS may fit