TL;DR: Threat modeling still reduces architectural risk, but AI coding assistants, continuous deployment, and larger codebases are making framework choice more consequential, according to Apiiro. STRIDE, DREAD, and PASTA each solve different parts of the problem, while the growing challenge is keeping analysis aligned with fast-changing systems.
At a glance
What this is: Apiiro argues that threat modeling still works, but AI-era development makes framework choice more consequential because speed, system complexity and change now outpace manual review cycles.
Why it matters: For IAM and security practitioners, the lesson is that threat modeling must be matched to programme maturity and development velocity, or it becomes too abstract to guide real controls.
Context
Threat modeling is a design-time governance practice that depends on having enough architectural stability to reason about trust boundaries, data flows and attack paths. AI-assisted coding, continuous deployment and larger interconnected systems reduce that stability, so the main challenge is no longer only identifying threats but keeping the model current enough to drive decisions. The article sits in application security, but it also intersects with identity because spoofing, privilege escalation, access control and auditability are recurring threat classes.
The practical gap is selection, not theory. STRIDE is built for systematic threat identification, DREAD adds prioritisation, and PASTA pushes toward business-aligned attack simulation. Teams that pick the wrong level of process for their maturity often either under-analyse fast-changing systems or over-invest in analysis they cannot sustain. That mismatch is increasingly common in modern development programmes.
Key questions
Q: How should security teams choose between STRIDE, DREAD, and PASTA?
A: Use STRIDE when you need broad, repeatable threat identification, DREAD when you need to rank an existing list of threats, and PASTA when you need a business-aligned analysis of a critical system. Many teams combine STRIDE and DREAD for practicality, then reserve PASTA for high-consequence applications where attack simulation changes the remediation decision.
Q: Why do fast-moving development environments make threat modelling less reliable?
A: Because the model can go stale faster than teams can review it. Continuous deployment, AI-assisted coding and expanding codebases change trust boundaries and attack paths so quickly that a threat model built for a static design may no longer reflect the system in production.
Q: What breaks when threat modeling is only done in periodic workshops?
A: Periodic workshops often produce models that age quickly, especially in agile and cloud environments. The main failure is stale risk visibility. Teams miss newly introduced attack paths, dependencies, and infrastructure changes, while remediation moves too late. That creates friction between security and engineering and weakens the value of the model as a living control.
Q: When should organisations use PASTA instead of lighter frameworks?
A: Use PASTA when the system is business critical, the attack path needs simulation, and executive stakeholders need risk translated into business outcomes. For smaller changes or faster-moving teams, the overhead can outweigh the benefit, so a lighter framework is usually the better fit.
Technical breakdown
STRIDE maps architecture to six repeatable threat classes
STRIDE is a taxonomy-driven method for identifying threats early in design. Teams map services, data flows, trust boundaries and external entities against six categories: spoofing, tampering, repudiation, information disclosure, denial of service and escalation of privilege. Its value is not prediction accuracy in the abstract, but consistency. By forcing teams to ask the same questions of each component, STRIDE turns architecture review into a repeatable security exercise that is easier to operationalise across product teams.
Practical implication: Use STRIDE when you need a shared language for identifying threat classes before implementation begins.
DREAD converts threat lists into prioritised risk decisions
DREAD is a scoring model, not a threat discovery method. It rates damage, reproducibility, exploitability, affected users and discoverability so teams can rank findings that were already identified, often via STRIDE. That makes prioritisation more explicit, but not perfectly objective. The model still relies on reviewer judgement, which means scoring consistency matters as much as the score itself. In practice, DREAD works best where teams need a defensible way to compare many findings and allocate remediation effort.
Practical implication: Use DREAD after discovery to decide which threats deserve engineering attention first.
PASTA links attack simulation to business impact
PASTA is a seven-step, business-aligned approach that begins with objectives and moves through scope, decomposition, threat analysis, weakness analysis, attack simulation and risk impact analysis. Its distinguishing feature is the attempt to model how an attacker would actually chain weaknesses into an exploit path and what that would mean for the business. That depth makes it useful for high-value systems, but it also creates higher overhead and requires more specialised skill than lighter frameworks.
Practical implication: Use PASTA for critical systems where realistic attack paths and business impact need to be modelled together.
NHI Mgmt Group analysis
AI-era development makes threat modelling a governance problem, not just a methodology choice. The article shows that speed and system churn now shape whether a framework remains useful at all. A method that works on a stable design can fail operationally when code and architecture change continuously. The practical conclusion is that threat modelling programmes need governance around freshness, scope and review cadence, not just a preferred worksheet.
STRIDE remains the right entry point for teams that need repeatability before depth. Its strength is architectural coverage, especially where teams need to consistently surface spoofing, tampering and privilege escalation risks across many services. That makes it useful for organisations that are still building a shared language for threat identification, including identity-related risks such as broken access control and authentication spoofing.
DREAD solves prioritisation, but it does not solve trust in the scoring process. The framework can make remediation decisions more explicit, yet the scores still depend on human judgement and can drift between reviewers. That means the real control is not the number itself but the consistency of the scoring model. Teams should treat DREAD as a prioritisation discipline, not as objective measurement.
PASTA is the clearest fit when security teams must connect attack paths to business exposure. Its value is that it forces analysis beyond component-level issues and into the consequences of realistic attacker behaviour. That is most defensible for high-value systems where executives, auditors and engineering leads need a common view of impact. The practitioner lesson is to reserve this depth for the places where it will change decisions.
What this signals
Threat modelling is only effective when the review cadence matches delivery cadence. In AI-assisted engineering environments, the old assumption that a design review remains valid for weeks is no longer safe. Security leaders should treat model freshness as part of programme governance, not as a documentation task.
Framework selection now shapes operational usefulness more than theoretical completeness. Teams that need broad coverage and repeatability should favour STRIDE first, while teams with mature risk governance can reserve deeper methods for the systems where business impact justifies the effort.
For practitioners
- Calibrate framework depth to delivery speed Use STRIDE for fast-moving product work, DREAD for ranking the resulting findings, and PASTA only where the system justifies deeper business-impact analysis.
- Standardise the architecture artefacts first Require data flow diagrams, trust boundaries and external entities to be documented before threat workshops begin so reviewers are analysing the same system view.
- Separate identification from prioritisation Do not ask one framework to do both jobs. Capture threats systematically first, then use a second method to rank them for remediation.
- Re-run threat models on change-triggering events Update models when continuous deployment, major dependency changes or AI-assisted code generation materially alter the attack surface.
Key takeaways
- The article’s central point is that threat modelling still matters, but AI-era delivery speed makes framework choice and review cadence far more consequential than before.
- STRIDE, DREAD and PASTA address different stages of the work, from threat discovery to prioritisation to business-aligned attack simulation.
- For practitioners, the practical test is whether the framework you use can still produce timely, actionable findings as the system changes.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | ID.RA-01 — Asset vulnerabilities are identified and documented | Threat modelling identifies architectural risk before it becomes exploitable code. |
| PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article repeatedly references spoofing and privilege escalation as core threat classes. | |
| Recommendation — Document system vulnerabilities and attack paths before implementation begins. Review authorisation paths early so privilege escalation risks are visible before release. | ||
| MITRE ATT&CK | TA0001;TA0004;TA0006 — Initial Access; Privilege Escalation; Credential Access | STRIDE's spoofing and escalation themes align with common adversary tactics in application security. |
| Recommendation — Map application threat models to attacker tactics so detection and control coverage stays grounded in real abuse paths. | ||
| NIST SP 800-53 Rev 5 | SA-11 — Developer Testing and Evaluation | Threat modelling supports secure design review and validation before code ships. |
| Recommendation — Embed threat modelling into design review and verification before deployment. | ||
Key terms
- Threat Modeling: A structured way to identify where an application can be entered, abused, or misused before or during development. It maps trust boundaries, access points, and likely abuse cases so teams can design controls that match the way attackers and misuse actually happen.
- STRIDE: STRIDE is a threat classification framework that groups design risks into spoofing, tampering, repudiation, information disclosure, denial of service, and escalation of privilege. It helps teams systematically review system components and map each one to likely attack classes during design analysis.
- DREAD: DREAD is a threat scoring method that rates damage, reproducibility, exploitability, affected users, and discoverability. It is used to prioritise identified threats, but its results still depend on the consistency of reviewer judgment and the assumptions used in scoring.
- PASTA: PASTA is a seven-step threat modelling method that starts from business objectives and works through technical scope, attack simulation, and risk impact analysis. It is designed to connect technical vulnerabilities to operational and business consequences, especially for complex systems.
Deepen your knowledge
The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security and secrets management. It is designed for practitioners who need to connect identity controls to broader security architecture and operational risk.
Published by the NHIMG editorial team on August 18, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org