Nowhere Near the Threshold

A power station in Britain went dark for four days in July, and the company running it had no legal obligation to tell the government it had happened.

That second part is the story.

The Telegraph broke the news on August 22. A UK government spokesperson confirmed the incident to both The Register and Cybersecurity Dive, describing it as affecting a "small-scale energy generator" and adding that "at no point was there a risk to the wider energy system." Energy Minister Michael Shanks posted publicly that there was no threat to the wider grid, nobody lost power, and his department briefed the CEOs of multiple energy companies afterward with advice on staying secure.

Press reporting has pointed at Iran-linked actors. The UK government has not formally attributed the attack to anyone, and I'm going to leave it there. Robert M. Lee, who runs Dragos, made the point better than I can when he wrote that people jumping to conclusions on attribution are the easiest marks for a false-flag operation. It's probably Iran. Probably isn't good enough to build a board briefing on.

The detail that matters isn't who did it. It's this line, from a government source explaining to the Telegraph why the incident stayed quiet for a month:

"We have thresholds for important generators to legally notify us of cyber activity, and this site is nowhere near."

Nowhere near.

The threshold was measuring the wrong thing

The generator was too small to be regulated as important. It was not too small to be attacked, and it was not too small to stop producing electricity for four days.

Those are two different questions, and almost every regulatory regime I have worked inside conflates them. Reporting thresholds are built around aggregate systemic impact — how much does this asset matter to the grid as a whole. That's a reasonable way to allocate a regulator's attention. It is a terrible way for a company to decide how much protection its own operations deserve.

In my experience, this is where the compliance conversation goes wrong at the board level. An executive hears "we're below the threshold" or "that system is out of scope" and files it under handled. Out of scope means the regulator isn't looking. It says nothing about whether the plant runs on Monday.

I spend a chapter of Cyber Risk Is Business Risk on exactly this gap, and I keep meeting it in the field. The scoping exercise for an audit becomes the de facto security architecture. Whatever fell outside the boundary got less funding, older equipment, thinner monitoring, and no tabletop exercise — not because anyone decided it was low-risk, but because nobody was going to ask about it.

An attacker scanning the internet for exposed controllers does not have a scope document.

Four days is the number to argue about

Set aside the intrusion. Look at the recovery.

Muhammad Yahya Patel, a cybersecurity advisor at Huntress, put the right question on the table: why did recovery take four days, and are smaller operators prepared to contain and recover from this at all? Phil Tonkin, field CTO at Dragos, raised the other one — an attack this simple against a target this small is repeatable, and repeatable at scale.

Four days offline is an operations number, and it belongs to the chief executive more than the CISO.

This is the third of the three questions I put in front of executives in the book. What do we have? How are we protecting it? What happens when something goes wrong? Most boards get a version of the first two every quarter, dressed up in dashboards. The third one gets answered with the phrase "we have an incident response plan," which is not an answer. The answer is a number: how many days, for which systems, verified how recently, by whom.

If your organization has never produced that number under test conditions, then four days is not an anomaly you can feel superior about. It's a plausible outcome you haven't measured.

Why "too small to bother with" just stopped working

For twenty years, the small site's real defense was economics. Attacking it required a human being with specialized industrial-control knowledge to spend days on a target of almost no value. It wasn't worth anyone's time, so it mostly didn't happen.

Three days before the Telegraph story ran, that changed in public.

On August 19, CISA, the FBI, the NSA and other federal agencies issued joint advisory AA26-231A, warning of an active campaign against internet-exposed Siemens S7 programmable logic controllers — the small computers that physically run pumps, valves and turbines. The attackers were using AI-generated exploitation scripts disguised as legitimate monitoring software, built on the python-snap7 library, to find devices, harvest credentials and disrupt processes. The advisory names the S7-200 through S7-1500 families. Siemens told Cybersecurity Dive the advisory contains no new vulnerabilities — the techniques are new, aimed at misconfigurations the company had already flagged in July.

The agencies wrote that this is not a theoretical risk, it is an active threat. Federal advisories don't usually talk like that.

Here's what it means in business terms. When the specialized labor required to attack an obscure industrial controller collapses into a generated script, the attacker's cost of going after a small target approaches the cost of going after a large one. Every asset that was protected by being unimportant just lost its protection. Britain's NCSC put a marker down on this back in June: chief executive Richard Horne told the RUSI security lecture that more than 200 incidents affecting UK critical national infrastructure crossed his desk in the year to May 2026, roughly 75% of them linked to state actors, and that by 2028 the NCSC expects AI-enabled capability to be exploiting known flaws in legacy technology at scale.

The NCSC put that timeline at 2028. The plant went down in July.

What to ask this week

Four questions for your next conversation with your CISO or head of operations. None of them require a technical answer.

Show me the list of operational sites and systems that fall below a regulatory reporting threshold. Not the compliance scope — its inverse. That list has probably never been assembled, which is the point of asking.

For the three most important items on it, what is our measured recovery time? Measured, not estimated. If the honest answer is "we don't know," write that down and put a date on finding out.

Which of our industrial controllers are reachable from the internet? CISA's guidance in AA26-231A is unglamorous and specific: get PLCs off the public internet, replace default credentials, patch to current firmware, require multifactor authentication for remote access. If your team can't answer within a day which devices are exposed, that gap is the finding.

When we lose a site for four days, who calls whom, and what do we tell customers on day one? The UK government briefed energy CEOs after the fact. Your equivalent of that briefing should exist before the fact.

The generator that went offline in July was, by the letter of British law, unimportant enough to stay silent about. It still stopped producing power for ninety-six hours, and the only reason we're discussing it at all is that a newspaper found out a month later. Somewhere in your organization is an asset with the same profile — exempt, unmonitored, cheap to attack, and expensive to lose. Go find it before someone with a generated script does.