La Verità Scomoda sul Threat Modeling
La maggior parte del threat modeling che vedo nelle aziende è teatro della sicurezza. Sessioni di due ore, un whiteboard pieno di box e frecce, qualcuno che scrive "SQL injection" e "man-in-the-middle" su post-it, un documento che finisce in una cartella SharePoint e non viene mai più aperto. Il CISO spunta la casella, il team torna a scrivere codice, e la superficie di attacco rimane identica a prima.
Il vero threat modeling è una disciplina ingegneristica. Il suo output non è un documento — è una comprensione condivisa delle minacce rilevanti per il sistema, tradotta in decisioni di progettazione specifiche, requisiti di sicurezza verificabili e storie di rischio che i developer possono affrontare concretamente.
Nel contesto del Cyber Resilience Act, il threat modeling non è più solo best practice: è il meccanismo operativo per soddisfare i requisiti di cybersecurity risk assessment dell'Annex I. Ogni produttore soggetto al CRA deve essere in grado di dimostrare che ha identificato i rischi del suo prodotto e li ha gestiti. Il threat modeling strutturato è come si fa.
"The goal of threat modeling is not to produce a threat model document. The goal is to secure the system."
— Adam Shostack, autore di Threat Modeling: Designing for Security
Le Quattro Domande Fondamentali
Adam Shostack ha strutturato il threat modeling attorno a quattro domande. La difficoltà sta nell'onestà delle risposte.
Su cosa stiamo lavorando?
Costruire un modello accurato del sistema: componenti, flussi di dati, trust boundary, asset critici. La maggior parte dei team risponde con un diagramma architetturale idealizzato che non mostra dove passano i dati sensibili, chi ha accesso a cosa, o dove si trovano i confini di privilegio. È il punto di partenza sbagliato.
Cosa può andare storto?
Identificare le minacce rilevanti per il sistema specifico. Non un elenco generico di vulnerabilità, ma minacce contestualizzate agli asset, alle superfici di attacco e ai trust boundary identificati nella Q1.
Cosa facciamo al riguardo?
Per ogni minaccia rilevante: definire la mitigazione, assegnare ownership, stimare lo sforzo e inserirla nel backlog come issue tracciabile. Questo passaggio è quello più spesso saltato — e quello che determina se il threat model ha valore reale.
Abbiamo fatto un buon lavoro?
Validare il threat model: il modello del sistema è aggiornato? Le minacce identificate sono quelle giuste? Le mitigazioni proposte sono adeguate? Il threat model è vivo o è già diventato un artefatto obsoleto?
Decomporre il Sistema: Dove il 90% dei Team Fallisce
La qualità di un threat model è direttamente proporzionale alla qualità del modello di sistema su cui si basa. Se il tuo DFD è impreciso o non aggiornato, il resto dell'analisi è costruito su sabbia.
Data Flow Diagrams (DFD): la fondamenta del threat model
Un DFD per il threat modeling ha elementi specifici: processi (cerchi — elaborano dati), data store (rettangoli doppi — archiviano dati), entità esterne (rettangoli — utenti, sistemi esterni), flussi di dati (frecce) e trust boundary (linee tratteggiate). Ogni freccia deve rispondere: cosa fluisce, in quale direzione, sotto quale protocollo, e chi controlla quel canale?
Un DFD che non mostra dove passano le credenziali, dove vengono cifrati i dati, o dove un processo eleva i suoi privilegi non è utile per il threat modeling. Usa livelli: Level-0 per il contesto del sistema, Level-1 per i processi principali, Level-2 per i sotto-componenti critici.
Asset Identification: cosa stai proteggendo davvero?
Gli asset rilevanti includono: dati in transito e a riposo (PII, credenziali, chiavi crittografiche), funzionalità critiche (autenticazione, autorizzazione, workflow di pagamento), risorse di sistema (CPU, storage — per attacchi DoS) e reputazione. Un esercizio efficace: chiedi al team "quali sono le tre cose peggiori che potrebbero succedere a questo sistema?" Le risposte identificano quasi sempre gli asset più critici.
Trust Boundary: Il Concetto Più Critico
Il trust boundary separa due zone del sistema con livelli di fiducia differenti. L'errore più comune: pensare che esista solo il trust boundary tra Internet e il perimetro aziendale. In realtà, in un sistema moderno ce ne sono molti di più:
- Browser → Server: ogni request HTTP è un attraversamento. L'input dell'utente non è mai attendibile.
- Frontend → Backend: anche internamente, il frontend non dovrebbe avere accesso diretto a operazioni privilegiate.
- Microservizio A → Microservizio B: senza autenticazione interna, un attaccante che compromette un servizio si muove lateralmente senza attrito.
- Processo user-space → Kernel: ogni system call è un attraversamento di trust boundary.
- Container → Host OS: confine critico, soprattutto con container privilegiati.
- Firmware → Hardware security module: nei prodotti IoT soggetti al CRA, la catena di fiducia hardware/software è un trust boundary con implicazioni profonde.
- Applicazione → Dipendenza di terze parti: ogni libreria open source ha accesso al processo — il suo codice potrebbe essere compromesso (supply chain attack, rilevante per il CRA SBOM).
La regola: ogni volta che dati controllati da un'entità meno fidata raggiungono un'entità più fidata, c'è un trust boundary. Disegnali tutti nel DFD, poi analizza sistematicamente cosa attraversa ognuno.
STRIDE: La Metodologia Fondamentale
STRIDE fornisce sei categorie di minacce da applicare sistematicamente a ogni elemento del DFD. Per ogni componente (processo, data store, flusso di dati, entità esterna), chiedi quali categorie si applicano.
Nota tecnica: non tutte le categorie si applicano a tutti gli elementi. I processi sono vulnerabili a tutte e sei. I data store non sono soggetti a Spoofing e Repudiation. I flussi di dati sono vulnerabili a Tampering, Information Disclosure e DoS. Le entità esterne principalmente a Spoofing.
Dal campo: STRIDE applicato meccanicamente produce minacce banali. Il valore emerge quando lo si usa come framework di domande, non come checklist. Per ogni minaccia chiedi: è realisticamente sfruttabile in questo sistema specifico? Qual è l'impatto reale? C'è già una mitigazione? Questo filtraggio è dove l'esperienza del security architect fa la differenza.
Oltre STRIDE: Le Altre Metodologie
PASTA — Process for Attack Simulation and Threat Analysis
Quando usarlo: sistemi enterprise complessi, threat modeling risk-centricMetodologia in sette stadi orientata al rischio: definisce gli obiettivi di business prima di analizzare le minacce, collegando vulnerabilità tecniche agli impatti sul business. Labor-intensive ma produce output strettamente allineato alle priorità aziendali. Ideale quando il threat modeling deve essere giustificato in termini di ROI a livello executive.
LINDDUN — Privacy threat modeling
Quando usarlo: requisiti GDPR, dati sensibili, privacy by designLINDDUN è a STRIDE ciò che il GDPR è all'ISO 27001: stesso paradigma, specializzato sulla privacy. Le sue sette categorie mappano minacce alla privacy in modo analogo a come STRIDE mappa minacce alla sicurezza. Se il prodotto tratta dati sanitari, biometrici o di localizzazione, LINDDUN complementa STRIDE e produce input diretto per il Privacy Impact Assessment.
TARA — Threat Analysis and Risk Assessment
Quando usarlo: embedded, IoT, automotive (ISO/SAE 21434), CRA Annex I complianceTARA è la metodologia adottata in automotive (UNECE WP.29, ISO/SAE 21434) ed è la più direttamente rilevante per la conformità CRA. Struttura l'analisi su asset identification, threat analysis e risk assessment con formule esplicite (likelihood × impact). Il suo punto di forza è la tracciabilità: ogni mitigazione è collegata a un requisito verificabile. Per il CRA, TARA produce direttamente la cybersecurity risk assessment richiesta dall'Annex I, Part I.
Attack Trees
Quando usarlo: analisi profonda di scenari specifici, red team planningModellano un singolo obiettivo dell'attaccante in una struttura ad albero (nodi AND/OR). Eccellenti per analizzare scenari di attacco complessi in profondità, identificare il percorso di attacco minimo e pianificare red team exercise. Non ideali come metodologia primaria per sistemi complessi, ma potenti come complemento a STRIDE per le minacce più critiche.
Dalla Minaccia alla Mitigazione: La Mappa STRIDE→Controlli
Un threat model senza mitigazioni è un esercizio accademico. Ogni minaccia deve essere collegata a un controllo specifico con ownership chiara e criteri di verifica.
- Spoofing → Autenticazione: MFA, sessioni a breve scadenza, mTLS per service-to-service, validazione rigorosa di tutti i claim di identità.
- Tampering → Integrità: HMAC o firma digitale su dati critici in transito, TLS 1.3, prepared statements per prevenire SQL injection, firma degli artefatti in pipeline CI/CD.
- Repudiation → Auditability: Log strutturati, centralizzati e tamper-proof (WORM storage, log signing), timestamp sicuri, logging di tutte le azioni amministrative e su dati sensibili.
- Information Disclosure → Confidenzialità: TLS su tutti i canali (anche interni), cifratura at-rest, data minimization, error handling che non espone dettagli interni, security headers HTTP (CSP, HSTS).
- Denial of Service → Disponibilità: Rate limiting a più livelli, circuit breaker, resource quotas, input validation rigorosa, timeout su tutte le operazioni I/O, pagination obbligatoria per query di lista.
- Elevation of Privilege → Autorizzazione: Modello deny-by-default, RBAC/ABAC con granularità adeguata, validazione server-side di tutti i controlli di accesso, least privilege per ogni service account.
Errore frequente: Usare TLS come risposta a tutte le minacce di Information Disclosure. TLS protegge i dati in transito, non quelli a riposo, non quelli nei log, non quelli esposti da un endpoint non autenticato. Ogni threat di Information Disclosure richiede analisi del suo vettore specifico.
Prioritizzare le Minacce: Oltre il CVSS
Il CVSS è nato per valutare vulnerabilità note e specifiche, non minacce architetturali. Applicarlo meccanicamente al threat modeling è metodologicamente scorretto. Preferisco un approccio a tre assi:
- Sfruttabilità contestuale: Quanto è realistica l'exploitazione in questo sistema specifico? Considera complessità tecnica, accesso richiesto e livello di sofisticazione dell'attaccante più probabile.
- Impatto sul business: Danno reale se la minaccia si materializza — perdita di dati, impatto reputazionale, sanzioni CRA/GDPR, perdita economica diretta.
- Costo della mitigazione: Sforzo ingegneristico, complessità operativa aggiunta. Una mitigazione che richiede sei mesi di refactoring ha un profilo di rischio diverso da una che si risolve con due righe di configurazione.
Tooling: Cosa Funziona, Cosa No
Il tool non fa il threat model. Un buon threat model si può fare con carta e penna. Detto questo, il tooling giusto riduce la frizione e migliora la tracciabilità.
- Microsoft Threat Modeling Tool: Gratuito, maturo, genera automaticamente minacce STRIDE dal DFD. Stencil per Azure, web, IoT. Limitato nella collaborazione multi-utente. Ottimo punto di partenza.
- OWASP Threat Dragon: Open source, disponibile come desktop e web app. Più flessibile, supporta template personalizzati. Ideale per team non-Microsoft.
- IriusRisk: La soluzione enterprise più completa. Integrazione nativa con Jira/GitHub/Azure DevOps, librerie di minacce per OWASP/NIST/PCI-DSS, compliance dashboard. Per organizzazioni con molti prodotti, è l'unica soluzione scalabile.
- Threagile: Threat modeling as code — il modello è YAML, le minacce generate automaticamente. Si integra in pipeline CI/CD. Per team con forte cultura DevOps.
- draw.io / Miro: Per la parte diagrammale in sessioni collaborative. Tieni separato il diagramma dall'analisi delle minacce.
Rendere il Threat Modeling Sostenibile
La sfida più grande non è fare il primo threat model. È fare il secondo, il terzo, il decimo. La maggior parte dei programmi muore dopo sei mesi perché il processo è troppo pesante e troppo slegato dal ritmo reale dello sviluppo.
Leggero e iterativo, non monolitico
Parti da un threat model di alto livello (Level-0 DFD) all'inizio del progetto, poi approfondisci iterativamente su ogni feature significativa. Quando un developer aggiunge un nuovo endpoint API, la domanda "introduce nuovi trust boundary?" deve essere naturale, non un evento eccezionale.
Security Champions
Un team di sicurezza centralizzato non può fare threat modeling di tutti i prodotti. La soluzione: distribuire le competenze tramite un programma di Security Champions — developer formati in threat modeling che diventano i referenti locali di sicurezza del loro team.
Threat model come PR artifact
Un approccio che funziona: il threat model diventa un campo strutturato nelle PR che modificano l'architettura. Basta rispondere: "quali trust boundary modifica questa PR? Quale minaccia nuova introduce? Come viene mitigata?" Questo sposta il TM nel flusso quotidiano senza sessioni dedicate per ogni piccola modifica.
Anti-Pattern: Le Cose Che Uccidono un Programma di Threat Modeling
Il "big bang" threat model
Un unico threat model monolitico fatto una volta all'anno. Output: un documento che nessuno legge. Il sistema cambia ogni settimana; il documento è obsoleto in due sprint. Il TM deve essere continuo e granulare.
Threat modeling senza gli sviluppatori
Sessioni in cui il security team analizza il sistema da solo, produce un report e lo manda ai developer come lista di "cose da fixare". Risultato: nessun contesto, nessuna ownership, nessun cambiamento. Il TM è una pratica collaborativa.
Fermarsi all'identificazione delle minacce
Produrre una lista di 40 minacce senza prioritizzazione né mitigazioni specifiche. Ogni minaccia deve avere un owner, una mitigazione specifica e un criterio di verifica — altrimenti il TM non cambia nulla.
Il DFD che non corrisponde alla realtà
Un modello idealizzato del sistema "come dovrebbe essere", non come è in produzione. Mancano le integrazioni di terze parti, i servizi di logging, le pipeline CI/CD. Un threat model fatto su questo DFD produce mitigazioni per minacce inesistenti e ignora quelle reali.
Threat modeling come compliance theater
Fatto solo perché lo richiede il CRA, il cliente o il CISO. Risultato: un documento prodotto nel minimo tempo possibile che soddisfa formalmente il requisito senza cambiare la postura di sicurezza del prodotto.
Threat Modeling e Cyber Resilience Act: Il Collegamento Diretto
Il CRA non menziona "threat modeling" per nome, ma i suoi requisiti tecnici sono praticamente impossibili da soddisfare senza un processo strutturato di analisi delle minacce:
- Annex I, Part I, §1 — Security by Design: "Prodotti progettati in modo da garantire un livello di cybersecurity adeguato ai rischi." È impossibile determinare un livello "adeguato" senza aver identificato i rischi. Il threat modeling strutturato è il meccanismo operativo per questo requisito.
- §1 — Nessuna vulnerabilità sfruttabile nota: La STRIDE analysis sistematica applicata al DFD identifica proattivamente le classi di vulnerabilità prima del rilascio.
- §3(d) — Protezione da accessi non autorizzati: Il trust boundary analysis identifica dove mancano i controlli di autenticazione e autorizzazione.
- §3(j) — Resilienza DoS: La categoria DoS di STRIDE produce i requisiti specifici di rate limiting, resource quota e circuit breaking.
- Annex I, Part II, §1 — SBOM: L'analisi delle dipendenze di terze parti nel DFD (trust boundary verso le librerie open source) alimenta direttamente la gestione dello SBOM.
Per i prodotti in Classe II (firewall industriali, gateway IoT critici) e Critico, la valutazione da parte dell'organismo notificato includerà quasi certamente la verifica di processi di threat modeling documentati e tracciabili. Avere TARA o STRIDE documentato e collegato ai requisiti di sicurezza del prodotto è come si supera la due diligence di certificazione.
Come Costruire un Programma che Duri
Tre conclusioni non negoziabili dall'esperienza sul campo:
Prima: il threat modeling deve essere parte del definition of done per ogni feature significativa, non un'attività straordinaria. Se richiede un'approvazione speciale, non verrà fatto. La frizione uccide l'adozione.
Seconda: il modello di sistema deve essere vivo. Ogni PR che modifica l'architettura dovrebbe aggiornare il DFD. Un threat model su un sistema obsoleto è peggio di nessun threat model.
Terza: misura l'output, non l'input. Non conta quanti threat model hai prodotto — conta quante mitigazioni sono state implementate, quante vulnerabilità architetturali risolte prima del rilascio. Questo è il ROI del threat modeling.
Il team di CRA.tips supporta i produttori nell'implementare processi di threat modeling conformi al CRA — dalla scelta della metodologia (STRIDE, TARA) all'integrazione nel processo di sviluppo, dalla documentazione della risk assessment alla preparazione per l'organismo notificato. Se vuoi costruire un programma reale, inizia dalla Gap Analysis CRA.
The Uncomfortable Truth About Threat Modeling
Most threat modeling I see in organizations is security theater. Two-hour sessions, a whiteboard covered in boxes and arrows, someone writing "SQL injection" and "man-in-the-middle" on sticky notes, a document that lands in a SharePoint folder and is never opened again. The CISO ticks the box, the team goes back to writing code, and the attack surface remains exactly as it was.
Real threat modeling is an engineering discipline. Its output is not a document — it is a shared understanding of the threats relevant to the system, translated into specific design decisions, verifiable security requirements, and risk stories that developers can concretely address.
In the context of the Cyber Resilience Act, threat modeling is no longer just best practice: it is the operational mechanism for satisfying the Annex I cybersecurity risk assessment requirements. Every manufacturer subject to the CRA must demonstrate they have identified their product's risks and managed them. Structured threat modeling is how you do it.
"The goal of threat modeling is not to produce a threat model document. The goal is to secure the system."
— Adam Shostack, author of Threat Modeling: Designing for Security
The Four Fundamental Questions
Adam Shostack structured threat modeling around four questions. The difficulty lies in the honesty of the answers.
What are we building?
Build an accurate model of the system: components, data flows, trust boundaries, critical assets. Most teams answer with an idealized architectural diagram that does not show where sensitive data flows, who has access to what, or where privilege boundaries lie. That is the wrong starting point.
What can go wrong?
Identify threats relevant to the specific system — not a generic list of vulnerabilities, but threats contextualized to the assets, attack surfaces, and trust boundaries identified in Q1.
What are we going to do about it?
For each relevant threat: define the mitigation, assign ownership, estimate effort, and add it to the backlog as a trackable issue. This is the most often skipped step — and the one that determines whether the threat model has real value.
Did we do a good enough job?
Validate the threat model: is the system model current? Were the right threats identified? Are the proposed mitigations adequate? Is the threat model alive — updated when design changes — or is it already another stale artifact?
Decomposing the System: Where 90% of Teams Fail
The quality of a threat model is directly proportional to the quality of the system model it is based on. If your DFD is inaccurate or out of date, the rest of the analysis is built on sand.
Data Flow Diagrams (DFDs): the foundation of the threat model
A DFD for threat modeling has specific elements: processes (circles — process data), data stores (double rectangles — store data), external entities (rectangles — users, external systems), data flows (arrows), and trust boundaries (dashed lines). Every arrow must answer: what flows, in which direction, over what protocol, and who controls that channel?
A DFD that does not show where credentials flow, where data is encrypted, or where a process elevates its privileges is not useful for threat modeling. Use levels: Level-0 for system context, Level-1 for main processes, Level-2 for critical sub-components.
Asset Identification: what are you actually protecting?
Relevant assets include: data in transit and at rest (PII, credentials, cryptographic keys), critical functionality (authentication, authorization, payment workflow), system resources (CPU, storage — relevant for DoS), and trust/reputation. A useful exercise: ask the team "what are the three worst things that could happen to this system?" The answers almost always identify the most critical assets.
Trust Boundaries: The Most Critical Concept
The most common mistake: thinking the trust boundary is only between the Internet and the corporate perimeter. In a modern system, there are many more:
- Browser → Server: every HTTP request is a crossing. User input is never trusted.
- Frontend → Backend: even internally, the frontend should not have direct access to privileged operations.
- Microservice A → Microservice B: without internal authentication, an attacker compromising one service moves laterally without friction.
- User-space process → Kernel: every system call is a trust boundary crossing.
- Container → Host OS: critical boundary, especially with privileged containers.
- Firmware → Hardware security module: in IoT products subject to the CRA, the hardware/software chain of trust has deep security implications.
- Application → Third-party dependency: every open-source library has access to the process — supply chain attacks are directly relevant to CRA SBOM requirements.
The rule: every time data controlled by a less-trusted entity reaches a more-trusted entity, there is a trust boundary. Draw them all. Then systematically analyze what crosses each one.
STRIDE: The Foundational Methodology
STRIDE provides six threat categories to apply systematically to every DFD element. For each component, ask which categories apply.
Technical note: not all categories apply to all elements. Processes are vulnerable to all six. Data stores are not subject to Spoofing and Repudiation. Data flows are vulnerable to Tampering, Information Disclosure, and DoS. External entities are primarily subject to Spoofing.
Field note: STRIDE applied mechanically produces banal threats. Value emerges when you use it as a question framework, not a checklist. For every theoretical threat ask: is it realistically exploitable in this specific system? What is the real impact? Is there already a mitigation covering it? This filtering is where the security architect's experience makes the difference.
Beyond STRIDE: Other Methodologies Worth Knowing
PASTA — Process for Attack Simulation and Threat Analysis
Use when: complex enterprise systems, risk-centric threat modelingSeven-stage risk-oriented methodology that defines business objectives before analyzing threats, linking technical vulnerabilities to business impacts. Labor-intensive but produces output tightly aligned with business priorities. Ideal when threat modeling must be justified at executive level.
LINDDUN — Privacy threat modeling
Use when: GDPR requirements, sensitive data, privacy by designLINDDUN is to STRIDE what GDPR is to ISO 27001 — same paradigm, specialized for privacy. Seven categories map privacy threats analogously to how STRIDE maps security threats. Essential complement for systems processing health, biometric, or location data.
TARA — Threat Analysis and Risk Assessment
Use when: embedded, IoT, automotive (ISO/SAE 21434), CRA Annex I complianceThe methodology most directly relevant to CRA compliance. Adopted in automotive (UNECE WP.29, ISO/SAE 21434). Structures analysis on asset identification, threat analysis, and risk assessment with explicit formulas. Every mitigation is linked to a verifiable requirement. For CRA, TARA directly produces the cybersecurity risk assessment required by Annex I, Part I.
Attack Trees
Use when: deep analysis of specific scenarios, red team planningModel a single attacker objective as a tree (AND/OR nodes). Excellent for deep analysis of complex attack scenarios and identifying minimum attack paths. Not ideal as a primary methodology for complex systems, but powerful as a complement to STRIDE for the most critical threats.
From Threat to Mitigation: The STRIDE→Controls Map
- Spoofing → Authentication: MFA, short-lived sessions, mTLS for service-to-service, rigorous identity claim validation.
- Tampering → Integrity: HMAC or digital signatures on critical data, TLS 1.3, parameterized queries, artifact signing in CI/CD pipelines.
- Repudiation → Auditability: Structured, centralized, tamper-proof logs (WORM storage, log signing), secure timestamps, logging of all administrative actions.
- Information Disclosure → Confidentiality: TLS on all channels (including internal), at-rest encryption, data minimization, secure error handling, HTTP security headers (CSP, HSTS).
- Denial of Service → Availability: Multi-layer rate limiting, circuit breaker, resource quotas, rigorous input validation, I/O timeouts, mandatory pagination for list queries.
- Elevation of Privilege → Authorization: Deny-by-default model, RBAC/ABAC, server-side validation of all access controls, least privilege for every service account.
Common mistake: Using TLS as the answer to all Information Disclosure threats. TLS protects data in transit — not at rest, not in logs, not exposed by an unauthenticated endpoint. Every Information Disclosure threat requires analysis of its specific vector.
Prioritizing Threats: Beyond CVSS
CVSS was designed for known, specific vulnerabilities — not architectural threats. Applying it mechanically in threat modeling is methodologically wrong. I use a three-axis approach:
- Contextual exploitability: How realistic is exploitation in this specific system? Consider technical complexity required, access needed, and the sophistication of the most likely attacker for this system.
- Business impact: Real damage if the threat materializes — data loss, reputational damage, CRA/GDPR penalties, direct financial loss.
- Cost of mitigation: Engineering effort and operational complexity. A mitigation requiring six months of architectural refactoring has a different risk profile than one solved by two lines of configuration.
Tooling: What Works, What Doesn't
- Microsoft Threat Modeling Tool: Free, mature, generates STRIDE threats automatically from the DFD. Stencils for Azure, web, IoT. Limited multi-user collaboration. Excellent starting point.
- OWASP Threat Dragon: Open source, desktop and web app. More flexible, supports custom templates. Ideal for non-Microsoft environments.
- IriusRisk: The most complete enterprise solution. Native Jira/GitHub/Azure DevOps integration, threat libraries for OWASP/NIST/PCI-DSS, compliance dashboards. Scalable for organizations with many products.
- Threagile: Threat modeling as code — YAML model, automatically generated threats. Integrates into CI/CD. For DevOps-heavy teams.
- draw.io / Miro: For the diagrammatic part in collaborative sessions. Keep the diagram separate from the threat analysis.
Making Threat Modeling Sustainable
Lightweight and iterative, not monolithic
Start with a high-level threat model (Level-0 DFD) at project start, then deepen iteratively on each significant feature. When a developer adds a new API endpoint, "does this introduce new trust boundaries?" should be a natural question.
Security Champions
A centralized security team cannot threat model every product. Distribute expertise through a Security Champions program — developers trained in threat modeling who become their team's local security referents.
Threat model as a PR artifact
A practice that works: structured fields in PRs that modify architecture — "which trust boundaries does this PR change? What new threat does it introduce? How is it mitigated?" This moves TM into the daily development flow.
Anti-Patterns That Kill a Threat Modeling Program
The "big bang" threat model
A single monolithic threat model done once a year. The system changes every week; the document is stale in two sprints. Threat modeling must be continuous and granular.
Threat modeling without developers
Security team analyzing the system in isolation, sending a report as a "fix list." No context, no ownership, no change. Threat modeling is a collaborative practice — developers know the implementation details the security architect does not.
Stopping at threat identification
A list of 40 threats without prioritization or specific mitigations. Every threat must have an owner, a specific mitigation, and a verification criterion — otherwise the TM changes nothing.
The DFD that does not match reality
An idealized model missing third-party integrations, logging services, and CI/CD pipelines added "temporarily" years ago. A threat model built on this DFD produces mitigations for nonexistent threats and ignores real ones.
Compliance theater
Done only because the CRA, client, or CISO requires it. A document produced in minimum time satisfying the formal requirement without changing the product's security posture.
Threat Modeling and the Cyber Resilience Act: The Direct Connection
The CRA does not name "threat modeling" explicitly, but its technical obligations are practically impossible to satisfy without a structured threat analysis process:
- Annex I, Part I, §1 — Security by Design: "Products designed to ensure a level of cybersecurity appropriate to the risks." Impossible to determine "appropriate to the risks" without first identifying them. Structured threat modeling is the operational mechanism.
- §1 — No known exploitable vulnerabilities: Systematic STRIDE analysis on the DFD proactively identifies vulnerability classes before release.
- §3(d) — Protection against unauthorized access: Trust boundary analysis identifies where authentication and authorization controls are missing.
- §3(j) — DoS resilience: The STRIDE DoS category produces specific requirements for rate limiting, resource quotas, and circuit breaking.
- Annex I, Part II, §1 — SBOM: Analyzing third-party dependencies in the DFD (trust boundaries toward open-source libraries) feeds directly into SBOM management.
For Class II products (industrial firewalls, critical IoT gateways) and Critical, assessment by a notified body will almost certainly verify documented, traceable threat modeling processes. Having TARA or STRIDE documented and linked to the product's security requirements is how you pass certification due diligence.
Building a Program That Lasts
Three non-negotiable conclusions from field experience:
First: threat modeling must be part of the definition of done for every significant feature. If it requires special approval and a 6-page template, it will not happen. Friction kills adoption.
Second: the system model must be a living artifact. Every PR modifying architecture should update the DFD. A threat model on an outdated system is worse than no threat model at all.
Third: measure outputs, not inputs. What counts is not how many threat models were produced — it is how many mitigations were implemented and how many architectural vulnerabilities were resolved before release. That is the ROI of threat modeling.
The CRA.tips team supports manufacturers in implementing CRA-compliant threat modeling processes — from methodology selection (STRIDE, TARA) to SDLC integration, risk assessment documentation, and notified body preparation. If you want a real program, start with the CRA Gap Analysis.