9 min read - AI-Assisted PLC Attacks: Audit Remote Access Before Buying Tools

On 27 August, more than 100 technology, finance and security organisations backed an open letter calling for a surge in cyber defence. It says AI-enabled attacks will become more widespread and capable in the coming months. Its requests include fixing the highest-risk weaknesses, checking that fixes work and applying compensating controls where essential systems cannot be patched safely.

That is a serious warning, but it is not a purchase order for an AI security product. Axios reported on 27 August that the letter contains no commitments, deadlines or named investments from its signatories. An SME still has to decide which exposure deserves money and attention first.

For manufacturers and industrial suppliers, a joint US government advisory offers a concrete place to look. CISA's 19 August advisory on Siemens S7 programmable logic controllers describes an active threat against US installations. The agencies say the actors use AI-generated exploitation scripts, public information and the python-snap7 library to imitate legitimate monitoring tools and reach internet-exposed or weakly segmented controllers.

The report does not establish that a site in France or Morocco has been targeted. It does show how an old operational technology problem changes when attackers can produce and adapt scripts faster. The immediate buyer question is therefore plain: can you prove who can reach each controller, through which path, and how you would spot an unauthorised change?

Start with exposure, not with the AI label

A programmable logic controller, or PLC, operates physical equipment. It may sit behind an engineering workstation, a vendor gateway, a plant firewall or a remote maintenance service. A business owner may never see it in the normal IT asset register even though production depends on it.

CISA's advisory names Siemens S7-200, S7-300, S7-400, S7-1200 and S7-1500 families. It tells owners to inventory controllers, remove internet exposure, patch, strengthen access controls, monitor activity and check ladder-logic integrity. It also calls out a common blind spot: asset owners may not know that an integrator or service provider has left remote access exposed.

Do not turn that list into a claim that every Siemens controller is vulnerable or compromised. Model, firmware, configuration, connectivity and surrounding controls change the risk. Nor should a company that uses another PLC brand ignore the lesson. The advisory itself says ongoing PLC targeting is broader than Siemens, while its technical findings remain specific to the activity it observed.

The first review should follow the route an attacker would need, not the organisation chart. Trace the public address, VPN, jump host, engineering workstation, maintenance account and controller. Include indirect paths from a managed service provider or machine supplier. If no one can draw that route, the company cannot yet judge whether a new detection product covers it.

Ask the integrator for evidence you can keep

For every remote route, record the business owner and the technical operator. Then ask:

• who authorises access, and whether approval expires after the maintenance window;
• which named accounts, devices and source networks can connect;
• whether multi-factor authentication protects the remote entry point;
• where session, configuration and controller-change records are kept;
• how the owner can suspend access without waiting for the supplier;
• when the route was last tested from outside the trusted network.

An integrator's statement that access is "secure" is not test evidence. Ask for the diagram, relevant settings, a dated access review and the result of a controlled connection test. Keep the evidence in a repository the asset owner can reach during an incident. A support portal that disappears with the supplier relationship is a poor place for the only copy.

Define what "fixed" means before changing production

Industrial teams sometimes postpone patches because downtime or compatibility failure could be more damaging than the known flaw. The open letter acknowledges this problem and asks organisations to apply and verify compensating controls when essential services cannot be patched without disruption. CISA likewise tells operators to test updates in a development environment and verify compatibility with their operational environment and third-party integrations.

That makes a status of "patch planned" too vague. Use a remediation record that can survive a shift change:

The verification should come from a different observation than the change itself. A firewall ticket marked complete does not prove the PLC is no longer reachable. Check from the relevant untrusted network, inspect the resulting path and confirm that required maintenance still works. For a firmware update, record the deployed version and run the approved functional test against the physical process.

Backups deserve the same precision. A file with an old ladder-logic program is not a recovery plan. The team needs a known-good copy, the engineering tools and credentials required to restore it, an owner who can authorise restoration and a test showing that the procedure works without unsafe equipment behaviour.

