After ThreatModeler bought IriusRisk: the 2026 enterprise threat-modeling decision

The Threat-Modeling Market Just Consolidated

On December 30, 2025, ThreatModeler closed its acquisition of IriusRisk for over $100 million, combining the two largest enterprise threat-modeling platforms into a single category leader at roughly $50M combined annual recurring revenue. The combined company is majority owned by Invictus Growth Partners, with Paladin Capital Group — IriusRisk’s longstanding investor — remaining a shareholder. The deal was announced January 8, 2026 and is positioned as a response to the AI-coding-era inflection in application security: the velocity of code generation has outrun the cadence of traditional threat modeling, and consolidation is meant to fund the AI-native rebuild.

The deal matters to buyers in three ways. First, organizations running both products in parallel — a pattern that was historically common because IriusRisk’s strength in developer-and-architect adoption complemented ThreatModeler’s strength in security-architect and enterprise-governance scenarios — face a forced procurement decision. Second, organizations mid-evaluation between the two now have one vendor to evaluate against the alternatives, not two. Third, organizations that were comfortable with the prior duopoly’s pricing dynamics should expect the consolidated vendor to revisit pricing power on the next renewal cycle.

This is the second major application-security consolidation in the post-2024 wave (after the cloud-security-posture-management roll-ups and the application-security-testing roll-ups that ran through 2023-2024) and the first in the threat-modeling sub-category. The pattern at this stage of the cycle is predictable: consolidation, integration burden, a window of customer goodwill while the integration ships, and a renegotiation cycle eighteen months later.

What Changes for Buyers in 2026

Three things that were stable in the 2024-2025 buyer experience need re-evaluation:

• Product roadmap alignment. The combined platform has stated its direction: a unified AI-driven threat-modeling product that pulls forward IriusRisk’s developer-engagement model and ThreatModeler’s enterprise-governance model. The migration path for existing customers of either product is the variable. Customers who built workflows around one product’s specific surface should ask, in writing, what the migration timeline looks like and what gets deprecated.
• Pricing power on renewal. The combined entity has the largest install base and the strongest enterprise distribution in the sub-category. Renewal pricing is the lever the new ownership will pull first. Buyers with significant existing spend should expect to push back harder than they did with either standalone vendor.
• Substitute path. The clear substitute path is the code-native security category — Snyk, GitHub Advanced Security with Copilot Autofix, Endor Labs, Semgrep — which operates one layer down from threat modeling but increasingly absorbs threat-model-style outputs as a side effect of code analysis. The substitute path is not a one-for-one replacement, but it is a credible alternative for teams whose threat-modeling spend was already adjacent to their code-security spend.

The decision frame for the 2026 buyer is whether to lean into the consolidation, pivot to a code-native alternative, or build a thinner LLM-assisted threat-modeling capability internally and free up the spend.

The Three Realistic Paths

Path 1: Stay on the combined ThreatModeler-IriusRisk platform. This is the lowest-friction path for organizations whose threat-modeling discipline is mature, whose security-architect headcount is meaningful, and whose compliance posture (PCI, HIPAA, FedRAMP, regulated-industry overlays) requires the formal threat-model artifacts the platform produces. Negotiate the renewal aggressively, get the migration path in writing, and use the eighteen-month integration window as leverage. Expect the consolidated product to deliver better AI-assisted threat generation than either standalone product did, on the timeline the combined company is publicly committing to.

Path 2: Pivot to a code-native security alternative. This is the right path for organizations whose threat-modeling spend was driven primarily by an AppSec-team requirement that turned into a quarterly box-checking exercise rather than a continuous discipline. Snyk’s threat-modeling features, GitHub Advanced Security with Copilot Autofix, Endor Labs’ supply-chain-and-architecture analysis, and Semgrep’s rule-based pattern detection cover much of the same ground at a fraction of the cost, with the side effect of running continuously inside the developer’s existing IDE and CI rather than as a separate ceremony. The trade-off: less formal artifact production, less explicit STRIDE / PASTA / LINDDUN methodology surface, less polish in the executive-facing reports. For most non-regulated industries this trade-off is worth it.

Path 3: Roll your own with LLM-assisted modeling. The 2026 LLM landscape is good enough that a thin in-house threat-modeling capability — a small library of standardized diagrams, an LLM-driven analysis layer that walks the diagram and identifies STRIDE-class threats with severity and mitigation, a CI integration that re-runs the analysis on architecture changes — is a build-not-buy decision a senior security engineer can ship in a quarter. The advantages are obvious: zero vendor risk, zero per-seat costs, full customizability, integration with the team’s existing chatops and ticketing. The disadvantage is meaningful: someone has to own the system, maintain the prompt library, calibrate for false positives, and produce the audit-friendly artifacts that compliance asks for. For organizations with a mature security-engineering team and a tolerance for owned tooling, this is increasingly the right path.

The decision is not “one of three” — most organizations will end up running some hybrid. The discipline is to be explicit about which workloads belong on which path rather than defaulting to the consolidated vendor for everything because that was the historical default.

See the IAN team run on your cloud. We connect to your AWS account via a scoped read-only role, run the Observe-tier agents, and leave you with a concrete audit report — cost waste, security exposure, compliance gaps, and a labor-offset estimate. You keep the findings regardless of next steps. Get a free infrastructure audit →

