DEV Community: Max Bayern

OT Security Weekly DACH, KW 46/2026: Remote Access & Refrigeration

Max Bayern — Sat, 14 Nov 2026 08:02:44 +0000

The overall threat level for OT in Germany, Austria and Switzerland stays elevated for KW 46/2026 (06 to 13 November). Two topics stood out this week: attacks on refrigeration systems and weaknesses in remote access. Industrial remote maintenance portals, PHP2Shell vulnerabilities and an SSL VPN under active exploitation were the main problems on the access side.

Key developments this week

mbCONNECT24: Remote Code Execution without authentication (VDE-2026-128, CVSS 3.1: 9.8 and 8.1). On 10 November, MB connect line published two PHP2Shell vulnerabilities in the mbCONNECT24/mymbCONNECT24 remote maintenance portal through CERT@VDE. Version 2.21.6 fixes them. Helmholz also reported vulnerabilities in its myREX24V2 remote maintenance server. CERT@VDE advisory · SANS ICS Critical Control: CC4 Secure Remote Access
Refrigeration attacks: France blames an IRGC-linked unit. According to BleepingComputer (09 November), France attributes the October attacks on Danfoss refrigeration controllers in around 700 targeted stores to Shahid Kaveh, a unit linked to Iran's Revolutionary Guards. France has not attributed the later November wave in six European countries. BleepingComputer · SANS ICS Critical Control: CC1 ICS Incident Response
SonicWall SonicOS SSL VPN: CVE-2026-19868 actively exploited. Since 06 November, this vulnerability has been listed in CISA's Known Exploited Vulnerabilities catalog. CISA · SANS ICS Critical Control: CC4 Secure Remote Access
OpenSSH SSHole: login without a valid password. The flaw affects Linux systems using musl libc without PAM and is fixed in OpenSSH 10.6p2. This matters for embedded Linux devices that offer SSH access. SecurityWeek · SANS ICS Critical Control: CC5 Risk-Based Vulnerability Management

What it means per sector

Power & grids. Operators should ask two questions: would their own separation between IT and control systems hold in a real incident, and can they keep operating without IT? Show that there is no permanent link from office IT into control systems, such as a shared Active Directory, a jump host or file shares. Practise running with office IT isolated, including billing, feed-in payments and the report to BSI (CC2, CC1). For PHP2Shell, ask your system supplier which components use PHP. Until updates are in place, allow access to web interfaces only from fixed admin hosts and monitor that traffic (CC2, CC3). Full report (German)

Food & beverage. This week, the cold chain dominated this sector. Anyone running refrigeration systems with remote maintenance has to expect state actors too. For dairies, meat processors and cold stores, this was the most important news of the week. Our assessment is that devices from the affected vendors are also likely to be in use in DACH. Find every refrigeration controller with remote access, remove public IP addresses, and allow access only through a hardened VPN with MFA. Set temperature and setpoint alarms so that someone responds at night as well (CC2). We found no confirmed ransomware case with a production stoppage at a DACH food or beverage manufacturer in this period. Full report (German)

Machine builders. The week was mostly about vulnerabilities in remote maintenance portals and edge software. If you run your own mbCONNECT24 instances, update them to 2.21.6 right away, then review the access logs and inform affected customers. Update myREX24V2 to the latest version and make its admin interface reachable only from the management network. Open engineering project files only from known sources and keep engineering stations without email or internet access (CC2). For product security under the Cyber Resilience Act, SSHole is relevant. Practise incident response for a compromised remote maintenance setup, including customer notification and the CRA reporting process (CC1). Full report (German)

What to do now

Patch remote maintenance portals now. Have your service provider update mbCONNECT24 to 2.21.6 and myREX24V2 to the latest version. For hosted instances, ask the machine builder in writing for the patch level and date. Until then, open connections only when needed (CC4).
Harden the SSL VPN. Read the vendor notice for CVE-2026-19868 and patch. Enforce phishing-resistant MFA, and check VPN logs from the past weeks for logins at unusual times or from foreign countries (CC4, CC3).
Take refrigeration off the internet. Allow access only through a VPN with MFA, set plausibility limits on setpoints with alarms, and decide who shuts the system down in an emergency and how it runs without remote control (CC2, CC1).
Track embedded SSH and PHP exposure. In your asset inventory, flag embedded Linux devices with SSH access and ask the vendors whether they are affected by SSHole and PHP2Shell. Until the update, disable password logins or allow SSH only from the management network (CC5).
Test your IT/OT separation. Verify that there is no permanent path from office IT into control systems, and practise running with office IT isolated (CC2, CC1).

