DEV Community: Max Bayern

OT Security Weekly DACH, KW 43/2026: Remote Access & Siemens PLCs

Max Bayern — Sat, 24 Oct 2026 07:03:06 +0000

The overall threat level for OT in the DACH region (Germany, Austria, Switzerland) is high this week (reporting period 15 to 23 October 2026). Remote access and Edge Devices are in focus again: a BeyondTrust Remote Support Zero-Day was exploited before it was disclosed. On the plant floor, new vulnerabilities hit the web server of Siemens SIMATIC S7-1500 and ET 200SP.

Key developments this week

1. BeyondTrust Remote Support: Zero-Day exploited before disclosure (CVE-2026-102764), SANS ICS Control: CC4 Secure Remote Access
BeyondTrust dates the two known compromises to 29 August. The vulnerability was published on 15 October and added to the KEV catalog on 16 October. According to Rapid7, Mandiant attributes the activity to ARMORY CASTLE (formerly UNC5221), a suspected China-nexus espionage actor. Patch self-hosted appliances immediately; versions before 24.3.1 need an upgrade first. Rapid7 recommends checking for compromise even after patching. According to Rapid7, Mandiant advises preserving evidence before making changes, isolating suspicious appliances and rebuilding them from a clean, patched image if compromise is confirmed or cannot be ruled out. Rotate stored credentials for OT systems and hunt with the IoCs from Mandiant (as listed by Rapid7).
Source: Rapid7

2. Siemens SIMATIC S7-1500 and ET 200SP: vulnerabilities in the web server (ICSA-26-295-14), SANS ICS Control: CC2 Defensible Architecture
Attackers can execute PLC operations within the rights of the logged-in user. Numerous products are affected. Siemens is preparing fixes and recommends countermeasures until they ship. Use your asset inventory to find CPUs with the web server enabled and disable it where it isn't needed. Otherwise, restrict access to the web server to engineering networks with a firewall, and tell your team to upload only trusted trace files.
Source: CISA ICSA-26-295-14

3. Joint advisory on SafePay ransomware (AA26-293A), SANS ICS Control: CC5 Risk-Based Vulnerability Management
The group has hit organizations across several critical infrastructure sectors. Check the patch level of the CVEs named in the advisory on firewalls, VPN and Veeam servers. Enforce MFA on every VPN account, and keep an offline backup of OT-relevant systems that you have already tested restoring.
Source: CISA AA26-293A

4. Siemens Software Center abused for ClickFix Malware, SANS ICS Control: CC3 ICS Network Visibility & Monitoring
According to The Hacker News, the attackers bring their own genuine, signed older copy of the software together with archive.dll, delivered as an MSI through a ClickFix lure. Systems are at risk when someone runs the ClickFix lure. Keep the Software Center on the latest version. Hunt on Windows and engineering PCs for ClickFix and MSI executions, and for SiemensSoftwareCenter.exe in AppData\Local\Programs started by msiexec.exe. Check IoCs against the vendor's original advisory before blocking them on your firewall and proxy.
Source: The Hacker News

5. Attacks on refrigeration controls in France, SANS ICS Control: CC4 Secure Remote Access
AP reported on 16 October on the attacks on refrigeration controls in France.
Source: Insurance Journal / AP

What it means per sector

Food & beverage production (threat level: elevated). The week was shaped by the aftermath of the refrigeration control attacks in France. We are not aware of a confirmed case in Germany. The risk lies with older, unmaintained or internet-exposed remote maintenance modules of refrigeration systems. In our assessment, this can also affect cold stores, frozen-food warehouses, dairies and breweries. Ask your refrigeration service provider in writing which controllers are reachable from the internet. Close direct access paths and replace them with VPN plus MFA. On Danfoss systems, enable Strict Security Mode and change default passwords, and plan replacements for legacy devices that no longer get updates. The Siemens S7-1500/ET 200SP advisory is the most important item for production. Import trace files only from your own verified sources, and that includes files from service technicians on USB. Your Incident Response plan should define how orders are handled manually and fresh goods are rerouted if a major retail customer goes down. Keep contact channels to the customer's purchasing team that don't depend on email or the portal. Also test the offline backup of recipe and MES data. Full report (German)

Machine builders (threat level: high). This week the most important news for machine and plant builders concerns vulnerabilities in their own products. Check your installed base for S7-1500/ET 200SP CPUs with the web server enabled, disable it where it isn't needed, instruct service technicians to upload only trusted trace files and send customers a short security notice. If you run self-hosted BeyondTrust appliances for remote maintenance, patch them, check them for compromise, rotate every stored credential for customer plants and inform affected customers. Bring your own Siemens Software Center installations to the latest version. Check whether your own ticket and CRM systems contain stored passwords and rotate them. Use personal, time-limited accounts with 2FA for service work instead of shared admin passwords. Full report (German)

What to do now

Immediately: Patch BeyondTrust Remote Support (upgrade first if older than 24.3.1), check for compromise even after the patch, rotate stored OT and customer credentials and hunt with the Mandiant IoCs (as listed by Rapid7). (CC4)
Immediately: Disable the web server on S7-1500/ET 200SP CPUs or restrict access to it to engineering networks with a firewall until Siemens delivers fixes, and accept trusted trace files only. (CC2)
Immediately: Hunt on Windows and engineering PCs for ClickFix/MSI executions and SiemensSoftwareCenter.exe started by msiexec.exe, block verified IoCs and update the Software Center to the latest version. (CC3)
Immediately: Inventory remote access to refrigeration systems, close direct internet access and route it through VPN with MFA. (CC4)
0 to 3 months: Check your VPN and Edge Device inventory against the CVEs in AA26-293A, enforce MFA for all remote access and test restoring an offline backup. (CC5)

Full sector reports (German)

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

PHP2Shell in OT Sites: Why the Vulnerability Will Linger for Years

Max Bayern — Thu, 22 Oct 2026 06:32:05 +0000

TL;DR: PHP2Shell has been the target of widespread attack attempts since its disclosure on October 21, 2026, with first attempts seen as early as October 17 according to Amazon. A login does not protect you, and there are no official updates for PHP 8.1 and older. In industrial sites, PHP sits in the web interfaces of controllers, industrial routers and firewalls, as well as EV chargers and energy equipment whose firmware is rarely updated. Operators should cut these web interfaces off from the internet now. Vulnerable PHP web interfaces will in all likelihood still be found in industrial sites well beyond 2030.

This is an English adaptation of my German original.

On October 21, 2026, the PHP team closed two critical vulnerabilities known as PHP2Shell. Both allow remote code execution without authentication. The BSI (German Federal Office for Information Security) warns at level 3 (orange). The discussion so far mostly centers on websites and online shops. From an OT perspective, what matters is what happens inside the plants, for operators and machine builders in the DACH region and beyond.

The attacks are already running

Broad attack attempts have been under way for some time. According to Amazon, the first attack attempt on its honeypots was seen on October 17, four days before disclosure. Cloudflare observed attempts even before the announcement and a sharp increase after it.

The US agency CISA had not observed exploitation at the time of disclosure. Mass scanning and attack attempts are documented. How many of them succeeded is unknown.

PHP processes the crafted request before the actual application even starts. A password on the web interface does not stop the attack.

According to Sansec, the faulty code originates from PHP 5.4, i.e. from 2012. Since then, PHP has found its way into a great many devices.

Where PHP hides in OT devices

Public documentation indicates PHP in the web interface of devices such as the following. This is not a list of affected products: whether and how a device is affected by PHP2Shell is for the respective vendor to assess. Most of the vendors listed here have not yet published a statement on PHP2Shell.

