AI Is Not the Main Security Problem in the Siemens S7 Campaign

AI changes attacker economics. It does not create process authority.

The striking part of the current Siemens S7 reporting is the use of AI-assisted tooling. That matters because code generation, protocol examples and public documentation can reduce the time needed to build reconnaissance and interaction scripts. It can widen the pool of actors able to automate tasks that previously demanded more specialist knowledge.

But the physical consequence does not come from the model. It comes from the control path that already exists. A script only becomes an OT event when it can reach a controller, speak a protocol the device accepts, cross the relevant engineering or network boundary and exercise authority that changes process state.

That distinction matters operationally. If defenders make the incident an 'AI malware' problem, they risk optimising for code signatures and tool attribution while leaving the enabling architecture untouched. The durable control is to reduce unauthorised reach and bound what any reachable engineering path can do.

An exposed PLC is a trust-boundary failure before it is an AI problem

Siemens' own bulletin points operators back to industrial-security guidance and product manuals. That is a useful reminder that PLC security depends on deployment context. Internet exposure, permissive routing, flat maintenance networks, weak remote-access controls and unmanaged engineering workstations can turn a controller into an externally reachable authority over the process.

Not every S7 deployment has the same protections, firmware generation or protocol configuration. The useful question is therefore not whether 'S7 is insecure'. It is which exact controllers are reachable, through which conduits, from which identities and tools, with what ability to read, write, stop, start or modify operational logic and parameters.

This is where asset context matters more than a generic vulnerability list. A PLC that is technically reachable but cannot receive unauthorised state-changing operations presents a different risk from a controller sitting behind an engineering path that grants broad process authority to a compromised workstation or remote-access account.

Detection should focus on authority-changing behaviour

AI-generated scripts can be re-written faster than static signatures can be maintained. That makes behavioural detection more valuable. In an S7 environment, defenders should understand normal engineering sources, expected TCP/102 communication relationships, maintenance windows, project-download behaviour and the operational conditions under which state-changing commands are legitimate.

The objective is not to treat every S7 packet as malicious. Plants need programming, diagnostics, maintenance and vendor support. The useful detections are deviations from authorised engineering behaviour: a new source communicating with a PLC, control traffic outside an approved window, unexpected project or configuration changes, unusual stop/start actions, repeated enumeration, or an engineering session originating from the wrong trust zone.

These signals should be correlated with process evidence. A cyber alert becomes more actionable when the SOC can connect it to controller state, engineering-change records and the physical process without asking operators to hand over control to the monitoring stack.

Exposure reduction has to preserve plant operability

The simplistic answer is to disconnect every PLC. In many plants that is neither realistic nor safe. Remote support, historian flows, engineering access and production integration can be operational dependencies. The better architecture removes direct internet reachability, constrains conduits, uses controlled jump or access paths, separates engineering authority from ordinary user access and makes exceptional remote sessions explicit and observable.

IEC 62443's zones-and-conduits model is useful here because it forces the organisation to describe which communications are required and where trust boundaries should sit. The same logic helps with incident response: if one engineering path is suspect, the plant should be able to restrict that path without unnecessarily isolating unrelated process areas.

Written by

Antonio González, PhD

Cybersecurity practitioner focused on product security, OT/ICS and cyber-physical systems. Cybersecurity Under Pressure translates incident evidence into engineering and business decisions.

About →LinkedIn ↗