Ever since the Hugging Face attacks were reported, I’ve been very concerned about the threat that bot swarms pose to the North American power grid. My concern only grew when I read that a swarm of 10,000 OpenAI agents had solved the over century-old Navier-Stokes mathematical problem in 88 hours, as well as when (as described in the post I just linked) I read about the amazingly painstaking work that the 700 or so bots that attacked Hugging Face had performed in order to break through the Captcha that protected the site. It seemed (and still seems) to me that, given enough bots and a little time, there is no task that a bot swarm can’t accomplish, with the caveat that they can’t accomplish a task that’s impossible for bots, such as building a house.
I initially thought (or perhaps hoped) what would at least slow the bot swarms down was the fact that the US power grid (and to some extent the Canadian grid) is incredibly diverse. It is owned and operated by literally thousands of different entities; each one decides for itself what equipment and software it will use, and when and where it will deploy it.
In fact, even within one large electric utility, there could easily be thousands of different types of control systems from different vendors, installed in different locations at different times and with different software and firmware versions. I figured that, if the bots have to comb every nook and cranny of the internet to find information (like product name, version number, and vulnerabilities that affect a product and version number) that is essential for an attack, that will make it much harder (and in some cases impossible, if the information has been very well guarded) to launch an effective attack.
But I recently realized that it’s almost trivially easy for bots to gather information on at least some of the most important control systems they want to attack. They just need to do what lots of humans do nowadays: ask a chatbot. Those bots seem to know an awful lot about some very important systems that are monitoring and controlling the grid. Bot swarms don’t have to discover all that information for themselves; they can just ask their neighbors in botland.
Note: The fact that the bots even had access to that information shows that the current NERC CIP controls on storage or use of “BES Cyber System Information” – BCSI – in the internet are very inadequate. That point was made very eloquently by a good friend in this post that he wrote and I published recently. I think the BCSI requirements should be rewritten to reflect the facts that a) there is already lots of BCSI available on the internet (which shouldn’t be tolerated), and b) it’s impossible for any NERC entity to prevent any more of their BCSI from becoming available. In other words, the BCSI requirements need to focus on risk mitigation, not risk elimination. The latter goal can never be realized.
However, there is something that I have always (until this year) considered to be a literally insurmountable barrier to any far-reaching cyberattack on the North American grid (or even on one of the four electrically separate Interconnects that constitute “the grid”): the fact that the NERC CIP cybersecurity standards ensure that the most important systems that monitor and operate the Bulk Electric System (called high and medium impact BES Cyber Systems) are well protected from cyberattacks; this is primarily because those systems are painstakingly separated from the internet. I know of no practical way that even a huge bot swarm could break into enough of these systems to cause any outage, let alone a widespread or prolonged outage.
Now the question becomes: Given that a cyberattack on high and medium impact systems is highly unlikely to produce any outage, could an attack on other systems that operate the grid do that? These “other systems” include the tens of thousands of low impact systems that are subject to CIP compliance (but with much less stringent requirements than the highs and mediums), as well as the hundreds of thousands of systems that distribute power to residential, commercial and industrial users – which are completely outside of NERC’s and FERC’s authority.
Of course, since these other systems are individually not very impactful, an attack on any one of them will not affect the grid at all, even though it might produce an outage in a local area like one neighborhood in a city. Outages like that happen all the time, usually due to storms or even squirrels (note there is no record of a cyberattack on electric power control systems ever causing an outage in North America). Even if someone attacked 1,000 “other” systems – that operate in smaller generating stations, low voltage distribution substations, and small grid control centers – during for example the course of a single day, those attacks alone wouldn’t impact the Bulk Electric System (BES), even if they caused some local outages.
However, the picture changes if we talk about simultaneous attacks on a large number of small systems. In this post, I described at a high level how a large swarm of bots might collaborate to plan and carry out near-simultaneous cyberattacks on many small power facilities in one region; that might cause instability in the grid in that region.
This instability could in turn cause some larger generation facilities to shut down. It might also bring about a problem that has just appeared in the last few years: grid instability could cause a lot of data centers to drop off the grid and go on backup power, which could lead to further instability and more generators and data centers going off the grid, etc. etc. This is a problem because at every moment in every part of the grid, power supply must almost exactly match power demand (called “load”). If they don’t match, the frequency at which the grid operates will vary from the optimum (60 hz in North America and 50 hz in Europe) in one direction or the other. Even a tiny deviation from the optimum can lead to major equipment damage, blackouts or both.
In fact, this problem has led to three incidents in Northern Virginia (the Saudi Arabia of data centers) in which momentary grid instability caused many data centers to leave the grid. The resulting imbalance between supply and load led to serious instability.
The first two times this happened, in 2024 and 2025, less than two gigawatts of load was lost. This is a big amount, but in both of those cases, the operator of that portion of the grid, PJM, was able to fix the problem very quickly. However, when the same problem occurred this year, over three GW of load was lost, and it took PJM ten minutes to stabilize the grid. Since even a few seconds of grid instability can cause serious problems, this was an eternity. What will happen in the next incident? NERC has taken some emergency measures, including developing standards that apply to data centers, but we won’t know whether they’re working until they don’t.
In other words, even though a bot swarm might attack a lot of the most important assets attached to the grid simultaneously, it’s very unlikely there would be any impact on the operation of the grid at all; in fact, it’s unlikely that any of those assets would even be penetrated, let alone disabled. But we can’t say the same about a simultaneous attack by a bot swarm (perhaps 10,000?) on a large number (perhaps thousands?) of smaller grid assets. It’s possible that this attack could set off a “cascading” grid disturbance like the one described, even if only a small percentage of the assets attacked are disabled.
How can we (meaning the power industry) prevent a bot swarm from carrying out attacks like this? The answer is easy: We can’t. Moreover, neither OpenAI nor Anthropic – the ones who can do it - has expressed any willingness to take steps on their own to prevent this, such as deliberately limiting the capabilities of new models. Each will only do that if the other moves first, which means nothing is going to happen, at least for a while.
Thus, the only good solution to this problem is to prepare for the onslaught, meaning the defenses of NERC CIP low impact facilities and non-CIP distribution facilities (control centers, substations and power plants) need to be beefed up. I’ll collectively refer to these as “low facilities”.
One way to do this is to require owners or operators of low facilities to abide by the same cybersecurity regulations as the owners or operators of high and medium impact CIP facilities. But that’s a non-starter, for the simple reason that most of these facilities will be uneconomical to operate if they must do that. What’s Plan B?
My Plan B is based on the idea that the only certain way to prevent one or more bots from penetrating a grid facility is to insert a human into the loop. That is, any human or bot that wants to connect remotely to a certain grid system (say, a small hydroelectric plant) – or a group of systems at a single facility - will need to convince another human being that they are not only a person, but a person who should be allowed to access that system. Here are some of my ideas:
1. Suppose Person1 wishes to connect remotely to a system (or group of systems) at a low impact generating facility (say, a 5MW hydroelectric dam in the Sierras). Person1 will utilize a simple client (telnet?) on a computer to connect to the IP address of the low facility. They will be greeted by a simple (and inexpensive) dedicated device (which I will call “the Device”). This will prompt them to enter a code. It will also display a “session ID” like “C2”. The Device will increment the session number with every new session.
2. The Device will send a text to Person2, who will be either onsite at the low impact facility or remote. Person2 will usually work for the company that owns the facility, but they could also work for a trusted third party engaged by the company. Person2 might or might not be onsite at the grid asset (of course, onsite is better, but low facilities are often unmanned). The text sent by the Device to Person2 will be a code (perhaps eight digits).
3. Note that the device will only text with one Person2. If another Person2 needs to be involved because of an increase in the volume of incoming connections, a second, separate Device will be needed (this is another reason why the Devices need to be inexpensive).
4. Along with the code, the Device will also text the Session ID to Person2. While in theory this shouldn’t be necessary, it’s a belt-and-suspenders measure to keep Person2 from confusing multiple instances of this process.
5. Meanwhile, when Person1 receives the prompt to enter the code, they will text a pre-agreed authentication message to a dedicated “incoming” cell phone used by Person 2. The text will consist of the message plus the session code.
6. If Person2 deals with a large number of Person1’s (i.e., remote users of a system at the low facility), they will maintain a simple Directory computer, not connected to the internet or any other system. The only software running on that computer will be a simple database package that will list the name of the approved remote user, their pre-arranged authentication message, and their personal cell phone number (in case there is an issue that needs to be discussed). There could also be an email address for each remote Person1, although email should never be used to send codes or discuss this methodology. Whenever someone is no longer allowed to access the system in question, they need to be removed from the Directory.
7. When Person2 receives the text from Person1, they will verify the phone number is listed in their Directory with the same text string sent by Person1. Then they will text the code, using a dedicated “outgoing” cell phone, to the number from which Person1 texted their incoming phone (of course, this will require manually entering the incoming number on the outgoing phone. In fact, Person2 shouldn’t maintain a directory on either dedicated phone).
8. Upon receiving the text from Person2, Person1 will enter it where prompted on their computer screen. If the Device rejects the code for any reason, Person1 will have to restart the process from the beginning.
9. New sessions will be provisioned for a fixed amount of time, perhaps one hour or 30 minutes. If Person1 is in the middle of their session and sees the need to extend it, they will text Person2 to request the extension. Person2, if they agree with the request, will message the Device (using a connection other than the internet, e.g. a cellular modem installed in the device) ordering the extension. This can be done many times, if the remote access policy of the company that owns the low facility allows it.
10. Sometimes, a remote user (perhaps a vendor technician troubleshooting a problem) will need a connection to remain open for an extended period of time. Of course, that will be possible if the company’s policy allows it. However, the remote user will need to text a special message to Person2 at regular intervals (perhaps every two hours) to keep the connection open.
Tom Alrich’s Blog, too is a reader-supported publication. You can view new posts for three months after they come out by becoming a free subscriber. You can also access all of my 1300 existing posts dating back to 2013, as well as support my work, by becoming a paid subscriber for $30 for one year (and if you feel so inclined, you can become a founding subscriber for $100). Whether free or paid, please subscribe.
If you would like to comment on what you have read here, I would love to hear from you. Please comment in my chat or email me at [email protected].