Controllers and HMI: WAGO PFC100, WAGO PFC200, WAGO CC100, WAGO Edge Controller, WAGO Touch Panels (Standard, Advanced, Marine); Kunbus Revolution Pi with PiCtory
Routers and switches: NetModule NB800, NB1601, NB1800, NB1810, NB2800, NB2810, NB3701, NB3800, NG800; Phoenix Contact TC ROUTER 4002T, 4102T, 4202T; TC CLOUD CLIENT 2002T, 2102T; FL SWITCH 2000 series; FL NAT 2008
Firewalls (status per vendor advisories as of October 22, 2026): Palo Alto PAN-OS 10.2 to 12.2 and Panorama (affected according to the Palo Alto advisory, fix pending); OPNsense (fixed in 26.7.7 and 26.4.2p3 according to OPNsense); Netgate pfSense (update released); Juniper J-Web on SRX and EX (PHP-based web interface); Citrix, Ivanti and F5 BIG-IP use PHP according to heise, whether they are affected is open; Fortinet is checking FortiADC, FortiSIEM and FortiClient EMS, FortiOS is not affected
EV chargers: eCharge Hardy Barth cPH2 and cPP2; Salia PLCC charge controller (according to ONEKEY)
Energy, PV, smart meters, telecontrol: Contec SolarView Compact; Ezylog PV server; volkszaehler.org; Mitsubishi Electric smartRTU and INEA ME-RTU
Building and access control: ABB Cylon Aspect (NEXUS, MATRIX-2, ASPECT-Enterprise); Schneider Electric U.motion Builder; Nice Linear eMerge E3
Monitoring in OT networks: Nagios XI, Cacti, LibreNMS, Zabbix frontend

In our research, we found no public evidence of PHP for: Ignition, Copeland XWEB Pro, Kieback&Peter DDC4000, the Samson TROVIS district heating controller, Solar-Log, Danfoss AK-SM 800A, Siemens SCALANCE and RUGGEDCOM, as well as smart meter gateways. No evidence does not mean ruled out.

All sources and ongoing updates are in the incident situation report on PHP2Shell (German).

PHP alone does not make a device vulnerable

Whether a device is actually vulnerable depends on the PHP version and the operating mode, and on whether the web interface is reachable at all. Only the vendor can assess this. Operators can find the current status in vendor advisories and at CERT@VDE.

Why the vulnerability stays in industrial sites for years

It is not new that such vulnerabilities have long-lasting effects. For Log4Shell, according to Tenable, almost a year later 72 percent of organizations were still vulnerable. An earlier php-cgi vulnerability was used by ransomware a few days after the patch and still a year later. With Contec SolarView, a PHP vulnerability in this PV monitoring product was exploited by Mirai a year after the exploit appeared. Devices were later also hijacked for banking fraud.

PHP2Shell will likely follow a similar pattern, just in stages. Until the end of 2026, mass scans and botnets are likely to dominate. Firewalls and VPN access are likely to be the main focus, because they open the way into the network. In 2027 and 2028, the large vendors are likely to deliver updates, but operators will probably only apply them in maintenance windows. To make things worse, PHP 8.2 reaches end of life at the end of 2026, and 8.3 at the end of 2027. From 2029, a remainder is likely to stay, mainly devices without vendor support. This is exactly what botnets and criminals can then be expected to use.

The longest-lived vulnerable systems will in all likelihood be charge controllers with old PHP versions, PV loggers, telecontrol stations in water and district heating, building automation and access control, and industrial routers in machines running without a maintenance contract. For production and maintenance, this means: the router in the control cabinet, through which the machine builder has had remote maintenance access for years, belongs at the top of the list.

What the CRA means for machine builders

Since September 11, 2026, manufacturers must report actively exploited vulnerabilities as an early warning within 24 hours and in detail within 72 hours. Once active exploitation is confirmed, this can also apply to machine builders if they place the machine on the market as a product with digital elements and the vulnerability sits in a purchased controller or router. If you do not know where PHP is installed, you cannot report on time. We support the reporting process and supplier inquiries with CRA as a Service.

What operators should do right now

Cut the web interfaces of controllers, remote maintenance routers and firewalls off from the internet and make them reachable only via VPN or a jump host.
Firewalls first: update OPNsense and pfSense; for PAN-OS, restrict management to trusted internal addresses until the fix is available.
Inventory devices with web interfaces, including firmware version, and ask the vendor for the PHP version and update date. Where this overview is missing, an OT asset inventory helps.
Check exposed systems for anomalies from October 17 onward. If you find traces, contact our OT emergency response.

Securing for the long term

For the time after the emergency, operators are best advised to follow the SANS Five ICS Cybersecurity Critical Controls. Applied to PHP2Shell, this means: an ICS-specific incident response plan and a defensible architecture with a dedicated management network. Add passive attack detection in the OT network (see attack detection), secure remote access with multi-factor authentication, and risk-based vulnerability management with an SBOM at procurement. Continuously matching vendor advisories against your own inventory has become feasible even for small teams with AI support.

Quickly done in IT, far from done in industrial sites

In IT, PHP2Shell will in all likelihood be largely dealt with in a few weeks. In industrial sites, the vulnerability will remain well beyond 2030: the devices run for a long time and are rarely updated. Besides, hardly anyone knows that PHP is inside them at all. Operators should therefore by no means wait until the vendor delivers an update. Anyone who isolates the web interfaces now removes most of the risk, even before the update arrives.

Max Gilg, OT cybersecurity expert from Rosenheim, OT-Cyber.de

Sources: PHP advisory, BSI warning 2026-297981-1032, CISA alert of 10/21/2026, Amazon Threat Intelligence, Cloudflare, SANS ISC, Sansec, Palo Alto advisory CVE-2026-109618, Fortinet FG-IR-26-186, Cisco cisco-sa-php-october26, OPNsense, NCSC-NL php2shell, ONEKEY, heise, Kaspersky ICS CERT, Tenable, VulnCheck. All individual sources are in the situation report.

Want to keep track of advisories against your own asset inventory? See KI-Lagebild für Ihre Anlagen.

Original (German): https://ot-cyber.de/blog/php2shell-in-ot-anlagen-warum-die-luecke-jahre-bleibt.html

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

OT Incident Response for Grid Operators: Practice, Don't File Away

Max Bayern — Wed, 21 Oct 2026 08:04:16 +0000

The NIS2 implementation act is now in force in Germany, and for affected grid operators and utilities (Stadtwerke) the consequences are concrete. They must be able to handle security incidents, they need plans for operations, recovery and crisis management, and they must report significant security incidents to the BSI (the German Federal Office for Information Security) within 24 hours at the latest. This article is an English adaptation of my German original.

Whether an OT incident response plan holds up in a real incident only shows in an exercise. That exercise needs grid control and protection engineering at the table, along with IT and executive management. Grid operators should run a scenario at least once a year, ideally quarterly as a tabletop, in which the control system itself can no longer be trusted. The manual operation at the substation has to be genuinely tried out. After every exercise, the plan gets rewritten.

I'm Max Gilg, an OT cybersecurity expert from Rosenheim. In this series I go through the five SANS ICS Critical Controls one by one, each for a specific industry. This time it's CC1, ICS Incident Response, for power and grid operators in Germany. All incidents mentioned are publicly documented.

Why a plan in the cabinet is not enough

Many organizations have an emergency manual that was approved and ticked off in an audit. It gets interesting at 2 a.m.: the control room sees switching operations nobody triggered. Someone has to decide whether the telecontrol link to the substations gets cut. Someone has to drive out and switch on site, and someone has to report to the BSI. Who does what must be settled beforehand.

That attackers deliberately target power grids is well documented. On 23 December 2015, about 225,000 customers lost power at three Ukrainian distribution system operators. According to the US agency CISA, the attackers rendered systems unusable with KillDisk and destroyed the firmware of serial-to-Ethernet converters in substations (CISA). In April 2022, ESET and CERT-UA analyzed an attack attempt on high-voltage substations of a Ukrainian utility. There, the Industroyer2 malware was to be deployed, alongside several wipers such as CaddyWiper (ESET WeLiveSecurity, 12 April 2022).

A key CISA recommendation from 2016: develop and practice contingency plans that allow safe operation or shutdown even when the ICS is actively working against the process. That is an uncomfortable thought for a control room. Many emergency plans assume the control system keeps working and only a server fails. It looks different when the screens show values nobody can believe anymore. Whether your own team can keep grid operations running for a while without telecontrol is something no document answers. Only an exercise does.

