When an auditor asks why a control was accepted, the answer is one click away.
Compliance rests on evidence: that the right controls were chosen, that someone accountable approved them, and that the record still holds a year later. ThreatModeler® Nexus™ produces that evidence as a byproduct of the design work, traced to the architecture and mapped to the frameworks you report against.
Evidence that traces to the design, and survives the turnover.
The reports are manual, and the reasoning lives in people's heads.
Demonstrating a control is in place is one thing. Showing why it was chosen, what it protects, and who signed off is harder, especially when the people who made the call have moved on.
Documentation that holds up when someone asks.
ThreatModeler Nexus is a threat modeling platform first: it shows what could go wrong in a system so you can mitigate it. The Reporting Agent turns that work into the reports compliance and risk teams need, without a separate documentation effort.
Every decision sourced
Threats, controls, and accepted risks trace to the architecture and the framework, with timestamps and version history that survive staff changes and audits.
Many frameworks, one model
Mappings to 180+ frameworks mean one threat model satisfies overlapping obligations, instead of a separate exercise for each regulation.
Human in the loop
Role-based access, approval workflows, and a deterministic framework keep accountability clear. AI accelerates the work; people approve what matters.
The regulations and standards that require threat modeling.
Threat modeling is explicitly required or strongly implied by a growing body of regulation. ThreatModeler Nexus maps every model to the specific frameworks in scope, so compliance evidence is a byproduct of the work rather than a separate exercise.
NIST SSDF 1.1
NIST SP 800-218 Secure Software Development Framework. The OMB mandate (May 2022) requires federal agencies and their suppliers to demonstrate compliance. Control SA-8 (PW.1.1) explicitly requires threat modeling as part of a secure software development process.
NIST CSF 2.0 and 800-53 rev5
The NIST Cybersecurity Framework and the federal control catalog. Both reference threat modeling as part of the identify and protect functions, with 800-53 rev5 requiring risk assessment practices that the Secure Design Graph operationalizes at the application level.
PCI DSS v4.0
Requirement 6.3.2 (software vulnerability management) and Requirements 12.3 (targeted risk analysis) require organizations to understand the attack surface of in-scope systems. ThreatModeler Nexus maps PCI DSS requirements to components and controls automatically for every in-scope application.
GDPR
Article 25 (Data Protection by Design and by Default) and Article 35 (Data Protection Impact Assessment) both require a structured risk analysis from the design stage. The Secure Design Graph models data flows and trust boundaries explicitly, so GDPR controls are placed at the design level.
FDA 524B
The US FDA's Cybersecurity in Medical Devices guidance (2023) requires device manufacturers to submit a threat model as part of premarket documentation. ThreatModeler Nexus generates submission-ready threat analysis directly from the device's design model.
HIPAA and HITECH
The HIPAA Security Rule requires covered entities and business associates to conduct a risk analysis. The Secure Design Graph maps controls to HIPAA requirements and identifies gaps before an audit or breach surfaces them.
DORA (EU)
The EU Digital Operational Resilience Act requires financial entities to perform ICT risk assessments and maintain a register of critical systems. Threat modeling integrates with DORA's requirement to identify and manage ICT risks at the system design level.
IEC 62443
The international standard for industrial control system security defines security levels (SL-1 through SL-4) and requires a security risk assessment as part of the development lifecycle. ThreatModeler Nexus supports IEC 62443 threat modeling natively, with findings mapped by security level.
FedRAMP and Executive Order 14028
EO 14028 (May 2021) mandated a zero-trust architecture and software supply chain security for federal systems. FedRAMP requires continuous monitoring and risk assessment for cloud services. The Secure Design Graph provides the application-level risk record both require.
ISO/SAE 21434 and WP.29
ISO/SAE 21434 requires a Threat Analysis and Risk Assessment (TARA) for automotive systems from concept through the product lifecycle. WP.29 extends this requirement internationally. ThreatModeler Nexus supports vehicle cybersecurity threat modeling natively, including post-market updates.
Additional frameworks: ISO 27001, NIST AI RMF, CIS CSC v8, CSA CCM v4, SOC 2, Singapore Cybersecurity Act (CII operators), IEC 81001-5-1 (health software), NERC CIP, and more.