Full sector reports (German)

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

OT Security Weekly DACH, KW 45/2026: Remote Maintenance in Focus

Max Bayern — Sat, 07 Nov 2026 08:09:36 +0000

The overall OT threat level for DACH (Germany, Austria, Switzerland) is high in KW 45/2026. The most important incident this week is the attacks on refrigeration systems in German supermarkets. According to dpa/Handelsblatt, in one affected case (Wetter-Volmarstein) the actual attack hit the company that maintains the cooling systems remotely; for the other locations no attack path has been published. At the same time, attackers are exploiting edge devices at the boundary between IT and OT: Siemens SIMATIC IoT2050 Advanced with Node-RED and Zyxel GS1900 switches. Ivanti Connect Secure users should also check that they have installed the patch Ivanti released on October 29.

Key developments this week

Supermarket refrigeration attacked, in one case via the remote maintenance provider. According to dpa/Handelsblatt (Nov 3), refrigeration systems in German supermarkets were apparently manipulated remotely, among others in Lilienthal, Wuppertal, Wetter-Volmarstein, Reisbach (Lower Bavaria), Raesfeld (Münsterland) and the districts of Kaiserslautern and Kusel. For Wetter-Volmarstein the report says the actual attack was on the firm that maintains the refrigeration systems remotely. For the other locations the article names no attack path. Handelsblatt. SANS ICS Critical Control: CC4 Secure Remote Access.
Joint US advisory on refrigeration and cold-chain monitoring. On November 5, CISA, FBI, HHS, USDA and the Department of Transportation published a joint call to harden refrigeration controllers and cold-chain monitoring. Core points: no controller panels on the internet, remote access only behind an up-to-date firewall, OT on a dedicated VLAN, no default passwords, phishing-resistant MFA where feasible, and alerts on setpoint deviations. CISA. CC4 Secure Remote Access.
Siemens SIMATIC IoT2050 Advanced: Node-RED flaw exploited (CVE-2026-58115, CVSS 10.0). The missing-authentication flaw affects IoT2050 Advanced devices running Industrial OS with Node-RED installed. Siemens fixed it in August (SSA-834709); VulnCheck has observed exploitation attempts against its honeypots since October 30. Fix: Node-RED 4.3.4.1 or later, or remove Node-RED. The Hacker News. CC5 Risk-Based Vulnerability Management.
Zyxel GS1900 zero-day (CVE-2026-107441). According to BleepingComputer (Nov 4, citing GreyNoise), attackers compromised 996 switches in 48 countries through an out-of-bounds write in the web management interface of ten GS1900 models. Zyxel released new firmware on October 22. BleepingComputer. CC5 Risk-Based Vulnerability Management.
Siemens Industrial Edge: Brotli vulnerability (SSA-443410, CVE-2026-111497, CVSS 9.8). Affected are both management applications on the IEM and device applications on the edge devices. Updates exist for Cloud Connector Configurator (V1.24.3), Databus Configurator (V4.0.1), DataXess Configurator (V1.5.7), Edge OPC UA Server Configurator (V2.3.10), Flow Creator Configurator (V1.15.1) and Data Flow Monitoring (V3.0.18). There is no fix yet for Common Configurator: on the device (CC on Edge) Siemens says to stop it; on the IEM, uninstall all management applications and protect the IEM with a firewall/WAF. If no management applications are installed, nothing needs to be done on the IEM side; check device applications separately. Industrial Edge Hub and IEM Cloud are fixed centrally. Siemens ProductCERT. CC5 Risk-Based Vulnerability Management.
Follow-up: Ivanti Connect Secure. Volexity documented a chain of zero-days on October 13 (CVE-2026-104935, CVE-2026-111357) that allowed unauthenticated root code execution. The patch for the privilege escalation part (CVE-2026-111357) followed on October 29. Anyone who patched only in mid-October still needs that update. Volexity. CC4 Secure Remote Access.