Germany also offers lessons, although not classic cyberattacks on grid operators. According to press reports, after the disruption of the KA-SAT satellite network in February 2022, remote monitoring failed at a large number of wind turbines in Germany. The turbines kept running in automatic mode but could no longer be controlled remotely (pv magazine, 1 March 2022). The remote-control disruption then continued for some time (it-daily, Modern Power Systems). If your telecontrol depends on a single communication path, you should play through exactly this case once.

In Berlin, according to press reports, an arson attack cut parts of a district off the grid, affecting numerous households (SRF, Der Standard). That was sabotage, not a cyberattack. Still, it is instructive for your plan: from restart and recovery to communication with authorities and the public to shift planning during longer outages, these are topics missing from many IT contingency plans.

What NIS2 requires from power and grid operators in Germany

The act implementing the NIS2 directive has been promulgated in the Federal Law Gazette (BGBl.) and is in force. The minimum measures under § 30 (2) BSIG include handling security incidents, maintaining operations with backup management, recovery after an emergency, and crisis management. In addition there are procedures to assess the effectiveness of these measures (§ 30 BSIG). The BSI explicitly counts testing of contingency plans as part of Business Continuity Management (BCM) and points to BSI Standard 200-4 as the method (BSI, NIS-2 BCM, BSI Standard 200-4). That is no coincidence: how effective a plan is that nobody has ever tested is hard to assess.

For reporting, § 32 BSIG prescribes a three-stage process: an initial report no later than 24 hours after becoming aware of a significant security incident, a follow-up report no later than 72 hours after becoming aware of it, and a final report no later than one month after the 72-hour report (§ 32 BSIG). The BSI provides further information on the reporting obligation (BSI, NIS-2 reporting obligation).

Grid operators also deal with the Bundesnetzagentur (Federal Network Agency). It has published drafts intended to merge the existing IT security catalogs for networks and energy installations. General measures for cybersecurity and business continuity (BCM) are to be separated from the specific requirements (Bundesnetzagentur, press release). Until a new catalog is published, the existing catalogs under the EnWG remain the reference, and attack detection systems (SzA) must still be operated (Bundesnetzagentur, Bundesnetzagentur, IT security). Operators should check the final status of the new catalog directly with the Bundesnetzagentur, since at the time of writing it could not be confirmed as adopted. Note that an SzA initially only tells you that something is wrong. How the control room responds must be written in the plan and practiced.

CC1 ICS Incident Response in the control room

In their 2022 SANS whitepaper, Robert M. Lee and Tim Conway put ICS Incident Response first as Critical Control 1. They mean a plan that emerges from operations, focuses on the integrity and recovery of systems, and is practiced with scenarios that fit your own ICS environment (SANS, copy). A post on the SANS blog also recommends running technically grounded ICS tabletops regularly (SANS Blog).

For a grid operator this means: the plan starts with the question of how supply stays secure. Which server gets rebuilt comes later. IT contributes to the plan, but grid control decides when to re-enable systems or switch to manual operation.

Practicing without endangering the grid

Four weeks are enough for the first exercise.

Week 1: Choose a scenario. The scenario should be technically possible in your own installation. For example: the telecontrol link to several substations drops, the operator workstations in the control room are encrypted, or a service provider reports misuse of its remote maintenance access. Or a combination: ransomware encrypts the office IT, an engineering workstation in the control room shows suspicious connections, and unexpected commands appear on an IEC 104 link. That ties IT and OT together, and this is the interface where things usually go wrong.

Week 2: Clarify roles. Define who may cut the telecontrol connection and who decides on the switch to manual operation. Just as important: who has the phone numbers of protection engineering, the grid control system vendor and the on-call duty, on paper. Invite switching supervisors, protection engineering, IT, communications and one person from executive management. CISA provides a free ICS exercise package (Situation Manual) that adapts well to German conditions (CISA ICS CTEP, overview).

Week 3: Play it through. Two to three hours at the table, with a clock. Every participant says what they do at minute 5, at hour 1 and at hour 24. In between come injects, such as "The control room loses visibility of three substations" or "The vendor wants remote maintenance access to the grid control system." The reporting chain is rehearsed too: someone must decide whether an incident is significant, someone writes the 24-hour report, and on weekends that person needs a deputy. Often it only becomes apparent here, for example, that nobody has access to the reporting portal, or that the phone list exists only in the encrypted mail system.

In parallel, it gets practical. A team drives to a substation and checks whether switching on site is possible, who is authorized to do it, and whether the keys are where the plan claims. This works in normal operation, without switching a single device. Recovery also belongs on the test bench: configurations of protection devices, telecontrol components and operator workstations should be available offline, and firmware versions documented.

Week 4: Rewrite the plan. For every gap found, assign an owner and a deadline by which it should be closed. At the next run, check whether that worked. This is exactly one building block for the effectiveness assessment under § 30 BSIG.

Typical gaps in control systems

The following points are typical examples, not study results. A typical gap would be a missing up-to-date asset inventory of the telecontrol substations. In an emergency nobody knows which firmware runs where, and rebuilding takes much longer because first you have to search. Visibility in the OT network can also be missing.

Takeaways

Run a tabletop at least yearly, better quarterly, with a scenario in which the control system itself can't be trusted.
Put grid control, protection engineering, IT and executive management at the same table.
Actually try out manual operation at the substation (possible in normal operation without switching any device).
Keep phone numbers on paper, and keep device configurations offline with documented firmware versions.
Rehearse the 24-hour report with a deputy for weekends.
Rewrite the plan after every exercise, with an owner and a deadline per gap.

If you need support in an actual incident, see OT-Notfallhilfe bei Cyberangriffen (Incident Response).

Original (German): https://ot-cyber.de/blog/notfallplan-im-netzbetrieb-geuebt-statt-abgeheftet.html

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

OT Security Weekly DACH, KW 42/2026: Cooling controllers under attack

Max Bayern — Sun, 18 Oct 2026 09:03:38 +0000

We at OT-Cyber.de rate the overall threat level for OT in Germany, Austria and Switzerland as high for KW 42/2026. Attackers manipulated internet-exposed refrigeration controllers in French supermarkets, and at the same time two edge devices that often guard the IT/OT boundary are under attack: Ivanti Connect Secure is actively exploited, and for Palo Alto PAN-OS the vendor reports very limited exploitation so far. If you run controllers with a public IP or rely on these gateways for remote access, take the controllers off the internet and treat the gateways as possibly compromised.

Key developments this week

Refrigeration controllers in French supermarkets manipulated. During the night of 11 to 12 October, attackers changed temperatures and defrost times in fridges and freezers in several hundred French supermarkets through remote controls that were reachable from the internet. Large amounts of food spoiled. CERTFR-2026-ALE-012 confirmed numerous compromised Danfoss AK-SM and AK-SC controllers on 12.10., added Copeland xweb and Dixell xweb on 13.10. and updated its recommendations on 16.10. CERT-FR considers the campaigns probably still ongoing and expects devices without patches (end of life) to be compromised again even after a factory reset. According to Reuters, at least 4,500 Danfoss interfaces were visible online on 13.10. Matching SANS ICS control: CC4 Secure Remote Access, plus CC5 for the end-of-life hardware.

BSI publishes BSI-CS 154. On 13 October the BSI released BSI-CS 154 "Gefährdung durch internet-verbundene OT-Systeme". It targets operators of small networked installations: food refrigeration, PV inverters, single wind turbines, drinking water and wastewater sites. The demand is blunt. Block direct internet access to controllers and secure remote access. The BSI explicitly warns of copycats. So far there is no confirmed case in DACH; the German retail association BVLH reports none in Germany. Matching control: CC2 Defensible Architecture.

Ivanti Connect Secure zero-day (CVE-2026-104935). The flaw is exploited in the wild and has been in the CISA KEV catalog since 13.10. The downstream privilege escalation in the chain still has no patch, and according to Volexity fully patched devices were affected too. Update to 22.8R2.5, 25.1.1.2 or 25.1.3.x, and do not rely on the Integrity Checker Tool alone. Matching control: CC4 Secure Remote Access, with CC1 for the incident response side.

