blakelassman.dev

Writing

80 cents on the dollar

August 26, 2026·4 min read

sledsecuritybudgets

State governments are sitting on a security problem that is hiding in plain sight. 🔍

I have been digging into where state agencies actually stand on secure software delivery, and a few numbers keep coming back up.

Start with the one everybody quotes. Federal agencies report spending roughly 80 cents of every IT dollar on operations and maintenance of existing systems, much of it decades-old technology, some of it running with known unpatched vulnerabilities. That figure is well documented at the federal level by GAO.

State-level data is thinner, and I think that is worth saying out loud rather than borrowing the federal number and hoping nobody checks. The best state-specific figure I could find is older: in a 2018 Center for Digital Government survey, 20% of state respondents said more than half their IT budget went to maintaining legacy systems. Different number, same direction, and nobody has measured it well since. The absence of current data is itself part of the story.

What we do have current data on is how state CISOs feel about it. In the 2026 NASCIO-Deloitte Cybersecurity Study, just 26% said they were extremely or very confident their state’s information assets are protected. In 2022 that number was 48%. Confidence has roughly halved in four years. And 16% reported an outright budget reduction in 2026, against zero reporting cuts in 2024.

Meanwhile the attackers moved. The 2026 Verizon Data Breach Investigations Report found vulnerability exploitation is now the number one initial access vector at 31%, having passed credential abuse at 13%. Third-party involvement in breaches reached 48%, up from 30% the year before. Unscanned code and unpatched dependencies are precisely where this is going.

What ties them together 🧵

Most state agencies are running a fragmented toolchain. Source control in one system, CI/CD in another, ticketing in a third, and a security scanner bolted onto the end that runs after code ships, assuming it runs at all.

Every seam between those tools is a place where something gets missed. Not because anyone is careless, but because nobody owns the gap. The scanner team does not own the pipeline, the pipeline team does not own the ticket, and the finding that surfaces three weeks after deploy belongs to whoever happens to read the report.

The part nobody puts in the slide deck 💸

Here is what I think actually explains the maintenance spend, and it is not inertia.

Maintenance is operating expense. It is already in the budget, it gets approved on a routine cycle, and nobody has to defend it in a hearing. Modernization is something else entirely. It needs a business case, a procurement cycle that can outlast the administration that started it, and it carries political risk if the migration goes sideways in public.

So the real choice is not “keep the old thing” versus “build the new thing.” It is “spend money nobody will question” versus “spend money that becomes somebody’s problem if it goes wrong.”

Framed that way, the maintenance share stops looking like a failure of will. It looks like a rational response to how the money works. 🤷

When I made this point on LinkedIn, Bob Henderson, an IT director, pushed back in a way that sharpened it:

Legacy technical debt is drowning our governments. It’s not in the security space, it’s everywhere else. Tools running critical systems like Medicare, EBT, DoT, and more are lingering as ticking time bombs. But getting these agencies to fund upgrades is beyond pulling teeth; it’s a ‘it works don’t fix it’.

He is right that it is not only a security story, and right that “it works, don’t fix it” is the prevailing posture. My read is that the posture is downstream of the funding structure rather than the cause of it.

What breaking through looks like

The agencies that get past this tend to do one specific thing. They stop pitching modernization as an improvement and start pricing the exposure of not doing it.

The question shifts from “what does this migration cost” to “what does another four years on an unsupported platform cost, and whose name is on accepting that risk.” That reframe moves the conversation off the IT budget and onto the risk register, and the risk register has a very different set of people reading it.

It does not make procurement faster. It does make the alternative visible, which it usually is not.

The open question 🤔

If you work in state government, or you sell into it, I am curious which one you would name as the bigger blocker.

Is it the tool sprawl itself, or is it the budget structure that keeps the sprawl in place?

I keep going back and forth. The sprawl is the visible problem. I am not convinced it is the load-bearing one.