Critical Infrastructure Resilience Standards for State IT Agencies

For a long time, the guiding question in critical infrastructure security was simple: which systems need protecting? Lock down the server, patch the firewall, badge the door. That's asset-centric thinking, and it made sense back when infrastructure was more siloed and systems didn't need ten other systems just to stay up.

The newer model asks a different question: which capabilities have to keep running no matter what breaks? That's function-centric resilience. Asset protection assumes a wall built high enough will hold. Function-centric resilience assumes the wall gets breached eventually and asks what happens next: does 911 dispatch still work, does the payment system still clear, does the court docket still move. It puts redundancy and contingency planning ahead of perimeter hardening, and it accepts that some component somewhere is going to get compromised.

The public-private partnership model for critical infrastructure dates back to the 1990s, and it was voluntary by design. That approach has been under strain for years, mostly because voluntary standards get adopted unevenly, and unevenness in a networked system is exactly where attackers go shopping. NSM-22 is the policy document that finally puts weight behind mandatory minimums, and it's overdue by at least a decade. For a state IT director, that reframes the whole job: the question shifts from whether assets are locked down to whether the functions residents actually depend on can survive a disruption somewhere else in the chain.

What NSM-22 actually requires and what it means for states

National Security Memorandum 22, issued April 30, 2024, is the first full rewrite of federal critical infrastructure policy in more than a decade. It replaces Presidential Policy Directive 21 from 2013, and the structural changes are not cosmetic.

The Secretary of Homeland Security, acting through CISA's Director, is now formally the National Coordinator for critical infrastructure security and resilience. For state agencies, that makes CISA the primary federal counterpart across eight sectors, including information technology, communications, emergency services, and elections. NSM-22 also requires national risk management plans to update every two years, a noticeably tighter cycle than what came before. State programs still running on a "review it every few years" habit are already behind schedule, whether they've noticed yet or not.

There's also a new classification worth knowing: Systemically Important Entities, or SIE. This tier flags infrastructure whose disruption could ripple into national security or economic stability concerns. States running systems that qualify face a heavier compliance and scrutiny load, whether they've built for it or not.

None of this makes state compliance legally mandatory today, at least not directly. But NSM-22 explicitly tells federal agencies to lean harder on procurement rules, regulatory authority, and grant conditions to push baseline standards downstream. Grant eligibility, cybersecurity funding included, is increasingly tied to showing alignment with those baselines. So while NSM-22 doesn't hand state IT directors a checklist, it sets the direction and leaves the translation work to CISA guidance and sector-specific frameworks. Which raises the obvious next question: translated into what, exactly?

The NIST Cybersecurity Framework 2.0 as the practical operating standard

The answer, in large part, is NIST's Cybersecurity Framework, still the most widely adopted governance structure across federal, state, and local government. Its risk-based, adaptable design is a big part of why it's become the default anchor for state programs that need something concrete to build against.

CSF 2.0, released in February 2024, widens the framework's scope beyond critical infrastructure specifically to apply to any organization, which settles any lingering question about whether it's relevant to a state motor vehicle department or a county health system. The framework runs on six core functions: Govern, Identify, Protect, Detect, Respond, and Recover.

Govern is the new one, and it's the function state IT leaders keep underrating. Skip it, and everything else in the framework turns into a technical exercise instead of an accountability structure; Identify, Protect, and Detect all answer to whoever owns Govern, and if nobody at the leadership table owns it, nobody owns the outcome either. It treats cybersecurity as an enterprise risk issue that belongs in the room with agency executives, with policy structures, defined roles, and accountability that reaches up past IT managers. Identify covers asset inventory and interdependency mapping. Protect is access control and platform hardening. Detect is continuous monitoring. Respond and Recover are the incident-handling and restoration functions most agencies already have some version of, even if it's an outdated one.