Palo Alto PAN-OS root RCE via the management interface (CVE-2026-0322). Published 14.10., updated 15.10., CVSS 4.0 score 8.6, exploit maturity ATTACKED. Palo Alto describes very limited exploitation of the management interface; the flaw has been in KEV since 14.10. The advisory FAQ lists three IPs associated with the activity: 66[.]42[.]72[.]14, 208[.]83[.]239[.]114 and 149[.]248[.]47[.]234. Fixed versions include 12.2.4, 11.2.16 and 10.2.18-h12. Matching control: CC2 Defensible Architecture, with CC3 for the log review.

Eclipse Milo: six flaws in the OPC UA server (ICSA-26-288-01). The fix is only in version 1.1.5; the 0.6.x branch gets no patch. Milo is a library, so it hides inside SCADA products, gateways and control systems. Matching control: CC5 Risk-Based Vulnerability Management.

What it means per sector

Power & grids. No confirmed cyberattack on grid operators, municipal utilities or generators in DACH became known this week, so the sector sits at "elevated" rather than "high". The risk still comes in over the IT/OT boundary. At a typical Stadtwerk, an Ivanti VPN or a PAN-OS firewall is exactly what provides remote access into the control room and the segmentation between office and grid control systems. On the renewables side, a study by Modat and NCSC-NL counted 8,547 internet-reachable control and management systems in wind and solar parks, 884 of them in Germany, and at 181 sites in Europe the researchers had full control. If your Ivanti gateway was exposed, hunt in the logs back to 01.10. Full report (German)

Utilities (water, wastewater, municipal). BSI-CS 154 names drinking water and wastewater sites directly, next to refrigeration and PV. Think of the small pumping station or the elevated tank with a controller reachable through a port forward because that was the quickest way to give the integrator access. The same edge devices are in play here as in the power sector. Answer the BSI-CS 154 questions per site and move every external maintenance path behind a VPN with MFA. Full report (German)

Food & beverage. This was the sector most directly hit, at least in France. The attack worked because refrigeration contractors often get remote access the simple way: a public IP or port forward on the store controller, default password unchanged. In Germany and Switzerland the major retailers report no infection so far, and there are no officially confirmed cases in DACH. Production sites with cold storage use the same controllers. Set temperature alarms so they also fire when setpoints are deliberately changed, because an attacker who moves the setpoint can otherwise keep the alarm quiet. Check your insurance terms on data transfer to the contractor before you change the setup. Full report (German)

Machine builders. The French campaign is a lesson about the remote access you ship yourself. Find out which of your controllers and web interfaces are reachable from the internet at customer sites and write to those customers. Get rid of factory default passwords or force a change at commissioning, and inform customers about end-of-life products still in the field. Two more items land on your desk: Siemens SSA-591731 covers web server flaws up to CVSS 9.6 in SIMATIC S7-1500, ET 200SP and drive controllers, with no fix yet. Disable the web server where it is not needed, otherwise restrict 80/tcp and 443/tcp to fixed engineering IPs. And search your SBOMs and build dependencies for org.eclipse.milo, move to 1.1.5 and publish your own advisory. If your service technicians reach customers through an Ivanti gateway, rotate the AD credentials that went through it and review those service paths. Full report (German)

What to do now

Disconnect every refrigeration and building controller with a public IP (Danfoss, Copeland, Dixell and the rest). Contractor access only via VPN with MFA; a firewall rule limited to the contractor's IPs is a stopgap at best. Change default passwords, compare setpoints, configuration and defrost schedules with the target values, set Danfoss devices to the "Strict" security mode and plan replacement of end-of-life units.
Patch Ivanti Connect Secure and treat the gateway as compromised: network and memory forensics, Volexity IoCs, log review. Reset accounts and service accounts used over the VPN. Until the privilege escalation is fixed, put a separate jump host with its own login and MFA between the VPN and the OT network.
Patch PAN-OS and make the management interface reachable only from a dedicated admin network or through a jump host. Enforce MFA for admin accounts, review admin logins and configuration changes of the last weeks, and search logs for 66[.]42[.]72[.]14, 208[.]83[.]239[.]114 and 149[.]248[.]47[.]234.
Ask your SCADA, gateway and control system vendors whether Eclipse Milo is in their SBOM and request their patch plan. Meanwhile disable anonymous OPC UA sessions and keep OPC UA servers reachable only from the OT zone.
Work through the BSI-CS 154 questions for every networked installation (internet exposure, VPN, second factor, update status) and put the answers into your asset inventory.

Full sector reports (German)

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

EU CRA and BSI TR-03183: What Grid Tech Vendors Need to Do Now

Max Bayern — Wed, 14 Oct 2026 08:05:22 +0000

Since 11 September 2026 (Art. 71 CRA, Regulation (EU) 2024/2847), manufacturers of products with digital elements must report actively exploited vulnerabilities and severe security incidents via a reporting platform that ENISA is establishing (BSI). Under the German government's draft CRA implementation act, the BSI is meant to become the market surveillance authority (cyber-regulierung.de). If you build protection, telecontrol, control or metering technology, gateways, routers or software for grid operators, you should now put three things in place: a rehearsed reporting process (mandatory since September 2026), SBOMs, and an intake channel for vulnerability reports. SBOM and vulnerability handling under Annex I become mandatory on 11 December 2027, when all CRA requirements apply (Art. 71, Regulation (EU) 2024/2847). According to the BSI, TR-03183 is an aid to implementation.

This is the English adaptation of my German original.

I'm Max Gilg, an OT cybersecurity expert from Rosenheim. In this series I put the Cyber Resilience Act (CRA) into context for individual industries. Today: vendors supplying the power and grid sector in Germany. It is about obligations and deadlines, not incidents or lab results.

What has been mandatory since 11 September 2026?

The CRA is Regulation (EU) 2024/2847. It applies directly; no national transposition is needed. According to the BSI, it entered into force 20 days after its publication in the Official Journal. Since then it has become applicable in stages (BSI). The reporting obligation under Art. 14 has applied since 11 September 2026 (Art. 71, Regulation (EU) 2024/2847). Reports go through a reporting platform that ENISA is establishing (BSI).

Art. 14 CRA provides for staged deadlines: an early warning, a more detailed notification, and a final report (Regulation (EU) 2024/2847).

The obligation also covers products that were on the market before December 2027 (McCann FitzGerald). For the power sector this means: even a telecontrol substation unit that has been running in the field for years and falls within the CRA's scope is covered as soon as the manufacturer learns that a vulnerability in it is being actively exploited.

Will the BSI become the CRA market surveillance authority?

That is what the government draft of the CRA implementation act provides: the BSI is to take on the role of market surveillance authority. The draft creates no new obligations; those come directly from the EU regulation (cyber-regulierung.de). Important: As of today (14 Oct 2026) I could not verify that the act has been passed and promulgated. Check the status before making decisions.

Violations of Annex I and Art. 13 and 14 can lead to significant fines (Regulation (EU) 2024/2847; Jones Day).

Which power and grid products are particularly affected?

Annex IV (critical): smart meter gateways in smart metering systems (Springlex)
Annex III, Class II: firewalls, intrusion detection and prevention systems (Springlex)
Annex III, Class I: among others VPN products, routers, switches, operating systems, network management and SIEM systems

The EU Commission has clarified these categories technically; the core function is what counts (HSF Kramer). My OT assessment: an embedded VPN module does not automatically make a substation automation system an "important" product, whereas a remote access gateway with VPN as its core function can fall under it in individual cases. For protection devices, RTUs and inverters, classification depends on the individual case. Non-binding EU Commission guidance helps with support period, risk assessment and reporting obligations (Hunton).

What does BSI TR-03183 require?

TR-03183 is the BSI Technical Guideline on the CRA (BSI TR-03183):

Part 1: general requirements for manufacturers and products, modeled on the CRA's articles and annexes
Part 2: formal and technical requirements for SBOMs
Part 3: handling of incoming vulnerability reports

Part 2 requires machine-readable SBOMs. Which format versions and mandatory fields per component apply is defined by the respective version of the TR; the current BSI TR-03183-2 is authoritative.

