NIST Cybersecurity Framework 2.0: what changed and how to use it

What the framework is

The NIST Cybersecurity Framework (CSF) is a voluntary, outcome-based structure for managing cybersecurity risk. It does not tell you which firewall to buy or which setting to change. Instead it describes what good looks like as a set of outcomes, and leaves the "how" to other documents, standards and your own judgement. Version 1.0 appeared in 2014 for US critical infrastructure; version 1.1 followed in 2018. Version 2.0 was released on 26 February 2024 and is published as NIST CSWP 29.

The framework has three parts. The Core is a hierarchy of Functions, Categories and Subcategories (six Functions, 22 Categories and 106 Subcategories in 2.0). Organisational Profiles describe a current state and a target state using the Core outcomes. Tiers (Partial, Risk Informed, Repeatable, Adaptive) describe how rigorous and integrated your risk management practices are.

Why it matters

CSF is the most widely referenced common language for security programmes. Boards, auditors, insurers and regulators recognise its six Functions, and many other documents now map to it: the CIS Controls, ISO/IEC 27001, NIST SP 800-53 and, since 2025, NIST’s own incident response guidance in SP 800-61 Rev. 3. If you can describe your programme in CSF terms, you can usually translate it into whatever framework a customer or regulator asks for.

Key ideas in version 2.0

• Govern is a new Function. It pulls together organisational context, risk management strategy, roles and responsibilities, policy, oversight and, importantly, cybersecurity supply chain risk management. In 1.1 these ideas were scattered across Identify.
• Scope is universal. The title dropped the reference to critical infrastructure. Version 2.0 is written for schools, small firms, charities and governments as well as utilities and banks.
• Supply chain risk is first-class. A whole Category (GV.SC) covers suppliers, from due diligence before a contract to planning for the end of a relationship.
• Implementation examples and references live online. Rather than freezing mappings in the PDF, NIST maintains Informative References and short implementation examples in an online tool, so they can be updated without a new framework version.
• Quick Start Guides target specific audiences, such as small businesses, enterprise risk managers and people creating Profiles.

What changed recently

Since the launch, NIST has kept adding companion material rather than changing the Core. Recent examples include a final Quick-Start Guide on Informative References (SP 1347), Community Profiles built on CSF 2.0 for specific sectors and technologies, and a draft guide on using AI to support CSF analysis and reporting that was open for comment in October 2026. The CSF has also been translated into many languages, including Arabic. The Cyber AI Profile work (draft NIST IR 8596) also uses the CSF 2.0 structure, which shows how the framework has become a scaffold for newer topics.

How practitioners apply it

1. Scope. Decide whether the Profile covers the whole organisation, one business unit or one system.
2. Build a Current Profile. For each relevant Subcategory, record what is actually achieved today, with evidence.
3. Build a Target Profile. Use business priorities, threats, legal duties and risk appetite to choose the outcomes you need and how strongly.
4. Analyse the gaps and turn them into a prioritised, funded action plan with owners.
5. Repeat. Revisit the Profiles after major changes or at least annually, and report progress in Govern terms to leadership.

Tip: Tiers are not maturity scores for each control. They describe the overall character of your risk management. Avoid turning them into a points system for every Subcategory.

A small IT team does not need a consultant to start. Take one Category at a time, such as asset management, and ask three questions: what outcome does the Subcategory describe, what evidence do we have today, and what would "good enough" look like for our size and risk? The answers become rows in a simple gap register.

Engineers often meet CSF through mappings. A firewall rule review, for example, supports Protect outcomes about platform security and network protection, while centralised logging (see syslog and NTP monitoring) supports Detect outcomes on continuous monitoring.

Limitations and open questions

• It is deliberately vague. Outcomes such as "assets are inventoried" do not set a level of rigour. Two organisations can both claim the same outcome with very different quality.
• It is not certifiable. There is no official CSF certificate, so assurance depends on whoever performs the assessment. Organisations that need certification usually pair CSF with ISO/IEC 27001.
• Measurement is still hard. NIST has published guidance on measurement, but there is no agreed way to score progress across organisations.
• Mapping fatigue. Many frameworks map to CSF, but mappings are approximate. Treat them as a starting point, not proof of compliance.