CSF 2.0 doesn't hand anyone a list of specific controls to install. It gives the shared vocabulary that other guidance, like CISA's performance goals, builds concrete practices on top of.

CISA's Cybersecurity Performance Goals 2.0 and what baseline compliance looks like

CPG 2.0 landed December 11, 2025, updating CISA's recommended baseline practices for critical infrastructure owners and operators, covering both IT and operational technology environments. The goals stay voluntary in name. In practice they set the floor: fall below it, and an agency becomes the exploitable weak link in a much bigger chain.

CPG 2.0 mirrors CSF 2.0's six-function structure, Govern included, so agencies already working toward CSF alignment get a fair amount of direct carryover instead of starting a second, unrelated compliance project. The problem CPG 2.0 is trying to solve is inconsistency: cybersecurity investment and maturity vary wildly across critical infrastructure sectors, and that unevenness is exactly what threat actors use to trigger cascading failures. State agencies show up repeatedly as a documented source of that inconsistency, largely because budgets and staffing vary so much county to county, state to state.

The practical focus areas include identity and access management with multifactor authentication, asset visibility across hybrid and cloud environments, logging and detection, incident response and recovery readiness, and governance documentation with actual leadership sign-off. Of everything covered here, CPG 2.0 is probably the clearest signal of what a CISA-aligned state program is supposed to look like heading into 2026.

Zero Trust Architecture mandates at the federal level and where state agencies stand

Executive Order 14028 and OMB Memorandum M-22-09 forced Zero Trust Architecture onto every federal civilian agency, covering MFA, encryption, software supply chain security, and expanded logging. Gartner projected that 60% of enterprises would treat Zero Trust as their security starting point in 2025, so the private sector is moving in roughly the same direction as the federal mandate.

State agencies have no equivalent mandate, and adoption lags accordingly. State systems connect to federal infrastructure in several ways: through data sharing, benefits administration, election systems, emergency communications. A Zero Trust gap at the state level doesn't stay a state-level problem; it's a soft spot in a system that's supposed to be federally hardened, and that's the part most state compliance conversations skip past.

Zero Trust runs on five pillars: Identity, Devices, Networks, Applications and Workloads, and Data. Line those up against the common failure points in real state ransomware incidents (misconfigured cloud storage, inconsistent identity policies, monitoring that only covers half the network) and the overlap is not subtle. The hard part is that ZTA is genuinely disruptive to implement for agencies still running legacy, on-premises systems that were never built with this architecture in mind. Moving to hybrid or cloud-native services is real interoperability work, and hybrid environments tend to widen the blind spots rather than shrink them, at least during the transition.

There's no federal mandate forcing a state ZTA roadmap into existence right now. But between the threat data and the direction grant compliance is heading, waiting for a mandate before starting is a bet against a trend that's already clear.

CIRCIA's mandatory incident reporting rule and what state agencies should prepare for

CIRCIA, passed in 2022, is the first comprehensive federal law requiring mandatory cyber incident reporting across sectors. CISA's proposed rule sets a 72-hour window for reporting a "substantial cyber incident" and a 24-hour window for reporting a ransomware payment. That's a tight clock, and it assumes an agency already knows how to classify what just happened before the clock even starts running.

The proposed rule would reach an estimated 316,244 entities across all 16 critical infrastructure sectors, and state agencies operating in covered sectors fall squarely inside that scope. CISA pushed the final rule's deadline from October 2025 to May 2026, and further slippage looks likely given funding disruptions and the agency's own implementation gaps; a GAO report from July 2024 found CISA had completed only a portion of its CIRCIA implementation requirements at that point. Slow rollout is not the same as low stakes, though: the direction of the rule is settled even if the exact start date keeps moving, and building the reporting workflow only after it becomes mandatory means building it during an actual incident, which is the worst possible time to design a process.