The BSI presents the TR as an aid to implementation. The details are meant to be defined by harmonised standards that are currently being drafted (BSI).

Which steps should vendors take now?

I map the steps to the SANS Five ICS Cybersecurity Critical Controls (my own assignment):

Rehearse the reporting process (CC1 ICS Incident Response): Who decides on a weekend night whether a vulnerability is "actively exploited"? Define roles, keep a template for the early warning ready, and run the reporting deadlines once against the clock.
An SBOM per firmware release (CC5 Risk-Based Vulnerability Management): generate it automatically in the build, not by hand. Only then can you quickly see which devices in the field are affected after a new CVE.
Intake channel for reports (CC5): security.txt, a reachable PSIRT address, a Coordinated Vulnerability Disclosure policy, and CSAF advisories for grid operators.
Review remote access functions (CC4 Secure Remote Access): default passwords, open services, maintenance ports and permanent tunnels belong in the Annex I risk assessment. Remote access should be disableable, logged and use its own authentication.
Document the architecture (CC2 Defensible Architecture): disclose ports, protocols and security functions so operators can plan zones and conduits per IEC 62443-3-3. IEC 62443-4-1 and -4-2 provide the framework for development.
Logging for operators (CC3 ICS Network Visibility & Monitoring): make security events exportable, for example via syslog, so the grid operator's attack detection (SzA) can analyse them.
Clarify support period and conformity route: The CRA generally requires at least five years of support, adjusted to the expected product lifetime (Art. 13). In grids, devices often run considerably longer. If you need a third-party assessment, plan early.

My take: The reporting obligation is the test run for the whole CRA. Without an SBOM per firmware version, the short reporting deadlines are hard to meet in a real incident.

In my view, AI can also help small product teams, for example with matching SBOMs against new CVEs, drafting advisories, and pre-sorting incoming reports. What matters is focusing on the five SANS controls rather than on individual tools.

What does this mean for grid operators and buyers in Bavaria?

In my experience, many grid operators fall under NIS2 or KRITIS rules and therefore need suppliers that report vulnerabilities quickly. Buyers should already demand an SBOM per TR-03183-2, CSAF advisories, a support period and a PSIRT contact in tenders. This helps the manufacturer meet key CRA obligations and the operator meet its supply chain obligations.

My recommendation: Build the reporting path and the SBOM first. The CRA already requires the reporting path today, the SBOM from December 2027, and grid operators should demand both in tenders.

Who helps manufacturers in Bavaria with the CRA?

With CRA as a Service and OT vulnerability management, I set up reporting process, SBOM pipeline and vulnerability intake with manufacturers in a practical way. For operators there is an OT asset inventory. When things are on fire, there is OT emergency help. I work across the DACH region, with a focus on Bavaria, Salzburg and Tyrol.

Sources

BSI: Cyber Resilience Act – https://www.bsi.bund.de/dok/cra
BSI: CRA topic page – https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Informationen-und-Empfehlungen/Cyber_Resilience_Act/cyber_resilience_act_node.html
BSI: TR-03183 – https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Standards-und-Zertifizierung/Technische-Richtlinien/TR-nach-Thema-sortiert/tr03183/TR-03183_node.html
cyber-regulierung.de: CRA implementation act – https://www.cyber-regulierung.de/cra-durchfuhrungsgesetz/
Regulation (EU) 2024/2847 – https://eur-lex.europa.eu/eli/reg/2024/2847/oj
Springlex: CRA Annex III – https://www.springlex.eu/en/packages/cra/cra-regulation/annex-3/
Springlex: CRA Annex IV – https://www.springlex.eu/en/packages/cra/cra-regulation/annex-4/
HSF Kramer – https://www.hsfkramer.com/fr/notes/cybersecurity/2026-posts/cyber-resilience-act-commission-clarifies-important-and-critical-product-categories
Hunton – https://www.hunton.com/privacy-and-cybersecurity-law-blog/european-commission-issues-guidance-on-the-cyber-resilience-act
McCann FitzGerald – https://www.mccannfitzgerald.com/knowledge/data-privacy-and-cyber-risk/cyber-resilience-act-reporting-obligations-apply-from-11-september-2026
Jones Day – https://www.jonesday.com/en/insights/2026/07/eu-cyber-resilience-act-24hour-reporting-duties-start-september-11-2026

If you want your teams (maintenance, engineering) to practise this, see Cyber-Awareness für Instandhaltung und Technik.

Original (German): https://ot-cyber.de/blog/cra-bsi-und-tr-03183-was-netztechnik-hersteller-tun-muessen.html

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

Fridges Hacked: What Food Producers in DACH Should Do Now

Max Bayern — Wed, 14 Oct 2026 06:01:12 +0000

What happened in France?

This is an English adaptation of my post on OT-Cyber.de. Here is the German original.

On the night of 11 to 12 October 2026, refrigeration controllers in supermarkets of several French chains were manipulated remotely. According to BFMTV, as cited by RTBF, the attackers reportedly forced defrosting (RTBF). Fresh and frozen goods had to be thrown away.

Scope: According to RTBF and AFP, at least 300 stores of Intermarché and Netto are affected, and fewer than 100 stores of Coopérative U. At Monoprix it is around 30 stores, confirmed by the retailers according to AFP (RTBF, AFP).
Damage: Fresh and frozen goods had to be disposed of.
Investigation: The Paris public prosecutor's office is investigating. Besides lost goods, RTBF also mentions equipment that had started to catch fire (RTBF).

Still open: the threat actor, the attack path and the affected firmware versions. I track the current status in my incident situation report (German).

Who is affected?

Affected party	Scope	Status	Source
Intermarché and Netto (Les Mousquetaires)	at least 300 stores	confirmed by the group	RTBF, AFP, franceinfo
Système U (Coopérative U)	fewer than 100 stores	confirmed by the group	RTBF, AFP, franceinfo
E.Leclerc	several stores	affected according to AFP	AFP
Carrefour	80 supermarkets	confirmed by Carrefour	Reuters
Monoprix	around 30 stores	confirmed by the retailers according to AFP	AFP, Je bosse en grande distribution

Why is this an OT incident?

I'm Max Gilg, an OT cybersecurity expert from Rosenheim. To me this is a textbook case: nobody had to encrypt anything or steal data. Remotely triggered defrost cycles were enough to destroy goods. Refrigeration is OT – a setpoint is a control command with physical effect.

According to reports, no customer data was stolen. A classic IT view would have reported "no data breach" while production was down.

Does this also affect companies in Bavaria, Austria and Switzerland?

Remotely accessible refrigeration is common here too. Typical setups in supermarkets, cold storage facilities and food production sites include:

Controllers and system managers connected to a remote monitoring service of the refrigeration service provider.
Permanently open access, often a single account for many sites.
Nobody on site knows exactly who accesses what and when.

For food companies that fall under NIS2, refrigeration belongs in the risk analysis – and manufacturers of such controllers need to prepare for Cyber Resilience Act (CRA) obligations on vulnerabilities and updates.

What should operators do now?

I map the steps to the SANS Five ICS Cybersecurity Critical Controls:

CC1 ICS Incident Response: Define how you continue manually and locally if refrigeration is manipulated. Who may disconnect remote control? Who calls the refrigeration technician? Who decides on disposing of goods?
CC2 Defensible Architecture: Put refrigeration and building systems in their own zone, never directly reachable from the internet.
CC3 ICS Network Visibility & Monitoring: Get alerts on setpoint and operating mode changes, including at night. An alarm at night, e.g. at 4 a.m., is only worth something if someone responds.
CC4 Secure Remote Access: Vendor remote access only with approval, a personal account per user, MFA and logging. Close permanently open tunnels.
CC5 Risk-Based Vulnerability Management: Know the firmware versions of your controllers and prioritize updates by physical impact. EoL controllers no longer get updates: replace them or disconnect them from the internet.

My recommendation: This week, ask your refrigeration service provider who can access your controllers tonight. If the answer takes longer than one sentence, you have your first action item.

