NIST Cybersecurity Framework (CSF) 2.0, explained

NIST Cybersecurity Framework (CSF) 2.0 is NIST Cybersecurity White Paper (CSWP) 29, published 26 February 2024. It organises cybersecurity outcomes into six Functions — GOVERN, IDENTIFY, PROTECT, DETECT, RESPOND and RECOVER — each broken into Categories and Subcategories. NIST's abstract describes CSF 2.0 as a taxonomy "that can be used by any organization — regardless of its size, sector, or maturity," a deliberate break from the framework's original 2014 title, "Framework for Improving Critical Infrastructure Cybersecurity," which CSF 2.0 drops entirely.

The six Functions

NIST's text gives each Function a one-sentence definition. GOVERN is new in CSF 2.0 and is described as sitting at the centre of the other five because it "informs how an organization will implement the other five Functions":

Function	Code	NIST's definition
Govern	GV	"The organization's cybersecurity risk management strategy, expectations, and policy are established, communicated, and monitored."
Identify	ID	"The organization's current cybersecurity risks are understood."
Protect	PR	"Safeguards to manage the organization's cybersecurity risks are used."
Detect	DE	"Possible cybersecurity attacks and compromises are found and analyzed."
Respond	RS	"Actions regarding a detected cybersecurity incident are taken."
Recover	RC	"Assets and operations affected by a cybersecurity incident are restored."

NIST frames these as concurrent, not sequential: GOVERN, IDENTIFY, PROTECT and DETECT "should all happen continuously," while RESPOND and RECOVER "should be ready at all times and happen when cybersecurity incidents occur."

The 22 Categories

Appendix A of CSWP 29 breaks each Function into Categories with a two-letter-plus-two-letter identifier. Counting NIST's own Table 1 gives 22 Categories across the six Functions:

Function	Categories (identifier)
Govern (6)	Organizational Context (GV.OC) · Risk Management Strategy (GV.RM) · Roles, Responsibilities, and Authorities (GV.RR) · Policy (GV.PO) · Oversight (GV.OV) · Cybersecurity Supply Chain Risk Management (GV.SC)
Identify (3)	Asset Management (ID.AM) · Risk Assessment (ID.RA) · Improvement (ID.IM)
Protect (5)	Identity Management, Authentication, and Access Control (PR.AA) · Awareness and Training (PR.AT) · Data Security (PR.DS) · Platform Security (PR.PS) · Technology Infrastructure Resilience (PR.IR)
Detect (2)	Continuous Monitoring (DE.CM) · Adverse Event Analysis (DE.AE)
Respond (4)	Incident Management (RS.MA) · Incident Analysis (RS.AN) · Incident Response Reporting and Communication (RS.CO) · Incident Mitigation (RS.MI)
Recover (2)	Incident Recovery Plan Execution (RC.RP) · Incident Recovery Communication (RC.CO)

Each Category is further divided into Subcategories, the actual outcome statements; NIST notes their numbering is "intentionally not sequential," since gaps mark CSF 1.1 Subcategories that were relocated in 2.0. The full Subcategory list, plus the separately maintained Informative References and Implementation Examples that suggest how to achieve each one, are published through the CSF 2.0 Reference Tool on NIST's CSF website rather than frozen into the CSWP 29 text itself, so they can be updated more often.

Profiles and Tiers: two different axes

CSF 2.0 keeps these as distinct concepts that are easy to conflate:

• Organizational Profile — describes which outcomes you pursue. A Current Profile states what you do today; a Target Profile states what you are aiming for. NIST notes a Target Profile "can help express the organization's cybersecurity risk management requirements and expectations to suppliers, partners, and other third parties."
• Community Profile — a shared Target Profile baseline for "a particular sector, subsector, technology, threat type, or other use case," published so individual organisations do not start from a blank page.
• Tiers — describe how rigorously you pursue them, independent of which outcomes you picked. NIST defines four: Partial (Tier 1), Risk Informed (Tier 2), Repeatable (Tier 3) and Adaptive (Tier 4), a "progression from informal, ad hoc responses to approaches that are agile, risk-informed, and continuously improving." NIST is explicit that Tiers "should complement an organization's cybersecurity risk management methodology rather than replace it."

Is it mandatory, and who is it for

CSF 2.0's own text calls it "a foundational resource that may be adopted voluntarily and through governmental policies and mandates" — it carries no universal legal force on its own, but a specific regulator, customer contract or procurement rule can choose to require conformance with it. NIST states the primary audience is "individuals responsible for developing and leading cybersecurity programs," while noting the framework is also meant to be legible to "executives, boards of directors, acquisition professionals ... risk managers, lawyers, human resources specialists." Unlike the 2014 original, CSF 2.0 explicitly targets organisations of "all sizes and sectors — including industry, government, academia, and nonprofit," not just operators of critical infrastructure.

Why GOVERN and the supply-chain Category matter for device and firmware teams

The GV.SC (Cybersecurity Supply Chain Risk Management) Category is new to the Core structure in CSF 2.0 and, per NIST's text, provides "a connection between outcomes that focus purely on cybersecurity and those that focus on C-SCRM," pointing to NIST SP 800-161r1 for the detailed practice. For a device or firmware maker, this is the Category that should absorb supplier due diligence: chip-vendor SDKs, ODM-built images, and open-source components you did not write yourself. It sits alongside, rather than replaces, the specific technical work of a firmware SBOM or an OpenSSF Scorecard check against a dependency's repository — CSF organises why and how you govern that risk; the SBOM and Scorecard are evidence you can plug into the IDENTIFY and GOVERN outcomes.

RESPOND and RECOVER map onto the operational side of a PSIRT: incident analysis, mitigation, and the reporting and communication Category (RS.CO) are the same activities covered by a vulnerability disclosure policy and a CRA 24-hour reporting process, if your product is in scope of the EU Cyber Resilience Act. No regulation known to us at the time of writing names CSF 2.0 conformance as a direct legal requirement for device makers; treat any such claim as to be confirmed against the specific regulator or customer contract involved.

A workable starting point

1. Start with a Current Profile, scoped narrowly — one product line or one business function — rather than attempting an organisation-wide profile on the first pass.
2. Use GOVERN to set the frame before filling in the other five Functions. NIST places it centrally for a reason: without a stated risk strategy and named authorities, the other Functions have nothing to prioritise against.
3. Pick a Tier honestly, not aspirationally. A Tier 1 (Partial) organisation that knows it is Tier 1 can plan a realistic path to Tier 2; one that claims Tier 3 without the repeatable process behind it gains nothing.
4. Reuse a Community Profile if one exists for your sector instead of building a Target Profile from zero.
5. Treat GV.SC as the anchor for supplier and component risk, and feed it with the SBOM, VEX and Scorecard evidence you already produce.

SoftWSP's firmware and vulnerability-handling work maps most directly onto the IDENTIFY, PROTECT and RESPOND Functions of CSF 2.0: see device firmware security and PSIRT as a service.

This guide summarises the public NIST CSWP 29 text; it does not constitute legal or compliance advice.