The prep work is easy to describe and genuinely hard to do: build internal criteria for what counts as a "substantial cyber incident" under CISA's threshold, build the 72-hour reporting workflow before it's legally required, and document ransomware response procedures with a clear chain for reporting any payment within 24 hours. A separate rule covering cyber incident reporting for federal contractors is expected to finalize in fall 2026, so agencies holding federal contracts are looking at two overlapping reporting obligations, not one.

Federal grant funding state agencies can use and the cost-sharing pressure ahead

DHS put $91.7 million into the State and Local Cybersecurity Grant Program in FY 2025, and SLCGP remains the main federal funding channel for state and local cybersecurity work. Getting the money requires a CISA-approved Cybersecurity Plan, a Planning Committee, and a Charter, so alignment with CISA's baseline standards is effectively the price of admission.

The cost-sharing math is where things get uncomfortable. The federal share caps at 60% for FY 2025 and drops further starting FY 2026. States pick up the rest, and that shift lands hardest on smaller agencies and states already running lean IT budgets: the same agencies least likely to have spare capacity for a bigger local match. That's the part of this whole stack most likely to actually break something.

Two legislative items worth tracking. The PILLAR Act would extend SLCGP through FY 2035, widen eligibility to cover operational technology and AI platforms, and expand outreach to rural and underserved communities; it passed the House in November 2025 but has stalled in the Senate. Separately, a proposed bill would restore dedicated federal funding for the Center for Internet Security and the Multi-State Information Sharing and Analysis Center, which would let state and local governments use shared cybersecurity services without paying for them directly. SLCGP's eligibility requirements are worth treating less like a funding form and more like an implementation roadmap, since the standards it demands are the same ones NSM-22 and CPG 2.0 already point toward.

Operationalizing interdependency awareness in state IT programs

Here's the part that trips up most programs, and it isn't the paperwork. It's mapping which functions genuinely count as critical, and which systems, often owned by someone else entirely, those functions quietly depend on.

IT infrastructure supporting emergency services connects into communications networks, public safety databases, and payment platforms, often through vendor relationships nobody thinks to map until something breaks. The 2025 PowerSchool breach makes the point clearly: a single vendor dependency exposed data belonging to tens of millions of students and educators, showing that a state-level impact doesn't need a state-level failure. It just needs one shared vendor with a weak spot.

So what does building this capability actually look like? Cross-agency dependency mapping comes first: figuring out which functions rely on which shared systems, and where the single points of failure sit. From there, contingency planning has to happen at the function level, because a plan focused only on restoring a single server says nothing about whether court dockets can still move while that server is down. Redundancy needs to get designed in up front rather than bolted on after an incident exposes the gap. CISA's exercise program is a genuinely underused resource here; in FY 2025 alone, it ran exercises with thousands of participants across state, local, tribal, and territorial governments and industry partners, a structured way to test interdependency assumptions before an actual incident tests them instead. Unified visibility across hybrid environments underpins all of it. Without it, an agency can't map dependencies, can't spot lateral movement, and can't coordinate recovery across systems that don't talk to each other in the first place.

Building a compliance and resilience program that keeps pace with the evolving framework

None of this sits still long enough to check a box and walk away. NSM-22 requires risk plans to update every two years. CPG 2.0 is already a revision of an earlier version. CIRCIA's final rule hasn't even locked its start date. A compliance program built around a single snapshot in time goes out of date fast, and treating any one of these documents as a finished checklist is the mistake most likely to leave an agency exposed.

The more durable approach treats CSF 2.0 as the structural backbone, since its six functions hold steady across policy cycles even as the specifics underneath them shift. CPG 2.0 works as the current-state baseline check: the most recent read on what CISA actually considers "good" right now. SLCGP requirements function as the near-term compliance floor, since they carry real funding consequences and reflect CISA's live expectations rather than last year's.

Put those three together and a state IT program has a structure that can absorb the next revision without a full rebuild. Given how often "final" rules keep sliding their own deadlines, that might be the most realistic goal on the table.