With AI, asset inventory and analysis of remote access logs are feasible even for small teams – focusing on these five controls delivers more than any single product.

How I can help

With an OT asset inventory we find out which refrigeration and building systems are reachable. With OT security consulting and attack detection in OT networks we secure remote access and make altered setpoints visible. In an acute incident: OT emergency help, across DACH.

If your maintenance and engineering teams need to recognise these risks: Cyber-Awareness für Instandhaltung und Technik.

Corrected on 14 October 2026: outdated status information, temperature values and an unverified company statement removed.

Original (German): https://ot-cyber.de/blog/kuehlung-gehackt-was-lebensmittelbetriebe-in-dach-tun.html

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

OT Security Weekly DACH – KW 41/2026: Edge Devices Under Fire

Max Bayern — Sat, 10 Oct 2026 07:04:17 +0000

The threat level for OT operators in Germany, Austria and Switzerland stays high in KW 41/2026. Once again, the biggest risks did not come through the PLCs. They came through the edge devices and the remote access in front of the control network. A zero-day in Citrix NetScaler was actively exploited, and Cisco Catalyst SD-WAN Manager has a critical authentication bypass with no workaround. Patching alone is not enough this week: if you don't also hunt for signs of compromise, you may miss webshells and backdoors that are already in place.

Key developments this week

1. Citrix NetScaler: SAML zero-day CVE-2026-88779 also hits devices that were already patched (SANS ICS Critical Control: CC4 – Secure Remote Access)
Attackers are targeting NetScaler Gateways with a SAML configuration. Citrix describes the issue as a denial of service. The flaw also affects devices that had been patched shortly before against earlier vulnerabilities. The patch was released early on 04.10., and reboots were also reported on build 14.1-73.37. Check your configuration for add authentication samlAction or samlIdPProfile and update right away to 14.1-73.41 or 13.1-64.28 (FIPS: 14.1-73.41 FIPS or 13.1-37282). After that, hunt for webshells, new local accounts and foreign sessions. Check for nsaaad crashes since 02.10. Reset sessions and credentials. If you find signs of compromise, rebuild the device and cut its access to the control systems until then.
Source: BleepingComputer

2. Cisco Catalyst SD-WAN Manager: auth bypass CVE-2026-76504 (CVSS 9.8), no workaround (CC2 – Defensible Architecture)
The vulnerability allows attackers to bypass authentication, and there is no workaround. Update to the fixed releases listed in the advisory and review your admin accounts. Take the management interface off the internet and allow access only from a dedicated management network.
Source: Cisco Security Advisory

What it means per sector

Power & grids: For energy suppliers in DACH, the main danger came through edge devices again. Remote access and perimeter systems such as NetScaler and Cisco SD-WAN Manager are affected; the NetScaler attacks were broad and not aimed at any specific sector. Grid operators and municipal utilities often run their remote maintenance through such systems. A recent analysis also found control and login systems in European wind and solar parks openly reachable from the internet (Help Net Security). Check your own public IP ranges for exposed systems. Full report (German)

Food & beverage: In KW 41 we found no publicly confirmed cyberattack on a food or beverage manufacturer in DACH. The situation is still tense, because dairies, breweries and bottlers use the same edge devices for remote maintenance, site networking, mail and remote access. Your business impact analysis and emergency plan should cover how production and shipping keep running if cloud, ERP or logistics IT is down for 3–7 days. That means offline recipes, batch lists, manual delivery notes and cold-storage emergency processes. Practice these procedures (CC1). Also agree on reporting channels, recovery times and backups with your service providers in the contract. For OT remote maintenance, allow access only through a separate jump host with MFA. Full report (German)

Machine builders: Machine builders and system integrators often use the same kind of edge devices for remote maintenance that are affected this week. If you provide remote access to customer plants through NetScaler or Cisco SD-WAN, you need to patch this week and rotate credentials. Build remote maintenance sessions only with MFA and customer approval. Separate the mail gateway from the internal network and from development environments. Check whether your OT segments stay isolated even without the SD-WAN policy. Full report (German)

What to do now

Patch the edge right away: NetScaler (14.1-73.41 / 13.1-64.28), Cisco Catalyst SD-WAN Manager (fixed releases per the advisory).
Hunt for compromise after patching: look for webshells, new local and API accounts and suspicious sessions. Check for nsaaad crashes since 02.10. If you find evidence, start incident response according to your plan (CC1).
Reset sessions and credentials: kill all VPN and admin sessions, rotate passwords and enforce phishing-resistant MFA for every remote access path (CC4).
Take management interfaces off the internet: NetScaler, SD-WAN Manager and other edge devices such as firewalls and mail gateways should be reachable only from a dedicated management network (CC2).
Inventory your end-of-life field devices: find field devices running end-of-life firmware and restrict their interfaces until you can upgrade (CC5).

Full sector reports (German)

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

AI and Firmware: Architecture Beats Point Solutions

Max Bayern — Wed, 07 Oct 2026 08:15:51 +0000

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:

"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".
"What isn't on the internet is safe." Firmware enters the plant via service laptops, USB sticks, update tools and remote maintenance.
"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

Forescout Vedere Labs, 01.09.2026: https://www.forescout.com/blog/can-ai-create-plc-attacks-yes-but-it%E2%80%99s-not-that-easy-yet/
SecurityWeek, 09/2026: https://www.securityweek.com/experiment-porting-a-plc-exploit-with-ai-takes-hours-and-hundreds-of-dollars/
The Hacker News, 09/2026: https://thehackernews.com/2026/09/researchers-use-claude-to-port-pre-auth.html
Cybersecurity Dive: https://www.cybersecuritydive.com/news/frontier-ai-exploit-flaws-water-PLCs-industrial-devices/829307/
Chaz Schlarp, Everything I own, owned, 23.08.2026: https://schlarp.com/posts/everything-i-own-owned/
CERT@VDE, VDE-2021-050: https://certvde.com/en/advisories/VDE-2021-050
SANS, Five ICS Cybersecurity Critical Controls: https://www.sans.org/white-papers/five-ics-cybersecurity-critical-controls/
Regulation (EU) 2024/2847: https://eur-lex.europa.eu/eli/reg/2024/2847/oj
EU Commission, CRA Reporting: https://digital-strategy.ec.europa.eu/en/policies/cra-reporting
Pillitteri, CRA reporting obligations: https://pasqualepillitteri.it/en/news/15586/cyber-resilience-act-reporting-obligations-september-11
Bundesregierung, NIS-2: https://www.bundesregierung.de/breg-de/aktuelles/nis-2-richtlinie-deutschland-2373174
DSN Group, NIS2UmsuCG: https://www.dsn-group.de/datenschutz-notizen/das-nis-2-umsetzungsgesetz-ist-in-kraft-getreten-welche-schritte-sind-nun-erforderlich-4457509

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).

Tanker Hack: What Access to the Propulsion System Means for OT

Max Bayern — Mon, 05 Oct 2026 09:38:59 +0000

On 21 August 2026, the US Coast Guard and the FBI boarded a crude oil tanker. This post is a short English adaptation of my German original and looks at what the incident means for OT, plants and machinery.

What happened

The vessel is the VL Prosperity: 333 meters long, carrying roughly 2.3 million barrels of crude oil, flying the Liberian flag. The trigger was information that "foreign cyber actors" had compromised the onboard networks. The Coast Guard confirms "malicious cyber activity". On 2 October 2026, Bloomberg reported, citing US officials, that investigators had found evidence of temporary access to the propulsion system.

What I want to state explicitly:

The FBI says there are currently no reports of an operational disruption, a danger to the crew or environmental damage.
It is not proven that the attackers changed anything on the propulsion system.
The dramatic accounts (throttled cooling, increased engine speed, 30 hours of radio outage) come from Iranian state media and are unconfirmed.
The engine room images circulating alongside them are fakes, according to an analysis by Cydome.

All confirmed facts, open questions and assessments with sources are in our incident situation report on the VL Prosperity (in German).

Why this is not just a maritime topic