What it means per sector

Power & grids (threat level: elevated). In KW 45 there was no publicly known attack on grid control systems, protection systems or substations in DACH. The risk is at the edges: Ivanti Connect Secure, SIMATIC IoT2050 Advanced with Node-RED and Zyxel GS1900. At municipal utilities, these devices often sit exactly where remote maintenance and data links lead into OT. Full report (German)

Food & beverage (threat level: high). This week is about the cold chain. According to dpa, refrigeration controllers in German supermarkets were apparently manipulated remotely, and food had to be thrown away. According to The Hacker News, a Danfoss spokesperson told the Dutch broadcaster NOS that the affected stores there were not on a secure network and still used default passwords (The Hacker News). Full report (German)

Machine builders (threat level: elevated). SIMATIC IoT2050 Advanced is a gateway of the kind found in many machines, and its Node-RED flaw is now being exploited. In the refrigeration attacks, one German case points to the company that maintains the systems remotely. That matters to every OEM and integrator that runs remote access to customer plants: one compromised service account can reach many customers at once. Full report (German)

What to do now

Lock down vendor remote access (CC4, immediately): List all remote access paths used by service providers (refrigeration, filling, packaging, building services). End permanent connections and allow access only on request, with MFA and logging through a Jump Host. Ask providers in writing whether they are affected and which credentials they store for your systems.
For OEMs and integrators (CC4, immediately): Harden your remote maintenance platform with MFA, customer approval per session, separate credentials per customer and log reviews. Stop sharing service credentials across customers.
Patch and isolate edge devices (CC2/CC5): Search your asset inventory for IoT2050 Advanced with Node-RED and GS1900. Update Node-RED to 4.3.4.1 or remove it; update the GS1900 firmware, expose the web UI only from a management VLAN and change every password that was in the switch configuration. On Ivanti Connect Secure, install the October 29 patch and renew all credentials and sessions used through the gateway. Handle Industrial Edge according to SSA-443410 (including CC on Edge and Data Flow Monitoring) and separate the IEM from the rest of the network.
Segment refrigeration and remote maintenance systems (CC2, 0 to 3 months): Put them in their own network zone, separate from the office network. Replace unsupported devices.
Build network visibility and run an IR exercise (CC3/CC1, 0 to 3 months): Monitor traffic between IT and OT so Lateral Movement and Webshells are detected. Run an Incident Response exercise for an extortion scenario with data exfiltration, including the NIS2 notification.

Full sector reports (German)

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

Exposed Building Automation Services: Bavaria and DACH

Max Bayern — Mon, 02 Nov 2026 16:18:02 +0000

On 02.11.2026 I used Shodan to measure how much building automation in Germany is directly reachable from the internet. This is an English adaptation of my post; the full write-up is here: German original. The short version: a considerable number of services, most of them KNXnet/IP.

What I looked at

Building automation and control systems (BMS, German: Gebäudeleittechnik, GLT) cover everything that keeps a building running: heating, ventilation, air conditioning and refrigeration, lighting and blinds, energy meters, access control, and the control layer that ties it together. In many companies this technology belongs neither to IT nor to production. It sits with facility management or the electrical contractor, so few people look at it.

I used Shodan, which continuously scans the internet and identifies services by their responses. Shodan has its own detection for BACnet and KNX. I also searched for Tridium Niagara and included web interfaces of typical BMS products. I only counted totals and did not look at individual installations.

Important caveat: Shodan counts reachable services, not devices, and says nothing about whether a device is protected by additional measures.

How much building technology is reachable in Germany?

A considerable number of building automation services. The groups found, from largest to smallest:

System	Found in Germany	Also found in Bavaria
KNXnet/IP (lighting, blinds, room control)	by far the largest group	yes
Saia PCD Webserver	yes	yes
Sauter moduWeb	yes	yes
BACnet/IP (with BACnet response)	yes	yes
Tridium Niagara (excluding cloud hosters)	yes	yes
BAB eibPort (KNX server)	yes	yes

In addition Shodan finds WAGO controllers with a web interface. WAGO runs in buildings and in industry, so I do not include them in the count.

Three notes on the counting:

