What Is Threat Modeling?
Threat modeling is a structured, repeatable process for identifying, prioritizing, and addressing security risks in a system before those risks become exploitable vulnerabilities. At its core, it answers a direct question: what could an attacker do to this system, and how do we stop them?
Unlike penetration testing—which validates whether known vulnerabilities can be exploited in a running system—threat modeling operates upstream in the design phase, where fixing security problems costs a fraction of post-deployment remediation. The NIST Cybersecurity Framework identifies threat analysis and risk assessment as foundational practices for any security program, and NIST SP 800-154 specifically addresses data-centric system threat modeling as a method for identifying how sensitive information could be exposed or manipulated before a system is built.
Organizations that embed threat modeling fundamentals into their security program gain a proactive edge: they map attack surfaces systematically, prioritize mitigations based on real risk, and produce documentation that supports compliance requirements under NIST SP 800-171, SOC 2 Type II, and HIPAA Security Rule §164.312. This step-by-step guide covers the essential process, the most widely used frameworks, and practical tools your team can deploy today.
Threat Modeling By The Numbers
IBM Cost of Data Breach Report 2024
IBM Cost of Data Breach Report 2024
Verizon Data Breach Investigations Report 2024
The Four Core Questions Every Threat Model Must Answer
Threat modeling authority Adam Shostack—who codified much of Microsoft's threat modeling methodology and authored Threat Modeling: Designing for Security—identifies four questions that every threat modeling session must answer, regardless of framework or tool in use:
- What are we building? Define the system boundary: components, data stores, data flows, and external integrations.
- What can go wrong? Enumerate threats using a structured approach such as STRIDE or MITRE ATT&CK.
- What are we going to do about it? Select mitigations, compensating controls, or formally accepted risks for each identified threat.
- Did we do a good enough job? Review and validate the threat model against test results and evolving system changes.
These questions underpin the OWASP Threat Modeling methodology and align with NIST SP 800-53 control requirements for risk assessment and system analysis. They apply whether your team is securing a REST API, a multi-cloud architecture, or an operational technology (OT) environment.
Before selecting a specific methodology, orient every threat modeling session around these four questions to keep analysis grounded in outcomes rather than process compliance. For teams new to structured security analysis, reviewing what is cyber threat intelligence provides useful context on the threat actor environment that informs which threat categories to prioritize in your enumeration phase.
Threat Modeling Step-by-Step: The Core Process
Define Scope and Objectives
Identify the system or component under review, its business purpose, and the data it processes. Document security objectives: what must be protected, from whom, and under what regulatory requirements (HIPAA, PCI DSS 4.0, NIST SP 800-171, etc.). A tightly scoped threat model is more actionable than a vague enterprise-wide assessment.
Decompose the System Architecture
Create a Data Flow Diagram (DFD) that maps every component, data store, process, external entity, and trust boundary. Use DFD Level 0 for high-level context and DFD Level 1 for detailed component interactions. Mark every point where data crosses a trust boundary—these are your highest-risk attack surfaces.
Identify Threats Using a Framework
Apply a systematic threat enumeration methodology. STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege) maps naturally to DFD elements and is well-supported by tooling. Cross-reference findings with the MITRE ATT&CK framework to align threats with real-world adversary techniques and documented threat actor tactics.
Score and Prioritize Threats
Rate each identified threat using a risk scoring method. DREAD (Damage, Reproducibility, Exploitability, Affected Users, Discoverability) provides a quick numeric score for rapid triage. CVSS v3.1 or v4.0 is preferred for threats that map to known vulnerability classes. Focus remediation effort on high-scoring threats first.
Define Mitigations and Controls
For each prioritized threat, assign a specific response: implement a control (such as enforcing multi-factor authentication for Spoofing threats), accept the risk with documented rationale, transfer via cyber insurance or vendor SLA, or eliminate the attack surface entirely. Map mitigations to security controls in NIST SP 800-53 or CIS Controls v8 to satisfy audit requirements.
Document, Validate, and Iterate
Produce a threat model document capturing the system diagram, threat list, risk scores, and assigned mitigations. Validate mitigations through unit tests, integration tests, or targeted penetration testing. Schedule a threat model review whenever the system architecture changes—a threat model is a living artifact, not a one-time deliverable.
STRIDE: The Most Widely Used Threat Modeling Framework
Developed at Microsoft as part of the Security Development Lifecycle (SDL), STRIDE remains the most broadly adopted threat modeling methodology for application and API security. Each letter maps to a threat category and the security property that mitigations must preserve:
Threat
Property Violated
Example Attack
Common Mitigation
Spoofing
Authentication
Credential stuffing, session hijacking
MFA, strong session management
Tampering
Integrity
SQL injection, man-in-the-middle modification
Input validation, TLS 1.3, digital signatures
Repudiation
Non-repudiation
Deleting audit logs, forging timestamps
Immutable audit logs, cryptographic signing
Information Disclosure
Confidentiality
Data exposed in API responses, misconfigured storage
Encryption at rest and in transit, least-privilege access
Denial of Service
Availability
HTTP flood, resource exhaustion attacks
Rate limiting, auto-scaling, WAF rules
Elevation of Privilege
Authorization
Broken access control, IDOR vulnerabilities
Role-based access control (RBAC), zero-trust architecture
STRIDE is most effective when applied element-by-element to a DFD: for each process, data store, data flow, and external entity, systematically ask which STRIDE categories apply. The Microsoft Threat Modeling Tool automates much of this by generating STRIDE threats from diagrams drawn inside the application, making it a practical starting point for development teams.
When selecting authentication mitigations for Spoofing threats, align your controls with nist phishing resistant mfa security keys official guidance, which covers phishing-resistant authentication options recommended for high-assurance scenarios. For a broader view of adversary techniques that map to STRIDE categories, the mitre att&ck framework cross-reference adds real-world threat actor behavior to your enumeration.
PASTA and LINDDUN: Risk-Centric and Privacy-First Alternatives
PASTA: Process for Attack Simulation and Threat Analysis
PASTA is a seven-stage, risk-centric threat modeling methodology designed for organizations that need to connect security findings directly to business impact. Unlike STRIDE's categorical approach, PASTA structures analysis around the likelihood and business consequence of each attack scenario. The seven stages are: define business objectives, define the technical scope, decompose the application, perform threat analysis, perform vulnerability and weakness analysis, model the attack, and analyze overall risk and impact.
PASTA is well-suited for regulated industries—financial services, healthcare organizations under HIPAA Security Rule §164.308, and federal contractors under NIST SP 800-171—because its risk-scoring output maps directly to control frameworks and audit evidence requirements. The trade-off is complexity: PASTA sessions require dedicated security practitioners and more structured facilitation than STRIDE workshops. Organizations already running annual risk assessments under ISO 27001:2022 or SOC 2 Type II will find PASTA's risk-output format integrates naturally into existing documentation.
LINDDUN: Privacy-Focused Threat Modeling
LINDDUN addresses a gap in traditional security threat modeling by focusing specifically on privacy threats. The acronym covers: Linkability, Identifiability, Non-repudiation, Detectability, Disclosure of information, Unawareness, and Non-compliance. Organizations building products that process personal data under GDPR, CCPA, or HIPAA will find LINDDUN surfaces privacy risks that STRIDE misses—such as an attacker's ability to link anonymized records or infer sensitive attributes from metadata patterns.
For teams with strong privacy requirements, LINDDUN is best run in parallel with STRIDE rather than as a replacement, ensuring both security and privacy threat surfaces receive systematic coverage. The full methodology is documented at the LINDDUN project website, developed by researchers at KU Leuven.
Key Benefits of Implementing Threat Modeling
Early Risk Detection
Identify and address security flaws at the design phase, where remediation costs are significantly lower than post-deployment fixes discovered during testing or breach response.
Compliance Documentation
Produce auditable evidence for NIST SP 800-171 (§3.11.1), SOC 2 Type II (CC3.2), HIPAA Security Rule §164.312, and PCI DSS 4.0 risk assessment requirements.
Prioritized Remediation
Use DREAD or CVSS scoring to rank threats by impact and likelihood, so your team directs effort toward the highest-risk vulnerabilities rather than fixing issues at random.
Security-Aware Development
Threat modeling sessions build security intuition across engineering teams, reducing recurring vulnerability classes and shifting security knowledge left in the SDLC.
Attack Surface Reduction
Systematic DFD analysis surfaces unnecessary trust boundary crossings, redundant services, and over-privileged components that silently expand your attackable area.
Third-Party Risk Visibility
Map external API integrations, cloud dependencies, and vendor components into the threat model to identify supply chain risks before they reach production systems.
Threat Modeling Tools: What Security Teams Actually Use
Selecting the right tooling accelerates threat modeling without replacing the analytical work that practitioners must perform. The tool category you choose should match your team's technical depth, the volume of systems under review, and whether you need integration with existing developer workflows.
Diagramming and DFD Tools
The Microsoft Threat Modeling Tool (free, Windows-based) generates STRIDE threats automatically from Data Flow Diagrams built inside the application—practical for teams standardizing on STRIDE without a licensing budget. OWASP Threat Dragon (open source, cross-platform) provides a browser-based and desktop DFD editor with STRIDE threat generation and JSON export, enabling version-controlled threat model storage alongside source code in your repository. Teams already using Lucidchart, draw.io, or Miro can produce DFDs in those tools and document threats separately in a security tracking system or wiki.
Developer-Integrated Platforms
Enterprise platforms such as IriusRisk and ThreatModeler embed threat modeling into the secure software development lifecycle (SSDLC) with library-driven threat generation, requirement tracking, and integration with Jira, Confluence, and CI/CD pipelines. These platforms are appropriate when threat modeling needs to scale across dozens of applications with consistent methodology enforcement and auditable output for compliance reviews.
AI-Assisted Threat Enumeration
AI-assisted tools can suggest threats based on code scanning and architecture descriptions, accelerating initial enumeration. Security practitioners should review AI-generated threat lists carefully: they may miss context-specific risks or produce generic findings that do not reflect actual system behavior. Use AI suggestions as a starting checklist, not a substitute for structured analysis guided by a qualified practitioner.
Teams gathering external intelligence to enrich threat enumeration will find osint for cybersecurity beginners covers practical techniques for identifying active threat actors and published techniques targeting their sector—a layer that grounds your threat list in real attacker behavior rather than theoretical categories alone.
Start Small, Iterate Fast
Practical guidance: Threat model your highest-risk application first—the one handling the most sensitive data or most exposed to the internet. A two-hour STRIDE workshop with a whiteboard DFD delivers more value than a delayed, perfect threat model. Establish the habit, then improve the process with each iteration.
Integrating Threat Modeling Into Your Security Program
Threat modeling delivers its greatest value when embedded in your development lifecycle rather than treated as a periodic audit exercise. Three integration points create the most durable impact:
Shift-Left in the Development Lifecycle
Introduce threat modeling at the architecture review stage of new projects and significant feature additions. Define a lightweight threat model template that developers complete before opening a design review request. This makes security review a documented checkpoint with required outputs rather than an informal conversation with no record.
Change-Triggered Reviews
Establish a defined trigger list for threat model updates: adding a new external API integration, changing authentication or authorization mechanisms, migrating to a new cloud provider, or onboarding a new category of sensitive data. Without a change-trigger policy, threat models drift out of date and lose utility as living security documents. A threat model reflecting last year's architecture can create false confidence in this year's system.
Penetration Testing Alignment
Share threat model outputs with your penetration testing team before each engagement. Threat models identify the attack surfaces and threat hypotheses that testers should validate, making test scopes tighter and findings more actionable. This alignment also distinguishes between theoretical threats identified in modeling and confirmed vulnerabilities validated through testing—a distinction auditors and executives find valuable.
For compliance mapping, document how each identified threat and assigned mitigation addresses requirements in your applicable framework. HIPAA-covered entities should map threat model outputs to §164.312 technical safeguards. Organizations pursuing SOC 2 Type II should retain documentation as evidence for common criteria CC3.2. NIST SP 800-171 contractors can satisfy requirement 3.11.1 using threat model documentation as part of their System Security Plan (SSP). For a broader view of building layered defenses that threat modeling supports, review our cybersecurity guide.
Get Expert Threat Modeling Support
Bellator Cyber Guard's security engineers facilitate threat modeling workshops, build threat model libraries aligned to your compliance requirements, and integrate findings into your existing security program. Start with a no-cost strategy call.
Frequently Asked Questions
Threat modeling is a structured process for identifying and prioritizing potential security threats to a system, application, or architecture before they can be exploited. It involves decomposing a system into components and data flows, applying a threat enumeration methodology (such as STRIDE or PASTA), scoring threats by risk, and assigning mitigations. The output is a documented set of threats, their risk ratings, and the controls assigned to address them—supporting both proactive security and compliance evidence requirements.
Threat modeling is most effective when performed during the design phase of a new system or feature, before code is written. It should also be revisited whenever the system architecture changes materially—such as adding a new external API, changing authentication mechanisms, migrating to a new cloud provider, or onboarding a new data type. Most security programs establish a recurring cadence (annual minimum) alongside change-triggered reviews to keep threat models current.
STRIDE is a threat categorization framework developed at Microsoft as part of its Security Development Lifecycle (SDL). The acronym stands for Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and Elevation of Privilege. Each category maps to a security property that mitigations must preserve—for example, Spoofing threatens Authentication, and Tampering threatens Integrity. STRIDE is applied element-by-element to a Data Flow Diagram to systematically enumerate threats across every component and interaction in a system.
Threat modeling identifies potential security risks at the design or architecture level, typically before a system is built or during development. Penetration testing validates whether identified or suspected vulnerabilities can actually be exploited in a built, running system. The two practices are complementary: threat modeling informs what attack surfaces a penetration test should focus on, and penetration test findings can trigger updates to the threat model. Neither replaces the other, and mature security programs use both in sequence.
Common threat modeling tools include the Microsoft Threat Modeling Tool (free, Windows-based, STRIDE-focused), OWASP Threat Dragon (open source, cross-platform DFD editor), IriusRisk (enterprise platform with SDLC integration), and ThreatModeler (cloud-based, supports STRIDE and PASTA). Many teams also use general diagramming tools such as draw.io or Lucidchart for DFDs and track threats in Jira, Confluence, or spreadsheets. The right tool depends on team size, chosen methodology, and integration requirements with existing developer workflows.
A Data Flow Diagram (DFD) is a visual representation of how data moves through a system. In threat modeling, DFDs map every process (code that transforms data), data store (database, file system, cache), external entity (user, third-party API, partner system), and data flow (network connection, API call), along with trust boundaries that separate security zones. Trust boundary crossings receive the most scrutiny because they represent points where unauthorized access or data manipulation is most likely to occur.
PASTA (Process for Attack Simulation and Threat Analysis) is a seven-stage, risk-centric threat modeling methodology that connects technical security threats to business impact. The stages are: define business objectives, define technical scope, decompose the application, perform threat analysis, perform vulnerability analysis, model the attack, and analyze risk and impact. PASTA is often preferred in regulated industries because its risk-scoring output maps directly to frameworks such as NIST SP 800-171, ISO 27001:2022, and SOC 2 Type II audit requirements.
A threat model should be reviewed at least annually as part of your security program's regular assessment cycle. More importantly, it should be updated whenever there is a material architecture change: adding or removing an external integration, modifying authentication or authorization mechanisms, processing a new category of sensitive data, or migrating infrastructure. Without change-triggered reviews, threat models quickly become stale and lose their value as actionable, audit-ready security documents.
Effective threat modeling sessions typically include developers or architects who built the system (for technical accuracy), a security engineer or practitioner (to guide the methodology and identify security-specific threats), a product or business representative (to provide context on data sensitivity and business risk), and ideally a QA engineer (to identify validation and testing gaps). Keeping the working group to four to six participants produces the most efficient sessions. Leadership should review and sign off on risk acceptance decisions but does not need to attend working sessions.
Threat modeling directly supports risk assessment requirements across multiple frameworks. NIST SP 800-171 requirement 3.11.1 requires periodic assessment of risk to organizational operations and assets—threat model documentation satisfies this requirement as part of a System Security Plan. HIPAA Security Rule §164.308(a)(1) requires a risk analysis; a structured threat model can serve as the technical component of that analysis. SOC 2 Type II requires risk assessment evidence under common criteria CC3.2. PCI DSS 4.0 requires annual risk assessments for all in-scope systems. Consult your compliance advisor to confirm how threat model outputs map to your specific requirements and documentation standards.
Schedule
Want personalized advice?
Our cybersecurity experts can help you implement these best practices. Free consultation.
