A software failure can contribute to a cascading blackout, but the records show it as one link in a chain, not a single switch. In 2003 a silent alarm failure left operators blind while physical faults piled up. In 2015 attackers used remote access to open breakers. Both ended with power restored.
What does the 2003 North American blackout show?
On 14 August 2003 a blackout cut power to about 50 million people in eight US states and Canada, according to reporting on the official task force findings. The Register's account of the report says the alarm function in a utility's energy management system in Ohio failed silently, so control room operators did not know they were working with outdated information. While alarms were down, three high-voltage lines tripped.
The reporting describes the root of the alarm failure as a race condition: two processes gained write access to a shared data structure at the same time because of a coding error, which sent the alarm application into an infinite loop. The vendor identified the bug about eight weeks after the blackout. The software involved was compiled from about four million lines of C code.
Two points deserve emphasis. First, the software fault did not cause the lines to trip; it removed the operators' ability to notice and respond. Second, the task force made 46 recommendations, of which over a dozen concerned cybersecurity, and the vendor sent a patch to all customers of that product.
What does the 2015 Ukraine outage show?
CISA's alert says that on 23 December 2015 three regional electricity distribution companies in Ukraine suffered unscheduled outages after remote intrusions. Attackers remotely operated circuit breakers, using existing remote administration tools or industrial control client software through VPN connections, probably with credentials obtained earlier. They also wiped systems with malware and corrupted firmware on some substation devices, which CISA assesses was meant to hinder restoration. About 225,000 customers were affected, and power was restored.
This was a cyber attack against distribution companies, not a failure of the interconnected transmission system, and the harm was bounded by operators who could switch to manual control. CISA's recommended mitigations were mostly basic: asset inventory, network isolation of control systems, limited and time-boxed remote access with strong multi-factor authentication, application allowlisting, and plans to operate safely if the control system is breached.
So how plausible is a cascading blackout from software?
The honest answer is that it is possible and has precedent, and that the public record supports no probability estimate. Neither event shows a path from one bug or one intrusion to a continental failure on its own. The grid has physical protection systems, manual procedures and trained operators that act as brakes. But the records do show the weak points: loss of situational awareness, remote access paths into control networks, and software that the operators cannot see into.
Beware of confident predictions with dates or percentages. None of the sources above offers one, and a claim of that kind needs evidence the public record does not contain.
What is useful for an engineer to do?
If you build or run software that touches operational systems, the useful lesson is about visibility and fallbacks. Make failures loud: a monitoring component that fails silently is worse than none. Know every remote access path and who can use it. Keep an inventory of the software in your control systems and its vulnerabilities, so a disclosure is a lookup. Rehearse manual operation.
Dependency inventories and reachability analysis serve that inventory job in the software around operational systems. They do not replace standards, such as NIST SP 800-82 for operational technology, nor the physical safeguards in the grid.
What to do
- Inventory the software and remote access paths in any system that touches operations.
- Make every monitoring and alarm component report its own failure loudly.
- Limit remote access to what is needed, time boxed, with strong multi-factor authentication.
- Isolate control networks from untrusted networks, including the internet.
- Keep a vulnerability list for operational software, with owners and review dates.
- Rehearse manual operation and recovery at least yearly.
- Treat predictions of grid collapse with dates as claims that need evidence.
Quick check
Did a software bug cause the 2003 blackout?
It contributed. An alarm failure left operators unaware of line trips, but physical line trips were also part of the chain, according to the reporting on the task force findings.
Did the 2015 Ukraine attack take down a national grid?
No. CISA reports three regional distribution companies were affected, with about 225,000 customers losing power, and power was restored.
Sources
- The Register: Blackout bug report (8 April 2004)
- CISA: IR-ALERT-H-16-056-01, cyber-attack against Ukrainian critical infrastructure
- NIST SP 800-82 Revision 3: Guide to Operational Technology Security
Last reviewed: 18 October 2026.
