DEV Community

Max Bayern
Max Bayern

Posted on Originally published at ot-cyber.de

AI and Firmware: Architecture Beats Point Solutions

#security #iot #cybersecurity #ics

Firmware no longer stops an attacker just because it is hard to understand. AI tools can speed up reverse engineering of embedded firmware and porting of PLC exploits. In the lab, this still took considerable help from the researchers. This is a summary of my German original. It affects operators and machine builders across DACH whose protection relies mainly on individual products, or whose controllers expose old, unpatched services on the network. What helps now: reduce exposure (segmentation, disable FTP and unnecessary services), monitor the OT network and practice Incident Response. Align all of it with the five SANS ICS Critical Controls and IEC 62443. In short: architecture and process instead of point solutions.

I'm Max Gilg, an OT cybersecurity consultant from Rosenheim. Here I sort out what is actually documented, and what happened in the lab versus in real plants.

How fast can AI build firmware and PLC exploits today?

Two research results are documented. Real attacks of a different kind have also been reported.

Lab result 1: WAGO PLC (Forescout, 01.09.2026). Forescout Vedere Labs used Claude (Sonnet 4.6, then Opus 4.6), Ghidra and real hardware to port a pre-auth exploit for CVE-2021-31886 from the WAGO 750-852 to the 750-831, without source code and without a debugger. CVE-2021-31886 is a pre-authentication buffer overflow in the Nucleus FTP server. The final RCE development stage took 8 hours 32 minutes at 535.74 USD in API costs. Afterwards, according to Forescout, the AI "moved from a harmless payload to multiple working network payloads in minutes". During development of a command-and-control (C2) implant, one payload wrote to flash memory and permanently bricked the PLC. The researchers had to keep guiding the AI out of dead ends (Forescout, SecurityWeek, The Hacker News, Cybersecurity Dive).

Research result 2: PC peripherals (Chaz Schlarp, 23.08.2026). Security researcher Chaz Schlarp had an AI agent (Claude Opus 5) reverse engineer the firmware of five PC peripherals, including a webcam, a monitor and a microphone, in about 13 hours of processing time over two weeks. Most devices had little or no firmware integrity checking; on the one device with signature validation, a single HTTP POST could disable the check (schlarp.com). These are not OT devices. But anyone who looks after edge devices in the field knows the design: microcontroller, update tool and hardly any anti-tamper.

Real attacks. Forescout also points to attacks on exposed PLCs at US water utilities (Forescout).

My assessment: "If AI, guided by experts, makes firmware analysis noticeably faster, the security of your plant must not depend on nobody looking into the firmware."

Why don't individual security products protect anymore?

Many plants in Bavaria, Salzburg and Tyrol have grown over the years: a firewall at the boundary, a remote maintenance box per supplier, a USB sanitization PC in maintenance. Together this is no defense once three assumptions fall apart:

  1. "Our controller is too exotic." Forescout shows that AI also analyzes proprietary embedded firmware. Forescout writes that the assumption that attackers favor engineering protocols over complex PLC exploits "may become less reliable as AI reduces the effort required for exploit development". For now, Forescout still rates such exploits as "less attractive than easier alternatives".
  2. "What isn't on the internet is safe." Firmware enters the plant via service laptops, USB sticks, update tools and remote maintenance.
  3. "The vendor will patch it." The WAGO flaw dates from 2021. Controllers often stay in operation for many years and rarely get Secure Boot retrofitted.

Two different risks are at play: Forescout shows remote code execution through an old network service (a buffer overflow in the FTP server), Schlarp shows firmware that can be modified because integrity checks are missing or can be switched off. Secure Boot and signed updates address the second; only reduced exposure and monitoring address the first. "AI turns a legacy liability on the network into an attack path. If you can't patch a vulnerable PLC, you must make it unreachable and watch it. That is architecture, not a product purchase."

Which steps help right now?

My guide is the Five ICS Cybersecurity Critical Controls from SANS (SANS).

Foundation: know what is on the network. Without an asset inventory you don't know whether affected controllers such as the WAGO 750-831, and in which firmware version, are in your hall. An OT asset inventory, including firmware versions, covers this.

CC2 – Defensible Architecture: Segmentation by zones and conduits per IEC 62443-3-2, with a Security Level (SL-T) per zone. CERT@VDE (VDE-2021-050) recommends allowing no direct access from untrusted networks, disabling DHCP, DNS and FTP port 21, and updating the firmware. For the 750-852 and 750-831, which are based on Nucleus V1, no firmware update is available; CERT@VDE recommends isolating such devices in zones and restricting external communication paths. There, segmentation and disabled services remain the only protection.

CC3 – ICS Network Visibility & Monitoring: Attacks like these often show up on the network before they show up on the device. Forescout recommends monitoring for "unusual protocol use, repeated crashes, unexpected outbound communication"; firmware downloads outside maintenance windows are another warning sign. CERT@VDE also advises monitoring network traffic for anomalies. Attack detection in OT networks can detect this, an antivirus scanner typically cannot.

CC4 – Secure Remote Access: Remote maintenance only through a central jump host with MFA, per-session approval, time-limited and logged. No permanently open VPN tunnels per supplier.

CC5 – Risk-Based Vulnerability Management: Prioritize by reachability, exploitability and impact on the process. "Hard to exploit" is no longer a good reason for postponing. OT vulnerability management can support this.

CC1 – ICS Incident Response: Forescout explicitly recommends practicing Incident Response against AI-assisted OT attack paths. Who decides on shutting down? Where is the golden image of firmware and PLC program, and how long does restart take?

My recommendation: "Don't buy another security box before you know which devices with which firmware you have and who can reach them from outside."

What does this mean for production and maintenance?

For production managers, availability counts. In the lab, a faulty payload permanently bricked a PLC by accident. In my assessment, an attacker could cause the same damage deliberately, and even a "clumsy" attack can lead to a standstill. Clarify which controllers are stocked as spare parts. For maintenance: only load firmware from vendor sources, verify signature or hash, and treat service laptops and USB sticks as their own risk zone. That also protects the service technician.

What do CRA and NIS2 change about the firmware question?

The Cyber Resilience Act (Regulation (EU) 2024/2847) requires manufacturers of products with digital elements to report actively exploited vulnerabilities and severe incidents, and to ensure secure updates and vulnerability handling (EU Commission, EUR-Lex). For machine builders, Secure Boot, signed updates and an SBOM are therefore no longer optional extras. CRA as a Service helps with implementation.

In Germany, NIS2 is being implemented through the NIS2 implementation act (Bundesregierung, DSN Group). Operators must demonstrate risk management, emergency plans and reporting channels, in other words architecture and process. Buyers should put signed firmware, Secure Boot, documented update processes, disableable services and an SBOM into tenders.

Who helps with OT security in Bavaria, Salzburg and Tyrol?

With OT-Cyber.de I support operators and machine builders across DACH, focused on the border region around Rosenheim. The entry point is usually an OT-Security-Beratung on segmentation and remote maintenance. If things are already on fire, the OT emergency help is reachable 24/7.

Sources

If you want a hands-on starting point, see our OT-Security-Beratung.

Original (German): https://ot-cyber.de/blog/ki-knackt-firmware-architektur-schlaegt-einzelloesung.html

Max Gilg is an OT cybersecurity consultant based in Rosenheim, Germany (OT-Cyber.de).

Top comments (0)