On the BACnet port Shodan reports far more hits than actually answer with BACnet. If you only count the port, you significantly overestimate the situation.
Some of the BACnet responders report HikCentral Professional as the product, so not a classic building controller. I left them in anyway. My assessment: anyone who connects them via BACnet is linking them to the building technology.
For Niagara, most hits were at Linode and Alibaba Cloud. My assessment: these are more likely test or research systems than buildings, so I only count the services outside these clouds.

Bavaria, Salzburg and Tyrol

Shodan also finds reachable BMS services in Bavaria, most of them KNXnet/IP.

In Austria, too, KNXnet/IP is a topic, including in the states of Salzburg and Tyrol. Switzerland also shows reachable KNXnet/IP services.

For our border region around Rosenheim this means KNX is the most important topic in building technology. A note on accuracy: Shodan assigns location via the IP address, which can also be the provider's headquarters.

How dangerous is this?

I rate the situation as high. According to CISA, an attacker with network access can access the KNX installation. The Shodan count does not show whether a gateway uses KNX Secure.

Exploitation is documented. In October 2021 a German engineering firm contacted Limes Security because it had lost control of a customer's building automation. Limes Security calls the attack wave KNXlock. According to Tech Times, citing Limes' analysis, an attacker wiped hundreds of devices over the internet and set their own password, the so-called BCU key. Lighting, blinds, heating, ventilation and air conditioning, and motion detectors failed, and the building ran on manual circuit breakers for weeks. According to the report, the estimated replacement cost was over 100,000 euros. For this vulnerability CISA published advisory ICSA-23-236-01 on 24.08.2023 (CVE-2023-4346, CVSS 7.5).

The web interfaces are no better. According to Shodan, all panels found from Saia PCD, Sauter moduWeb, eibPort and WAGO respond unencrypted over HTTP. Anyone logging in there risks sending their password in cleartext. According to Shodan, many moduWeb panels run on a Jetty web server version 7.6.16.

For Niagara I checked the software version with a somewhat broader query (only Linode and Alibaba excluded). Of these, a majority still report version 3.7 or 3.8.

Who is hit hardest?

Not every reachable KNX gateway is a disaster. A large share sit on connections of the largest access providers, mostly ordinary internet connections. My assessment: a good share of them are in private homes. It becomes critical where building technology secures operations:

Data centers: cooling and ventilation decide availability.
Food, cold storage, pharma: if temperature control fails, goods spoil.
Hospitals and care facilities: ventilation, heating and access.
Manufacturing halls in mechanical engineering: hall climate, compressed air and energy. A tampered ventilation or refrigeration system can stop production.

A production manager rightly thinks in terms of downtime and restart. The question is not whether someone makes the lights flicker, but how long the hall stands still if cooling fails and nobody has the key for the locked devices.

What I recommend to operators now

My recommendations:

Secure remote access: Never put building technology directly on the internet. Electricians and system integrators should only come in via VPN or a secured Remote Access path with a personal login per user.
Segment the network: Put the BMS in its own segment, separate from the office network and from production. Remove gateways left over from the construction phase after acceptance.
Know what you have: Put all KNX gateways, DDC controllers and web panels into your OT asset inventory. Check firmware, change default passwords, replace old panels and outdated Niagara versions. For KNX, set the BCU key and hand it to the owner together with the project documentation, as the KNX Association recommends in the CISA advisory. Demand KNX Secure for new builds.
Look at the traffic: Capture KNX and BACnet traffic and alert on write access from unknown stations. Attack detection in OT networks does exactly that.
Plan for emergencies: Who switches over manually on site? Where are the project data and keys? Who can be reached at the integrator? For the worst case there is OT incident response support.

"If you do not have your building technology in your asset inventory, you will not even know which system is being controlled by someone else in an emergency." Max Gilg, OT cybersecurity expert from Rosenheim

What NIS2 and the CRA have to do with it

For operators within the scope of NIS2, the network and information systems that keep their service running are part of risk management. My assessment: in data centers, hospitals and food production, building technology is part of that. For manufacturers of new connected BMS products, the Cyber Resilience Act is also relevant. For the installed base in the basement, both only help if someone knows the systems.

If you want to know where your own building technology stands, OT-Security in Bayern offers a point of contact. The same applies to Salzburg and Tyrol.

