Top 5 Threat Modeling Tools for 2026: IriusRisk vs SD Elements vs ThreatModeler vs Threat Dragon vs Microsoft TMT

The short answer

Most threat modeling tool purchases fail, and they fail the same way: a platform is bought, a dozen models are built while the vendor is still onboarding you, and nothing new is modeled six months later. Threat modeling is a practice problem wearing a tooling costume. Pick accordingly.

• IriusRisk if a security team needs consistent models across a large application portfolio. Free Community Edition: three models, one user.
• SD Elements if your real driver is evidencing secure design to auditors, and you want requirements rather than diagrams.
• ThreatModeler if your architecture lives in cloud accounts and infrastructure-as-code, and you want models generated from it.
• OWASP Threat Dragon if engineers should own the models and version them in the repo. Free, Apache 2.0.
• Microsoft Threat Modeling Tool to teach STRIDE. Free, Windows only, and not a program foundation.
• Nothing at all if your team does not already hold design reviews. There is no practice for the tool to scale.

Last verified: September 2026.

The uncomfortable part: abandonment is the base case

Vendors in this category sell the diagram. The diagram was never the problem.

A 2025 USENIX Security study by Kaur and colleagues interviewed twenty-five open-source developers. It found that structured threat modeling methods were seen as introducing cost with limited perceived benefit, in teams that are decentralized and lack dedicated security expertise. That describes most product teams, not just open-source ones. The paper's title is a direct quote from a participant: threat modeling is very formal, it is very technical, and it is also very hard to do correctly.

The failure mechanics are consistent across organizations:

• No trigger. "We threat model quarterly" means the session competes with delivery work and loses. A model with no triggering event does not get scheduled.
• No owner for the output. A generated list of ninety countermeasures that lives inside the threat modeling tool is not work. Nobody is assigned to it and nothing closes.
• Models that describe last year. The architecture changed and the model did not. Once a model is visibly wrong, engineers stop trusting the exercise, and then stop attending.
• Security performs it at the team. A model produced by a security analyst about somebody else's system is a document. A model produced by the team is a decision they will defend.
• The wrong metric. Counting models created is easy and produces models created. Counting design risks remediated is harder and produces security.

What makes adoption stick

Five changes matter more than the tool choice, and all five are free.

1. Trigger, not schedule. Require a model when a design crosses a defined line: a new external interface, a new data classification, a new trust boundary, a new third-party dependency handling sensitive data. Everything else is exempt by default. This turns threat modeling from an obligation into a checkpoint.
2. Findings become tickets, with owners and dates. Whatever tool you use, the threat model's output belongs in the tracker the engineers already open every morning. This is why the issue tracker integration is the feature to negotiate hardest on, and why it is telling that IriusRisk's free tier withholds it.
3. Time box it. Sixty to ninety minutes with a facilitator and a defined scope. Open-ended modeling sessions get postponed once and never rescheduled.
4. Engineers own it, security facilitates. The team that built the system knows where the trust assumptions are buried. The security engineer's job is to ask the uncomfortable question and to know the threat taxonomy, not to produce the artifact.
5. Accept risks explicitly. A model that generates a hundred countermeasures and closes none of them teaches the team that the exercise is theatre. Decide in advance which risk levels create tickets and which are accepted with a written note, and record the acceptance.

If you cannot commit to those five, no tool on this page will change the outcome, and the cheapest honest move is to run whiteboard sessions against the OWASP threat modeling cheat sheet until you can.

Two different products are being sold here

The word "threat modeling tool" covers two designs that suit different buyers.

Diagram-driven tools (IriusRisk, ThreatModeler, OWASP Threat Dragon, Microsoft Threat Modeling Tool) start from an architecture picture: components, flows, trust boundaries. Threats attach to elements of that picture. This surfaces architecture-specific problems, such as a boundary drawn in the wrong place, and it needs somebody who can read a diagram adversarially.

Survey-driven tools (SD Elements) start from structured questions about the system: what technologies, what data, what deployment model, what regulations. Output is a prioritized set of security requirements and verification tasks rather than a diagram. This scales across a large portfolio without a security architect in every session, and it cannot see the thing specific to your architecture.

Neither is better. A regulated enterprise with two hundred applications and an audit obligation usually needs the survey-driven approach to cover the portfolio, plus diagram review for the genuinely novel systems. A platform team building one complex distributed system needs the diagram.

What changed since the last buying cycle

Three things are worth knowing before you shortlist.

• Security Compass acquired Devici in June 2025, bringing Chris Romeo's continuous threat modeling product alongside SD Elements. Devici exports in the Open Threat Model standard, which imports into SD Elements so its decision engine can generate requirements from an architecture. The devici.com domain now redirects to Security Compass. If you evaluated Devici as a standalone vendor, that is no longer the purchase.
• ThreatModeler moved and rebuilt. The company now operates at threatmodeler.ai, leads with an agentic platform called Nexus that holds FedRAMP Moderate authorization, and ships an MCP server that puts threat modeling inside AI assistants and IDEs. Peer references older than about eighteen months describe a materially different product.
• The Microsoft Threat Modeling Tool is alive, barely. Microsoft shipped GA version 7.3.51110.1 on 10 November 2025, ending a gap since the October 2023 release. It remains a free, Windows-only desktop application. Treat the update as maintenance, not as a signal that a platform is coming.

