Threat Modeling vs Risk Assessment: Which Comes First?
Quick answer. Threat modeling maps how a system can be attacked: assets, actors, trust boundaries and attack paths. A risk assessment scores those paths by likelihood and business impact, then assigns treatment and owners in the risk register.
Video transcript
Threat models and risk registers that never reference each other leave two gaps: attack paths nobody owns, and scores nobody can trace.
A threat model maps how a system can be attacked. A risk assessment scores those attack paths by likelihood and business impact, then assigns treatment and owners.
For architecture work, model first. A risk you have not described cannot be scored with confidence. Enterprise triage can run the other way.
Then it loops. Model the paths, score each one, decide treatment and an owner. Material changes feed the model again.
Keep the attack path in the register. In Guardian's mapping, each row holds the asset, the threat event, inherent and residual scores, controls, and an owner with a review trigger.
A compromised admin key leads to an unauthorized upgrade. Bad oracle data drives wrong borrowing or liquidation. Each path gets named controls in the register.
Keepers show why the model must cross the onchain and offchain boundary. Guardian's GMX keeper review returned 55 findings, eight High, all eight resolved. It is one engagement, not an industry rate.
NIST CSF 2.0 is guidance: record threats, then prioritize response by likelihood and impact. DORA is binding EU law, applied since January 17, 2025. Confirm scope with counsel.
Read the full article, or talk to Guardian. Managed Security reviews every deployment and configuration change as it lands, with monitoring around the clock.
Why the Order Matters
A threat model and a risk register that never reference each other leave two gaps: attack paths nobody owns, and risk scores nobody can trace.
In a digital asset system, those paths cross contracts, admin keys, oracles, keepers, APIs, cloud infrastructure and third-party dependencies. Guardian
This article compares the two methods, sets their order and shows the handoff. For a full worked model, see our threat model example for a DeFi lending protocol.
Definitions in One Table
Threat modeling analyzes a representation of a system to find its security and privacy concerns. Threat Modeling Manifesto working group
The Threat Modeling Manifesto frames it as four questions: what are we working on, what can go wrong, what will we do about it, and did we do a good enough job?
A risk assessment is decision support. NIST SP 800-30 places it within risk management, giving senior leaders what they need to choose a response, such as mitigation or accepting residual risk. National Institute of Standards and Technology
| Dimension | Threat modeling | Risk assessment |
|---|---|---|
| Core question | How can this system be attacked? | Which risks matter most, and what do we do? |
| Unit of analysis | Assets, actors, trust boundaries and attack paths | Risks scored on likelihood and business impact |
| Main output | Attack paths and candidate controls | Ranked risks, treatment decisions and owners |
| Main audience | Builders, operators and security reviewers | Senior leaders and risk owners |
| Cadence | Refined continuously as the system changes | Repeated and maintained as conditions change |
Inputs and Outputs
The two methods consume different evidence and produce different artifacts.
A threat model starts from how the system is built and ends with attack paths. A risk assessment starts from those paths and ends with decisions.
Without that split, a register fills with vague rows such as smart contract risk, which no single control can answer.
| Stage | Threat modeling | Risk assessment |
|---|---|---|
| Inputs | Diagrams, roles, keys, data flows, offchain services, vendors | Modeled paths, asset values, existing controls, risk tolerance |
| Key judgment | What can go wrong, and where | How likely, and how bad for the business |
| Output | Attack paths with candidate controls | Scored risks, treatments, owners and register rows |
| Done when | Every path to funds has a control or a named gap | Every material risk has a decision and an owner |
Which Comes First
For architecture work, model first. A risk you have not described cannot be scored with any confidence.
Treatment changes the system, and material changes feed the model again. The Manifesto favors this continuous refinement over a single delivered document. Threat Modeling Manifesto working group
Enterprise triage can run the other way. NIST frames risk assessment across a hierarchy, from the organization down to individual systems. National Institute of Standards and Technology
A firm with many systems can use a high-level assessment to pick which ones deserve a deep threat model first.
Guardian's Managed Security describes this live loop: every path to funds mapped, updated in real time as the protocol changes, and multisig transactions verified before signing. Guardian
Feeding the Risk Register
The handoff fails when a register row drops the attack path. Keep the path, then add business context.
The fields below are Guardian's mapping, grounded in the NIST risk-assessment process rather than a mandated template. National Institute of Standards and Technology
For scored sample rows on a four-point scale, see our Part 500.9 risk assessment template.
- Asset: the funds, key or service the path reaches.
- Threat event: the modeled path, the attacker capability it needs and the trust boundary it crosses.
- Inherent likelihood and impact, scored before controls.
- Controls, each tied to the path step it breaks.
- Residual likelihood and impact, scored after controls.
- Treatment: mitigate, transfer, avoid or accept, with a written justification.
- Owner and due date for each open action.
- Review trigger: the system change that reopens the row.
Keys, Oracles, Signers and Keepers
Admin keys: the model traces compromised signer access to an unauthorized upgrade or transfer.
The register then records treatments such as signer separation, threshold approvals, transaction decoding, timelocks and monitored outflow limits. Our institutional signer policy covers thresholds, transaction decoding and timelocks.
Oracles: the model follows stale, manipulated or misconfigured price data into wrong issuance, borrowing or liquidation.
The matching register row names price bounds, freshness checks, fallback feeds and one owner for parameter changes. For attack mechanics, see oracle manipulation attacks.
In Guardian's public GMX Risk Oracle report, the RISK_ORACLE role could update sensitive market parameters within broad per-key bounds. Important cross-parameter checks were missing. Guardian
If the minimum collateral factor fell below the liquidation threshold, users could open positions that were immediately liquidatable. The finding, rated Low and now resolved, shows why a register row needs bounds across parameters, not just per key.
Signers: the model asks what a signer can see and approve, which API or frontend builds the transaction, and whether a compromised device can skip independent review.
The assessment then ranks the outcomes: client-asset loss, outage, regulatory exposure and recovery cost.
Keepers show why the model must cross the onchain and offchain boundary. Guardian's GMX keeper review, run from January to June 2026, is one public example.
Its scope included order execution, liquidations, funding-rate and risk-oracle executors, an HTTP API, a signed-price service and infrastructure dependencies.
The focus was keeper logic diverging from contract behavior, including pricing and risk math re-derived in TypeScript. A contract-only threat model would miss that path.
The review returned 55 findings, eight of them High, and all eight High findings were resolved. Details remain private, so this is one engagement, not an industry rate.
The DORA and NIST CSF 2.0 View
Neither framework supplies a protocol-specific threat model. Both set governance and outcome requirements that a live model and register can map into. European Union, EUR-Lex, European Banking Authority, National Institute of Standards and Technology
NIST CSF 2.0, published February 26, 2024, sets high-level outcomes for understanding, assessing, prioritizing and communicating cybersecurity risk.
It is guidance rather than law for most teams. Its Govern function (GV.RM) holds risk strategy.
ID.RA-03 calls for internal and external threats to be identified and recorded. ID.RA-05 uses threats, vulnerabilities, likelihoods and impacts to understand inherent risk and prioritize risk response.
Threat model paths are the ID.RA-03 record; register scores and treatments answer ID.RA-05 and Govern. Our NIST CSF 2.0 controls list sets out every subcategory and maps key ones to digital asset controls.
DORA, Regulation (EU) 2022/2554, is binding EU law. The EBA states it has applied since January 17, 2025.
It covers ICT risk-management frameworks, the identification and classification of ICT assets, resilience testing and ICT third-party risk.
Article 8(2) requires firms to identify all sources of ICT risk on a continuous basis. They must also assess cyber threats and ICT vulnerabilities.
Article 8(3) requires firms other than microenterprises to run a risk assessment on each major change. That covers network and information system infrastructure, and processes affecting ICT assets.
A live threat model can map each wallet, signer, contract and vendor to those duties. The register then shows how each was assessed and treated.
Which DORA provisions apply depends on legal status and jurisdiction, so confirm with counsel. Our guide to DORA for crypto companies covers scope.
Frequently Asked Questions
Is a penetration test a risk assessment?
No. A pentest checks whether specific weaknesses can be exploited within a defined scope. Its findings feed both methods: they confirm or add threat model paths and raise likelihood scores in the register. See what a web3 pentest covers.
Does NIST CSF 2.0 require a specific threat modeling method?
No. CSF 2.0 describes outcomes and does not prescribe one implementation, threat modeling or scoring method. Choose methods that give consistent, comparable results you can trace to risk decisions. National Institute of Standards and Technology
How often should the threat model and risk register be updated?
Whenever the system or its dependencies change materially: an upgrade, a signer change, a new chain, an oracle change, an incident or a material vendor change. Likelihood and impact scores rest on judgment, so rescore the affected rows each time.
How do threat assessment, risk analysis and risk management differ?
NIST defines threat assessment as formally evaluating the degree and nature of threat to an information system or enterprise. Risk analysis identifies risks, their probability and impact, and safeguards; NIST treats it as synonymous with risk assessment. Risk management is wider: frame, assess, respond and monitor. National Institute of Standards and Technology, CSRC, National Institute of Standards and Technology
Related reading
- threat model example defi
- nydfs risk assessment guidance crypto template
- defi risk management institutions
- nist csf 2 controls list digital assets
- third party risk management digital assets
Sources
- Threat Modeling Manifesto working group: Threat Modeling Manifesto
- National Institute of Standards and Technology: SP 800-30 Rev. 1, Guide for Conducting Risk Assessments
- National Institute of Standards and Technology: The NIST Cybersecurity Framework (CSF) 2.0
- European Union, EUR-Lex: Regulation (EU) 2022/2554, Digital Operational Resilience Act
- European Banking Authority: Preparations for reporting of DORA registers of information
- Guardian: GMX Keeper Review: Offchain Automation Audit
- Guardian: Managed Digital Asset Security Services
- Guardian: GMX Audits and Security Reviews
- National Institute of Standards and Technology, CSRC: Threat Assessment/Analysis - Glossary
- National Institute of Standards and Technology, CSRC: risk analysis - Glossary
- National Institute of Standards and Technology: NISTIR 4734, Foundations of a Security Policy for Use of the National Research and Educational Network
- National Institute of Standards and Technology: The NIST Cybersecurity Framework (CSF) 2.0, NIST CSWP 29
- Guardian: GMX Risk Oracle Audit Report: L-01 Missing Cross-Parameter Sanity Checks
Keep Your Threat Model Live
Guardian Managed Security reviews every deployment and configuration change as it lands. Monitoring runs around the clock, and when something fires, a Guardian engineer who knows your system responds.