A practical, plain-language look at what shifted between NIST Cybersecurity Framework 1.1 and 2.0 — written in our own words for OT and industrial-control security practitioners, not a substitute for reading the actual published framework.
Adoption caveat: unlike NEC, NFPA 72, ASHRAE 90.1, or ASCE 7, NIST CSF is a voluntary framework, not a code adopted into legal force by a jurisdiction. Whether an organization follows 1.1 or 2.0 (or a specific sector-mapped variant) depends on internal policy, client/contract requirements, insurance requirements, or a specific regulatory framework that references it — always confirm which version any specific contract, client, or regulatory requirement actually points to before assuming 2.0 automatically applies.
| Function | Topic | Why it matters for your work |
|---|---|---|
| GOVERN | New sixth core function | A prior OT/ICS security program built against CSF 1.1's five functions is missing an explicit governance layer by CSF 2.0's structure — worth a gap review even if the underlying technical controls haven't changed, since governance documentation is increasingly what auditors and insurers ask for directly. |
| Scope | Expanded applicability beyond critical infrastructure | Smaller engineering firms and system integrators working on industrial control projects who previously treated CSF as "not written for us" should reconsider — the 2.0 framing explicitly includes them, and clients increasingly expect CSF alignment as a baseline expectation regardless of firm size. |
| IDENTIFY / PROTECT | Supply chain risk management | System integrators and vendors providing remote access or maintenance to industrial control systems should expect clients to ask more specifically about supply-chain security practices — this is one of the more consequential practical shifts for anyone in the OT vendor ecosystem, not just end-user operators. |
| Implementation | Implementation examples | Teams that found CSF 1.1's outcome statements too abstract to translate into concrete OT network or PLC-level controls now have an official companion reference to draw from — worth revisiting even for a mature program, since the examples can surface gaps the abstract language didn't make obvious. |
| PROTECT | Alignment with OT-specific guidance (e.g., NIST SP 800-82) | Industrial control and SCADA security programs that previously had to do significant translation work to map CSF onto OT-specific controls should find that translation work meaningfully reduced under 2.0 — worth revisiting existing crosswalk documentation. |
This table summarizes the structural and scope changes between CSF versions, described here in our own words. It is not a line-by-line diff of framework text and should not be used as a substitute for the official NIST publication.
CSF 2.0 added a sixth function, Govern, alongside the original five (Identify, Protect, Detect, Respond, Recover) — formalizing organizational cybersecurity governance, risk strategy, and oversight as a distinct, ongoing function rather than folding it into Identify.
A prior OT/ICS security program built against CSF 1.1's five functions is missing an explicit governance layer by CSF 2.0's structure — worth a gap review even if the underlying technical controls haven't changed, since governance documentation is increasingly what auditors and insurers ask for directly.
CSF 2.0 broadened its stated scope from being written primarily for critical infrastructure to being explicitly applicable to organizations of any size, sector, and cybersecurity maturity — including industrial and OT environments beyond the original critical-infrastructure framing.
Smaller engineering firms and system integrators working on industrial control projects who previously treated CSF as "not written for us" should reconsider — the 2.0 framing explicitly includes them, and clients increasingly expect CSF alignment as a baseline expectation regardless of firm size.
Supply chain risk management was elevated and expanded within CSF 2.0, reflecting growing recognition that OT/ICS security risk frequently originates from third-party vendors, integrators, and remote-access relationships rather than the operator's own network alone.
System integrators and vendors providing remote access or maintenance to industrial control systems should expect clients to ask more specifically about supply-chain security practices — this is one of the more consequential practical shifts for anyone in the OT vendor ecosystem, not just end-user operators.
CSF 2.0 introduced "implementation examples" for each subcategory — concrete, illustrative actions organizations might take — as a companion resource to the framework's outcome-based language, intended to make the framework more directly actionable.
Teams that found CSF 1.1's outcome statements too abstract to translate into concrete OT network or PLC-level controls now have an official companion reference to draw from — worth revisiting even for a mature program, since the examples can surface gaps the abstract language didn't make obvious.
CSF 2.0's broader framing and updated reference tools improve alignment with OT/ICS-specific NIST guidance, making it easier to map CSF functions directly onto industrial control system security practices rather than treating OT as an awkward fit for an IT-oriented framework.
Industrial control and SCADA security programs that previously had to do significant translation work to map CSF onto OT-specific controls should find that translation work meaningfully reduced under 2.0 — worth revisiting existing crosswalk documentation.
This page summarizes, in our own words, the structural and scope changes between NIST Cybersecurity Framework 1.1 and 2.0, focused specifically on what matters for OT and industrial-control security practitioners. It is an educational summary and change-awareness tool, not a compliance reference or a substitute for the official NIST publication.
Unlike a building code, NIST CSF has no fixed revision cycle and no jurisdiction that enforces it — it is a voluntary framework whose applicability depends on internal policy or external requirement (contract, insurance, or a regulatory framework that references it). CSF 2.0, published in 2024, made structural changes — most notably adding the Govern function and broadening scope beyond critical infrastructure — that are significant enough that a security program built against 1.1 is not automatically equivalent to one built against 2.0, even if the underlying technical controls are similar.
We review NIST CSF publications and summarize the changes most relevant to OT, SCADA, and industrial-control security practice on this site, in our own explanatory language — we do not reproduce NIST's publication text verbatim beyond brief, clearly-attributed references. Where our SCADA/industrial-controls content references specific CSF functions or categories, we note which version that reference is based on.
Not automatically — NIST CSF is voluntary, and whether 1.1 or 2.0 applies depends on what your organization, client, or any regulatory framework you follow specifically references. Some sector-specific frameworks and contracts still reference 1.1 explicitly and haven't been updated. Always confirm which version any specific requirement points to.
NIST publishes CSF 2.0 for free directly (nist.gov/cyberframework), including the framework core, implementation examples, and informative references. This page is a summary and change-awareness tool, not a substitute for the official publication.
No — CSF is a general-purpose cybersecurity framework applicable across IT and OT environments. For OT-specific technical guidance, NIST also publishes SP 800-82 (Guide to Operational Technology Security), which is commonly used alongside CSF to map the framework's functions onto industrial-control-specific controls.