Where this sits in the application security stack

Threat modeling addresses design defects, which no scanner will ever report, because a system working exactly as specified and specified wrong looks healthy to every tool you own.

• The secure coding practices guide covers the implementation layer: the vulnerability classes a developer introduces after the design is settled, and how to verify them.
• The ASPM platform comparison covers aggregating and prioritizing findings across all your application security tools, which is where threat model output should eventually land alongside everything else.
• The SAST and code review tools comparison covers finding flaws in the code that implements the design.

Sequencing advice, plainly: if your scanning coverage is patchy or nobody triages the findings you already generate, fix that first. Threat modeling adds items to a backlog, and adding items to a backlog nobody processes is not a security improvement.

Who should not buy this category

• Teams with no design review ritual. There is nothing for the tool to make consistent. Establish the meeting first, with a whiteboard, and buy tooling when you can name the specific friction it would remove.
• Startups with one product and no security hire. A facilitated whiteboard session at each significant design change, recorded in the design document, gets you most of the value for nothing.
• Organizations whose application security basics are missing. If dependency scanning and secrets scanning are not running, those come first. Design review is a maturity-three activity and skipping to it is expensive.

How we evaluated

Last verified: September 2026.

Threat modeling tools are unusually easy to rank wrongly, because the features that demo well are not the features that decide whether a rollout survives. These are the dimensions used here, in the order they matter:

• Path from finding to owned work. Whether the tool pushes countermeasures into the issue tracker the engineers already use, or leaves them inside the tool. This is the single strongest predictor of whether a program is alive in year two.
• Who can participate. Platform support, seat limits, and licensing unit. A tool that charges per seat or excludes macOS engineers quietly turns threat modeling into a security-team activity, which is the beginning of abandonment.
• Model input. Diagram-driven, survey-driven, or generated from cloud and infrastructure-as-code. Each catches a different class of problem and misses a different class.
• Honest free-tier limits. Not whether a free tier exists, but which features it withholds, since vendors withhold the adoption-critical ones.
• Maintenance signal. Release cadence, current version, and whether the product you would evaluate today matches the one your references describe.

What we checked

Every product claim on this page comes from the vendor's own site or documentation, read in September 2026.

• IriusRisk plans page for the Community Edition limits: three active threat models, one user, draw.io interface, XML diagram export, and technical and compliance reports. The same page gives the Enterprise terms: quote only, priced by number of threat models, unlimited users, issue tracker integration, and OpenAPI access. The Community Edition page supplies the free-forever statement and the export formats.
• Microsoft Learn release notes for the Microsoft Threat Modeling Tool: GA version 7.3.51110.1 dated 10 November 2025, the preceding GA release of 26 October 2023, and the stated requirements of Windows 10 Anniversary Update or later with .NET 4.7.1.
• OWASP Threat Dragon project page for licensing, supported methodologies, and deployment modes, and the GitHub releases for version 2.6.2 dated 10 May 2026.
• ThreatModeler for the current product line (Nexus, MCP server, CloudModeler), the FedRAMP Moderate authorization claim, and the absence of any published pricing. We also confirmed that the former threatmodeler.com pricing URL now redirects to the new domain.
• Security Compass for SD Elements, and the company's own acquisition announcement for the Devici purchase in June 2025. The devici.com domain now redirects to Security Compass, which we verified directly.

For the abandonment argument we used a peer-reviewed study: "Threat modeling is very formal, it's very technical, and also very hard to do correctly": Investigating Threat Modeling Practices in Open-Source Software Projects. The authors are Kaur, Powers, Thompson, Fahl, and Votipka, and it was published at the 34th USENIX Security Symposium in August 2025. It is an interview study of twenty-five open-source developers, so it is evidence about volunteer and decentralized teams specifically. We treat it as strongly suggestive of the same dynamics in commercial teams, not as proof of them.

What we could not verify

Security Compass returns an access error to automated retrieval, so the SD Elements and Devici pricing pages could not be read directly. The Devici free-tier limits described here (three threat models, up to three users) come from the vendor's own pricing page content as indexed, and the commercial tiers are quote-based. Confirm both with Security Compass before you plan a budget.

We found no published price for SD Elements, ThreatModeler, or IriusRisk Enterprise, and we did not substitute an aggregator estimate for any of them. Where a vendor does not publish a price, this page says so.

What we did not do

We did not run these tools against a reference architecture, and this page makes no hands-on testing claims. Rankings reflect documented capability, licensing structure, free-tier limits, maintenance signals, and fit for the stated use cases.

We did not rank on the size of a rules or threat library. Every commercial vendor reports a large one, the counts are not comparable, and library size has never been the constraint on a threat modeling program.