How I counted

The basis is the Shodan API, queried on 02.11.2026. Counted are services that responded in the last scan. A device with two open services can appear twice; devices behind a router without port forwarding are missing. Location follows the IP address. Vendor assignment is based on banner and page title. I do not publish individual addresses or installations.

If your maintenance and technical teams need to understand these risks, see Cyber-Awareness für Instandhaltung und Technik.

Original (German): https://ot-cyber.de/blog/1-500-offene-gebaeudesteuerungen-lage-bayern-und-dach.html

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

OT Security Weekly DACH, KW 44/2026: PHP2Shell in OT products

Max Bayern — Sat, 31 Oct 2026 08:03:08 +0000

The overall threat level for OT in Germany, Austria and Switzerland is elevated for calendar week 44/2026. Power & grids, food & beverage and machine builders are each rated high. PHP2Shell (CVE-2026-109618/-109619) dominated the week. CISA added it to its KEV catalog on 26 October. In parallel, attackers exploited a Cisco ASA/FTD zero-day that crashes SSL-VPN devices, which are the remote access many operators use for remote maintenance.

Key developments this week

1. PHP2Shell: in CISA KEV, PAN-OS affected, OT vendors confirm affected products

CISA listed both PHP vulnerabilities as actively exploited on 26 October. Palo Alto PAN-OS is also affected. Several OT vendors have confirmed affected products: Siemens (RUGGEDCOM APE1808), Schneider Electric, B&R (APROL), Belden NetModule (no patch yet), HMS (Netbiter, Talk2M) and Wibu-Systems (CodeMeter License Central). The fixes are in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35.

SANS ICS Critical Control: CC5 Risk-Based Vulnerability Management (plus CC2 Defensible Architecture for management access)
Source: CISA KEV alert, 26.10.2026

2. Cisco Secure Firewall ASA/FTD zero-day crashes SSL-VPN devices

Attackers are exploiting this flaw to make SSL-VPN devices restart, and Cisco has confirmed exploitation. Until you can update, check the configuration-dependent mitigations in Cisco's advisory carefully. Cisco warns that they weaken security.

SANS ICS Critical Control: CC4 Secure Remote Access
Source: Cisco Security Advisory

3. Siemens SIMATIC S7-1500, ET 200SP & co.: eight web server vulnerabilities, no fix for many products

The advisory covers the web server of S7-1500, ET 200SP and other SIMATIC devices. For some products, fixes are not or not yet available. These controllers are built into countless machines running in the field.

SANS ICS Critical Control: CC2 Defensible Architecture
Source: CISA ICSA-26-295-14

4. Mitsubishi Electric ICONICS GENESIS64 / MC Works64: authentication bypass (ICSA-26-300-02)

Attackers can bypass the login. Check the CISA advisory for affected products and available mitigations.

SANS ICS Critical Control: CC5 Risk-Based Vulnerability Management
Source: CISA ICSA-26-300-02

What it means per sector

Power & grids: There was no confirmed attack on grid control systems in DACH this week. However, several actively exploited vulnerabilities affect the Edge devices that municipal utilities and grid operators use to connect remote maintenance and outstations. The Siemens RUGGEDCOM APE1808 with PAN-OS is also affected. Siemens refers customers to its support for patch information. In October, Cisco confirmed exploitation of the SSL-VPN DoS flaw. Full report (German)

Food & beverage: This week's focus was refrigeration. Forescout reports refrigeration control systems openly reachable on the internet, among them Copeland/Dixell XWEB and Danfoss StoreView (Forescout). Anyone who runs cold stores, fermentation cellars or tank farms through a web HMI with remote maintenance is particularly exposed. A pre-auth flaw in Veeam Backup & Replication 13 also puts recovery capability at risk. Full report (German)

Machine builders: For component manufacturers, PHP2Shell is relevant to the CRA reporting obligation. If you ship PHP inside products with digital elements, check now (via SBOM or firmware analysis) whether a report is required, and inform your customers proactively (SecurityWeek). The unpatched S7-1500/ET 200SP web server flaws affect machines already installed at customer sites, so send customers a short service notice and track Siemens' patch date. Full report (German)

What to do now

