Your PLC should not be on the Internet: the IEC 62443 lesson from the Siemens S7 threat

THE EXPLOIT IS NEW. THE ARCHITECTURE PROBLEM ISN'T.

Your PLC should not have to defend itself against the Internet.

Siemens S7 · Internet exposure · ISA/IEC 62443

Somewhere right now there is an S7-1200 you could find with a search query of a few words. Not because anyone hacked it, but because it is simply switched on, with a public address, because at some point there was an engineer who wanted to check in from home in the evening.

None of that is new. What is changing is how quickly someone can do something with it.

What was actually reported

On 20 August 2026, NSA, CISA, FBI, DOE and EPA issued a joint warning about Siemens S7 PLCs. It covers the S7-200, S7-300 and S7-400, the S7-1200 in the 1211C through 1217C variants, and the S7-1500 — including the F-series, the controllers that run safety functions.

What was observed: attackers use Censys and ZoomEye, the same scanning services researchers use, to find PLCs that are exposed to the Internet and running outdated software. They then have AI help write exploitation scripts, based on information that is simply public. One of the scripts described poses as a legitimate monitoring tool and speaks S7comm.

And here is the part that usually gets lost in retelling. The warning is about reconnaissance and building tooling. It does not establish that a specific Siemens vulnerability was successfully exploited, and it names no CVE at all. The wording is conditional: if these PLCs are exposed to the Internet or insufficiently segmented, then known vulnerabilities can be exploited.

That difference is not a security person splitting hairs. It decides what you do on Monday. With confirmed exploitation you go hunting for traces. Here you go and look at what is reachable from outside — a different conversation, with different people.

Two things that keep getting conflated

There are two problems sitting side by side here, and they almost always get treated as one.

The first is that AI lowers the barrier. The time, expertise and cost of building offensive tooling go down. What took someone competent and a few weeks last year takes less now. That is real, and at the same time less spectacular than it sounds: public information is being turned into working code faster, not new physics being invented. What that means for defenders we wrote up earlier in AI and the attacker.

The second is that an industrial controller is reachable from the Internet. That is not a threat problem but an architecture problem, and it existed long before anyone pointed a language model at exploit code.

The distinction between architecture and design matters here. Architecture is about which zones exist and what may reach what. Design is about how you realise that: which device, which rule, which setting. You can have an excellent design — tidy rules, well-configured firewalls — sitting on top of an architecture where a controller is still on the street. Then you have documented the problem neatly rather than solved it.

This article is about the second. Not because the first does not matter, but because the second is something you can fix in a way that keeps working when the attacker's tooling changes again. And it will.

The question the conversation turns on

If an attacker knows the IP address of this PLC, what must they pass or compromise before they can talk to it?

That is all of it. Take your most important controllers, work through that question and write the answer down. Not in a document — on a sheet of paper, with someone from operations in the room.

If the answer is “nothing”, you do not have a threat problem. You have an architecture problem, and no detection rule fixes that.

What you often hear is: “yes, but it has a password.” That is a lock on a door that opens onto the street. The lock may well hold. But you have hung your entire defence on one thing, on a device designed to run a process reliably, not to hold its own against the Internet.

What IEC 62443 actually contributes

The ISA/IEC 62443 series is not a product and not a certificate. It is a way of treating industrial cybersecurity as an architecture question instead of a list of controls. Five concepts do most of the work here.

First, define what you are talking about

Security architecture starts with the System under Consideration: what is inside and outside the environment you are assessing. That sounds like paperwork until you notice what fell outside. The cellular router the installer left behind. The cloud portal the vendor uses to manage their own equipment. The switch's management interface, which nobody owns.

What falls outside the boundary also falls outside your risk assessment. And that is exactly where the connections you did not see tend to live.

Exposure changes the risk

A controller reachable from the Internet has a fundamentally different attack surface from the same controller behind a few controlled transitions. That belongs in your risk assessment.

It does not mean every installation needs identical controls. A packaging line and an installation with a safety function should not land on the same level. Controls follow risk — that is what 62443-3-2 is about.

Zones and conduits, and what they are not

Two misconceptions turn up in almost every diagram. A VLAN is not automatically a zone: a VLAN separates traffic, a zone is a group of assets with comparable security requirements and a reason for being grouped. And a firewall rule is not automatically a conduit: a rule states what is permitted, a conduit is the deliberately designed communication between two zones.

For the boardroom the translation is simple. A zone is a room where you can explain why those things are in it together. A conduit is a door where you can explain why it exists, who may pass through it, and what happens when you close it. If you cannot explain that, you do not have a zone — you have a subnet. How to get there is covered in a VLAN is not a segmentation strategy.

Only what operations actually need

62443 works with the idea of restricted data flow. In practice: record, per connection, which source, which destination, which protocol, for which operational reason, and what happens if it becomes unavailable.