A modern tanker is a floating plant: propulsion, auxiliary systems and cargo monitoring, all connected via controllers and networks. On top of that come satellite communication, remote maintenance by vendors and digital machinery monitoring. The Coast Guard names connectivity as the reason for the vulnerability: "When these vessels are highly connected, they're susceptible to cyber threats." The technical hurdle is "not necessarily that sophisticated".

Replace "ship" with "production line" and "satellite communication" with "remote maintenance router", and you get a fairly accurate description of how many connected production plants are built today.

If the path really led through the onboard IT all the way to the machine, the tanker shows what is possible then. Whether ship or filling line: if you don't know who can reach your controllers from the outside, you have already given up half of your control.

Five lessons for plants and machinery

I map them to the SANS Five ICS Cybersecurity Critical Controls.

Know and control remote access (CC4, Secure Remote Access). On ships as in factories, vendors often have permanent access. Every access path should be inventoried, logged and enabled only when needed, via a jump host with MFA.
Separate IT and the control level (CC2, Defensible Architecture). In an incident like this, a central question is whether the onboard IT was connected to propulsion and navigation. Every operator should be able to answer that question for their own plant.
See what happens in the OT network (CC3, Network Visibility). It is not publicly known how long the attackers were in the system on board. Without detection in the OT network, this is also one of the most common open questions after an incident in production.
Practice manual operation and restart (CC1, Incident Response). According to DNV, most ships have backup systems. In my view, these make the difference between an incident and a casualty. In production, the question is: do operations and maintenance know how to safely keep running or shut down without the control system?
Take legacy systems seriously (CC5, Risk-Based Vulnerability Management). The new cyber requirements for ships (IACS UR E26/E27) only apply to newbuilds with a construction contract from 1 July 2024 – the VL Prosperity dates from 2015. Mechanical engineering is similar: the CRA applies to products newly placed on the market, while existing plants often keep running for many more years.

Lesson six: disinformation belongs in the incident plan

Fake images, unconfirmed accounts from state media, anonymous sources: in this incident, a large part of the reporting was hard to verify. Anyone who has to inform customers, authorities and press in a real emergency needs prepared statements and a clear separation between "confirmed" and "assumed". That is exactly why our incident situation reports work with a counted knowledge scale.

And what about AI?

According to a report by Anthropic from September 2026, an Iran-linked threat actor used AI to compile public data on US naval forces and known vulnerabilities in maritime VSAT terminals and industrial controllers. A connection to the VL Prosperity is not proven. But it shows how quickly attackers can assemble targets and weaknesses today – one more reason to focus on the five controls rather than on point solutions.

Practical takeaways

Inventory every remote access path to your controllers; use a jump host with MFA.
Be able to answer whether your IT network is connected to the control level.
Get visibility and detection in the OT network.
Practice manual operation and restart without the control system.
Plan for legacy systems that will keep running for years.
Prepare statements that separate "confirmed" from "assumed".

How we support

If you want to know which remote accesses point to your controllers, we start with an OT security consulting engagement or an OT asset inventory. For machine builders who build remote maintenance into their products, CRA as a Service is the right entry point. And if things are already on fire: OT incident response. To prepare maintenance and engineering teams, see Cyber awareness for maintenance and engineering.

Original (German): https://ot-cyber.de/blog/tanker-hack-was-der-zugriff-auf-den-antrieb-fuer-ot-bedeutet.html

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

OT Security Weekly DACH – KW 40/2026: Edge Zero-Days in Remote Access

Max Bayern — Sun, 04 Oct 2026 07:04:57 +0000

The threat level for OT operators in Germany, Austria and Switzerland stays high in KW 40/2026. Once again the biggest risk comes through edge devices used for remote access and for connecting sites. Citrix NetScaler ADC/Gateway has zero-days under active exploitation, and Cisco Catalyst SD-WAN Manager has a critical flaw. Both sit right at the boundary that many operators rely on to reach their OT.

Key developments this week

1. Citrix NetScaler ADC/Gateway: two RCE zero-days under active exploitation (CVE-2026-88771, CVE-2026-88772)
Both flaws allow unauthenticated Remote Code Execution. CISA has added both to the KEV catalog. Fixed builds are listed in the Citrix security bulletin.
Source: CISA alert · SANS ICS Critical Control: CC4 – Secure Remote Access

2. Cisco Catalyst SD-WAN Manager: critical flaw grants admin rights without authentication (CVE-2026-76504, CVSS 9.8)
A patch is available, but there is no workaround.
Source: Cisco Security Advisory · SANS ICS Critical Control: CC2 – Defensible Architecture

3. MikroTik RouterOS: pre-auth RCE in the web management
Update RouterOS to the fixed version listed in the advisory.
Source: CISA ICS Advisory · SANS ICS Critical Control: CC5 – Risk-Based Vulnerability Management

4. Lantronix G520 LTE gateway: root code execution through an insecure firmware update chain
An attacker can inject firmware that runs with root privileges. Install the fixed firmware version listed in the advisory.
Source: CISA ICS Advisory · SANS ICS Critical Control: CC5 – Risk-Based Vulnerability Management

5. Ransomware: activity against the industrial sector remains high
Source: Industrial Cyber · SANS ICS Critical Control: CC1 – ICS Incident Response

What it means per sector

Power & grids: The biggest risk this week was remote access, meaning the edge devices used for Remote Access and for connecting sites. In our experience, municipal utilities and grid operators commonly use Citrix NetScaler and Cisco SD-WAN to connect service providers for Fernwartung (remote maintenance), as well as control centres and outstations. These devices also enforce segmentation all the way into the OT. If an attacker takes over one of them, they are standing directly in front of the grid control systems. CISA has added the Citrix zero-days to the KEV catalog. Full report (German)

Food & beverage: Many plants route the remote maintenance that machine builders provide for filling, packaging and refrigeration lines through exactly these systems. The same systems often connect plants, bottling sites, warehouses and cold stores. Patches exist for both Citrix and Cisco, but Cisco has no workaround. On top of that come flaws in MikroTik routers and Lantronix cellular gateways. Edge devices like these often sit unnoticed in outlying warehouses, cold stores, collection points and on machines. Ransomware pressure remains high. Full report (German)

Machine builders: Machine and plant builders deliver remote maintenance and connect their sites through exactly the edge devices being targeted. Besides Citrix and Cisco, three other issues matter for remote maintenance:

vulnerabilities in TeamViewer
the MikroTik RouterOS pre-auth RCE
the manipulable firmware update chain in the Lantronix G520

These components are often built into remote maintenance boxes, control cabinets and industrial PCs in plants already delivered to customers. Search your Asset-Inventar and product SBOMs, roll out the updates and tell your customers. In your own products, check that updates only run over TLS with a verified signature. Full report (German)

What to do now

Citrix NetScaler: Before you patch, back up logs and snapshots and hunt for IoCs, including the ones Citrix provides through the NetScaler Console. Then update to the fixed builds listed in the Citrix security bulletin. After patching, kill all sessions and rotate the credentials used through the gateway, especially those of remote maintenance accounts. Hunt for webshells and unexplained gaps in logging. Check which customer or OT systems were reachable through the gateway. If you find signs of compromise, check your reporting obligations under NIS2/BSIG.
Cisco SD-WAN Manager: Patch immediately and make the Manager reachable only from an admin network. Search the Manager's access logs for requests with malformed URI encoding and check the full Cisco advisory for the exact IoCs. If you get hits, start Incident Response. Then compare the SD-WAN configuration against a known-good version to spot unplanned routing changes.
Edge inventory: Use network scans to find MikroTik and Lantronix G520 devices that are missing from the Asset-Inventar. Update MikroTik and the G520 to the fixed versions from the vendor advisories, prioritising by how critical each station is. Expose management interfaces only to a dedicated management network, and install firmware only through a verified path from a trusted source.
Remote access architecture: Route Fernwartung into the OT through a central, logged Jump Host with MFA and approval per session, not directly through the gateway. Remove shadow access via LTE routers.
Incident readiness: Define and rehearse an OT Incident Response playbook for running without MES/ERP. Test restoring PLC programs, HMI projects and MES databases from offline backups at least once a quarter. In Austria, check whether the NISG 2026 applies to you and decide who submits the 24-hour early warning.