Monitor changes that matter to the process

CISA lists network and controller signals worth hunting for, including unexpected S7 communications, memory or ladder-logic changes, connections from unusual locations and activity without a corresponding work order. A smaller organisation may not have an industrial security operations centre, but it can still connect a few high-value records.

Start by matching remote sessions to approved maintenance windows. Compare controller changes with a ticket or work order. Alert when an engineering workstation connects from a new route or when a controller changes outside the agreed window. Make sure somebody can receive the alert when the plant is running, and write down what that person can safely do.

Avoid sending raw operational technology logs into an AI service until the data path, permissions, retention and supplier access have been reviewed for that system. A defensive model may help group events or draft an investigation, but it does not know whether a change is safe for the physical process. A qualified operator must own that decision.

Our guide to cybersecurity guardrails for AI-assisted development covers the software side of generated code. In an industrial environment, the acceptance gate also needs process-safety and recovery evidence because the code can affect machinery rather than only an application.

Buy defensive AI only against a measured gap

The new letter asks technology partners to make AI-powered defence easier for critical infrastructure operators to deploy. That may produce useful tools. It does not remove the need for a buyer-controlled test.

Choose one gap from the exposure review. It might be identifying an unknown internet-facing asset, correlating maintenance sessions with changes, or prioritising a queue of known weaknesses. Build a test pack from authorised, sanitised records and compare the candidate with the current process.

Measure missed high-risk cases and false alerts. Check how much analyst time the tool moves rather than saves. Restrict the model's access and keep any remediation action behind an approval step. Finally, confirm that the company can export findings, rules and investigation records if it changes supplier.

The NIST CSF 2.0 small-business guide is useful here because it treats cyber risk as business governance, asset knowledge, protection, detection, response and recovery. NIST presents the guide as a starting point, not a prescribed control set. Use it to make sure a tool purchase does not consume the budget while ownership, recovery or supplier access remains unresolved.

A 30-day sequence for an industrial SME

During the first 72 hours, name an accountable business owner, locate the PLC and engineering-workstation inventories, and ask integrators for every remote access route. Check public exposure without scanning production equipment aggressively. Escalate any unknown or direct internet path through the site's approved incident and safety procedures.

By the end of the first week, classify controllers by physical consequence and connectivity. Remove access that has no current purpose, rotate or suspend orphaned credentials and time-limit the routes that remain. Preserve logs and configuration evidence before making changes if compromise is suspected.

Use the rest of the month to test patches or compensating controls, verify backups and restoration, and connect high-value change events to work orders. Only then write a buying brief for the gap the current controls cannot cover. The brief should name the required evidence, access limit, operator and exit condition.

Sources and limitations

• The multi-company call for collective cyber defence, reviewed 28 August 2026, supplies the current warning and its requests on verified fixes, compensating controls and support for defenders.
• The joint CISA advisory AA26-231A, released 19 August and reviewed 28 August 2026, documents the active US Siemens S7 threat, observed methods, affected product families and mitigations.
• Axios's 27 August report, reviewed 28 August 2026, dates and independently reports the letter while noting that it contains no commitments, deadlines or specific investments.
• NIST's CSF 2.0 small-business guide, reviewed 28 August 2026, provides the business-risk structure used to check governance, protection, detection, response and recovery.

The CISA activity concerns US targets and does not prove compromise or targeting in France or Morocco. Product versions, exposure and vendor guidance can change. The audit and buying sequence is Exceev's operational synthesis, not a procedure endorsed by the sources and not legal, regulatory, safety or incident-response advice. Industrial changes require the asset owner's normal safety, engineering and change-control approvals.

Audit the access route

AI may let attackers produce industrial exploitation scripts faster. It does not erase the route they still need into the plant. Find that route, make the remote owner visible, verify each fix from outside the change process and test recovery. A defensive AI purchase makes sense after that work reveals a gap the team can define and measure.