Those last two are the interesting ones. A connection nobody can give a reason for, and where nobody knows what breaks if you close it, is almost always one that was added for convenience. Usually by someone who no longer works there.

Remote access is not exposure

This is where the conversation usually stalls, so plainly: remote access is not the same thing as being directly on the Internet. A supplier, OEM or your own engineer often genuinely needs access. That is fine. The question is which architecture it runs through.

Depending on risk, that involves things like authenticated access with individual accounts rather than one shared password, multi-factor authentication, a VPN or ZTNA where appropriate, an intermediate step such as a jump host, rights based on role rather than habit, access limited in time, an approval step before the session opens, logging of what happens, and restriction to the protocols that are needed.

Note: that is a list of common controls, not a list the standard prescribes. IEC 62443 does not require a specific product or vendor. What you need follows from your risk assessment, not from a sales conversation.

One layer is not an architecture

The reflex after a warning like this is a firewall rule. It helps. But it is not the answer, and that is precisely where most incidents go wrong: there was a firewall, and behind it everything was flat.

Defence in depth means a failure in one place does not become a route to the process. Architecture and boundaries. Segmentation into zones. Controlled conduits between them. Hardening of the controllers themselves. Authentication and authorisation. Monitoring that recognises abnormal behaviour. Change control, so you know what changed. Controlled remote access. And patching or mitigating based on risk.

What that looks like when one layer has to carry it alone is in our analysis of the attack on a Polish power plant. No zero-day, just a chain of individually reasonable decisions.

And the controller itself

Hardening a PLC is a different conversation from hardening a server, because here availability and safety come first. “Just patch everything” is not advice you can execute in a plant, and anyone who has stood on a production floor knows it.

What you can do: run firmware that is still supported. Test security updates before they reach the line and schedule them in a maintenance window. Disable services you do not use. Restrict who may program the device, and from where. Use strong authentication where the device supports it. Protect the configuration against unauthorised change. Keep a known-good configuration as a backup — and test once that you can actually restore it. And watch for changes, because an unexpected program change on a PLC is not noise.

If you cannot patch, that is a risk decision with compensating controls. Not an action item you move to next quarter.

Security levels are a target, not a rating on the box

62443-3-3 describes system requirements and attaches security levels to them. What makes it useful is that you can set a target security level per zone based on risk, and compare it with what the environment can actually do today. That gap is your work list.

What it is not: a rating on a device. A PLC is not “SL 3”. The level belongs to a zone and to the requirements that apply there. If a vendor shows you a security level on a datasheet, they are selling you something other than what the standard means.

Five questions to ask today

1. Are any PLCs, HMIs, engineering interfaces or OT gateways directly reachable from the Internet?
2. Is every external connection into OT represented as a deliberately controlled communication path?
3. Can we explain why each asset belongs to its current security zone?
4. Is inter-zone communication limited to operationally required flows?
5. If remote access credentials or the remote access platform are compromised, what prevents an attacker from reaching the controllers?

That last one produces the best conversation. It moves the question from “do we have MFA” to “what happens when that one layer fails”. And that is what you want to be talking about.

Do not trust the diagram alone

An architecture diagram describes intent. Exposure is about reality, and in industrial environments those two drift apart further than anyone is comfortable with. There is often fifteen years between the drawing and the installation.

So verify what is genuinely reachable from outside. Your public address space. NAT and port forwarding rules, including ones set years ago. Industrial and cellular routers, including a supplier's. Remote access gateways. Integrator connections. OT equipment managed from a cloud portal. And the management interfaces of your switches, firewalls and gateways, because those are almost always forgotten.

Attackers do not attack your Visio diagram. They attack what they can reach.

What it comes down to

AI changes the speed and accessibility of offensive capability. Good OT architecture changes what that capability can actually reach.

That is not wordplay. If a controller is only reachable through a transition you designed, it matters less how quickly someone assembles a script. They do not get there without first passing something you deliberately put in the way — and that is exactly the kind of obstacle that keeps working when the tooling changes.

The objective is not to make a PLC secure enough to survive on the Internet.

The objective is to design the architecture so it never has to.

Beyond the checklist

Want to go deeper than the checklist? CyberBusters also delivers the PECB ISA/IEC 62443 Lead Implementer training, for professionals who need to translate IEC 62443 into practical governance, risk and architecture decisions.

Sources

• The Hacker News — AI-generated exploit scripts target Siemens S7 PLCs, news context for the joint NSA, CISA, FBI, DOE and EPA advisory of 20 August 2026
• CISA — Cybersecurity Advisories
• Siemens ProductCERT, for current advisories on Siemens products
• ISA — ISA/IEC 62443 series of standards
• IEC 62443-3-2 — security risk assessment for system design
• IEC 62443-3-3 — system security requirements and security levels