Full sector reports (German)

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

Securing Citrix NetScaler: A Checklist for Operators, Including OT

Max Bayern — Sat, 03 Oct 2026 15:19:41 +0000

If you run Citrix NetScaler ADC or Gateway, you need to do three things now:

Install the fixed builds (14.1-73.37 or 13.1-64.23, or the corresponding FIPS/NDcPP builds).
Check the appliance for webshells and other traces of compromise.
Separate OT remote access from the corporate gateway.

This affects organizations that run vulnerable NetScaler builds. Mandiant names targeted sectors in North America and Europe. At utilities and industrial companies, NetScaler is often the path service providers use to reach control centers and plants.

What happened?

Since early September 2026, a threat actor has been exploiting two zero-days in NetScaler (CVE-2026-88771, CVE-2026-88772). Mandiant does not attribute the activity to a specific actor. Mandiant knows about the exploitation of CVE-2026-88771 only from vendor information. Mandiant describes an exploitation campaign with reconnaissance and credential theft that uses:

several PHP webshells (including WHIPSHOT)
a tunneling tool (SLAPSHOT)
persistence via handlers in httpd.conf and an SUID bit on /bin/sh
credential theft in the internal network

Citrix has released fixed builds.

My assessment: A patch closes the door, but it doesn't throw out anyone who's already inside. So check every appliance for the traces Mandiant describes, even if it is already patched.

Step 1: Patch the right way

Install the fixed builds (14.1-73.37, 13.1-64.23 or the corresponding FIPS/NDcPP builds) on every ADC and Gateway instance, including test and emergency systems.
My recommendation as general best practice: terminate all active sessions after patching. That way, sessions that may have been stolen lose their validity.
Replace older firmware branches that are out of support. Don't keep running them.

Step 2: Check for compromise

A patch does not remove webshells or backdoors. Check every appliance, even if it's already patched:

File system: Look for unknown PHP files and unexpected .deb or .sig files in the VPN directories, especially under /var/netscaler/gui/vpn/scripts/linux/ (also vista/ and mac/), /netscaler/ns_gui/vpn/media/ and /var/vpn/theme/. Mandiant has published IoCs for this.
Persistence: Check /etc/httpd.conf for unknown AddHandler or AliasMatch entries, check whether /bin/sh has the SUID bit set, and look for /tmp/.uxdport or /tmp/.uxdlock and unexpected Python processes.
Logs: Go back to early September. Watch for NSPPE crashes (ssl_handshake_failure with DTLS, pitboss messages in /var/log/messages) and check the httpaccess and httperror logs for unusual 404 responses with a large body.
Follow-on access: Check whether the NetScaler opened connections into the internal network that aren't part of normal operations.

If you find something, don't just rebuild the appliance. Preserve evidence first, then start incident response and rotate every credential that went through the gateway.

Step 3: Protect your OT

At utilities, municipal utilities (Stadtwerke) and machine builders, NetScaler often fronts more than office IT. Remote maintenance, the control center and service providers' access also run through it. That means:

Secure Remote Access (SANS CC4): Never route OT remote access straight through the corporate gateway. Use a dedicated jump host with MFA and per-session approval.
Defensible Architecture (SANS CC2): Put a firewall with clear rules between IT and OT. A compromised gateway must not be able to reach the control systems.
Network Visibility & Monitoring (SANS CC3): Monitor connections from IT into OT networks. That's where lateral movement shows up first.

If you also use your NetScaler gateway for OT, you've turned an IT problem into a plant problem.

What this means for NIS2 and critical infrastructure (KRITIS)

If you fall under NIS2 and find a compromise, you have reporting obligations with short deadlines. So document the check itself carefully: what you checked, when, and what you found.

Quick checklist

[ ] Fixed builds (14.1-73.37 / 13.1-64.23 or FIPS/NDcPP builds) installed on all ADC/Gateway instances, including test and emergency systems
[ ] All active sessions terminated after patching (best practice)
[ ] Unsupported firmware branches replaced
[ ] VPN directories (/var/netscaler/gui/vpn/scripts/, /netscaler/ns_gui/vpn/media/, /var/vpn/theme/) checked against Mandiant IoCs
[ ] /etc/httpd.conf, SUID bit on /bin/sh, /tmp/.uxd* files and Python processes checked
[ ] Logs reviewed back to early September (NSPPE crashes, httpaccess/httperror, 404 responses with a large body)
[ ] Unexpected outbound connections into the internal network checked
[ ] OT remote access separated from the corporate gateway (jump host, MFA, per-session approval)
[ ] All checks documented for NIS2

Further resources

Live incident tracker (German): Vorfall-Lagebild
Securing remote maintenance for the long term: OT security consulting

Original (German): https://ot-cyber.de/blog/netscaler-absichern-checkliste-fuer-betreiber-in-dach.html

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

Monta EV charging flaws: chargers can be impersonated (CVSS 9.4)

Max Bayern — Sat, 03 Oct 2026 07:46:36 +0000

TL;DR: CISA advisory ICSA-26-274-02 (October 1, 2026) lists four vulnerabilities in all versions of the Monta EV charging platform (monta.app), the worst rated CVSS 9.4. The OCPP WebSocket endpoints do not authenticate charging stations, and station IDs are publicly visible. Anyone operating chargers through Monta should enable OCPP 1.6 Security Profile 2 (Basic Auth over TLS) with a unique password per station as soon as possible.

What CISA published

CVE	Weakness	CVSS v3.1
CVE-2026-95102	Missing authentication on OCPP WebSocket endpoints (CWE-306) – attackers can impersonate a charging station	9.4
CVE-2026-97363	No limit on authentication requests (CWE-307) – brute force and denial of service	7.5
CVE-2026-97212	Multiple endpoints can connect with the same session ID (CWE-613) – may allow authenticating as other users	7.3
CVE-2026-93474	Insufficiently protected credentials – charging station identifiers are publicly accessible via web-based mapping platforms	see advisory

CISA lists the Energy and Transportation Systems sectors and worldwide deployment.

Why this is easy to abuse

A charger opens a WebSocket to the backend and identifies itself with its station ID. Without authentication, that ID is the only "secret" – and according to the advisory it is visible on public charging maps. In my assessment, an attacker could potentially connect as that charger with nothing more than a WebSocket client and perform unauthorized actions – and because authentication attempts are not limited, this could also enable denial of service.

Not a one-off

My take: this is likely an industry pattern rather than a one-off. OCPP has had security profiles for years – they just have to be switched on. Charging infrastructure is OT and deserves the same discipline as a substation.

Practical checklist for operators

Mapped to the SANS Five ICS Cybersecurity Critical Controls:

Enable Security Profile 2 (CC4 Secure Remote Access): TLS with server certificate plus Basic Auth for every station, with a long, unique password unrelated to the station ID. Monta states in the advisory that it supports this.
Close unauthenticated access (CC2 Defensible Architecture): Once all chargers are migrated, work with Monta to block unauthenticated connections for your stations. Monta says it will phase them out on a rolling basis – don't wait.
Inventory and firmware (CC5 Risk-Based Vulnerability Management): Which charger talks to which backend, on which firmware? Does the firmware support Profile 2 at all?
Monitor the charging operation (CC3 Network Visibility & Monitoring): Duplicate logins for the same station ID, connection drops and implausible meter values are red flags.
Plan the incident (CC1 ICS Incident Response): Who shuts what down if chargers fail at scale or report false data? Who informs customers and authorities?

Mid-term, move to Security Profile 3 (mutual TLS with client certificates) or OCPP 2.0.1.

Regulatory angle (EU)

Recharging point operators are explicitly listed in Annex I (energy sector) of the NIS2 directive. Whether a specific operator is in scope depends on national law and size thresholds.

Original (German, with regional context for Bavaria, Salzburg and Tyrol): Monta-Lücken: Ladesäulen übernehmbar – was Betreiber tun

Weekly OT threat picture for DACH by sector: ot-cyber.de/berichte · Help with OT vulnerability management: OT-Cyber.de

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