Procurement Considerations Post-Consolidation

Five things to ask the consolidated vendor explicitly during the next renewal cycle:

• Combined-product migration timeline. When does the unified platform reach feature parity with both legacy products, and what specifically gets deprecated at that point? Get the answer in writing and tied to a date.
• Per-seat economics on the new platform. The pricing surface was different across the two legacy products. The combined vendor will normalize, and the normalization will not be neutral. Ask for the new pricing model up front and model the next two renewals against it.
• Data export and portability commitments. If the migration goes badly, can you export your threat models, your standard library, your custom methodology in a format that another vendor — or an in-house tool — can ingest? The combined vendor’s answer here predicts the renewal leverage in eighteen months.
• AI feature roadmap and price exposure. AI-assisted threat generation is the consolidated company’s stated direction. Is AI capacity included in the existing seat price, charged separately, BYOK, or all three? The structural answer matters more than the specific quote.
• Compliance artifact compatibility. If your compliance auditor accepted the legacy product’s reports, will they accept the combined product’s? Run this past the auditor before signing rather than after.

How AI Coding Changes the Threat-Modeling Cadence

Threat modeling was historically a quarterly or per-major-release exercise because drawing a meaningful threat model took an expert architect days, and revising one took comparable effort. AI-assisted code generation broke this cadence in two ways. First, the rate of architectural change accelerated — features that used to ship in weeks now ship in days, which means the architecture diagram the security architect was working from is stale by the time the threat model is reviewed. Second, the surface area of code that needs threat modeling grew — not because the code is doing more, but because the LLM is generating more of it, and an LLM-written component is no more inherently safe than a hand-written one.

The combination forces a re-evaluation of cadence. Quarterly threat modeling against a code base that turns over weekly is theatrical. The 2026 pattern that works is continuous threat modeling — every meaningful pull request gets a delta threat-model assessment, every architectural change re-triggers the relevant threat-model sections, every newly-introduced trust boundary gets a model on the same cadence as the code that introduced it.

Continuous threat modeling is the discipline; the question is whether the consolidated vendor is the right system of record for it, or whether a thinner code-native or roll-your-own system fits the cadence better. The answer is organization-specific, but the question is the right one to ask in 2026.

How IAN Helps: The Security Agent for the AI Coding Era

IAN is the AI DevOps team for cloud infrastructure, delivered as a coordinated team of specialized agents. The security agent is one of those agents and is built for the continuous-threat-modeling cadence rather than the quarterly-ceremony cadence.

The security agent runs the Observe-tier checks continuously: configuration audits against AWS, GCP, and Azure; IAM exposure detection; secret-scanning across connected repos; drift detection against the customer’s defined posture; and architectural-trust-boundary analysis on every meaningful pull request. Findings post to the team channel and to the immutable audit trail. The Operate-tier actions — drift remediation PRs, IAM tightening on out-of-policy resources, automated secret revocation — run when in policy and reversible, and gate to a human approver otherwise. The Administer-tier actions — modifying the security posture itself, changing approval policies, adding or removing connected accounts — always require explicit approval.

The security agent is not a replacement for a formal STRIDE / PASTA / LINDDUN threat-modeling tool, and we say that explicitly. It is a complement: the agent runs continuously against the running infrastructure and the active code base, catches the operational and configuration exposures that historically slipped between threat-model reviews, and posts the audit trail that maps back to the formal threat-model artifacts when the auditor asks.

For organizations choosing Path 2 or Path 3 above (code-native or roll-your-own), the security agent is the operational complement that fills the run-time gap. For organizations choosing Path 1, the security agent runs alongside the consolidated vendor and reduces the burden on the formal threat-modeling discipline by surfacing the operational issues that don’t need to flow through a formal model.

Pricing is BYOK and usage-based with a monthly minimum. Customers bring their own model keys and pay inference costs directly to their model provider. IAN charges for the orchestration layer per agent action, per connected cloud account, per operation class.

The Three-Phase Rollout

Phase 1 — Decide which path the organization is on. Run an honest internal review against the three paths above. Get the security architect, the head of platform, and the AppSec lead aligned in writing. Two-to-four weeks of structured decision-making; the discipline is more important than the speed.

Phase 2 — Stand up continuous threat-modeling primitives. Whichever path is chosen, the underlying primitive is the same: every meaningful pull request gets a threat-model delta, every architectural change re-triggers the relevant model sections, every newly-introduced trust boundary gets a model. Wire this into the CI pipeline and the chat-ops surface. Two-to-six months depending on the path.

Phase 3 — Layer the security agent on top. Connect IAN’s security agent to the cloud accounts and the source repos. Configure capability tiers and approval gates. Let the agent run the Observe-tier checks continuously and the Operate-tier actions when in policy. Tune the auto-vs-gated boundary over the first quarter and let the audit trail accumulate enough data to make the next round of policy tuning a data exercise.

The compound: by the time Phase 3 lands, the threat-modeling discipline is continuous rather than ceremonial, the operational complement is automated, and the procurement leverage on whichever path was chosen in Phase 1 has improved because the team has options instead of a single dependency.

Get a free infrastructure audit → | See pricing →