Most organisations that use the NIST Cybersecurity Framework treat the Identify function's Risk Assessment category (ID.RA) the same way: a yearly workshop, a spreadsheet of generic risks such as "ransomware" and "insider threat", and a self-assessment that marks ID.RA-03 as achieved because the spreadsheet exists. When someone asks which threats apply to the payments service, or why one risk is ranked above another, the spreadsheet has no answer.
CSF 2.0 asks for more than that, and NIST's own guidance says how to get there. Under ID.RA-05, the first Implementation Example reads: "Develop threat models to better understand risks to the data and identify appropriate risk responses." This post shows what a threat model gives each ID.RA outcome, then maps a real register, the ten threats from our Invoicely threat model example, to CSF 2.0 subcategories and to a Current and Target Profile.
The short version: CSF 2.0 is voluntary and outcome-based, so it never requires threat modeling, but it's the method NIST names for ID.RA-05. A threat model answers most of the Risk Assessment category. The data flow diagram supports ID.AM-03, the attack tree leaves are ID.RA-03's recorded threats, likelihood × impact scores are ID.RA-04, the ranked register is ID.RA-05, each row's treatment and owner is ID.RA-06, and re-modeling on change is ID.RA-07. Using one matrix and one register format across systems supports GV.RM-06. Map each mitigation to the Protect or Detect subcategory it achieves, and the open rows become the gap between your Current and Target Profiles. There's no CSF certification, so never call a system "CSF compliant".
Where CSF 2.0 stands on 7 November 2026
| Item | Status |
|---|---|
| Version | CSF 2.0 (NIST CSWP 29), published 26 February 2024. It's still the current version. There's no CSF 2.1. |
| Structure | Six Functions (Govern, Identify, Protect, Detect, Respond, Recover), 22 Categories and 106 Subcategories. Govern is new in 2.0. |
| Who it's for | Any organisation, of any size or sector. The 1.1 title's focus on critical infrastructure was dropped. |
| Status | Voluntary. NIST doesn't certify against it. Many US public-sector programmes, cyber insurers and supplier questionnaires use it as a common vocabulary. |
| Supporting material | Implementation Examples for each Subcategory, Informative References (mappings to SP 800-53, ISO/IEC 27001, CIS Controls and others), Quick-Start Guides and Community Profiles. NIST's work since 2024 has added to these, not to the Core. |
Two parts of the framework matter for this post. The Core is the list of outcomes, such as "Internal and external threats to the organization are identified and recorded". It deliberately says nothing about how you get there. Profiles are how you use the Core: a Current Profile records which outcomes you achieve today, a Target Profile records the ones you've chosen to achieve, and the difference is your action plan.
What ID.RA actually asks for
CSF 2.0 has ten Risk Assessment subcategories. Five of them are about understanding and responding to risk, and those are the ones a threat model answers. The wording below is NIST's. The last column is what the threat model supplies.
| Subcategory | Outcome (CSF 2.0) | NIST Implementation Example | What the threat model supplies |
|---|---|---|---|
| ID.RA-03 | Internal and external threats to the organization are identified and recorded | Use threat intelligence on likely threat actors and their TTPs; implement processes for identifying internal threat actors | Every attack tree leaf: a specific threat to a specific component, with the actor and the weakness it relies on. Insiders sit in the same tree as outside attackers. |
| ID.RA-04 | Potential impacts and likelihoods of threats exploiting vulnerabilities are identified and recorded | Business leaders and practitioners estimate the likelihood and impact of risk scenarios and record them in risk registers | A likelihood and an impact on every leaf, scored on one risk matrix by the people who know the system. |
| ID.RA-05 | Threats, vulnerabilities, likelihoods, and impacts are used to understand inherent risk and inform risk response prioritization | Develop threat models to better understand risks to the data and identify appropriate risk responses | The register, ranked by score, with the attack tree showing which single fix closes the most paths. |
| ID.RA-06 | Risk responses are chosen, prioritized, planned, tracked, and communicated | Choose to accept, transfer, mitigate or avoid; track progress in a POA&M or risk register | A treatment, an owner and a status on every row. |
| ID.RA-07 | Changes and exceptions are managed, assessed for risk impact, recorded, and tracked | Document the possible risks of making or not making each proposed change | A threat-model pass on every significant change: edit the diagram, re-score the affected branch and record the difference. |
The other five ID.RA subcategories need their own processes. ID.RA-01 (vulnerabilities in assets) is scanning and testing, ID.RA-02 (threat intelligence) is an input you feed into the model, ID.RA-08 is your vulnerability disclosure process, and ID.RA-09 and ID.RA-10 cover the integrity of what you buy and assessing critical suppliers before you buy. A threat model helps with the last two by showing which suppliers sit on a critical path, but it isn't the assessment itself.
The ID.RA-05 example is worth noticing. Out of all the Implementation Examples NIST wrote for CSF 2.0's 106 subcategories, it's the only one that names threat models. NIST puts them at the point where risk turns into priorities, not as an engineering exercise off to the side.
How the pieces map
Two connections in that picture are easy to miss. ID.AM-03 asks for maintained representations of your network communication and data flows. Most organisations answer it with network diagrams, but a data flow diagram that's updated whenever the system changes is a more useful answer, because it shows where the data goes rather than where the cables go. GV.RM-06 asks for "a standardized method for calculating, documenting, categorizing, and prioritizing cybersecurity risks". One NIST example is literally "use templates (e.g., a risk register)". If every team threat models the same way, scores on the same matrix and writes the same register columns, the register from the payments team can sit next to the one from the data platform team and be compared.
A worked example: Invoicely's register in CSF terms
Invoicely is the small invoicing SaaS from our threat model example: a web API, a PDF worker, file storage, a Stripe webhook and a support console that shares the API's database role. That post found ten threats with a STRIDE sweep, built an attack tree for the worst goal and scored everything on a 5×5 matrix. Here's the same register written for a CSF programme. ID.RA-06 is the response column. The last column is the Protect or Detect subcategory each mitigation helps achieve.
| # | Threat (ID.RA-03) | L × I (ID.RA-04) | Response (ID.RA-06) | Mitigation supports | Owner |
|---|---|---|---|---|---|
| T2 | A customer reads another customer's invoices by changing the ID (IDOR) | 4 × 5 = 20 | Mitigate: ownership checks in a shared authorisation layer, and tests that call every endpoint as another tenant | PR.AA-05, PR.PS-06 | Engineering lead |
| T1 | Credential stuffing on login | 4 × 4 = 16 | Mitigate: rate limiting, breached-password checks and two-factor authentication | PR.AA-03, DE.CM-09 | Engineering lead |
| T5 | Support console shares the API's database role | 3 × 5 = 15 | Mitigate: a separate read-only role for support, with edits routed through the API | PR.AA-05 | Head of support + platform |
| T8 | Session token readable by JavaScript | 3 × 4 = 12 | Mitigate: httpOnly, SameSite session cookie | PR.PS-06 | Engineering lead |
| T4 | Forged payment webhook marks invoices as paid | 2 × 5 = 10 | Mitigate: verify Stripe signatures and reject replays | PR.AA-03, PR.DS-02 | Engineering lead |
| T3 | Anyone with a PDF link can open the invoice | 2 × 5 = 10 | Mitigate: short-lived signed URLs that need a sign-in to regenerate | PR.AA-05, PR.DS-01 | Product + engineering |
| T9 | One customer floods the PDF render queue | 3 × 3 = 9 | Mitigate: per-account render limits | PR.IR-04 | Platform |
| T7 | Stored XSS in invoice notes | 2 × 4 = 8 | Mitigate: render notes as text and add a content security policy | PR.PS-06 | Engineering lead |
| T6 | Support console actions aren't logged | 3 × 2 = 6 | Mitigate: log every console lookup and edit, and review them monthly | PR.PS-04, DE.CM-03 | Head of support |
| T10 | A mistyped email address exposes an invoice | 2 × 3 = 6 | Accept the residual risk after T3's fix, reviewed in six months | None (accepted) | CEO |
Read down the last column and two Protect subcategories come up again and again. PR.AA-05 (access permissions, enforced with least privilege) appears on three of the top six rows, and PR.PS-06 (secure software development) on three. That's information a generic CSF self-assessment rarely produces. It tells Invoicely that its biggest gaps are authorisation in its own code, not missing tools.
T10 is the honest row. Accepting a risk is a valid ID.RA-06 response, as long as it's a decision with a name and a review date. CSF expects risk responses to be "communicated", so accepted risks should be in the register with everything else, where leadership can see them.
From the register to a Current and Target Profile
Profiles are where most CSF programmes go vague: "PR.AA-05: partially achieved". The register makes each entry specific. Here's part of Invoicely's Current and Target Profile, written from the threat model rather than from a questionnaire.
| Subcategory | Current Profile | Target Profile | Gap closed by |
|---|---|---|---|
| ID.RA-03 | Threats come from yearly penetration tests and an ad hoc list. | Every production system has a threat model with recorded threats. | The Invoicely model, then one per system. |
| ID.RA-05 | Risks are ranked by gut feel in a yearly meeting. | Risks are ranked by likelihood × impact on one matrix, and the top rows drive the roadmap. | The scored register. |
| ID.RA-07 | Changes aren't assessed for risk. | Any change to a trust boundary, data store or external integration gets a threat-model pass before release. | A pull-request checklist item and re-modeling triggers. |
| PR.AA-05 | Partially achieved: the UI checks ownership but the API doesn't, and the support console has full access. | Achieved: every invoice and PDF endpoint checks ownership, and support has least privilege. | T2, T3, T5 |
| PR.PS-04 | Not achieved for the support console. | Achieved: console actions are logged and reviewed. | T6 |
This is also where the Tiers come in. CSF 2.0 describes four: Partial (Tier 1), Risk Informed (Tier 2), Repeatable (Tier 3) and Adaptive (Tier 4). One threat model of one system, done well, is a Tier 2 practice: risk-informed, but not yet how the organisation works. Tier 3 is when the method is formally approved, used for every system and updated as things change, which is the GV.RM-06 point again. Tiers describe the organisation's practices rather than a single system, so don't claim one from one good model.
Keep it alive
- On change. ID.RA-07 is the subcategory most programmes can't evidence. Make a threat-model pass part of the change process for anything that adds a trust boundary, a data store or an integration, and keep the before and after scores.
- On new intelligence. When threat intelligence (ID.RA-02) or a new vulnerability (ID.RA-01) affects a component on the diagram, add or re-score the leaf. That's the link between those inputs and ID.RA-05's priorities.
- On a schedule. Review each model at least yearly, and take the top of the register to leadership. That's how risk reaches enterprise risk management, which GV.RM-03 asks for.
- After incidents and tests. The Improvement category asks for lessons from evaluations (ID.IM-01), from security tests and exercises (ID.IM-02) and from day-to-day operations (ID.IM-03). If an incident or a penetration test found a path that wasn't in the tree, add it and re-score the branch.
What threat modeling can't do here
- It doesn't make you "CSF compliant". There's no such thing: the CSF is voluntary and has no certification. A threat model is evidence for specific outcomes, and you still choose and document your Target Profile.
- It doesn't cover Govern on its own. Mission, risk appetite (GV.RM-02), roles (GV.RR) and policy (GV.PO) are leadership decisions. The register informs them but doesn't make them.
- It doesn't replace detection and response. Detect, Respond and Recover need monitoring, playbooks and backups that work. The model tells you which logs and recovery paths matter most, not that they exist.
- It isn't a supplier assessment. GV.SC and ID.RA-10 need due diligence on suppliers. The diagram shows where each one sits, and our guide to threat modeling third-party vendor integrations covers the risks they bring, but the assessment itself is a separate process.
A checklist for CSF 2.0 Risk Assessment with threat models
- Pick one scoring matrix and one register format for the whole organisation, and write them down (GV.RM-06).
- Draw a data flow diagram for each in-scope system, with trust boundaries, and keep it current (ID.AM-03).
- Build an attack tree for each system's most important goals, including insider paths, and record each leaf as a threat (ID.RA-03).
- Score likelihood and impact on every leaf (ID.RA-04).
- Rank the register and use it to set priorities (ID.RA-05).
- Give each row a response, an owner and a status, including accepted risks (ID.RA-06).
- Map each mitigation to the Protect or Detect subcategory it achieves.
- Write your Current and Target Profiles from the register, not from a questionnaire.
- Make a threat-model pass part of change management, and keep the before and after scores (ID.RA-07).
- Review each model at least yearly and after incidents, and report the top of the register to leadership.
Sources, as of 7 November 2026: The NIST Cybersecurity Framework (CSF) 2.0, NIST CSWP 29 (26 February 2024), NIST CSF 2.0 Implementation Examples and NIST's Cybersecurity Framework page, including its updates archive. Subcategory wording is quoted from NIST. Check your Target Profile with your compliance team.
Frequently asked questions
Does NIST CSF 2.0 require threat modeling?
No. CSF 2.0 is voluntary and describes outcomes, not methods, so it doesn't require any specific practice. But NIST's own Implementation Examples for CSF 2.0 suggest it: the first example under ID.RA-05 is "Develop threat models to better understand risks to the data and identify appropriate risk responses." It's the only Implementation Example in the framework that names threat models, and a threat model also gives evidence for ID.RA-03, ID.RA-04, ID.RA-06 and ID.RA-07.
Which NIST CSF 2.0 subcategories does a threat model support?
Mainly the Risk Assessment category: ID.RA-03 (threats identified and recorded), ID.RA-04 (impacts and likelihoods recorded), ID.RA-05 (risk understood and prioritised), ID.RA-06 (risk responses chosen and tracked) and ID.RA-07 (changes assessed for risk impact). The data flow diagram supports ID.AM-03, which asks for maintained representations of data flows, and using one scoring method across systems supports GV.RM-06. The mitigations themselves then map to Protect and Detect subcategories such as PR.AA-05 and DE.CM-09.
Can you be certified against NIST CSF 2.0?
No. NIST doesn't certify organisations or accredit anyone to certify them against the CSF. A third party can assess your Current Profile against the framework, and some customers and regulators ask for that, but the result is an assessment, not a certificate. If you need a certification, ISO/IEC 27001 is the usual route, and NIST publishes mappings between the two.
What changed for risk assessment in CSF 2.0?
CSF 2.0, published on 26 February 2024, added a sixth function, Govern, and moved risk management strategy into it (GV.RM), with supply chain risk in GV.SC. The Risk Assessment category (ID.RA) grew from six subcategories in CSF 1.1 to ten, adding outcomes for managing changes and exceptions (ID.RA-07), vulnerability disclosure (ID.RA-08), hardware and software integrity (ID.RA-09) and critical suppliers (ID.RA-10). NIST also published Implementation Examples for each subcategory, which is where threat modeling is named.
Is NIST CSF 2.0 or ISO 27001 better for a threat model?
They aren't alternatives. ISO/IEC 27001 is a certifiable management system with Annex A controls, and the CSF is a voluntary set of outcomes many organisations use to describe and report their programme. The same threat model feeds both: the register rows give evidence for ISO 27001's risk assessment clauses and for CSF's ID.RA outcomes, and each mitigation can be mapped to an Annex A control and a CSF subcategory at the same time. Our guide to threat modeling for the ISO 27001 risk register covers the ISO side.