Continuous threat modeling for platform teams in 2026

Threat Modeling Stopped Being a Quarterly Visio Session

For most of the last decade threat modeling has been a checkbox event: a senior security engineer pulls up Visio or Microsoft TMT, draws a few rectangles representing services and a few lines representing trust boundaries, runs through STRIDE, files the document in SharePoint, and goes back to the actual work. The output was a static artifact that was out of date the day it was filed and that nobody on the development team ever opened again.

That model broke for two reasons. First, the rate of architectural change in 2026 is too fast for quarterly modeling — services ship daily, sometimes hourly, and a model rendered in March is a fiction in April. Second, the AI coding era has compressed the time between “an engineer types a prompt” and “production has new code paths” to minutes. The traditional threat-modeling cadence cannot keep up with the rate at which new code reaches production.

The vendor consolidation in January 2026 made the shift official: ThreatModeler acquired IriusRisk for over one hundred million dollars, combining the two leading enterprise threat modeling platforms into a single ~fifty-million-ARR business pushing continuous, AI-assisted, SDLC-embedded threat modeling. The frame that had been emerging for two years became the consensus market direction in a single press release.

Continuous threat modeling for platform engineering is what comes next. Here is what it actually looks like in production.

What “Continuous” Means in Practice

Continuous threat modeling is not “threat modeling, more often.” It is a structurally different practice with five properties that quarterly modeling does not have:

Trigger-based, not calendar-based. The model fires on architectural change — a new service in the catalog, a new external dependency, a change to a trust boundary, a new data classification. Not on the third Wednesday of every quarter. The trigger is the diff, not the date.

Threat-model-as-code, not threat-model-as-Visio. The model lives in a YAML or DSL file in the same repo as the service it describes, alongside the OpenAPI spec and the IaC. Pull request reviews include threat-model diffs. The modeling tool reads the file, not a wiki page.

Generated, then reviewed. AI-assisted modeling tools — ThreatModeler/IriusRisk post-merger, plus open-source efforts like Threagile, Microsoft’s pytm, and OWASP’s pyTM — generate a candidate model from architecture descriptions and pattern libraries. The security engineer’s job becomes review-and-edit, not blank-page draft. Cuts modeling time by fifty to eighty percent.

Embedded in the SDLC. The model is checked at PR time, the modeling tool is part of CI, and gating policies (no merge if a high-risk threat is unmitigated) live in branch protection. Threat modeling stops being a separate workstream and becomes part of code review.

Evidence as a side effect. SOC 2 CC3, FedRAMP RA-3 / SA-15, ISO 27001 8.27, and HIPAA §164.308(a)(1) all want documented threat modeling. Continuous modeling produces documentation continuously; the auditor’s evidence request becomes a query against the model registry, not a quarterly evidence-collection sprint.

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 →

The Trigger Model

Quarterly modeling has one trigger (the calendar). Continuous modeling has many. The working trigger set in 2026:

• New service registered in the service catalog. Greenfield service → fresh model required before merge to main.
• Architecture diagram diff in the repo (architecture-as-code tools like Structurizr, IcePanel, or even Mermaid diagrams in markdown). New trust boundary or new external dependency → model update required.
• OpenAPI spec change that adds a new endpoint, especially one that crosses a trust boundary or accepts a new data classification.
• IaC change that introduces a new public-facing resource — load balancer, CloudFront distribution, public S3 bucket, public RDS endpoint.
• Data classification change on an existing dataset. PII added to a previously-non-PII table → model must update to reflect the new sensitivity.
• Dependency upgrade that crosses a major version boundary in a security-relevant library.
• Major incident related to an unmodeled threat. Post-incident review writes the threat into the model so the next instance is caught at PR time.

The triggers are concrete. The platform team’s job is to wire them into CI and the service catalog, not to remember to run the model.

Threat-Model-as-Code: The File Format Question

The single most consequential decision a platform team makes in adopting continuous threat modeling is the file format. The format determines what gets reviewed, what gets versioned, and what an agent can read and write.

Threagile uses a YAML format with a defined schema for assets, communication links, trust boundaries, and threat categories. Generates risk reports and Excel deliverables on threagile run. Strong fit for teams that already have CI familiarity with YAML; weaker on UI for executives.

pytm (OWASP) is a Python DSL for threat models. Engineers write the model as Python; the tool generates DFDs, threat lists, and reports. Strong fit for engineering-heavy teams; the Python-as-DSL model produces excellent diffs in code review.

