Written and maintained by CASRAI Editorial Board
Last updated
If your grant’s cybersecurity-plan requirement cites “the NIST Cybersecurity Framework” or “CSF 2.0,” it is pointing you at a voluntary risk-management framework, not a certification you pass or fail. That distinction matters more than it sounds: CSF 2.0 gives your research-security office a shared vocabulary and a structure for organizing cybersecurity work, but it does not, by itself, satisfy a specific grant clause the way a completed NIST 800-171 self-assessment score or a CMMC certification does. This guide walks through what CSF 2.0 actually contains, how it fits alongside the 800-171/CUI compliance work most federally funded research offices already do, and what its Protect function concretely requires at the endpoint level — the one place a software purchase genuinely helps.
The six functions of CSF 2.0 — what changed from 1.1
NIST published CSF 2.0 on February 26, 2024, the first full revision since the original framework’s release in 2014. The core structure is organized around six functions, each broken into categories and subcategories that describe specific outcomes rather than specific tools:
- Govern (GV) — new in 2.0. Cybersecurity risk-management strategy, roles and responsibilities, policy, oversight, and supply-chain risk management. This sits at the center of the other five functions rather than after them.
- Identify (ID) — understanding the organization’s assets, data, systems, and the risks to them.
- Protect (PR) — the technical and procedural safeguards that limit or contain a cybersecurity event.
- Detect (DE) — timely discovery of anomalies and cybersecurity events.
- Respond (RS) — actions taken once an incident is detected.
- Recover (RC) — restoring capabilities and services impaired by an incident.
CSF 1.1 had five functions; Govern is the structural addition in 2.0, and it is a significant one, not a cosmetic rename. Under 1.1, governance activities were folded into Identify as a single category (ID.GV). NIST split governance out into its own top-level function because organizations kept treating strategy, policy, and oversight as an afterthought to technical controls rather than the thing that should shape which technical controls get prioritized in the first place. The framework also broadened its stated scope in 2.0: the original framework was written for critical-infrastructure operators; the current version explicitly targets organizations of any size, sector, or type — universities and research institutes included. Structurally, the six functions now break down into 22 categories and 106 subcategories.
None of this makes CSF 2.0 a checklist you complete once. It’s meant to be used iteratively: an organization assesses its current profile against the six functions, defines a target profile appropriate to its risk tolerance, and works the gap between the two on an ongoing basis.
How CSF 2.0 relates to NIST 800-171 and CUI compliance
This is the part that trips up research offices that already have 800-171/CUI compliance work underway, because the two documents look similar and get cited in the same sentence, but they do different jobs.
NIST SP 800-171 is a specific, numbered set of security requirements for protecting controlled unclassified information (CUI) in non-federal systems. It’s mandatory by contract flow-down whenever a federal award requires safeguarding CUI — most commonly via a DFARS clause on Department of Defense-funded work, though other agencies increasingly reference it too. Our existing guide on NIST 800-171 and CUI in university research covers what triggers the requirement and how it’s implemented; calculating and submitting your SPRS score covers the actual self-assessment mechanics a research office has to complete against those 110 controls.
CSF 2.0 is not that. It’s a voluntary, outcome-based framework for organizing a cybersecurity program — it doesn’t hand you a numbered list of 110 controls to implement and score. Where the two connect is that NIST maintains official mapping documents (the CSF 2.0 “Informative References”) that show how CSF subcategories relate to 800-171 requirements, ISO/IEC 27001 controls, and other frameworks, so an institution that has already built its control set around 800-171 can describe that same work using CSF language for a grant narrative or a board-level report without redoing the underlying work.
The practical consequence for a grant’s required cybersecurity plan: citing CSF 2.0 to describe your program’s structure is reasonable and increasingly common, but it does not substitute for the specific compliance obligation the award actually carries. If your award requires 800-171 compliance and an SPRS score, adopting CSF language doesn’t relieve that requirement — you still need the 800-171 self-assessment. If your institution also handles CUI marking and handling procedures day to day, our CUI cover sheets and marking guide and who is responsible for CUI compliance at a university cover the operational side that CSF’s high-level categories don’t get into. For DoD-specific work, note also that CMMC is a separate, certification-based model built on top of 800-171 — again distinct from CSF’s voluntary self-assessment model. Institutions that want a broader, internationally recognized management-system standard sometimes look at ISO/IEC 27001 instead of or alongside CSF; the two overlap conceptually but are governed by different bodies and different certification mechanics.
Tip: try code CASRAI at checkout for 15% off, if the offer is currently active for this program — codes vary by vendor and aren’t guaranteed.
What the Protect function requires at the endpoint level
Of the six functions, Protect is the one with the most direct software-purchasing implication, because two of its five categories describe controls that live on individual machines: PR.PS (Platform Security) and PR.DS (Data Security), alongside PR.AA (Identity Management, Authentication, and Access Control). In plain terms, Protect’s endpoint-facing outcomes ask an organization to be able to answer questions like:
- Are workstations and servers hardened and kept current against known vulnerabilities?
- Is malicious code detected and contained before it spreads or exfiltrates data?
- Is data at rest and in transit protected against unauthorized access?
- Are access controls enforced consistently across the endpoint fleet, not just on paper?
This is the one function where a specific software product is a genuinely honest part of the answer — and it’s an honest partial answer, not a complete one. Endpoint protection software addresses PR.PS and pieces of PR.DS; it says nothing about Govern (do you have a documented risk-management strategy and assigned accountability?) or Identify (do you actually have an inventory of what needs protecting?) — that organizational and policy work has to happen regardless of what’s installed on any machine, and it needs no software purchase at all.
We’ve separately reviewed Bitdefender GravityZone for research institutions, one option in this specific category: centrally managed endpoint detection and response, patch management, and disk/data protection controls aimed at exactly the PR.PS/PR.DS territory described above. It is not a CSF 2.0 compliance product and no vendor should claim it satisfies the framework’s Govern or Identify functions — nothing sold as software genuinely can, since those are strategy and inventory work, not technical controls. If your office is specifically evaluating endpoint tooling as part of building out the Protect function, that review covers tier differences and where independent test-lab results (not vendor marketing) actually stand.
See GravityZone’s endpoint protection tiers →
Self-assessment: mapping your current tools to CSF 2.0 categories
Before buying anything, it’s worth mapping what your institution already has against the six functions — most of this table is organizational work, not procurement:
| Function | What to check | Typically requires software? |
|---|---|---|
| Govern | Documented cybersecurity strategy, named accountable owner, board/leadership reporting, supply-chain risk process | No — policy and staffing work |
| Identify | Asset inventory, data classification, risk register covering research systems and CUI-handling systems | Partial — asset-discovery tooling helps but doesn’t replace the inventory decision-making |
| Protect | Endpoint hardening/patching, access control enforcement, encryption of data at rest/in transit, security awareness training | Yes, in part — endpoint protection, patch management, identity/access tooling |
| Detect | Logging, monitoring, anomaly detection coverage across research infrastructure | Yes, in part — often the same endpoint platform or a separate monitoring tool |
| Respond | Documented incident-response plan, defined roles, communication plan, tested tabletop exercises | No — planning and process work |
| Recover | Backup strategy, restoration testing, post-incident review process | Partial — backup tooling, but the plan and testing discipline is the harder part |
A research-security office that only ever buys endpoint software and never does the Govern/Identify/Respond work has, at best, addressed one function out of six and will still fail a genuine CSF-based assessment — the framework is explicit that these functions work together, not as a menu you pick one item from.
FAQ
Is CSF 2.0 mandatory for federal grants?
No, not directly. CSF 2.0 itself is voluntary guidance; NIST does not enforce compliance with it and no standard federal grant clause requires “CSF 2.0 compliance” as a pass/fail condition the way DFARS clauses require 800-171 compliance. Some funders or institutional policies reference CSF as a recommended structure for a required cybersecurity plan, which is different from a mandate to implement it. Always read your specific award’s terms and conditions rather than assuming CSF language in a grant document means the same thing as an 800-171 or CMMC requirement.
Does CSF 2.0 replace NIST 800-171?
No. They serve different purposes and neither substitutes for the other. 800-171 is a specific, mandatory-by-contract control set (110 requirements) for protecting CUI, with a defined self-assessment scoring methodology (SPRS). CSF 2.0 is a voluntary, higher-level organizing framework for a cybersecurity program generally. An institution can and often should use both: 800-171 for the specific CUI-protection obligation a DoD-funded award creates, and CSF 2.0 as the broader structure the rest of the cybersecurity program is organized around. NIST’s own informative-references mapping documents CSF categories against 800-171 requirements precisely because institutions use them together, not as alternatives.
How long does CSF 2.0 implementation take for a university IT department?
There’s no fixed timeline published by NIST, because CSF 2.0 isn’t a project with a defined end state — it’s meant to be adopted as an ongoing risk-management practice, and a large research university’s IT/research-security function typically already has pieces of it in place (incident response plans, backup procedures, some access controls) before ever formally mapping to CSF. Realistically, an initial current-profile assessment against the six functions, done properly with input from IT, research administration, and institutional leadership, takes most offices a few months of part-time effort; building out genuine gaps (especially in Govern, which many institutions have never formalized as its own function) can take considerably longer and is better scoped as a standing program than a one-time project with a completion date.
Read the full GravityZone review →
The honest summary: CSF 2.0 is a genuinely useful way to organize and communicate about a cybersecurity program, and understanding its six functions will make you a more literate reader of your own grant’s cybersecurity-plan requirement. But it’s a framework, not a certification — adopting its language doesn’t discharge a specific 800-171 or CMMC obligation, and no single piece of software, including the endpoint tool discussed above, addresses more than one or two of its six functions. The Govern and Identify work — the strategy, the accountability, the inventory — is where most research-security offices still have the most ground to cover, and it’s entirely policy and staffing work that no vendor can sell you a shortcut through.
