How should state and local governments prioritize cybersecurity when budgets, staff, and legacy systems are all constrained?

Why constrained governments should rank cybersecurity with the same urgency as other core operations

For state and local governments, cybersecurity works best when it is treated as a service dependency for every public function, not as a separate technology project. Under budget and staffing pressure, the right question is not how to “do everything,” but which controls most reduce outage, fraud, and recovery risk across many departments at once.

The practical priority order is usually exposure reduction first, then resilience, then simplification. That means removing known vulnerabilities, tightening identity and access paths, reducing duplicated tools, and making recovery repeatable enough that a small team can execute it under stress. The CISA Known Exploited Vulnerabilities Catalog is useful because it aligns scarce remediation work with vulnerabilities that are already being abused in the wild.

Shared services matter because government IT is usually fragmented by agency, county, or district. A platform approach can lower operational load, but the real gain comes from reducing the number of exceptions teams must remember and the number of places where a misconfiguration can survive unnoticed. The goal is fewer high-risk paths, not simply fewer products.

What gets funded first when everything is under strain

The first funding decision should go to controls that reduce the chance of a common compromise and the cost of recovery. Patching, identity hardening, logging, and tested backups are not equally visible, but they are usually more valuable than discretionary upgrades because they protect multiple services at once. The most constrained environments benefit from controls that can be standardized across departments rather than customized for each one.

Identity security deserves special treatment because it is often the shortest path from one weak system to many others. Centralising privileged access, removing stale accounts, and enforcing stronger authentication for administrators usually delivers more risk reduction than buying another monitoring tool. This is where public-sector guidance on identity and zero trust is especially relevant, including NHIMG’s Public Sector Identity Security Guide, which focuses on government identity, phishing-resistant MFA, and shared identity controls.

Legacy systems should not be allowed to dictate the entire programme. If a system cannot be modernised quickly, isolate it, reduce its privileges, and plan around its failure modes. That is often more realistic than waiting for full replacement before applying meaningful control.

Where government teams need a broader operating model, the NIST Cybersecurity Framework 2.0 is helpful because it frames the work as governance, protection, detection, response, and recovery rather than as a list of isolated projects.

How to keep small teams from being overwhelmed by complexity

Under-resourced teams usually fail from fragmentation before they fail from a single technical weakness. Too many consoles, too many exceptions, and too many one-off procedures create hidden labour that steals time from the highest-value work. Simplification is therefore a security control, not just an efficiency goal.

The most useful simplification moves are to standardize patch windows, reduce duplicated identity stores, consolidate logging where possible, and make recovery runbooks short enough to execute under pressure. That also makes accountability clearer across departments, which matters when services are shared but ownership is not. NHIMG’s Indian Government Breach and United Nations Breach both illustrate how exposed credentials and misconfiguration can turn administrative complexity into a real security problem.

A platform approach is strongest when it reduces both operational burden and security variance. If the platform still leaves every department to invent its own controls, it is not really a platform, it is just a shared source of complexity. The measure of success is whether a small team can administer the environment consistently and explain, audit, and recover it without relying on heroics.

Risk and Threat Considerations

When governments defer basic security work because budgets are tight, attackers often gain time, not just access. Known vulnerabilities, exposed credentials, weak recovery processes, and overextended administrators combine into a predictable compromise path, especially where the same identity or system pattern repeats across many agencies.

Failure mechanism: A single weak control, such as an unpatched internet-facing service or a shared privileged account, can become a repeatable entry point and then a lateral movement path into more sensitive systems.

Impact: The result can be service interruption, data exposure, ransom leverage, delayed recovery, and loss of public trust, with small teams forced to restore operations while still defending the rest of the environment.

Practitioner Guidance

What to prioritise: Fund the controls that remove the most common failure paths first, especially patch management, privileged access reduction, and tested recovery. If a control does not reduce the blast radius of a breach or speed restoration, it is probably not first in line for a constrained environment.

What to verify: Make sure each major service has a named owner, a current recovery procedure, and a clear dependency map. If the team cannot show who can restore the service, how long it takes, and what identity paths it depends on, the control is not yet operational.

Practitioner takeaway: Constrained governments should optimise for repeatable risk reduction across many systems, not perfect protection of any one system; the winning strategy is to harden the shared dependencies that most affect outage and compromise.

Related resources from NHI Mgmt Group

• How should educational institutions build a cybersecurity program when budgets are tight and systems are spread across classrooms, devices, and legacy platforms?
• How should critical infrastructure operators measure cyber resilience when budgets, staffing, and legacy systems are all constrained?
• Who should own cybersecurity risk management for municipal water systems when oversight is split across local, state, and federal actors?
• How should state and local governments use SLCGP funding to build a cybersecurity plan that lasts beyond the grant period?