You cannot patch your supplier's plant
On 19 August the NSA, CISA, the FBI, the Department of Energy and the EPA published a joint advisory, Defending Against an Active Threat to Siemens S7 Series PLCs. Someone is systematically hunting for Siemens programmable logic controllers that can be reached from the internet, and using AI to write the code that exploits them.
What the advisory leaves out is as telling as what it contains. There is no list of CVEs. There is no new vulnerability and no emergency patch. The weaknesses being exploited are known, published, and in most cases fixed by Siemens some time ago. What changed is the price of using them.
The agencies describe attackers generating exploitation scripts with AI assistance, built on python-snap7, an ordinary open-source library for talking to Siemens controllers. The scripts are dressed up to look like legitimate OT monitoring tools, which is a sensible thing to do if you expect anyone to be watching. Targets are found through commercial scanning services, Censys and ZoomEye, the same ones defenders use. Once in, the actors have been reading and writing data blocks over S7comm on port 102. They have not, as far as the agencies say, broken anything. The assessment is that this is reconnaissance and capability development, with the write access being practice for a day that has not arrived.
The targeted models run from the S7-200 through the S7-1500, and that list includes the F-series safety controllers. Safety controllers are the equipment that stops a process when the process becomes dangerous to people. The advisory is careful not to claim anyone has manipulated one, but it does name safety interlocks and emergency shutdown systems among the things that could be affected.
So the news is not that Siemens equipment is insecure. The news is that writing a working attack against an industrial controller no longer requires an industrial control engineer, and finding a target no longer requires anything at all.
The list, and the parts of it nobody will do
The advisory gives seven areas of hardening work. Inventory the controllers. Patch them. Get them off the internet. Tighten access. Turn on logging and monitoring. Harden the devices themselves. Call Siemens for model-specific advice.
It is good guidance and none of it is exotic. It also splits cleanly into two piles, and the split matters more than the list.
The first pile is nearly free. Block TCP port 102 at the perimeter. Audit the firewall rules to find out whether S7comm is exposed, which is a question most organizations have never actually asked. Turn on the password protection that the controller already supports. Remove the default SNMP community strings. Restrict programming access to the engineering workstations that are supposed to have it. This is an afternoon of work for someone who has the access and the authority, and it removes most of the exposure the advisory is warning about. A controller that cannot be reached is not interesting to a scanner.
The second pile is where it gets hard. Updating firmware on a controller running a continuous process means an outage window, and outage windows are scheduled months ahead and fought over. In regulated environments a change to a safety system can trigger revalidation. Some of this equipment is on its way out of the catalogue entirely. Siemens flagged the phase-out of the S7-300 and ET 200M in 2023, a line that had already been in service for more than a quarter of a century: roughly two more years of new orders, then about eight years of spare parts, and after that nothing. There are S7-300s still running plants that were commissioned when the engineer maintaining them was in school. Network re-architecture, ICS-aware monitoring, unidirectional gateways for the historian — those are projects with budgets, not tasks.
Then there is the part nobody puts in an advisory. A great many of the affected sites are small. A rural water system with two operators and no security staff is not going to work through a seven-part hardening programme, and saying so is not a criticism of the operators. They are running a plant with the money they have.
Which is why I would expect the free pile to get done in a lot of places, the expensive pile to get done in some, and a long tail of sites where neither happens because nobody there ever read the advisory at all.
We know roughly what that tail looks like. In November 2023, IRGC-affiliated actors calling themselves CyberAv3ngers took control of a booster station at the Municipal Water Authority of Aliquippa in Pennsylvania. CISA and the FBI documented the campaign across multiple states. Nothing about it was clever. The equipment was exposed to the internet and still carried the password it shipped with, which was 1111. The water kept running because the operators went manual, but the point of the exercise was never the water. It was the demonstration.
The timing is not yours
Here is the part I would want a board to understand. The activity in this advisory is not an attack in progress. It is preparation. Read access to learn a plant, write access to prove the technique works, and then nothing, until it suits somebody.
That inverts the usual urgency calculation. Most security work is a race against an incident that is either happening or isn't. This is a race against a decision that someone else will make later, for reasons that will have nothing to do with you — a diplomatic incident, a conflict, a bad week in someone's foreign policy. The window is open now and closes when they choose to use it, which means the argument for doing the cheap work this quarter rather than next is simply that you do not get to know how long you have.
Now the part you do not control
Suppose you do all of it. Your inventory is current, port 102 is closed, your firmware is patched, and you have ICS monitoring watching for snap7 imports on engineering workstations. Good. You have secured the smaller half of your exposure.
Look at the sectors the agencies named as most targeted: critical manufacturing, energy, water and wastewater, chemical, food and agriculture, commercial facilities. That is not a list of industries. That is the upstream of almost every business in the country. You may own no controllers whatsoever and still depend, completely, on plants full of them — the supplier who makes your packaging, the specialty chemical house with one reactor line, the contract manufacturer, the utility that feeds your site.
The failure you experience will not look like a cyber incident. It will look like a supplier calling on a Tuesday to say a line is down and they cannot yet tell you for how long. It might look like them not calling, and you finding out from a missed delivery. Whether the root cause was a compromised PLC or a fire is, from where you sit, almost irrelevant. What matters is the duration and whether you have any alternative.
The advisory gestures at this itself, in a sentence I would put in front of every procurement officer. The mitigations matter especially, it says, for owners who work with third-party service providers or system integrators with remote access to their controllers, because those asset owners "may not realize that their systems are exposed and at risk." Elsewhere it tells organizations that rely on integrators to send them the advisory and ask them to implement it.
That is a supply-chain instruction. It is aimed at the plant operator and their integrator, but the logic does not stop there. It runs all the way down the chain to you.
What to ask, and what the answers tell you
Vendor management already asks suppliers about financial health, insurance, capacity and delivery performance. For software vendors, somebody usually asks for a SOC 2 report. Almost nobody asks the questions that would matter here, and they are not difficult questions.
- Do you run programmable controllers in the process that makes what I buy, and do you have a current inventory of them? You do not need the inventory. You need to know whether one exists.
- Is any of that equipment reachable from the internet or from your business network — and did you verify that recently, or is it an assumption? The advisory exists because the assumption is often wrong.
- Who else can write to your controllers? Integrators, maintenance contractors, OEM remote support. Ask for names, how the access works, and whether it produces a log anyone reads.
- What is your firmware baseline, and when did you last move it? Where equipment genuinely cannot be patched, what compensates for that.
- If a controller's logic were altered or wiped tomorrow, how long until you are producing again? The answer depends on whether verified offline copies of the ladder logic and configuration exist, and whether anyone has ever tested restoring from them.
- Will you tell me if you have an OT incident that could affect my supply, and within how many hours? This one belongs in the contract with a number in it, not in a conversation.
- Can you show me something rather than tell me? An attestation, an assessment summary, a certification with a scope statement you can read.
Most suppliers will not answer these well. Some will not answer at all. That is not a failure of the exercise; it is the output of it.
You are not auditing anyone. You are sorting them. A supplier who comes back with specifics has told you something real about how that plant is run. A supplier who sends a glossy page about their commitment to security has told you something too. And the supplier who says they would need to check with their integrator has just told you who actually holds the keys to the plant your business depends on, which is worth knowing before the bad Tuesday rather than during it.
When the answer is bad
You cannot fix their plant. You have no authority there, no visibility, and no realistic prospect of either. What you have is everything on your own side of the line.
Know your single points — the inputs with one qualified source and a requalification timeline measured in months. Hold inventory against the ones that would actually stop you, which is dull and ties up capital and is the oldest working answer to this problem. Qualify a second source before you need one, because qualification is slow and cannot be started on the day. Put notification obligations in contracts at renewal, since that is the one moment you have leverage. And rehearse the supplier outage rather than the cyber attack: who decides to switch sources, at what threshold, with whose authority, and how long the decision itself takes. In most organizations the decision takes longer than the switch.
None of that requires knowing which of your suppliers is running an exposed S7-300. It works whatever the cause turns out to be, which is the property you want, because you are not going to find out in advance.
The advisory is worth acting on and I hope people act on it. But the honest expectation is that this fleet gets patched unevenly, and that the equipment which never gets patched will sit in plants you do not own, operated by people you do not employ, on networks you will never see. Prevention stops at your fence line.
You cannot patch your supplier's plant. What you can do is work out, before the phone rings, what you intend to do when it does.