Lock down management interfaces: Make firewall and Edge device management reachable only via a Jump Host and apply the PHP2Shell fixes. On NetModule routers without a patch, disable the web interface. (CC2)
Secure and back up remote access: Update Cisco ASA/FTD, monitor ASA restarts in your SIEM or syslog, and set up a second, independent remote access path for on-call staff and service providers in your Incident Response plan. (CC4, CC1)
Reduce the PLC web server attack surface: Inventory S7-1500/ET 200SP web servers and HMI access, disable what is not needed, and otherwise restrict web access to trusted IPs. Regularly check what is reachable from outside. (CC2, CC5)
Get refrigeration and HVAC controllers off the internet: Bundle contractor access through a Remote Access gateway with MFA and personal accounts, retire shared service-provider credentials, and evaluate temperature alarms independently of the controller. (CC4)
Prioritize by exploitation and exposure: Add PHP-based web UIs, ICONICS installations and SCADA legacy systems to your asset inventory, and patch KEV-listed and externally reachable items first. Keep at least one backup copy offline or immutable. (CC5, CC1)

Full sector reports (German)

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

SANS Five Critical Controls with AI: OT Security Without a SOC

Max Bayern — Wed, 28 Oct 2026 15:03:52 +0000

Small teams in manufacturing and machine building usually have no SOC of their own. You can still implement the five SANS ICS Critical Controls if AI takes over the legwork: it reconciles asset lists, filters advisories, pre-sorts alerts and drafts incident response plans. This applies to every operator and machine builder that falls under NIS2 or the Cyber Resilience Act (CRA), and equally to anyone who simply wants to avoid unplanned downtime. Operators should start with an incident response plan and controlled remote access. Decisions at the plant stay with humans. (This is an English adaptation of the German original.)

Five controls instead of a hundred requirements

The SANS Institute condenses industrial security into five ICS Critical Controls. Control 4, for example, covers Secure Remote Access (SANS Webcast).

Max Gilg, an OT cybersecurity expert from Rosenheim, works with these five points because they set priorities. And for good reason: a typical supplier with two IT people, for example, cannot tackle all the requirements of IEC 62443 at once. Five controls, however, are achievable.

You don't need a SOC for this: the five controls set the order, and AI does the collecting and cross-checking. What happens at the plant is still decided by a human.

Where AI in OT has to stop

In December 2025, CISA and the Australian ACSC, together with partner agencies including the BSI, published guidance on the secure integration of AI into OT (NCSC New Zealand). It formulates four principles. These include frameworks for AI governance and assurance as well as oversight mechanisms.

In day-to-day operations that means: AI may read and write drafts. It does not write values into a PLC, and it does not enable a firewall rule either. To complicate matters, configurations usually contain real IP addresses, hostnames or plant names. These do not belong unfiltered in a public AI service: replace them with placeholders first, or use a locally hosted model.

When production stops after a cyberattack

A pure IT emergency plan is not enough for a plant: it describes, for example, how to restore the mail server, but not who decides whether the line keeps running in manual mode.

AI can deliver the first draft. The basis is the asset list and the vendor contact list, plus the shift schedule (anonymized). The draft then states who calls whom in which order and where the PLC projects are stored. It also covers which backups are offline. In a second step, the AI writes an exercise scenario, for example ransomware on the engineering PC on a Friday at 10 p.m. Production management and maintenance play it through together with IT at a table for one hour. Every gap that shows up in that hour is a concrete work item.

The plan also includes the reporting route: in Germany under the NIS2 implementation act (DQS), in Austria under NISG 2026 (WKO). If it burns anyway, our OT-Notfallhilfe (OT emergency response) can help.

Segmentation without a big project

Segmentation starts with knowing what is actually on the network. That knowledge is usually scattered. Part of it sits in the switches' ARP tables and in the engineering projects, part in the maintenance team's Excel list or on delivery notes. An AI merges these sources into one table and flags contradictions, for example a controller that appears in the project but never shows up on the network. In the end, someone who knows the plant has to verify it.

With this OT asset inventory you can sketch a zone model. Next, the firewall rules are exported. The AI searches them for any-any rules and old exceptions, as well as for direct connections from the office network into the cell. The result is a prioritized list that the network engineer can work through in two maintenance windows.