ThreatModeler / IriusRisk (post-merger) uses a proprietary model format with import/export to standardized representations. The combined platform’s strength is the AI-assisted generation and the integration with enterprise GRC; the cost is vendor lock-in and a heavier deployment.

Microsoft TMT. Still used; weaker fit for continuous modeling because the file format is XML-based and not designed for repo-native review.

The pattern that holds for platform teams shipping daily is “threat-model-as-code” in the same repo as the service, in a format that diffs cleanly in pull requests, generated by AI assist on PR open, reviewed by security at PR review, and evaluated against gating policy at PR merge. The exact format is less important than the fact that it is in the repo and reviewed at PR time.

The Security-Agent Integration

Continuous threat modeling is the input to the security agent on the active operational layer. The model says where the threats are; the agent watches the running system to make sure those threats are actually mitigated.

Concretely, the integration looks like:

• At PR time. The threat modeling tool produces an updated model. The security agent reads the diff and surfaces threats that have new or changed mitigations: “this PR adds a new public-facing endpoint; the threat model says it should require WAF rules X, Y, Z; the security agent checks the WAF config and confirms compliance.”
• At deploy time. The agent verifies that the deployed system matches the threat model’s claims. Public buckets that should not exist, security groups that should be closed, IAM policies that should not exist — all verified continuously.
• At incident time. The agent uses the threat model to scope investigation. A reported anomaly on an endpoint with a known threat is investigated against the listed mitigations first.
• At audit time. The agent generates the SOC 2 / FedRAMP / HIPAA evidence directly from the model registry and the audit trail. No quarterly evidence sprint.

This is what closes the loop on threat modeling. The model is no longer a static document; it is a live policy that an Observe-tier agent enforces continuously, with Operate-tier remediation on reversible drift and Administer-tier escalation on irreversible policy changes.

What Continuous Threat Modeling Catches That Periodic Modeling Did Not

Three failure modes that the calendar-based model produces and the trigger-based model eliminates:

The unmodeled greenfield service. A team spins up a new service between modeling sessions; it goes to production unmodeled; the next quarterly review catches it ninety days later, after it has already accreted security debt. Continuous modeling catches it at PR time.

The drift between model and reality. A modeled trust boundary moves over the quarter as engineers refactor; the model still shows the old boundary; the auditor reads the old model; the actual environment is different. Continuous modeling forces the model to update with the architecture.

The latent threat in a refactored service. A service that was modeled two years ago has been refactored five times since; threats that were correctly mitigated in v1 may not be mitigated in v6 because the mitigation logic was removed in v3. Continuous modeling forces a re-model on architectural change, surfacing the regression.

The Three-Phase Rollout

Phase 1 — Threat-model-as-code in the repo. Pick the format. Convert one or two existing services from Visio or wiki to threat-model-as-code. Wire the AI-assisted generation tool into PR open. Two to four weeks for a representative service.

Phase 2 — CI gating and trigger expansion. Add the modeling tool to CI on the trigger set above. Add gating policy at PR merge — high-risk unmitigated threats block merge until mitigation is documented or risk is explicitly accepted by an authorized reviewer. Expand the trigger set incrementally. One to three months across a service portfolio.

Phase 3 — Security-agent integration. Wire the threat model into the active security agent. Drift between model and reality fires investigation. Audit-evidence generation runs against the registry, not against humans. The threat model becomes a live policy, not a document.

How IAN Helps

IAN’s security agent runs the Observe-tier checks against the deployed environment continuously and integrates with the threat model registry to verify that mitigations claimed in the model exist in the running system. Drift between model and reality is investigated, classified, and either auto-remediated under capability-tier policy or escalated to a human approver. The audit trail is the evidence the auditor asks for.

Because IAN sits in the active operational layer, the threat model is not a document the security team maintains separately from the rest of the operational surface. It is the input to the same agent fabric that runs cost, deployment, and incident response. The platform team gets one policy plane, one approval queue, one audit trail, and one bill.

Pricing is BYOK and usage-based. The threat-modeling integration runs against the customer’s existing modeling tool — ThreatModeler/IriusRisk, Threagile, pytm, or threat-model-as-code in any repo-native format — without lock-in to a specific format or vendor.

Get a free infrastructure audit → | See pricing →