NIST CSF 2.0 doesn't ask you to write more policy. It asks you to produce specific evidence: who has access to what, whether anyone reviewed it, and how fast you noticed and fixed it when something went wrong. A meaningful share of that evidence turns out to be identity and access data specifically, and that's the part of the framework most organizations discover they can't actually produce yet.
The whole picture, briefly: NIST CSF 2.0 is a non-prescriptive framework, a set of high-level outcomes organizations should be working toward, not a fixed list of controls. It's organized into six functions (Govern, Identify, Protect, Detect, Respond, Recover), each pointing to the kinds of practices and resources an organization can use to reach those outcomes. It's meant to apply to organizations of any size, in any sector, and it deliberately leaves the specific "how" up to you.
What this article focuses on: the framework touches everything from board-level risk strategy to incident recovery, more ground than any single tool covers. This piece narrows in on the slice that's genuinely an identity and access governance problem, specifically where that shows up inside Govern and Protect, what an IGA platform can and can't do about it, and where the rest of the framework still needs other tools and other work entirely.
The one thing to take away if you read nothing else: identity governance maps cleanly onto Identify and Protect (specifically PR.AA), and only partially, at the margins, onto Detect and Respond. Any vendor telling you one platform satisfies all six functions is overstating what that category of tool actually does.
What NIST CSF 2.0 actually is
Released in February 2024, CSF 2.0 is NIST's update to the 2014 original, broadened from a critical-infrastructure-specific framework to one meant for organizations of any size or sector. Two other changes came with that update worth knowing: expanded guidance on third-party and supply chain risk, and the elevation of governance into its own function rather than treating it as implicit.
It's not a checklist or a certification; it's a common vocabulary for organizing a cybersecurity program and communicating its maturity to a board, a regulator, or a partner running due diligence.
The framework organizes around six functions, up from five in the prior version. The addition is Govern, which sits explicitly on top of the other five and ties the whole program to business strategy, policy, and leadership accountability rather than treating security as a purely technical function.
Govern and Recover are largely strategic and planning functions. Identify and Protect, specifically, are where identity and access governance does the most direct work, and that's the focus for the rest of this article.
Where identity governance actually fits, precisely
Identify starts with an inventory you probably don't have. Before you can assess risk, you need to know what applications exist, who has access to them, and what data they hold. Most organizations' actual inventory stops at whatever's connected to their identity provider, which in a typical environment is a fraction of what's actually in use. Everything outside that boundary, shadow IT, apps a team adopted directly, tools with no owner on record, is invisible to an assessment built on an incomplete list. You can't identify risk in an application you don't know exists.
Protect is where identity governance does its most direct work, specifically under the access control piece of that function (NIST labels this sub-category PR.AA: Identity Management, Authentication, and Access Control). Least privilege, role-based access, and enforced approval workflows are what an assessor is checking for here. Access reviews also contribute evidence to Protect, not to Detect in the full sense NIST means it: a review that surfaces an inactive account still holding access, or a permission that doesn't match a role, is evidence that access controls are being maintained, which is squarely a Protect outcome.
Detect and Respond, in NIST's full sense, need more than access governance. Detect is about identifying cybersecurity events, real-time monitoring, anomaly detection at the network and behavioral level, which is UEBA and SIEM territory more than it's access review territory. Respond is about incident planning and containment once something's actually underway. Access governance contributes to both at the margins, faster deprovisioning shortens how long a compromised account stays useful, but it doesn't satisfy either function on its own, and claiming otherwise would overstate what an IGA platform actually does.
Identify and Protect are where an identity governance platform genuinely carries the evidence burden. The rest of the framework needs other tools and other work, which is worth being precise about before going further.
What an IGA platform can and can't solve
Since this article is arguing that identity governance covers a real slice of NIST CSF 2.0, it's worth being equally clear about the boundary of that slice.
What it covers well:
- Automated provisioning and deprovisioning, granting and revoking access based on role changes or HR data, rather than a manual process someone has to remember to run.
- Access certifications, periodic, evidence-backed reviews confirming people still need the access they hold.
- Segregation of duties, preventing toxic access combinations, like the same person being able to both request and approve a payment.
- Role-based access control, grouping permissions into defined roles instead of ad hoc, accumulated grants.
- Audit-ready reporting, generating the specific "who has access to what" evidence an assessor or auditor actually asks for.
- Self-service access requests, routed through real approval policy instead of email or informal asks.
What it doesn't cover:
- Real-time authentication. Logins, passwords, and MFA are an access management or SSO problem, not an IGA one.
- Privileged session monitoring. Recording or managing what an admin does inside a root-level session is PAM territory.
- Data-level security. Protecting data inside a file or database once a user already has valid access to it is a DLP problem.
- Malicious behavior detection. Catching a compromised account misusing valid permissions in real time needs UEBA, not access governance.
- Policy creation. An IGA platform enforces the access rules leadership defines. It doesn't decide who should have access to what in the first place, that's still a human, organizational decision.
Mapped back to NIST CSF 2.0 specifically: an IGA platform directly produces outcomes for Govern (identity-related policy and role clarity) and Protect, specifically PR.AA. It's a meaningful, evidence-heavy slice of the framework. It's not the whole framework, and no single tool category is.
If you check one thing before buying anything: ask exactly which NIST function and sub-category a tool claims to satisfy, by name. "Improves your security posture" is marketing. "Produces PR.AA evidence" is a claim you can verify.
Who's actually expected to align
Federal agencies and their direct contractors are the clearest case, alignment is expected, not optional, if you're part of that ecosystem. Beyond that, the framework has become a de facto reference point well outside government: healthcare, critical infrastructure, and cloud service providers use it as a structure for their security program regardless of federal ties, and it maps cleanly onto specific regulatory requirements under HIPAA, FISMA, and CMMC. If your organization handles sensitive data, critical services, or partners with entities that do, alignment is less a mandate and more the shared vocabulary you'll be expected to speak during due diligence.
Measuring where you actually stand: the implementation tiers
NIST's Implementation Tiers describe cybersecurity risk management maturity, separate from the six functions themselves. They're a useful gut check for how much of the identify/protect/detect/respond work above is actually happening versus documented as intent.
Most organizations that assess themselves honestly land at Tier 1 or 2 specifically because of the access-governance gap above: they have policies (which can look like Tier 3 on paper) but no consistent, evidence-backed process for identifying, controlling, and reviewing access (which is what actually moves the needle toward Tier 3 or 4 in practice).
How we help close the access-governance gap at Zluri
Given where identity governance actually maps onto the framework, this is the part of NIST CSF 2.0 alignment we're built to help with directly: the Identify inventory, and Protect's access-control outcomes specifically. We don't touch Govern's board-level strategy work, Recover's continuity planning, or the real-time monitoring and behavioral detection that Detect and Respond need in their fullest sense, those genuinely require other tools and other work.
Identify: discovery that doesn't stop at your IdP. Our discovery engine integrates directly with HRMS, IdPs, MDMs, and more to surface every application in use, including shadow IT, unfederated apps, and AI tools nobody formally approved, then auto-classifies them into detailed categories. That inventory is what tells you which apps hold sensitive data and need prioritized protection, the actual starting point Identify requires.
Protect: access control enforced by rule, not by memory. Once you know which applications need protection, our automation rule engine lets you define exactly who gets access and under what conditions, department, role, and more, rather than relying on someone remembering to restrict a sensitive app to the right group. A rule can specify that only finance admins get access to a sensitive financial application, for example, and enforcement happens automatically the moment the underlying conditions are met.
Protect, continued: reviews that produce real evidence, not a rubber stamp. Access Reviews shows every user with access to a given application alongside department, activity status, and role, so an inactive account holding access to a critical app is something a reviewer actually sees. When a review turns up a problem, deprovisioning or license downgrade runs through the same platform, so the fix is fast and the whole cycle, grant, review, correct, produces the audit trail Protect actually asks for.
If you're further along and want the deeper argument for why this kind of governance work, not just policy, is what actually prevents a program from failing its own goals, our piece on why IGA projects fail covers the same territory from the implementation side.
The honest takeaway
NIST CSF 2.0 alignment fails less often because of missing policy and more often because the policy describes a process that isn't actually happening: nobody has a complete inventory, access isn't consistently enforced by role, reviews are a formality, and remediation lags behind detection by weeks.
Closing that gap is what moves an organization from a Tier 1 or 2 self-assessment to something closer to Tier 3, and it's specifically an access governance problem before it's anything else.
Frequently Asked Questions
Is NIST CSF 2.0 mandatory?
For federal agencies and organizations directly contracting with the U.S. government, alignment is effectively expected rather than optional. For everyone else, it's voluntary but increasingly treated as a baseline, especially in healthcare, critical infrastructure, and any sector where HIPAA, FISMA, or CMMC requirements already point toward it.
What's new in NIST CSF 2.0 compared to the 2014 version?
The biggest change is the addition of a sixth function, Govern, which ties cybersecurity strategy explicitly to business objectives, risk appetite, and accountability. The framework's scope also broadened from critical-infrastructure-specific guidance to something meant for organizations of any size or sector.
Which NIST CSF 2.0 function is hardest for most organizations?
Identify tends to be the weakest in practice, because it depends on visibility most organizations don't actually have, a complete application and access inventory, including everything outside what's connected to the identity provider. Organizations often have Protect-adjacent controls and Govern-adjacent policy in place before they have the underlying inventory those controls should be based on.
Does an IGA platform satisfy NIST CSF 2.0's Detect and Respond functions?
Only partially, and it's worth being precise about the limit. Access reviews and fast remediation genuinely support parts of both, shrinking how long a stale or misused grant survives, but Detect and Respond in NIST's full sense call for real-time event monitoring and incident response, which is UEBA, SIEM, and incident-response territory more than identity governance. Treat IGA as covering Identify and Protect (specifically PR.AA) well, and plan separately for the rest.
Do the six functions need to be implemented in order?
No. NIST explicitly describes them as concurrent and continuous rather than sequential. In practice, though, Identify tends to be a practical starting point, since Protect, Detect, and Respond are all harder to do well without an accurate inventory to work from first.
How does NIST CSF 2.0 relate to frameworks like HIPAA or SOC 2?
NIST CSF 2.0 functions as a common reference structure that maps onto the specific requirements of regulatory frameworks like HIPAA, FISMA, and CMMC, and it aligns conceptually with certification frameworks like SOC 2 and ISO 27001. Aligning with CSF 2.0 doesn't automatically satisfy any one regulation's specific requirements, but the underlying access governance work, inventory, access control, review, and remediation, is largely the same work each of those frameworks separately asks for.
.svg)