Detecting attacks without a 24/7 control room

Detecting attacks starts with passive listening, for example via a mirror port on the production core switch. This usually does not disturb the controllers. The real problem for small teams begins afterwards: the volume of alerts.

This is where AI comes in. If an unusual S7 or Modbus/TCP connection shows up at night, it explains what might be behind it. By morning there is a short report in which known items such as the backup job or the remote maintenance window are already separated from what is new. Assessing a real suspicion nevertheless stays with your own team or a service provider. How this is built is described on the page about attack detection in OT networks (SzA).

Control 4: Remote access to the PLC, but controlled

The service technician may access the PLC via remote maintenance, but only in a controlled way. In its list "Top 10 Bedrohungen und Gegenmaßnahmen", the BSI describes the most important threats to industrial control systems (BSI). In a webcast on Control 4, SANS recommends MFA wherever possible, as well as jump hosts (SANS Webcast).

For maintenance, that means: access only via a jump host, enabled for the duration of the job, with MFA and logging. The vendor's service laptop does not connect directly to the cell network, and USB sticks are checked beforehand. The AI reads maintenance contracts and firewall rules and lists all remote access paths that are permanently open.

For purchasers, the CRA is the lever. It obliges manufacturers to report actively exploited vulnerabilities in their products and severe incidents having an impact on the security of the product (Regulation (EU) 2024/2847). The tender for your next machine should therefore contain clear requirements: remote maintenance only through your own access, and an SBOM, plus a support period and machine-readable advisories. Machine builders who have to deliver this are supported by our CRA as a Service.

Which vulnerabilities to tackle first

In practice, vulnerabilities are often closed late or not at all. Patching everything is unrealistic in OT anyway: every firmware update needs a maintenance window.

Risk-based means: first comes whatever is actively exploited and reachable from outside. Two sources help here: CISA's KEV catalog (Known Exploited Vulnerabilities) and vendor advisories, ideally in machine-readable form. Once a week, an AI matches both sources against the inventory. Its proposal is then either mitigate immediately or patch at the next shutdown. Everything else is monitored. We also take over this work in OT vulnerability management.

The first two weeks

In week one, the inventory and the list of remote access paths come first; in week two, the tabletop exercise for the emergency plan. After that follow firewall rules, passive network monitoring and the weekly advisory matching. What gets faster is mainly the collecting and sorting. Decisions are still made by the team.

It is welcome that the five controls can create a solid foundation for NIS2 and the CRA. What matters, though, is that both regulations have their own obligations, which are not fulfilled by this alone. Operators should start with remote access and the emergency plan, and certainly not only when the auditor arrives.

A note for context: the working methods described come from consulting practice; the post contains no lab measurements. Statements about authorities, standards and laws are taken from the linked sources. Time figures such as maintenance windows or the length of the tabletop exercise are based on experience.

If you are looking for a contact to get started: with our OT-Security-Beratung we support operators and machine builders across DACH, from the first workshop to the ongoing OT-Lagebild (OT situational picture).

Sources

SANS Webcast Control 4 Secure Remote Access: https://www.sans.org/webcasts/sans-5-ics-critical-controls-oil-natural-energy-control-4-secure-remote-access
NCSC New Zealand, Principles for the Secure Integration of AI in OT (summary of the four principles): https://www.ncsc.govt.nz/protect-your-organisation/principles-for-the-secure-integration-of-ai-in-ot/
BSI, ICS-Security Top 10 Threats and Countermeasures: https://www.allianz-fuer-cybersicherheit.de/SharedDocs/Downloads/Webs/ACS/DE/BSI-CS/BSI-CS_005.pdf
DQS, NIS2 implementation act: https://www.dqsglobal.com/de/entdecken/blog/nis2-und-nis2umsucg
WKO, NISG 2026: https://www.wko.at/oe/oesterreich/information-consulting-nisg-2026-nationalrat
Regulation (EU) 2024/2847 (Cyber Resilience Act): https://eur-lex.europa.eu/eli/reg/2024/2847/oj

For the architecture side of machines you build or buy, see Security-Architektur der Maschine.

Original (German): https://ot-cyber.de/blog/sans-five-critical-controls-mit-ki-ot-security-ohne-soc.html

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

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