The December 2025 Cyberattack on Poland’s Energy Sector

A reconstruction of the December 2025 cyberattack on Poland’s energy sector, showing how distributed generation, remote access, weak OT hardening, and fragile recovery paths can become a scalable cyber-physical risk.

Introduction

CERT Polska opens the report¹ by stating that on 29 December 2025, during the morning and afternoon hours, coordinated attacks occurred in Poland’s cyberspace against numerous wind and solar farms, a private manufacturing company, and a CHP plant supplying heat to nearly half a million customers. The attacks are described as purely destructive in nature and comparable to deliberate acts of arson. CERT Polska also stresses that both information systems and physical industrial equipment were affected, which it characterizes as uncommon in public reporting to date. The events took place during low temperatures and snowstorms shortly before New Year’s Eve, which amplifies their strategic meaning even though mass service disruption did not materialize.

What makes the case analytically important is not that it caused a national blackout. It did not. The importance lies elsewhere. The campaign demonstrated that a threat actor could simultaneously target dozens of grid edge and industrial environments, achieve operationally significant effects, and do so mainly by exploiting weaknesses in architecture, identity, and equipment hardening. That raises the threshold question of what modern energy sabotage really requires. The Polish case suggests that for many distributed energy environments, the answer is not highly specialized malware but a strong understanding of how remote access, telecontrol, and operational support are actually implemented in the field.

The primary facts established by CERT Polska

The report establishes several facts with high confidence. First, the incidents across the renewable facilities, the CHP plant, and the manufacturing company were coordinated, and CERT Polska assessed that they were carried out by the same threat actor. Second, at least thirty wind and solar farms were affected. Third, the CHP plant was significant enough to supply heat to nearly half a million customers. Fourth, the campaign was destructive rather than financially motivated. Fifth, the renewable attacks caused loss of communication with DSOs and loss of remote control, but did not stop electricity generation or destabilize the Polish power system.

That last point deserves emphasis. In the renewable sector, the attack did not primarily target the physical process of generation itself. Instead, it targeted the control and communication layer at the grid connection point. This distinction matters because it explains how a cyberattack can be strategically meaningful without causing immediate nationwide supply failure. A distributed generation fleet can continue to produce electricity while simultaneously becoming harder to monitor, harder to command, and slower to restore when supervisory and telecontrol devices have been damaged.

The renewable site attack

Architecture of the attacked renewable sites

CERT Polska explains the renewable architecture in order to make the attack intelligible. Electricity from wind turbines and photovoltaic systems is collected and routed to a power substation called the grid connection point. There, voltage is stepped up to 110 kV for transfer to the distribution grid. The DSO oversees conditions at the grid connection point and uses the GCP for remote monitoring and supervisory control. These substations are usually unmanned and remotely managed, which means remote access and telecontrol are structurally central to operations.

The report identifies the key industrial components present at the GCP. These include the remote terminal unit for telecontrol and supervision, a local HMI, protection relays, serial device servers for IP to serial connectivity, primary and backup communications including a cellular router, and an integrated VPN concentrator and firewall. Poland’s DSOs typically require communication between the operator’s SCADA system and the GCP to pass through serial links using DNP3.0 or IEC 101. That choice helps reduce the chance that a compromised GCP could directly pivot into the DSO network, but it does not prevent sabotage of the GCP itself.

%%{init: {"theme": "neo", "look": "handDrawn"}}%%

flowchart TD
    A[Wind turbines / PV fields] --> B

    subgraph GCP["Grid Connection Point substation"]

        subgraph ELEC["Electrical path"]
            B[Plant collection point<br/>MV switchgear / collection bus]
            C[Step up transformer<br/>to 110 kV]
        end

        subgraph OT["OT supervision and control"]
            P[Plant / facility systems<br/>generation asset controllers]
            E[RTU<br/>telecontrol and supervision]
            F[Local HMI<br/>status visualization]
            G[Protection relays<br/>fault detection and isolation]
            H[Serial device servers<br/>RS232 / RS485 to IP]
        end

        subgraph COMM["Communications and remote access"]
            I[Primary / backup communication links<br/>including cellular router]
            J[Integrated VPN concentrator<br/>and firewall<br/>remote service access and segmentation]
        end
    end

    B --> C
    C --> D[Distribution grid / DSO]

    A -. telemetry / status / control .-> P
    B -. measurements / switching status .-> E
    B -. protection signals .-> G
    C -. electrical measurements .-> G

    P -. plant status / commands .-> E
    G -. protection status / events .-> E
    E --> F
    E <--> H
    H <--> I

    J -->|remote service access| P
    J -->|remote service access| E
    J -->|remote service access| F
    J -->|remote service access| G
    J -->|remote service access| H

    K[DSO SCADA / supervisory control] -->|DNP3.0 / IEC 101<br/>via communication and serial links| I

    classDef edge fill:#ffe6cc,stroke:#b45f06,stroke-width:1.5px;
    classDef ot fill:#d9ead3,stroke:#38761d,stroke-width:1.2px;
    classDef elec fill:#fff2cc,stroke:#bf9000,stroke-width:1.2px;
    classDef ext fill:#d0e0e3,stroke:#134f5c,stroke-width:1.2px;

    class I,J edge;
    class P,E,F,G,H ot;
    class B,C elec;
    class A,D,K ext;

Figure 1: Simplified architecture of the attacked renewable plant and its grid connection point, showing the coupling between the electrical path, the OT supervision and control layer, communications links, and remote access components described by CERT Polska.

This architectural description is more than background. It reveals the attacker’s logic. The GCP is both a physical interconnection point and a digital supervision point. Damaging the devices there degrades remote control, remote visibility, and restoration readiness, even if turbines and PV strings continue to operate. The campaign therefore targeted the operational nervous system of the site rather than the generation assets directly.

Initial access at the renewable sites

%%{init: {"theme": "neo", "look": "handDrawn"}}%%

flowchart TD
    A[Internet] --> B[FortiGate VPN / firewall<br/>VPN interface exposed to Internet]
    B --> C[Accounts defined in configuration<br/>authentication without MFA]
    C --> D[Administrative privileges<br/>on FortiGate]
    D --> E[Credential reuse across sites<br/>or FortiGate configuration change]
    E --> F[Access to all subnets<br/>or equivalent reachability]
    F --> G[RTUs]
    F --> H[HMIs]
    F --> I[Protection relays]
    F --> J[Moxa serial device servers]

    D --> K[Factory reset of FortiGate]
    K --> L[Hinders restoration<br/>erases traces]

    classDef attack fill:#f4cccc,stroke:#990000,stroke-width:1.5px;
    classDef impact fill:#fce5cd,stroke:#b45f06,stroke-width:1.3px;
    classDef target fill:#d9ead3,stroke:#38761d,stroke-width:1.2px;

    class A,B,C,D,E,F attack;
    class K,L impact;
    class G,H,I,J target;

Figure 2: Reconstructed access path into renewable sites, highlighting exposed FortiGate VPN access, authentication without MFA, administrative control of the perimeter device, access expansion across OT subnets, and destructive reset of the FortiGate to hinder recovery and erase traces.

In each affected renewable facility, a FortiGate appliance served as both VPN concentrator and firewall. CERT Polska states that the VPN interface was exposed to the internet and that authentication to configured accounts did not require multifactor authentication. The report also notes that reusing the same accounts and passwords across multiple facilities is common in the industry. This matters because once a threat actor compromises one valid account, scaling to other sites using the same identity becomes easier and cheaper.

CERT Polska adds that many of the analyzed facilities did use segregated VLAN subnets, but that the attacker had administrative privileges on the FortiGate. That administrative position likely allowed the attacker either to obtain credentials for a VPN account with access to all subnets or simply to modify the device configuration to achieve equivalent access. All analyzed FortiGate devices were factory reset on the day of the attack, apparently both to hinder restoration and to erase traces. The perimeter device was therefore not just a gateway. It became the attacker’s identity broker, policy override point, and evidence destruction point.

Automated destruction inside the renewable substations

On 29 December 2025, destructive actions were initiated against the devices reached inside the substations. CERT Polska reports that the activity appears to have been at least partially automated. Devices were damaged in ascending IP order, and when the attack failed at a given IP address within a network segment, it did not continue against subsequent addresses. This detail suggests procedural automation rather than fully manual device by device compromise. It also suggests the adversary had enough knowledge of site patterns to encode attack logic around address layout.

The report is explicit that damage to RTU controllers caused the loss of communication between the facility and the DSO and prevented remote control, but did not affect ongoing generation. That statement captures the essence of the renewable attack. The attacker succeeded against telecontrol and supervision, not against the physical conversion of energy itself.

Hitachi RTUs

Most of the affected farms used Hitachi RTU560 controllers, running firmware versions 12.6.6.0, 12.7.3.0, 13.1.1.0, and 13.5.2.0. These devices were configured with default credentials, including an account named Default, and exposed a web interface reachable from the GCP network and, with sufficient privileges, from the FortiGate. The attacker used that default account to log into the web interface and upload corrupted firmware. The firmware, in ELF format, had 240 bytes of 0xFF inserted at the program entry point, causing invalid instruction execution and a reboot loop. The modified firmware identified itself as version 13.5.3.0, which was not present in the affected environments, implying that the attacker likely sourced it externally.

CERT Polska further notes that a secure update feature with digital signature verification had been introduced in version 13.2.1 but required explicit activation, and none of the supporting devices had it enabled. Even then, the report notes that CVE 2024 2617 could bypass secure update until fixed in version 13.7.7. Hitachi Energy PSIRT independently confirmed the scenario. This combination of default credentials, reachable management surfaces, weak firmware integrity enforcement, and known update path weakness is one of the clearest examples in the report of how OT sabotage can be achieved without needing ICS protocol malware.

Mikronika RTUs, Relion relays, HMIs, and Moxa serial servers

At facilities using Mikronika RTUs, the attacker logged in via SSH using default root credentials and executed a destructive command intended to delete all files from the Linux based system. Mikronika later recovered logs showing network scanning and login attempts on 25 December 2025 at all facilities where the device was deployed. Hitachi Relion 650 v1.1 protection devices were attacked in two cases via default FTP access, which allowed the deletion of critical files, caused the devices to shut down, and prevented them from restarting. CERT Polska notes that if the devices had been deployed per the manufacturer’s recommendations, the default FTP account would have been automatically disabled.

Some facilities used Mikronika Syndis software on Windows 10 HMIs. These systems had a default local administrator password. The attacker accessed them through RDP, enabled administrative shares, created a firewall rule called Microsoft Update that opened TCP 445, and used PowerShell to make the system accessible over SMB for remote command execution. Reconnaissance followed with Impacket, and on the morning of 29 December a malicious file was written to C:\Source.exe and executed. CERT Polska states that this was the same malware later analyzed as DynoWiper in the CHP case. On HMIs where the local administrator account had different credentials, only unsuccessful password breaking attempts were observed and the HMI was not damaged.

Every affected facility also used Moxa NPort 6xxx serial device servers. These exposed a web interface and were configured with default login credentials. The attacker used those credentials to reset devices to factory settings, change passwords, and set unreachable IP addresses such as 127.0.0.1. The result was not only unavailability but intentional delay in restoration. That detail is significant because it shows that the attacker optimized not just for immediate denial of service but for recovery friction.

%%{init: {"theme": "neo", "look": "handDrawn"}}%%

flowchart TD
    A[Access from compromised FortiGate<br/>into GCP network] --> B[Hitachi RTU560]
    A --> C[Mikronika RTU]
    A --> D[Hitachi Relion 650 v1.1 relay]
    A --> E[Windows HMI]
    A --> F[Moxa NPort 6xxx]

    B --> B1[Default web account]
    B1 --> B2[Upload corrupted firmware]
    B2 --> B3[Reboot loop / RTU unavailable]

    C --> C1[Default root SSH credentials]
    C1 --> C2[Delete system files]
    C2 --> C3[RTU failure]

    D --> D1[Default FTP account]
    D1 --> D2[Delete essential files]
    D2 --> D3[Relay shutdown / no restart]

    E --> E1[Default local admin password]
    E1 --> E2[RDP access]
    E2 --> E3[Enable admin shares<br/>open TCP 445<br/>SMB based remote execution]
    E3 --> E4[DynoWiper execution]

    F --> F1[Default web credentials]
    F1 --> F2[Factory reset]
    F2 --> F3[Password change + invalid IP]
    F3 --> F4[Serial gateway unavailable]

    B3 --> Z1[Loss of DSO communication]
    C3 --> Z1
    B3 --> Z2[Loss of remote control]
    C3 --> Z2
    F4 --> Z1
    F4 --> Z3[Restoration delayed]
    E4 --> Z4[HMI destroyed / operator visibility reduced]
    D3 --> Z5[Protection device unavailable]

    Z1 --> Y[Operational disruption while generation continues]
    Z2 --> Y
    Z3 --> Y
    Z4 --> Y
    Z5 --> Y

    classDef attack fill:#f4cccc,stroke:#990000,stroke-width:1.3px;
    classDef effect fill:#fce5cd,stroke:#b45f06,stroke-width:1.3px;
    classDef result fill:#d9ead3,stroke:#38761d,stroke-width:1.3px;

    class B1,B2,C1,C2,D1,D2,E1,E2,E3,E4,F1,F2,F3 attack;
    class B3,C3,D3,F4 effect;
    class Z1,Z2,Z3,Z4,Z5,Y result;

Figure 3: Device-level destructive actions within the grid connection point, showing how default credentials and exposed management interfaces enabled sabotage of RTUs, relays, HMIs, and serial device servers.

The CHP plant attack

The attack on one of Poland’s CHP plants had a different tempo and a broader enterprise dimension. CERT Polska states that the attack’s objective was the irreversible destruction of data stored on devices within the internal network through execution of a wiper. The destructive phase was preceded by a long term infiltration, theft of sensitive information, compromise of privileged Active Directory accounts, and unrestricted lateral movement. The wiper was distributed through Group Policy Objects, but an EDR solution detected and blocked the malicious activity. CERT Polska notes that suspicious activity had been visible for months before the attempted wiper deployment.

Between March and July 2025, the attacker conducted reconnaissance, unauthorized data access, and credential theft. CERT Polska traces early activity to RDP logons from an address assigned to a FortiGate interface on a jump host, then onward movement to other systems including the domain controller. The attacker captured screenshots with nircmd, executed commands via PsExec, and generated outlog.txt files that included process lists, network connections, routing tables, ARP cache entries, and user directory contents. The report also notes that many of the systems accessed via SMB had scada in their names, implying a specific focus on industrial automation assets.

Privilege escalation followed. CERT Polska describes a Base64 encoded ZIP archive being decoded with certutil, after which EDR detected a likely LSASS memory theft attempt. The attacker also used Rubeus to create a Diamond Ticket and later dumped the Active Directory database from ntds.dit after creating shadow copies. These are classic Windows domain compromise techniques, but here they are embedded in a campaign that also had an OT reconnaissance dimension.

Late 2025 activity in the CHP environment

When activity resumed in late 2025, the attacker repeatedly connected to the FortiGate SSL VPN portal using multiple accounts defined in configuration, again without two factor authentication. CERT Polska says the attacker used Tor nodes as well as Polish and foreign IP addresses associated with compromised infrastructure. After authenticating, the attacker used FortiGate bookmark functionality to RDP into jump hosts. Some bookmark definitions contained statically configured target credentials, so the attacker could use the SSL VPN portal to reach internal systems without supplying extra local or domain credentials. That is a severe design failure because it turns the perimeter device into a credential relay into the internal network.

The attacker also used a reverse SOCKS proxy, rsocx, under filenames such as r.exe and rsocx.exe, with the command r.exe -r 31.172.71[.]5:8008. Reconnaissance included built in tools such as nslookup and ping, as well as Advanced Port Scanner and Advanced IP Scanner. Microsoft Edge in private mode was used to access internal services and third party resources, including Dropbox and Pastebin. These details matter because they show a patient operator using both living off the land techniques and public tooling rather than relying exclusively on bespoke implants.

CERT Polska also documents theft of LSASS memory dumps, copies of the SAM and SYSTEM hives, theft of ntds.dit, exfiltration attempts via PowerShell to 31.172.71[.]5:50443, and theft of FortiGate configuration files. The attacker modified the FortiGate perimeter configuration by adding a rule that allowed any protocol and any IP to a specified device while disabling traffic logging and making the rule name resemble an existing institutional label in the configuration. This is a particularly clear example of how the attack combined access, persistence, stealth reduction of auditability, and destructive preparation.

Wiper deployment and attempted server destruction at the CHP

On the morning of 29 December, the attacker accessed the SSL VPN portal, RDPed to a jump host, then reached a domain controller where an archive containing the wiper was created. The malware was placed on a network share and deployed through an additional GPO. CERT Polska reports that the file itself was not detected by antivirus, but its execution was blocked at runtime by the EDR solution through a canary mechanism. That prevented data overwriting on more than 100 machines where the executable had already been launched. A second, slightly modified attempt later the same day also failed.

The attacker also tried to destroy data directly on server disks. CERT Polska describes the use of Tiny Core Linux booted on a server via the KVM interface, followed by dd to overwrite portions of attached disks with random data. The attacker also attempted to modify RAID configuration through Intel Rapid Storage Technology. This part of the report is especially revealing because it shows the operator shifting from filesystem destruction to direct storage layer sabotage when needed.

The manufacturing company

CERT Polska reports that the attacker also attempted to disrupt a manufacturing company on 29 December 2025 in coordination with the energy attacks, though the target was opportunistic rather than linked to the other organizations. Initial access came through a Fortinet perimeter device whose past vulnerability and configuration theft had already led to public disclosure in a criminal forum. After gaining access, the attacker modified FortiGate configuration for persistence through built in scripting, creating weekly scripts to exfiltrate privileged credentials and modify security settings. Those scripts sent results to an attacker controlled Slack channel using FortiGate’s own notification capability.

To move internally, the attacker again used an SSL VPN tunnel and Impacket. Administrative access to a domain controller enabled deployment of a PowerShell based wiper through a GPO pulling the file from a network share. CERT Polska calls this malware LazyWiper. The report also states that the attacker later used on premises credentials to access Microsoft 365 services such as Exchange, Teams, and SharePoint and was particularly interested in files and emails related to OT modernization, SCADA systems, and technical work. That behavior indicates intelligence collection alongside destructive operations.

Malware and wiper deployment

DynoWiper

CERT Polska identified four closely related DynoWiper samples. Two are version A, represented by Source.exe and dynacom_update.exe, and two are version B samples compiled under the name schtask.exe. According to the report, version A includes three phases: initialization, data corruption, file deletion, and then system shutdown. Version B removes the shutdown phase and inserts a five second sleep between corruption and deletion. The malware uses the Mersenne Twister random number generator, recursively scans removable and fixed drives, excludes a set of directories such as system32, windows, program files, temp, and appdata, corrupts files by overwriting selected offsets with pseudorandom 16 byte sequences, then deletes files. It contains no persistence, no command and control, no shell command invocations, and no specific attempt to conceal itself from antivirus.

ESET’s follow on analysis² sharpens this picture. ESET states that DynoWiper was deployed to a shared domain path such as C:\inetpub\pub\ under names like schtask.exe, schtask2.exe, and a redacted update filename, and that the PDB path in some samples was C:\Users\vagrant\Documents\Visual Studio 2013\Projects\Source\Release\Source.pdb. ESET infers that the build environment may have involved Vagrant managed virtual machines and notes that operators likely modified and rebuilt the wiper after failed attempts during the same day. ESET also stresses that unlike Industroyer and Industroyer2, the observed DynoWiper samples targeted only the IT environment and contained no observed OT specific functionality.

ESET additionally identifies similarities between DynoWiper and the ZOV wiper, including directory exclusion logic and distinct handling for smaller versus larger files, and attributes DynoWiper to Sandworm with medium confidence. CERT Polska is more conservative. It states that DynoWiper has some similarities to Sandworm and SeashellBlizzard wiper type tools but that the similarity level is too low to attribute it to previously used wiper families. That difference is not a contradiction so much as a difference of analytic scope. ESET is focused on malware lineage and TTP overlap. CERT Polska is focused on incident level evidence and national attribution discipline.

LazyWiper

LazyWiper, used in the manufacturing sector company, is a PowerShell based wiper that overwrites files with pseudorandom 32 byte sequences at 16 byte intervals, corrupting roughly two thirds of each targeted file. CERT Polska lists a wide range of file extensions targeted, including archive formats, backups, certificates, Office documents, engineering files, SQL, images, PDFs, logs, and even .exe. The report notes that the C# function responsible for file overwriting differs stylistically from the rest of the script, contains implausible comments, and was likely generated by an LLM. It also contains a safeguard that terminates execution if it detects it is running on a domain controller.

This is a notable detail because it shows that destructive operations do not necessarily require polished, bespoke malware engineering. In this case, a crude PowerShell wiper with likely machine generated code was sufficient when paired with domain level access and GPO based distribution. The sophistication was in the access and the operating model, not necessarily in the code quality of the payload.

Wiper distribution

CERT Polska shows that in the renewable case DynoWiper was executed directly on the HMI. In the CHP and manufacturing cases, however, wipers were distributed through Active Directory using a PowerShell script executed on a domain controller. The script backed up the existing Default Domain Policy, modified it to create a new policy called Custom Domain Policy, created a scheduled task called Custom GPO Task running as NT AUTHORITY\SYSTEM, launched the malware from a network share, and then deleted the task. CERT Polska lists the SHA256 values for the distribution scripts and highlights distinctive markers such as the task filter GUID 79A87EBB-4DF6-4541-9530-CAD8BEE8A7AD.

This mechanism is important because it shows the relationship between enterprise compromise and destructive scale. Once a domain controller is controlled, wiper distribution can become a matter of policy manipulation rather than one host at a time execution. The operational burden of scale moves from the malware to the directory service.

Attribution

CERT Polska analyzed both infrastructure and malware. On the infrastructure side, it found use of compromised VPS servers and compromised Cisco routers, with additional related devices identified through commercial network flow monitoring. In consultation with threat intelligence companies, CERT Polska concluded that the reconstructed communications overlapped substantially with infrastructure publicly described by Cisco and the FBI and associated with the activity cluster known as Static Tundra, Berserk Bear, Ghost Blizzard, and Dragonfly. CERT Polska says this cluster has a documented interest in the energy sector and industrial devices and concludes that the infrastructure used for initial access, exfiltration, VPN tunneling for wiper deployment, and RAID sabotage overlaps with Static Tundra infrastructure.

At the same time, CERT Polska is careful about the malware evidence. It states that DynoWiper contains some similarities to Sandworm and SeashellBlizzard associated wipers, and that the PowerShell script used to run DynoWiper on workstations uses the same deployment technique as Sandworm linked tools like ArguePatch and RansomBoggs, but it does not conclude that Sandworm participated. LazyWiper is explicitly deemed unsuitable for attribution because it was likely largely generated by an LLM and lacks distinctive features.

ESET goes further on the malware side and attributes DynoWiper to Sandworm with medium confidence, citing close resemblance to TTPs seen earlier in 2025 in ZOV wiper incidents in Ukraine. ESET also notes Sandworm’s long history of attacking Polish organizations, including those in the energy sector, first covertly for espionage and later destructively, as in the Prestige incidents.³

Additional OT perspective from Dragos

The OT cybersecurity firm Dragos states that the 29 December 2025 event was a coordinated cyberattack against multiple sites connected to distributed energy generation in Poland and describes it as the first major coordinated attack on distributed energy resources at scale⁴. In Dragos’s framing, the affected systems were the communication and control assets that link grid operators to combined heat and power facilities and to wind and solar sites, rather than the transmission backbone itself. Dragos also states that adversaries gained access to operational technology systems critical to grid operations and disabled some equipment beyond repair at site level.

This OT specific framing is consistent with the CERT Polska report, which explains that the attack on renewable sites caused loss of communication between facilities and DSOs and prevented remote control, while not interrupting ongoing electricity generation or destabilizing the Polish power system. In other words, the attacker succeeded against the supervisory and telecontrol layer at the grid connection point without producing an immediate bulk power effect.

Dragos adds an important interpretive layer. It argues that the event is significant not because it caused outages, but because it demonstrated that distributed energy infrastructure is now a valid target for a sophisticated adversary. The brief stresses that DER environments are more numerous, depend heavily on remote connectivity, often receive less cybersecurity investment than centralized plants, and therefore present a broader and less manageable attack surface. It also notes that RTUs standardize how remote sites interface with control centers, which makes compromise repeatable across many sites if edge devices, vulnerabilities, or connectivity patterns are similar.

%%{init: {"theme": "neo", "look": "handDrawn"}}%%

flowchart TD
    A[Many DER sites] --> B[Common edge architecture<br/>VPNs firewalls gateways remote access]
    F[Remote operations model] --> B
    G[Standardized low cost deployments] --> B

    B --> C[Similar OT integration patterns<br/>RTUs HMIs relays serial gateways]
    C --> D[Repeatable compromise paths]
    D --> E[Coordinated multi site OT disruption]

    H[Limited OT visibility and logging] --> E
    I[Restoration depends on site by site<br/>manual field intervention] --> E

    E --> J[Loss of telemetry]
    E --> K[Loss of remote control]
    E --> L[Damage to communications and edge devices]
    E --> M[Slower restoration and possible escalation<br/>to broader operational impact]

    classDef der fill:#d0e0e3,stroke:#134f5c,stroke-width:1.2px;
    classDef risk fill:#f4cccc,stroke:#990000,stroke-width:1.3px;
    classDef out fill:#d9ead3,stroke:#38761d,stroke-width:1.2px;

    class A,F,G,H,I der;
    class B,C,D,E risk;
    class J,K,L,M out;

Figure 4: Systemic risk pattern in distributed energy resources, showing how repeated architectural choices, shared remote access models, and limited visibility can turn many small sites into a scalable target for coordinated OT disruption.

Dragos also clarifies an operational point that is easy to miss in superficial retellings of the incident. In electric systems, loss of communications does not usually cause immediate shutdown. A device that loses connectivity often continues operating locally, but it can no longer be monitored or controlled remotely. This is why the power stayed on even though key OT and communications equipment had been compromised. Dragos therefore treats the incident as a serious OT intrusion with limited immediate physical effect, not as a failed or trivial attack.

The brief further argues that the December 2025 operation represents both continuity and evolution relative to earlier ELECTRUM operations. Continuity lies in the use of destructive tooling, wipers, and attacks on communications infrastructure. Evolution lies in the shift from centralized control points, such as those targeted in Ukraine in 2015 and 2016, toward the distributed edge of the grid, meaning RTUs and communication systems spread across many smaller generation sites. Dragos assesses with moderate confidence that ELECTRUM was responsible, while also noting that the observed impact appears more opportunistic and less fully prepared than the earlier Ukraine operations.

This perspective sharpens the strategic meaning of the case. The Polish incident was not merely an enterprise compromise that happened to touch energy companies. It was an attack on the digital coordination fabric of distributed generation. The core lesson is that a modern grid does not need to lose its transmission backbone to suffer operationally relevant cyber sabotage. It is enough for an adversary to degrade visibility, telemetry, remote control, and restoration capability across enough distributed sites at the same time.

Why the case matters

The Polish incident matters because it compresses several assumptions about energy cybersecurity into a single, well documented case and shows that many of them are no longer defensible. It demonstrates that operationally significant disruption can be achieved without causing a national blackout, without deploying highly specialized ICS malware at every stage, and without compromising the transmission backbone. The attacker was able to produce meaningful effects by targeting the digital coordination layer of distributed generation: remote access paths, telecontrol devices, communications infrastructure, domain services, and management surfaces that were easier to reach than the physical process itself.

That is the first major lesson. In energy systems, the threshold for serious impact is lower than many discussions still imply. A plant or portfolio does not need to stop generating for the attack to matter. It is enough that operators lose visibility, lose remote control, and lose confidence in the integrity of the devices that connect generation assets to the wider grid. Once those functions are degraded across many sites at once, the attacker has already created an operational problem, a regulatory problem, and a strategic signal.

The second lesson concerns distributed energy itself. Wind, solar, and CHP assets connected through remote telemetry and supervisory infrastructure are often treated as too small, too fragmented, or too peripheral to be systemically attractive. The Polish case shows the opposite. Their very number, geographic spread, and dependence on remote access make them suitable targets for a coordinated campaign. What looks like decentralization from an electrical perspective can still be concentration from a cyber perspective if dozens of sites share the same perimeter technologies, the same access patterns, the same administrative shortcuts, and the same weakly governed OT components.

The third lesson is that the decisive weaknesses were largely architectural and operational, not exotic. Exposed VPNs, missing multifactor authentication, reused credentials, permissive firewall configurations, default accounts on OT devices, insecure management protocols, weak firmware integrity protections, and poor recovery design were enough to enable sabotage at scale. That matters because it means the case cannot be dismissed as the product of rare zero days or uniquely sophisticated tooling. The uncomfortable implication is that similar outcomes are plausible anywhere comparable patterns exist.

Finally, the incident matters because it marks a strategic shift in how energy disruption can be pursued. Previous landmark grid attacks were associated with centralized control points and more obvious attempts to produce immediate outage effects. Poland shows a different model: attack the distributed edge, degrade the communications and supervision fabric, damage what is reachable, and impose operational stress without necessarily crossing the threshold into catastrophic national disruption. That model is more scalable, more deniable, and in some contexts politically more usable.

What Poland exposed, then, was not just a successful campaign against a set of organizations. It exposed a structural reality of modern power systems: as generation becomes more distributed, cyber fragility can also become more distributed, and if that fragility is not governed deliberately, it can accumulate quietly across many small sites until it becomes strategically significant.

Personal considerations: why this case matters to me in the Italian context

Why the Polish case does not feel remote

What makes the Polish case especially relevant to me is that I do not read it as a remote anomaly. I see the same structural pattern in Italy, even if the geopolitical position, the regulatory environment, and the generation mix are not identical. The common pattern is not a specific threat actor or a specific device model. It is the combination of distributed sites, heavy dependence on remote access, edge devices that concentrate trust and reachability, heterogeneous OT components with uneven hardening, and organizational fragmentation between owners, EPCs, integrators, vendors, and O&M providers.

This is exactly the environment in which a large share of today’s renewable and hybrid energy systems is being designed and deployed. A modern plant is no longer just an electrical installation that happens to contain some digital components. It is, in substance, a distributed cyber physical operating system whose physical assets are coordinated, supervised, updated, dispatched, diagnosed, and sometimes even commercially optimized through remote digital relationships. The plant’s true attack surface therefore does not coincide with the visible field equipment taken one by one. It is not just the inverter, or the turbine, or the RTU, or the firewall considered in isolation. It is the entire graph of trust, access, delegation, and dependency that binds those components to remote operators, O&M teams, vendor support channels, dispatch and telecontrol interfaces, aggregators, cloud platforms, market systems, data concentrators, and third party maintenance paths.

That is the crucial shift in perspective. The plant is no longer only what is physically installed inside the fence. It is also the extended digital ecosystem that is allowed to observe it, manage it, patch it, configure it, optimize it, and sometimes override it. Every one of those relationships is operationally useful, but every one of them is also a potential attack path, a privilege boundary, or a latent failure mode. Once this is understood, the Polish incident stops looking like an outlier produced by unusual circumstances and starts looking like a highly legible warning. It becomes recognizable as the kind of event that can emerge wherever distributed assets are connected faster than the surrounding architecture of trust is deliberately governed.

Why I use enterprise architecture and IEC 62443 at design time

This is also why I do not treat enterprise architecture and IEC 62443 as paperwork to be added after engineering choices have already been made. I use them at design time because that is the most cost effective place to solve the problem. If segmentation, conduits, identity boundaries, remote access patterns, logging points, recovery paths, and administrative domains are decided only after procurement and deployment, the organization pays twice: first for a fast but fragile implementation, and then again for compensating controls, redesign, and operational friction. By contrast, when these choices are made in the architecture phase, security becomes a property of the system shape rather than a collection of late exceptions.

That distinction matters economically as much as technically. A defensible architecture is not necessarily a more expensive architecture. Very often it is simply a more explicit one. The cost effective move is to define from the beginning which functions belong in which zones, which communications are actually required, which identities are allowed to traverse which boundaries, how vendor access is brokered, what must be logged outside the local device, and what recovery baseline must exist if a field component is bricked or reset. The Polish incident shows what happens when those questions are left implicit: the attacker discovers the real architecture before the owner has fully governed it.

From this perspective, IEC 62443 is useful not because it is fashionable or because it can be cited in a checklist, but because it provides a disciplined way to convert these problems into design decisions. Zones and conduits force explicit trust boundaries. The foundational requirements force discipline around identification and authentication, restricted data flow, system integrity, and timely response to events. In practical terms, that means remote access cannot simply terminate somewhere in OT; management interfaces cannot remain reachable by convenience; default credentials and legacy services cannot survive commissioning; and restoration cannot depend on improvised field work after the incident has already destroyed the evidence.

IEC 62443 reading of the Polish failure modes

The Polish case can also be read as a compact demonstration of why IEC 62443 is useful at design time. The standard is not important here as a formal citation exercise. Its value is that it forces the architect to translate vague security concerns into concrete design properties: zones, conduits, restricted data flows, identity boundaries, system integrity, monitoring, recovery, and lifecycle governance.

The table below maps the main failure modes visible in the Polish incident to the corresponding IEC 62443 design logic. The purpose is not to claim that formal compliance alone would have prevented the attack. It is more precise to say that an architecture genuinely designed according to IEC 62443 principles would have removed or weakened several of the attacker’s shortest paths to impact.

Failure mode visible in the Polish case	IEC 62443 design concept	Practical architectural implication
Internet exposed VPN became the entry point into renewable site environments	Zones and conduits	Remote access should terminate in a controlled access zone, not directly into OT or mixed management networks.
FortiGate administrative control allowed the attacker to expand reach across segregated subnets	Restricted data flow and non-bypassable enforcement points	VLANs alone are not enough. Inter-zone traffic must be controlled by explicit policy enforcement points whose compromise does not silently collapse the whole zone model.
Missing multifactor authentication and reused credentials enabled scalable access across sites	Identification and authentication control	Remote access must use individual accounts, MFA, site-specific authorization, credential rotation, and ideally privileged access management for administrative paths.
Default credentials on RTUs, HMIs, relays, and serial device servers enabled direct device compromise	Account management and secure commissioning	Commissioning must include removal or disabling of default credentials, creation of accountable role-based access, and verification that vendor defaults are not left active.
OT management interfaces were reachable once the attacker gained network access	Least functionality and management plane isolation	Web, SSH, FTP, RDP, SMB, and firmware update interfaces should be reachable only from an engineering or maintenance zone, never from general remote access paths.
Legacy or unnecessary services such as FTP were available on protection devices	Least functionality	Services that are not operationally required must be disabled. If they are required for maintenance, they must be isolated, monitored, and opened only under controlled conditions.
Corrupted firmware was uploaded to RTUs	System integrity and controlled change	Firmware update paths must be authenticated, authorized, logged, and integrity checked. Where signed firmware is not available or not enabled, architecture must compensate by isolating the update interface.
Windows HMIs could be accessed and prepared for remote execution through RDP, SMB, and local administrator credentials	Host hardening and execution control	OT Windows hosts require hardening baselines, local administrator control, restricted inbound services, application allowlisting, and monitored administrative access.
Serial device servers were reset, reconfigured, and assigned unreachable IP addresses	Configuration management and recovery engineering	Field device configurations must be backed up, versioned, and restorable. Recovery should not depend on manual rediscovery of device state after destructive action.
Factory reset of FortiGate devices hindered recovery and erased local traces	Security monitoring and protected logging	Security logs must be exported to protected collectors outside the local device. A perimeter device must not be the only place where evidence of its own compromise exists.
Multi-site similarity made the attack repeatable across distributed assets	Security lifecycle and governance across the fleet	Standardization must not mean identical weakness. Fleet architecture should standardize secure patterns, not shared credentials, shared exposure, or repeated misconfigurations.
Limited OT visibility made it difficult to determine the full operational scope of adversary action	OT network visibility and timely response	Operators need visibility into OT traffic, commands, configuration changes, and remote access sessions before the incident occurs, because much of the evidence is transient.
Restoration depended on damaged or reconfigured field devices across multiple remote sites	Resilience and incident response readiness	Incident response must include golden configurations, tested restoration playbooks, spare device strategy, and prioritization rules for simultaneous multi-site recovery.

The most important point is that IEC 62443 changes the topology of the attack graph. Without it, the attacker can move from remote access to perimeter device control, from perimeter control to OT reachability, from OT reachability to device management, and from device management to destructive action. With it, those transitions become explicit boundaries that must be crossed, authenticated, logged, justified, and constrained.

This is why IEC 62443 is most valuable before the plant is built. Once the system is already deployed, the owner is forced to retrofit controls around decisions that may already be structurally wrong. At design time, the same controls can be expressed as architecture: which zones exist, which conduits are allowed, which identities may cross them, which management interfaces are reachable, where evidence is stored, and how damaged devices are restored.

Structural compliance by construction

This approach also has an important secondary effect: it tends to align the plant with the direction of regulation before the regulation arrives in its most detailed and most enforceable form. I would not call that automatic compliance in a literal sense, because compliance always requires documentation, evidence, procedures, governance, and often formal role assignment. But I would call it structural compliance by construction. If the system is architected with explicit segmentation, secure remote access, asset accountability, monitoring, controlled change, and recovery engineering, then the gap between technical reality and regulatory expectation becomes much smaller.

This matters because the regulatory trajectory is no longer generic. It is becoming layered, cumulative, and increasingly specific at both system and product level. The result is that the technical decisions made during plant and interface design are progressively less separable from legal and regulatory obligations.

The national layer: NIS2 and PSNC are converging, not diverging

At the national level, the relevance to the Polish case is not abstract. The attack documented by CERT Polska is exactly the kind of event that exposes why cyber governance for energy and industrial operators can no longer be treated as a secondary compliance exercise. It combines destructive intent, compromise of remote access paths, cross domain movement between IT and OT, and operational impact below the threshold of a nationwide blackout. In Italy, that same class of risk now sits inside a regulatory environment that is becoming denser and more explicit, not looser.

The first point is that the Italian transposition of NIS2 is already in force. Decreto Legislativo 4 settembre 2024, n. 138 was published on 1 October 2024 and took effect on 16 October 2024⁵. That matters here because NIS2 is not just about generic cybersecurity maturity. It is about forcing operators of essential and important entities to treat cyber risk, incident management, supply chain exposure, and continuity as governed management obligations rather than discretionary technical choices.

The second point is that this decree does not replace or supersede the Perimetro di Sicurezza Nazionale Cibernetica. The PSNC was established earlier and remains structurally important for systems tied to national strategic interests.⁶ This is directly relevant to the logic of the article because the Polish case shows how systems that may appear operationally peripheral when considered site by site can become strategically relevant when attacked in coordination. The Italian framework is moving in the same conceptual direction: it narrows the distance between technical infrastructure and nationally significant infrastructure by treating certain digital systems, services, and interconnections as part of a higher consequence security perimeter.

The third and most important point is that NIS2 and PSNC are converging, not diverging. Article 33 of the Italian NIS2 transposition explicitly coordinates the two regimes by recognizing that, for systems already covered by the Perimetro, PSNC obligations on cyber risk management and incident notification are considered at least equivalent to the corresponding NIS2 obligations⁷. That is not a bureaucratic detail. It means that the direction of travel is toward a more integrated and less permissive model in which organizations cannot rely on fragmented interpretations of which rule really applies. From the standpoint of a plant owner, operator, or architect, the message is clear: the same architectural weaknesses highlighted by the Polish incident, especially around remote access, segmentation, trust boundaries, and recovery readiness, are increasingly becoming relevant both as technical exposures and as formal governance failures.

This is why the national layer matters so much to the argument of the article. The Polish incident is a warning that distributed energy and industrial systems can become operationally significant targets without first becoming big critical infrastructure in the traditional centralized sense. The Italian response, through NIS2 and the continuing force of PSNC, points in the same direction: cyber resilience is being treated less as an optional quality of implementation and more as an expected property of strategically relevant systems and services. ACN’s own public positioning reflects this shift by presenting the NIS framework as fully in force and by identifying the Agency as the competent authority and single point of contact for the regime⁸.

The grid code layer: what is already in force, and what is tightening further

At the energy specific layer, precision matters. The Terna Grid Code is already the governing framework for the transmission system and for the technical conditions under which plants, data acquisition systems, and defense related devices interface with Terna.⁹ But within that framework, it is important not to confuse three different things: the current requirements already in force, the new revision path now visible in Terna’s update documents, and the broader direction of tightening that emerges when those texts are read together.

What is already present in the current framework

Even in the current published version of Annex A.13, cybersecurity is not absent. The annex already contains a dedicated security chapter and already requires, among other things, protection and monitoring of communications toward Terna, logical segregation of networks and channels used for data exchange with Terna, prompt reporting of security incidents affecting the communication channel, VPN protection for acquisition systems that use intranet type communications, a VPN terminator on the owner side capable of segregating the network in which RTUs are present, security logs with synchronized timestamps, at least six months of log retention, and mutual authentication measures between the owner and Terna¹⁰.

That point is important because it means the baseline is not starting from zero. Telecontrol and telemetry connections toward Terna are already treated as security relevant interfaces, not as purely functional transport paths.

What the new A.13 update makes clearer and stricter

Where the tightening becomes visible is in the updated A.13 markup document, which shows Terna moving from a relatively compact security chapter to a broader and more explicit cybersecurity framework. The updated text introduces a dedicated Cyber Security section structured around topics such as asset inventory and third parties, cybersecurity monitoring and incident management, malware protection and traffic isolation, authentication and authorization, communications security and cryptography, packet filtering, patching, logging, and backup and restore.¹¹

The updated text also makes several obligations more explicit and more operational. It requires the plant owner to keep updated and consultable inventories of digital assets attached to the interconnection infrastructure, to maintain a 24x7 point of contact, to notify Terna of security events within four hours of detection when they may affect connected devices, communications infrastructure, Terna related information, or even supply chain events relevant to the interconnection, to ensure anti malware protection on IT, OT, IoT, and mobile devices, to isolate traffic between VPNs, to use robust credentials including examples such as MFA, to prepare for IEC 62351 secure communications, to apply security patches at least semiannually, and to implement backup and restore procedures.

So the direction of travel is clear. The newer A.13 text does not merely repeat the older security concepts. It broadens them, operationalizes them, and turns them into a more explicit lifecycle discipline for the infrastructure that connects the plant to Terna’s systems.

This is already a significant architectural message. It means that cyber requirements are not only imposed later through generic corporate policy or audit language. They are increasingly embedded into the very conditions under which telemetry and telecontrol can be connected to the transmission side. The practical implication is that the connection architecture itself must now be designed to sustain asset visibility, segmented trust boundaries, secure remote access, incident response coordination, evidence retention, and recoverability.

The same tightening logic is visible in A.69

This becomes even more relevant when one looks at Annex A.69, which governs the connection of production plants to Terna’s defense system. In its current logic, A.69 already depends on A.13, because the telecontrol and data connection criteria of A.13 form part of the technical environment within which defense related interfaces operate.

But the newer A.69 revision text shows the same direction of tightening more explicitly. The updated text contains its own Cyber Security chapter, structured around monitoring and threat detection, secure traffic isolation, authentication and authorization, traffic encryption, access controls and packet filtering, patching, and backup and restore.¹²

In addition, the revised A.69 text links cyber discipline directly to the integrated telecommunications architecture. It states that where the data connection system is integrated for A.69 purposes and also for A.7 and or A.13 purposes, continuity of telecontrol flows must be preserved throughout preparation, testing, and commissioning, and it imposes architectural consequences such as common communication technology constraints, readdressing of field devices, and the need to review the data network architecture when field devices other than RTUs and UPDM are used.

The actual direction of tightening

The most precise way to state the issue, then, is this: Terna’s current framework already contains cyber relevant obligations, but the newer A.13 and A.69 texts show a clear move toward a more explicit, more granular, and more enforceable cybersecurity model at the plant to Terna interface. The direction is not toward looser interoperability by default. It is toward tighter governance of communications, assets, authentication, logging, patching, and recovery, with increasing emphasis on the whole interconnection chain rather than on the mere existence of a data link.

The product layer: the Cyber Resilience Act and CEI 0-16 are raising the baseline

In parallel, the product security baseline is tightening as well. At EU level, the Cyber Resilience Act, Regulation (EU) 2024/2847, introduces horizontal cybersecurity requirements for products with digital elements, meaning hardware and software connected directly or indirectly to a device or network. The regulation entered into force on 10 December 2024. Its general application is staged, with the main obligations applying from 11 December 2027, while the reporting obligations for actively exploited vulnerabilities and severe incidents begin earlier, from 11 September 2026.¹³

This does not replace system architecture obligations, but it materially changes the product side expectations placed on vendors supplying connected components into energy systems. It pushes security requirements upstream, toward the design, development, lifecycle management, and incident reporting responsibilities of the product manufacturer.

The same tightening is visible in the Italian sector specific technical domain. CEI 0-16 Variant V5 explicitly requires, for the Controllore Centrale di Impianto (CCI) as a whole, conformity to IEC 62443-4-1 and IEC 62443-4-2. The text requires overall certification at Capability Security Level 1, together with additional assessment expectations for higher minimum levels on specific foundational requirements, in particular FR1, FR2, FR3, and FR7.¹⁴ This is not a generic invocation of good practice. It is a concrete sign that product and interface security expectations are being written into the technical rules of grid connected equipment.

What this means in practice

Taken together, these layers point in the same direction. NIS2, PSNC, the CRA, the Terna Grid Code, and CEI 0-16 are converging on one practical message: remote telemetry, dispatch, and control interfaces can no longer be engineered as operational conveniences and justified later. They must be designed from the outset as critical infrastructure surfaces.

This is why, for me, the lesson of the Polish case is straightforward. The right response is not to bolt more controls around the edges of an already ambiguous design. It is to design plants, substations, and remote operational ecosystems so that the most dangerous shortcuts are unavailable by default. That is what enterprise architecture is for at this level: not abstract modeling, but the deliberate shaping of trust, authority, and failure modes before those choices harden into expensive operational debt.

And this is the deeper reason I consider an architecture first, IEC 62443 informed approach to be the optimal balance between security and cost. It is cheaper to decide correctly than to retrofit under pressure. It is cheaper to standardize secure remote access than to investigate a fleet wide credential problem. It is cheaper to isolate management planes than to discover during an incident that a firewall configuration was the real crown jewel. It is cheaper to design for evidentiary logging and deterministic recovery than to rebuild dozens of sites with partial visibility after destructive actions have already occurred. In critical infrastructure, good architecture is not the opposite of cost effectiveness. It is usually the only durable form of it.

Conclusions

The December 2025 cyberattack on Poland’s energy sector should be read as more than a national incident report and more than a malware case study. It is a reference event for the next phase of energy cybersecurity. Its real importance lies in showing that coordinated cyber sabotage of distributed generation does not require spectacular novelty. It requires enough understanding of how modern plants are actually operated, enough reach into the edge devices that mediate trust and control, and enough operational discipline to turn repeated weaknesses into repeatable disruption.

That is why the case is strategically important. It shifts attention away from the old intuition that grid cyber risk is concentrated only in major control centers and transmission assets. Those remain critical, but they are no longer the whole picture. The distributed edge of the grid now matters because that is where scale, remote access, operational heterogeneity, and inconsistent security investment meet. In such an environment, systemic relevance can emerge from the synchronized compromise of many small or medium assets that would not appear decisive in isolation.

The Polish incident also sharpens a more general principle. In critical infrastructure, the most dangerous vulnerabilities are often not the most technically exotic ones. They are the ones that have been normalized into operations: shared credentials, overprivileged perimeter devices, weak separation between remote access and administration, opaque vendor pathways, incomplete logging, and recovery models that depend on assumptions of benign failure rather than hostile interference. Once those become routine, the attacker does not have to invent a new path. The path is already there, waiting to be used.

For Italy, and more broadly for European operators living through the energy transition, the lesson is immediate. The expansion of distributed energy cannot be treated as only a capacity, market, and interconnection problem. It is also a problem of cyber architecture. If the digital operating model of distributed generation is designed as a convenience layer around electrical assets, then the attack surface scales faster than resilience. If instead it is designed from the beginning as critical infrastructure, then many of the attack paths visible in Poland become harder, noisier, slower, and more recoverable.

That is the point at which the Polish case becomes constructive rather than merely alarming. It gives operators, engineers, regulators, and owners a very clear warning, but also a very clear design agenda. The objective is not abstract more security. The objective is to make sure that remote access, dispatch interfaces, telemetry paths, OT management surfaces, and restoration processes are governed as part of the plant’s essential architecture. Once that is done, compliance with tightening Italian and European requirements becomes less of a late-stage burden and more the formal expression of choices that were already technically correct.

The deepest conclusion, then, is simple. The future risk to energy systems will not be determined only by how much renewable capacity is added, but by how that capacity is digitally organized. The Polish incident shows what happens when distributed generation is operationally connected faster than it is architecturally governed. The real strategic response is to reverse that sequence.

Update, August 2026: the private APN attack path into a second CHP plant

On 8 August 2026, CERT Polska published a follow-up to its January incident report. The new analysis materially expands the reconstruction of the 29 December 2025 campaign: a second, smaller combined heat and power plant, supplying heat to approximately 50,000 residents, was also attacked that morning. More importantly, the investigation reconstructed an attack path that had not been visible in the original report. The attacker appears to have moved from a compromised wind farm, through a cellular router, into a DSO-managed private APN, then through a PLC connected to that APN into the second CHP plant’s OT network. CERT Polska states that, to the best of its knowledge, this is the first observed real-world cyberattack in which a private APN was used in this way to gain access to an OT network.¹⁵

This changes the architectural reading of the December incident in an important way. The original report already showed how weaknesses at individual grid connection points could be scaled across many renewable facilities. The follow-up shows something more systemic: communications infrastructure intended to connect geographically distributed field assets can itself become a lateral-movement fabric between otherwise unrelated operational environments. The significant boundary was therefore not only between the Internet and each plant. It was also between each field endpoint and the private telecommunications network to which that endpoint had been granted access.¹⁶

From a compromised wind farm into the private APN

The starting point was one of the wind farms already covered by the initial investigation. As described earlier in this article, the attacker had obtained access to a FortiGate appliance functioning as VPN concentrator and firewall. Inside that wind farm network was a Teltonika RUTX50 cellular router used for communication through a private APN operated by the DSO. The DSO’s technical requirement that communication with the RTU use a serial protocol had been respected: the cellular router was connected to the RTU through an RS485 serial interface. At the same time, however, the router also had an Ethernet interface connected to a VLAN behind the compromised FortiGate.¹⁷

That second interface was decisive. The Teltonika device exposed web administration and SSH services on its LAN side. Its original default password had been changed during commissioning, so this was not another simple default-credential case. CERT Polska could not determine how the attacker obtained the replacement password, nor could it establish whether a vulnerability in the router had been exploited. What investigators could establish was that the attacker logged into the router repeatedly over SSH during December and most likely used SSH tunnelling to obtain connectivity into the private APN.¹⁸

Beginning on 18 December, the attacker scanned that APN for services including VNC, HTTP, Siemens S7, and Modbus. One of the discovered endpoints was a WAGO PFC200 controller associated with the second CHP plant. Its web administration interface was reachable through the APN and was configured with the default credentials for its admin account. The attacker appears to have used the web interface to enable SSH on the controller’s WAN interface and then used another SSH tunnel to enter the CHP plant’s OT network. The WAGO controller had connectivity not only to the APN but also to SCADA systems and industrial network segments containing devices responsible for important plant processes.¹⁹

%%{init: {"theme": "neo", "look": "handDrawn", "layout": "elk"}}%%
flowchart TD
    A[Internet] --> B[Wind farm<br/>FortiGate VPN + firewall]
    B --> C[Teltonika RUTX50<br/>cellular router]
    C -->|SSH tunnel| D[DSO-managed<br/>private APN]
    D --> E[APN reconnaissance<br/>HTTP, VNC, S7, Modbus]
    E --> F[WAGO PFC200<br/>at second CHP plant]
    F --> G[Default admin credentials<br/>SSH enabled on WAN]
    G -->|SSH tunnel| H[CHP plant<br/>OT network]
    H --> I[SCADA interface]
    H --> J[Siemens S7-300<br/>S7-1200<br/>S7-1500]
    J --> K[Controllers placed in STOP mode<br/>configuration protected]
    K --> L[Steam turbine stopped<br/>water treatment stopped]
    L --> M[Cogeneration process interrupted]

Figure 5: Reconstructed attack path disclosed in CERT Polska’s August 2026 follow-up: compromise of a wind-farm perimeter led through a cellular router and a DSO-managed private APN to a WAGO controller at a second CHP plant, from which the attacker reached the plant’s OT network and process controllers.

The distinction from a direct compromise of the DSO network is important. The follow-up does not establish that the attacker penetrated the DSO’s SCADA or corporate infrastructure. Nor does it invalidate the earlier observation that serial DNP3 connectivity can reduce the possibility of directly pivoting from a GCP into DSO systems. Instead, it exposes an orthogonal path: the attacker exploited the field communications transport shared by multiple endpoints. In other words, the serial boundary protected one direction of trust, while an insufficiently isolated private APN created another.

That is a much more general lesson than the particular device models involved. A private APN may provide separation from the public Internet, but private addressing and restricted carrier access do not by themselves create endpoint isolation. If devices attached to the APN can establish arbitrary connections to one another, then compromise of any one reachable endpoint can potentially change the security meaning of the entire network.

Reconnaissance became direct manipulation of the physical process

Once inside the CHP plant, the attacker did not immediately begin destruction. CERT Polska reconstructed reconnaissance between 18 and 25 December. Attempts were made to authenticate to the plant’s firewall and VPN gateway, but they were unsuccessful. The attacker then scanned internal subnets for industrial services including S7, Modbus, and CODESYS, as well as RDP, VNC, HTTP, HTTPS, and RTSP. In one subnet, scanning began with the address assigned to the SCADA system, which CERT Polska interprets as suggesting that the attacker may already have identified a high-value target. On 25 December, successful S7 connections were established to three Siemens PLCs; their exact purpose cannot be determined, although CERT Polska considers reconnaissance in preparation for the later disruptive actions the most likely explanation.²⁰

The destructive phase on 29 December went significantly further than the loss of telemetry documented at the renewable sites. Activity inside the CHP network began at approximately 05:30 and continued until around 10:10. The attacker connected to the SCADA web interface and then to Siemens S7-300, S7-1200, and S7-1500 controllers. According to plant personnel, the PLCs were placed into STOP mode and protected with a password that prevented operators from changing their operating state or modifying the control logic. The resulting process effects were direct: the steam turbine and the water treatment system used to produce process water were shut down, interrupting the cogeneration process.²¹

The outage remained short because plant personnel responded quickly, restoring the affected controllers to factory settings and reloading available backups. Customers did not lose heat or electricity. But the timing contains an important incident-response detail: restoration began at approximately 07:30, while the attacker appears to have remained active in the network for several more hours. The emergency recovery procedure also deleted locally stored PLC logs, limiting subsequent forensic reconstruction. This is another example of a recurring tension in OT response: the fastest action for restoring the physical process is not always the action that best preserves evidence or assures that the adversary has actually been expelled.²²

The attacker also modified seven Moxa serial device servers and three Moxa network switches. As in the renewable-site attacks, the devices were factory-reset, their passwords were changed, and their IP addresses were replaced with unreachable values such as 127.0.0.1. CERT Polska assesses with high confidence that these actions were automated, based on the timing of the HTTP requests. Connections were additionally observed to two ABB ACS-series variable-frequency drives, although investigators could not establish whether configuration changes were made. Attempts to reach Schneider Electric ATV6xx drives failed because the attacker targeted the wrong TCP port.²³

This is significant because the new evidence crosses a boundary that the renewable attacks largely did not. At the wind and solar sites, the principal observed effect was destruction of the coordination and telecontrol layer while electricity generation continued. At the second CHP plant, the attacker reached controllers involved in the production process and deliberately changed their operating state. The December campaign therefore contained both forms of OT sabotage: attacks against the digital nervous system around the process and direct manipulation of controllers capable of stopping the process itself.

The cleanup sequence was part of the attack

The follow-up also makes the adversary’s evidence-destruction behaviour clearer. After the disruptive actions, the attacker returned to the SCADA web interface, which CERT Polska assesses was most likely an attempt to inspect the effects. The WAGO PFC200 that had served as the gateway into the CHP network was then damaged by corruption of its partition table. A subsequent factory-reset attempt by the plant could not restore the device, and laboratory examination failed to recover useful logs.²⁴

The attacker then moved backward through the same access chain. Approximately thirty minutes after the last observed activity at the CHP plant, the Teltonika router at the wind farm was factory-reset, its administrator password was changed, and its address was set to 127.0.0.1. Finally, the wind farm’s FortiGate VPN and firewall was also restored to factory settings, causing the loss of its logs. The sequence strongly reinforces a point already visible in the first report: destruction was aimed not only at operational availability but also at restoration capability and forensic visibility.²⁵

In this case, however, investigators recovered enough evidence from other sources to reconstruct the route. Mobile-network-operator logs, persistent data surviving on the Teltonika router, network logs inside the plant, device behaviour, and timing correlations collectively allowed CERT Polska to work backward from the physical disruption to the original wind-farm foothold. The case therefore provides a particularly concrete example of why logs required for serious OT investigation cannot reside only on the devices most likely to be reset, corrupted, replaced, or physically damaged.

What the update changes in the architectural lesson

The strongest new lesson is that a private APN must not be treated as a trusted extension of OT merely because it is private. CERT Polska found that the relevant APN configuration permitted arbitrary communication between attached devices. Its subsequent surveys indicated that this type of configuration was commonly encountered among Polish users of similar services, and the team states that comparable configurations are, to the best of its knowledge, also widely deployed internationally.²⁶

CERT Polska therefore recommends client isolation between APN-connected endpoints where possible, explicit risk assessment where endpoint-to-endpoint communication is genuinely required, allowlist-based controls between the APN gateway and OT, monitoring of traffic against an expected communications profile, centralized logging, removal of unnecessary web, SSH, and Telnet administration services from APN-reachable interfaces, elimination of default credentials, and inclusion of private APNs in penetration tests, red-team exercises, and architecture reviews. Most importantly, where the organization does not control or cannot independently verify the security properties of the APN, CERT Polska recommends treating it as an external, untrusted network with a trust level equivalent to the Internet.²⁷

That recommendation fits directly into the architecture-first interpretation developed earlier in this article. A network’s name or ownership model is not a security boundary. Trust must follow enforceable communication properties, not topology labels. A carrier-managed private APN, an MPLS service, a vendor VPN, a cloud private network, or another non-public transport may reduce some classes of exposure, but none should automatically confer authorization on the endpoints connected to it. The relevant questions remain the same: which identities and devices can communicate, through which interfaces, using which protocols, for which functions, under whose administration, with what logging, and with what controls if one endpoint is compromised.

The follow-up therefore strengthens rather than overturns the central thesis of the original article. The December 2025 campaign was not simply a collection of poorly hardened devices. It was an attack on relationships between systems: first Internet-to-perimeter, then perimeter-to-management plane, then management plane-to-cellular router, then private APN-to-field controller, and finally field controller-to-process network. Each individual connection had an operational purpose. The attack became possible because those legitimate connections composed into a path of authority that no single device description made obvious.

For distributed energy architecture, that is perhaps the most important addition to the case. The attack surface does not stop at the plant boundary, and it does not stop at the DSO-facing interface either. It includes the communications substrates through which geographically separated devices are made reachable. If a compromise at one renewable site can be converted into network reachability toward another industrial facility through shared telecommunications infrastructure, then inter-site isolation becomes a critical-infrastructure requirement, not merely a telecom configuration preference.

Appendix A — Recent European cyberattacks against energy infrastructure

The Polish incident is easier to interpret when placed beside other recent European cases. The comparison below is deliberately selective rather than exhaustive. It covers publicly documented incidents from 2023 to August 2026 for which sufficiently reliable evidence exists to distinguish compromise of an energy company’s enterprise IT from compromise of OT, direct manipulation of an industrial process, or disruption of energy delivery.

The table now uses a single chronological list, and each incident is treated in a corresponding subsection below. One case requires an explicit scope qualification: the April 2025 Norwegian dam attack involved water-management infrastructure associated with a fish-farming facility rather than an electricity-generation asset. It is retained as an adjacent OT comparator because it provides unusually clear evidence of remote cyber manipulation producing a physical effect, but it should not be misclassified as an attack on Norwegian hydropower infrastructure.²⁸

Date	Country and target	Attack class	Confirmed operational effect	OT significance
May 2023	Denmark — 22 energy-sector companies	Coordinated exploitation of vulnerable Zyxel perimeter devices	Eleven organisations were compromised; several reportedly entered island-mode operation	Attackers obtained access to ICS environments at some companies
November 2023	Slovenia — Holding Slovenske elektrarne (HSE)	Ransomware affecting enterprise systems	Information systems were affected, but electricity generation and trading continued	Key power-plant operation systems remained operational
January 2024	Ukraine — district-heating operator in Lviv	Disruptive OT attack; FrostyGoop assessed as likely used	Heating was lost for approximately two days	Malicious Modbus commands directly affected ENCO controllers
9 December 2024	Romania — Electrica Group	Lynx ransomware	Several IT services were affected; critical electricity systems were reported unaffected	No publicly established compromise of electricity-control OT
7 April 2025	Norway — Lake Risevatnet dam, Bremanger	Remote compromise of an OT control interface	A discharge valve was opened for approximately four hours, increasing water flow; no injuries or damage occurred	Direct manipulation of a physical process; adjacent water-infrastructure case rather than an energy-generation incident
Spring 2025, disclosed April 2026	Sweden — heating plant in western Sweden	Attempted destructive cyberattack attributed by the Swedish government to a pro-Russian actor	The attempt was stopped by protection mechanisms and caused no serious consequences	The stated objective was disruption of operational systems controlling heat production
26 December 2025	Romania — Complexul Energetic Oltenia	Gentlemen ransomware	ERP, document-management, email, website, and other business services became unavailable; company activity was partially affected	The National Energy System was reported not to be endangered
29 January 2026	Slovenia — Geoplin	Likely ransomware	Limited impact was reported in the gas supplier’s IT environment	No publicly established OT compromise or gas-supply interruption
3 February 2026	Romania — CONPET	Cyberattack against business IT; ransomware attribution reported separately	Corporate IT was disrupted while oil and petroleum-product transport continued	CONPET reported that SCADA and telecommunications systems were unaffected

Table 1: Selected publicly documented European energy-sector cyber incidents, together with the adjacent Norwegian OT case, May 2023–August 2026. The comparison distinguishes enterprise-IT compromise, access to industrial environments, attempted OT disruption, and confirmed manipulation of physical processes.

Denmark — coordinated compromise of energy companies, May 2023

The May 2023 Danish campaign is the closest pre-Poland example of coordinated compromise across multiple energy operators. SektorCERT documented attacks against 22 companies managing parts of Danish energy infrastructure; eleven were successfully compromised. Vulnerabilities in Zyxel firewalls provided the initial route into the affected environments, and SektorCERT reported access to industrial control systems at some victims. Several organisations resorted to island-mode operation during the incident or its containment.²⁹

The architectural parallel with Poland is stronger than the malware comparison. In both cases, an appliance intended to enforce the boundary between an external network and operational infrastructure became a mechanism through which that boundary could collapse. The Danish campaign therefore demonstrated before December 2025 that compromise of standardized edge infrastructure could be scaled across multiple energy operators. What the public Danish evidence did not show was the later Polish combination of destructive field-device actions, wipers, direct PLC manipulation, and lateral movement between geographically distinct operational environments.

Slovenia — HSE ransomware without electricity disruption, November 2023

Holding Slovenske elektrarne, Slovenia’s largest electricity producer, disclosed a cyberattack against its information systems in November 2023. HSE reported that key power-plant operation systems remained operational, electricity production and trading continued, and connectivity necessary for electricity operations was maintained. Slovenia’s Government Information Security Office stated that available information did not indicate a significant impact on the uninterrupted provision of essential electricity-generation and transmission services.³⁰ CERT-EU subsequently classified the incident as ransomware. ([hse.si][1])

The case illustrates why victim sector and cyber-physical impact must be treated as separate variables. A serious enterprise compromise at an electricity producer does not imply that the adversary obtained authority over the generation process. HSE is therefore a useful contrast with Poland: in Slovenia, the available evidence indicates that the operational boundary held; in Poland, attackers repeatedly crossed such boundaries and reached RTUs, HMIs, protection equipment, communications devices, and PLCs.

Ukraine — FrostyGoop and district-heating disruption in Lviv, January 2024

The January 2024 incident affecting a district-energy company in Lviv is the strongest recent European comparator for direct malicious manipulation of an industrial process. Information shared by Ukraine’s Cyber Security Situation Center with Dragos indicated that adversaries sent Modbus commands to ENCO controllers, causing incorrect measurements and system malfunction. Approximately two days of heating service were lost. Dragos assessed with moderate confidence that the FrostyGoop ICS malware was involved.³¹

FrostyGoop is significant because its functionality was explicitly oriented toward interaction with an industrial protocol. Poland demonstrates the complementary lesson: purpose-built ICS malware is not necessary once an attacker already possesses sufficient operational access. At the second Polish CHP plant, legitimate Siemens S7 functionality was sufficient to place controllers into STOP mode. At renewable sites, ordinary management interfaces were sufficient to corrupt firmware, delete device files, reset equipment, and destroy HMI systems. Both incidents therefore converge on the same underlying principle: the decisive capability is the ability to issue consequential commands to an industrial function, not the sophistication of the executable carrying them.

Romania — Electrica ransomware contained to IT, December 2024

On 9 December 2024, Electrica Group disclosed a cyberattack affecting its information infrastructure while stating that critical systems had not been affected. Romania’s National Cyber Security Directorate subsequently identified the event as a Lynx ransomware attack and reported that, based on the information available to it, critical systems used for electricity distribution remained unaffected.³²³³ ([dnsc.ro][2])

Electrica therefore belongs primarily to the enterprise-IT end of the spectrum. The incident remained relevant to infrastructure security because compromise of corporate systems can expose credentials, maintenance information, remote-access tooling, engineering documents, configuration data, and identities useful for a later OT intrusion. The public evidence, however, does not justify promoting the incident into a case of demonstrated manipulation of electricity-control systems.

Norway — direct manipulation of the Lake Risevatnet dam, April 2025

On 7 April 2025, attackers obtained remote control of a digital system operating a discharge valve at the Lake Risevatnet dam near Bremanger in western Norway. The valve remained fully open for approximately four hours, increasing water discharge by roughly 500 litres per second before the activity was detected and stopped. No injuries or physical damage resulted. Norwegian authorities later publicly attributed the operation to Russian or Russia-linked cyber actors.³⁴ ([Reuters][3])

Technical reporting by Claroty described a web-accessible control interface protected by weak authentication as the relevant exposure.³⁵ The incident is notable because attackers did not merely enter an organisation’s network: they changed the state of a physical actuator and altered a real process. ([Claroty][4])

Its inclusion here nevertheless requires precision. Contemporary reporting identifies the affected installation as a dam associated with fish farming, not as an electricity-generating hydropower plant. It is therefore an adjacent critical-infrastructure comparator rather than another energy-sector victim. ([The Guardian][5]) Its relevance to the Polish analysis lies in the mechanism: an internet-reachable management surface, weak authentication, and insufficient separation between remote administration and physical control were enough to convert ordinary remote connectivity into cyber-physical authority.

Sweden — foiled attack on a heating plant, spring 2025

In April 2026, Swedish Civil Defence Minister Carl-Oskar Bohlin publicly disclosed that a cyberattack had targeted a heating plant in western Sweden during the spring of 2025. According to the minister, the Swedish Security Service investigated the case and identified a pro-Russian actor with links to Russian intelligence and security services. The operation was intended to disrupt the facility’s functioning but was stopped by an existing protection mechanism, and no serious consequences resulted.³⁶ ([sverigesradio.se][6])

The evidentiary limitation is as important as the incident itself. Public reporting does not provide enough technical information to reconstruct the access vector, the targeted controller architecture, or the exact actions attempted. It therefore cannot be compared technically with the Polish private-APN attack chain or FrostyGoop. What can be stated is narrower: Swedish authorities described an attempted operation against OT responsible for a physical heating function, and the attack failed because a protection mechanism prevented the intended consequence. ([AP News][7])

This makes Sweden a useful example of a category that is easily lost in incident statistics: attempted cyber-physical disruption that does not become an outage. The absence of customer impact does not imply absence of operational intent, just as the continued generation of electricity at the Polish renewable sites did not make destruction of their telecontrol infrastructure operationally irrelevant.

Romania — Complexul Energetic Oltenia ransomware, December 2025

On 26 December 2025, only three days before the Polish campaign, Complexul Energetic Oltenia detected a ransomware attack identified as Gentlemen against its business IT infrastructure. Files and documents were encrypted, and several services became temporarily unavailable, including ERP, document management, email, and the company’s website. Company activity was partially affected, but the operator stated that the functioning of Romania’s National Energy System had not been endangered.³⁷ ([AGERPRES][8])

Recovery began on newly prepared infrastructure using available backups while investigators examined the extent of the compromise and the possibility of data exfiltration. ([AGERPRES][8]) The case is therefore useful not because it reproduces the Polish attack, but because it demonstrates the difference between destructive enterprise impact and destructive OT impact. Both can impose substantial recovery costs, but only the latter establishes direct adversarial authority over the energy process.

Slovenia — Geoplin likely ransomware, January 2026

On 29 January 2026, Slovenian gas supplier Geoplin was targeted in what CERT-EU described as a likely ransomware attack. Public reporting indicated limited effects on its IT environment and alleged theft of employee, financial, and internal corporate data.³⁸ ([cert.europa.eu][9])

The available evidence does not establish compromise of gas-control OT, manipulation of pipeline infrastructure, or interruption of gas supply. That limitation should remain explicit. Geoplin is consequently best classified as an energy-sector IT compromise with no publicly confirmed cyber-physical effect, rather than as evidence of an attack on the physical gas process.

Romania — CONPET business-IT compromise, February 2026

On 3 February 2026, Romanian national oil-transport operator CONPET experienced a cyberattack against its business IT environment. The company’s subsequent reporting stated that operational technologies were unaffected. Oil and petroleum-product transport continued, while SCADA and telecommunications systems remained operational.³⁹

CONPET completes the pattern already visible at Electrica, HSE, Geoplin, and Complexul Energetic Oltenia. Energy operators are attractive targets for conventional cybercrime and ransomware, but compromise of an energy company should not automatically be described as compromise of energy infrastructure at the process-control level. The distinction is particularly important when comparing such incidents with the Polish CHP plant, where attackers demonstrably reached PLCs and changed their operating state.

Three levels of operational significance

Taken together, the cases support a useful three-level distinction.

The first level comprises enterprise attacks against energy operators without publicly confirmed OT compromise. HSE, Electrica, Complexul Energetic Oltenia, Geoplin, and CONPET belong principally to this category. These incidents can still be severe: corporate identity systems, engineering documents, remote-access credentials, maintenance records, backups, and supplier information may all become strategically useful to an attacker. What the evidence does not establish is direct control of the physical energy process.

The second level comprises access to or attempted disruption of operational systems without a sustained physical service failure. The Danish campaign crossed into ICS environments at some organisations, while the Swedish incident was explicitly described as an unsuccessful attempt to disrupt operational systems at a heating facility. The renewable component of the Polish campaign also occupies part of this middle ground: generation continued, but telemetry, remote control, protection, communications, and recovery infrastructure were deliberately damaged.

The third level comprises confirmed manipulation of industrial functions that changes a physical process or interrupts an energy service. The Lviv heating attack belongs clearly in this category. So does the attack against the second Polish CHP plant, where controllers were placed into STOP mode and cogeneration was interrupted. The Norwegian dam incident demonstrates the same cyber-physical transition in an adjacent water-management domain: remote access became authority over an actuator, and a digital command produced measurable physical change.

This taxonomy is more informative than simply counting “energy cyberattacks”. From an architectural perspective, the significant variable is how far through the cyber-physical stack the adversary progressed: from enterprise data, to identities and management systems, to OT networks, to control devices, to process authority, and finally to observable physical consequences.

Why the Polish campaign remains unusual

The broader European record shows that few of the individual ingredients observed in Poland were unprecedented. Vulnerable perimeter appliances had already enabled coordinated compromise across Danish energy organisations. Ransomware had repeatedly affected European electricity, gas, and oil companies. Ukraine had already demonstrated direct malicious use of an industrial protocol to interrupt heating. Norway had shown that weakly protected remote control could produce immediate physical manipulation, while Sweden disclosed an attempted attack explicitly intended to disrupt heating-plant OT.

What distinguishes the Polish campaign is their composition within one coordinated operation. The attacker acted across dozens of distributed renewable sites, destroyed heterogeneous OT equipment, compromised enterprise and Active Directory environments, deployed wipers, attempted lower-level storage destruction, directly stopped PLCs at a CHP plant, and — as CERT Polska’s follow-up established — converted a compromised renewable site and a DSO-managed private APN into a lateral path toward another industrial facility.

The comparison therefore reinforces rather than dilutes the central thesis of this article. Recent European experience does not support a model in which destructive capability depends primarily on increasingly exotic “cyber weapons”. The recurrent mechanisms are more ordinary: perimeter appliances, weak identities, remote administration, management interfaces, insufficient segmentation, industrial protocols, shared communications networks, and fragile recovery paths. The strategic effect depends on which legitimate relationships those compromised components allow an attacker to traverse.

A useful exclusion: the April 2025 Iberian blackout

One highly visible European energy event should remain outside the table. The electricity blackout affecting Spain and Portugal on 28 April 2025 generated immediate speculation about cyberattack, but the investigation presented by the Spanish government in June found no evidence that a cyber incident or cyberattack caused the crisis, whether at the system operator, control centres, or generation facilities.⁴⁰ ([La Moncloa][10])

The investigation instead described a multifactorial electrical-system failure involving oscillations, insufficient dynamic voltage-control capability, voltage increases, and generation disconnections. ([La Moncloa][10]) Its exclusion illustrates the same evidentiary discipline used throughout this appendix: an operational failure, an attack claim, and a technically established cyberattack are different things. Unexplained physical disruption should be investigated for malicious causes when circumstances justify it, as CERT Polska did with the second CHP plant, but it should enter a cyberattack chronology only when evidence supports that classification.

Appendix B — How the European Union is responding

The Polish campaign exposes four different security problems at once: how energy operators govern cyber risk; how electricity-sector actors secure interconnected operational systems; how manufacturers design and maintain the products deployed inside those systems; and how Europe manages strategic dependence on technology suppliers. The European Union is increasingly addressing these as separate but interacting regulatory layers.

That distinction matters because no single instrument would have covered the entire Polish attack path. NIS2 regulates the cybersecurity governance of covered organisations. The Network Code on Cybersecurity adds rules specific to the interconnected electricity system. The Cyber Resilience Act changes the product-security baseline for hardware and software placed on the Union market. The proposed revision of the Cybersecurity Act, usually referred to as CSA2, would add a more explicitly strategic layer for ICT supply-chain risk and high-risk suppliers.⁴¹

EU instrument	Primary object of regulation	Relevance to the Polish failure modes	Status in August 2026
NIS2	Covered essential and important entities	Governance, risk management, supply-chain security, incident handling, business continuity, management accountability, supervision	In force; national implementation remains uneven
Network Code on Cybersecurity	Cybersecurity of cross-border electricity flows and identified high- and critical-impact entities	Electricity-sector risk assessment, common controls, reporting, crisis management, supply-chain and substation-security measures	In force; detailed methodologies and implementation work continue
Cyber Resilience Act	Products with digital elements placed on the EU market and their manufacturers	Secure defaults, attack-surface reduction, vulnerability handling, updates, product support, security documentation and reporting	In force; Article 14 reporting starts 11 September 2026; general application from 11 December 2027
Proposed Cybersecurity Act 2	EU cybersecurity governance, certification and ICT supply-chain security	Strategic supplier dependence, high-risk suppliers and potentially critical equipment used by energy operators	Commission proposal; not yet enacted

Table 2: The EU response operates at distinct but complementary levels: organisational governance, electricity-sector operation, product security, and strategic ICT supply-chain risk.

The importance of this architecture is that the four layers regulate different objects. A secure product does not guarantee a secure plant. A well-governed plant cannot compensate indefinitely for products that ship with avoidable vulnerabilities or weak lifecycle support. Sector-specific electricity rules cannot determine the security posture of every commercial product in the supply chain. And technical certification alone cannot answer geopolitical questions about structural dependence on suppliers subject to foreign control. The direction of EU policy is therefore toward overlapping controls rather than one universal cybersecurity regime.

NIS2: moving cybersecurity into management accountability

NIS2 is the broad organisational layer. Directive (EU) 2022/2555 covers energy as a sector of high criticality and requires covered essential and important entities to implement proportionate cybersecurity risk-management measures. Those measures expressly include incident handling, business continuity and crisis management, supply-chain security, vulnerability handling, security in acquisition and development, assessment of control effectiveness, cyber hygiene, cryptography, access control, asset management, and multifactor or continuous authentication where appropriate.⁴²

For the argument developed in this article, Article 20 is particularly important. NIS2 requires the management bodies of essential and important entities to approve cybersecurity risk-management measures and oversee their implementation. Member States must also ensure that management bodies can be held accountable for infringements of the relevant risk-management obligations under national law.⁴³ Cybersecurity is therefore no longer framed only as a matter delegated to an IT or OT security function. Decisions about remote access, supplier connectivity, shared credentials, recovery capability, network architecture, maintenance arrangements, and operational dependencies become governance questions for which senior management has an explicit regulatory role.

The supply-chain provision maps especially closely to the Polish case. Article 21 requires entities to address security aspects of their relationships with direct suppliers and service providers.⁴⁴ That is relevant to architectures in which EPCs, telecontrol integrators, equipment manufacturers, O&M contractors, telecommunications providers, and grid operators all participate in the operational trust graph. NIS2 does not prescribe one technical topology for those relationships, but it removes any defensible assumption that third-party connectivity sits outside the regulated risk-management perimeter.

NIS2 also establishes a staged reporting regime for significant incidents: an early warning must ordinarily be submitted within 24 hours of awareness, followed by an incident notification within 72 hours and a final report normally within one month.⁴⁵ The second Polish CHP incident illustrates why this matters operationally. The event was initially interpreted as a contractor error during maintenance and was reported only for informational purposes; CERT Polska’s awareness of the simultaneous attacks led investigators to reconsider it as potentially malicious. A mature reporting regime therefore has to capture not only obvious ransomware events but operational anomalies whose cyber origin may initially be uncertain.

The weakness is implementation uniformity. Member States were required to transpose NIS2 by 17 October 2024, but the deadline did not produce simultaneous national implementation.⁴⁶ ECSO’s tracker currently records primary transposition legislation in 23 of 27 Member States and documents material differences in scope, registration, supervision, deadlines, and implementation details.⁴⁷ The Commission applies a stricter completion test: as recently as July 2026 it referred Ireland, Spain, France, and the Netherlands to the Court of Justice for failure to notify complete NIS2 transposition.⁴⁸

This does not make NIS2 ineffective, but it means that an operator managing similar assets across several Member States can still encounter different national implementation conditions. The regulatory objective is a high common level of cybersecurity; the present implementation landscape has not yet completely achieved the common part.

The Network Code on Cybersecurity: translating cybersecurity into electricity-system rules

NIS2 is cross-sectoral. Electricity also has a dedicated instrument: Commission Delegated Regulation (EU) 2024/1366, the Network Code on sector-specific rules for cybersecurity aspects of cross-border electricity flows. The Regulation entered into force on 13 June 2024 and establishes a recurrent framework covering cybersecurity risk assessment, common minimum requirements, monitoring, reporting, crisis management, and other measures related to the security of the interconnected electricity system.⁴⁹

The Network Code is important because it treats cybersecurity not merely as enterprise security inside electricity companies, but as a property of system interdependence. ENTSO-E describes its purpose as establishing a European standard for cybersecurity of cross-border electricity flows, including cyber-risk assessment, common requirements, certification-related provisions, monitoring, reporting and crisis management.⁵⁰

That perspective closely matches the lesson of the CERT Polska follow-up. The most consequential boundary was not necessarily the corporate perimeter of one plant. It was the relationship among a compromised GCP, a cellular router, a DSO-managed private APN, another field endpoint, and the OT network of a separate CHP plant. The Network Code’s system-level approach is therefore directionally aligned with the problem demonstrated in Poland: security has to be assessed across dependencies and communications relationships, not only asset by asset.

Implementation is also becoming progressively more concrete. ENTSO-E and the EU DSO Entity have been developing methodologies and supporting documents under the Regulation, including cybersecurity risk-assessment methodologies, a cyberattack classification scale, minimum and advanced controls, and procurement recommendations for substation gateways.⁵¹ The latter is particularly relevant to an incident in which routers, gateways, VPN appliances, RTUs, serial servers, and other substation-edge components were central to both compromise and recovery.

The scope should nevertheless not be overstated. The Network Code is concerned specifically with cybersecurity aspects of cross-border electricity flows and uses risk-based processes to identify high-impact and critical-impact entities and processes. It is not a general cybersecurity code automatically governing every wind turbine, photovoltaic inverter, PLC, BESS controller, or industrial network in Europe. Its significance lies in creating a sector-specific control layer where cyber risk can propagate into the interconnected electricity system.

The Cyber Resilience Act: shifting part of the burden back to the product

The Cyber Resilience Act addresses a different failure mode. Regulation (EU) 2024/2847 establishes horizontal cybersecurity requirements for products with digital elements made available on the Union market.⁵² As discussed in my separate analysis of the CRA, its structural innovation is to move part of cybersecurity from procurement clauses and operator hardening into product law: an in-scope manufacturer must connect cybersecurity risk assessment, secure design, vulnerability handling, conformity assessment, technical documentation, support, and market surveillance to the product that it places on the market.⁵³

This is directly relevant to several Polish attack mechanisms, but with an important qualification. It would be incorrect to claim, without product-by-product legal analysis, that every firewall, router, RTU, PLC, relay, HMI package, or serial device server appearing in the CERT Polska reports is necessarily subject to the CRA in exactly the same way. Scope depends on the statutory product definition, market placement, intended or reasonably foreseeable connectivity, applicable exclusions, product classification, and the relevant transition rules.⁵⁴

The direction of the requirements is nevertheless clear. For in-scope products, Annex I establishes risk-based cybersecurity properties including secure-by-default configuration where applicable, protection against unauthorised access, attack-surface limitation, protection of availability, security-relevant monitoring, and the ability to address vulnerabilities through security updates. Manufacturers also have continuing vulnerability-handling obligations covering identification and documentation of vulnerabilities and components, testing, remediation, coordinated vulnerability disclosure, secure update distribution, and support-period management.⁵⁵

Those requirements correspond strikingly with recurring weaknesses in the Polish case: default credentials, unnecessary management services, weak update integrity, exposed administrative interfaces, vulnerable firmware, long-lived industrial products, and devices whose compromise or destruction significantly complicated restoration. The CRA cannot prescribe the network architecture of a CHP plant, but it can change the security baseline of the products from which that architecture is assembled.

The timing is equally important. The CRA entered into force on 10 December 2024, but its main product obligations apply generally from 11 December 2027. Article 14 reporting obligations apply earlier, from 11 September 2026, requiring manufacturers to report actively exploited vulnerabilities and severe security incidents affecting in-scope products according to the Regulation’s notification process.⁵⁶ The December 2025 Polish incident should therefore not be described as a failure of CRA enforcement: the Regulation’s general product-security regime was not yet applicable. Its relevance is prospective. It is part of the EU response intended to make comparable device-level weaknesses less acceptable in products entering the future European market.

For industrial infrastructure, lifecycle duration is particularly consequential. The CRA links vulnerability handling to a manufacturer-defined support period based on expected use, subject to statutory minimum rules. That matters for equipment expected to remain installed for many years, because a plant’s operational lifetime can substantially exceed ordinary consumer or enterprise IT refresh cycles.⁵⁷ Product procurement will therefore increasingly need to treat cybersecurity support horizon, update architecture, dependency support, and recovery capability as engineering characteristics rather than after-sales conveniences.

CSA2: from product security to strategic supplier risk

The proposed revision of the Cybersecurity Act adds another dimension. On 20 January 2026, the Commission proposed a new Cybersecurity Act — commonly called CSA2 — that would replace Regulation (EU) 2019/881, reinforce ENISA and the European cybersecurity certification framework, and establish a trusted ICT supply-chain security framework.⁵⁸

The distinction from the CRA is fundamental. The CRA asks whether a product and its manufacturer satisfy cybersecurity obligations. CSA2’s proposed supply-chain mechanism also addresses non-technical and strategic risk associated with suppliers and third countries. Under the Commission proposal, coordinated Union-level assessments could identify key ICT assets, countries presenting structural cybersecurity concerns, and suppliers considered high risk. Implementing measures could then restrict specified NIS2 entities from using, installing, or integrating relevant ICT components from designated high-risk suppliers, with transition periods and mitigation measures forming part of the mechanism.⁵⁹

Energy is not incidental to that debate. The Commission’s 2026 Strategic Roadmap for Digitalisation and AI in the Energy Sector explicitly points to the proposed Cybersecurity Act as a framework that could, where necessary, support restrictions on inverters from high-risk suppliers.⁶⁰ That is a significant shift in regulatory logic. Security assessment would no longer concern only whether an inverter, gateway, router, or software component meets technical requirements; it could also concern whether strategic dependence on its supplier creates an unacceptable systemic risk.

The connection to Poland is not that CERT Polska attributed the compromised equipment to “high-risk suppliers” in the CSA2 sense. It did not. The relevance is architectural. Modern energy systems can standardize the same vendors, firmware families, management planes, remote services, cellular equipment, and administrative models across thousands of geographically distributed assets. That standardization improves efficiency, but it can also create concentration risk. A vulnerability, supplier compromise, remote-management dependency, or politically unacceptable external influence can then propagate through an installed fleet rather than remain local to one plant.

The proposed framework remains exactly that — a proposal. It is proceeding through the ordinary EU legislative process and may change materially before adoption.⁶¹ It should therefore not yet be treated as a binding power to exclude vendors from European energy infrastructure. The more defensible conclusion is that EU policy has moved from discussing supply-chain risk principally as an operator risk-management problem toward considering an EU-level mechanism capable of imposing coordinated restrictions on strategically risky ICT suppliers.

What the four layers achieve together

The emerging EU framework can be understood as four complementary control surfaces:

1. NIS2 acts on the operator. It asks whether the organisation governing the plant understands its cyber risks, controls suppliers, manages incidents, provides continuity and recovery, and makes management accountable.

2. The Network Code acts on the electricity-system relationship. It asks how cyber risk affects interconnected electricity operations, which processes and entities are high impact, which controls and reporting mechanisms are required, and how risk should be coordinated across TSOs, DSOs, authorities and other actors.

3. The CRA acts on the product. It asks whether connected hardware and software are designed, supplied, documented, updated and supported according to a legally enforceable cybersecurity baseline.

4. CSA2, if adopted substantially in the form proposed, would act on strategic supply dependence. It would create mechanisms through which technically functional ICT components could nevertheless become unacceptable for certain critical uses because of broader supply-chain and third-country risk.

%%{init: {"theme": "neo", "look": "handDrawn", "layout": "elk"}}%%
flowchart LR
    N[NIS2<br/>operator governance<br/>risk + reporting + suppliers]
    E[Network Code on Cybersecurity<br/>electricity-system risk<br/>coordination + controls]
    C[Cyber Resilience Act<br/>product lifecycle<br/>secure design + updates]
    S[Proposed CSA2<br/>strategic ICT supply chain<br/>high-risk suppliers]

    A[Energy operational architecture<br/>remote access + communications<br/>OT devices + dependencies + recovery]

    N --> A
    E --> A
    C --> A
    S -. proposed .-> A

Figure 6: The emerging EU cybersecurity response addresses different objects of risk: operators through NIS2, electricity-system interdependencies through the Network Code on Cybersecurity, products through the Cyber Resilience Act, and strategic supplier dependence through the proposed Cybersecurity Act 2.

This layered response is directionally consistent with the architecture-first argument of this article. The Polish attack succeeded because individually legitimate relationships — remote VPN access, firewall administration, device-management interfaces, cellular connectivity, a private APN, field controllers, Windows domains, vendor access, and recovery mechanisms — composed into paths that an attacker could traverse. The EU response increasingly regulates the actors, products, relationships, and dependencies from which those paths are built.

But regulation cannot remove the design problem. NIS2 can make management responsible for risk without deciding the correct VLAN, conduit, jump-host, or maintenance architecture for a particular plant. The Network Code can define common electricity-sector requirements without hardening every field device. The CRA can require a better product baseline without preventing an operator from deploying a secure product in an insecure topology. CSA2 may eventually reduce certain strategic supplier dependencies without eliminating vulnerabilities in trusted suppliers. And none of these instruments can substitute for tested restoration, offline configuration backups, protected logs, site-specific credentials, constrained management planes, inter-site isolation, or disciplined commissioning.

The strongest reading of the EU response is therefore not that compliance will prevent the next Poland. It is that European law is progressively making the architectural shortcuts exposed by Poland harder to justify. Weak product defaults become a manufacturer problem. Uncontrolled supplier relationships become an operator-governance problem. Cross-border electricity dependencies become a sector-level risk problem. Concentration in strategically risky suppliers may become a Union-level supply-chain problem.

That is an important change in the allocation of responsibility. The old model allowed insecurity to fall between contracts: the manufacturer supplied a configurable product, the integrator installed it, the operator accepted it, the telecom provider connected it, and each party could plausibly regard the remaining risk as someone else’s problem. The emerging European framework increasingly removes those gaps.

The remaining task is technical rather than legislative: turn the overlapping legal obligations into one coherent architecture before the plant is commissioned. That means using product assurance, enterprise architecture, IEC 62443 zones and conduits, identity governance, supplier controls, communications isolation, evidence collection, and recovery engineering as parts of the same design process. The Polish campaign demonstrates what happens when operational connectivity is allowed to compose faster than security governance. The EU response is increasingly designed to make that condition legally, economically, and operationally more difficult to sustain.

See also cybersecurity longforms

Operational Technology in the Crosshairs: What the 2025–2026 Attacks Reveal About Industrial Cyber Risk

What the 2026 warnings from Europe and the United States reveal about exposed PLCs, cyber-physical risk, and resilient industrial architecture

VEX Standards from First Principles

From software inventories to defensible vulnerability-exploitability decisions

Cyber Resilience Act: The New Product-Security Baseline

Scope, legal roles, secure design, conformity, reporting, and lifecycle assurance across the digital-product supply chain

See also energy longforms

Operational Technology in the Crosshairs: What the 2025–2026 Attacks Reveal About Industrial Cyber Risk

What the 2026 warnings from Europe and the United States reveal about exposed PLCs, cyber-physical risk, and resilient industrial architecture

From EPC Documentation to System Assurance

Why European BESS projects require systems engineering, cybersecurity-by-design, and evidence-based commissioning

The EU Digital Battery Passport: Who Is Affected, What Must Be Done, and When

A practical guide to product scope, organisational responsibilities, data obligations, and the February 2027 deadline

See also posts

Guerra profonda: recensione tecnica e guida all'approfondimento

Sovranità digitale, guerra algoritmica, AI e conflittualità ibrida nel libro di Arturo Di Corinto

Programming Authority Is the Real PLC Security Boundary

Why network reachability, authentication, and controller programming must be treated as separate security states.

A CVE Is Not an Article 14 Report: What Actually Makes a Vulnerability Reportable?

How to distinguish identifiers, severity scores, exploitation signals, product evidence, and the CRA reporting threshold

Does the CRA Require Vulnerability Scanning from 11 September 2026? No, but It Does Require a Reporting Decision Process

What manufacturers must have ready for Article 14, what customers can legitimately expect, and how scanners, SBOMs, telemetry, and threat intelligence fit

After the Hugging Face Intrusion: What the New Technical Record Changes

A technical update to the July 2026 reconstruction, based on OpenAI's Black Hat account and subsequent primary disclosures

The Withdrawal of HAWK

How a Galois involution cut the effective key-recovery dimension and ended a NIST post-quantum signature candidate

Footnotes

1. See: CERT Polska report. CERT Polska is the first Polish computer emergency response team. It operates within NASK – National Research Institute, has been active since 1996, and carries out the role of CSIRT NASK, one of the three national level CSIRTs in Poland’s cybersecurity system. Its activities include incident handling, active response to threats, malware analysis, security research, threat information exchange, tool development, and public reporting on the security of Polish cyberspace. See also the official team description: About us.

2. See: DynoWiper update: Technical analysis and attribution.

3. See: DynoWiper update: Technical analysis and attribution.

4. See Dragos’s public summary of the report: Poland Power Grid Attack Targets Distributed Energy Resources.

5. The Italian transposition of NIS2 is Decreto Legislativo 4 settembre 2024, n. 138, published in Gazzetta Ufficiale on 1 October 2024 and in force from 16 October 2024. Official text: Gazzetta Ufficiale.

6. The Perimetro di Sicurezza Nazionale Cibernetica was established by Decreto-Legge 21 settembre 2019, n. 105, then converted with modifications by Legge 18 novembre 2019, n. 133. Its incident notification and security measures were further operationalized through DPCM 14 aprile 2021, n. 81, in force from 26 June 2021. See the official publication of the implementing regulation: Gazzetta Ufficiale.

7. Article 33 of Decreto Legislativo n. 138/2024 coordinates NIS2 with the PSNC framework by treating Perimetro obligations on cyber risk management and incident notification as at least equivalent for the systems already covered by that regime. Official text: Gazzetta Ufficiale.

8. ACN states that the new NIS regime has been in force since 16 October 2024 and that ACN is the competent NIS authority and single point of contact. See the official NIS portal: NIS - Network Information Security.

9. Terna publishes the Grid Code (Codice di Rete) and its annexes as the governing technical framework for the national transmission system. The official annex list includes A.13 Criteri di connessione al sistema di controllo di Terna and A.69 Criteri di connessione degli impianti di produzione al sistema di difesa di Terna. See Terna’s official Grid Code page: Codice di Rete Italiano.

10. Current published Annex A.13: Criteri di connessione al sistema di controllo di Terna.

11. PDF

12. PDF

13. The Cyber Resilience Act, Regulation (EU) 2024/2847, entered into force on 10 December 2024. The main obligations apply from 11 December 2027, while the reporting obligations under Article 14 apply earlier, from 11 September 2026. See the European Commission’s summary: Cyber Resilience Act.

14. PDF

15. CERT Polska. (2026, August 8). Follow-Up Analysis of the 29 December 2025 Energy Sector Incident. NASK – National Research Institute. Report

16. CERT Polska. (2026, August 8). Follow-Up Analysis of the 29 December 2025 Energy Sector Incident. NASK – National Research Institute. Report

17. CERT Polska. (2026, August 8). Follow-Up Analysis of the 29 December 2025 Energy Sector Incident. NASK – National Research Institute. Report

18. CERT Polska. (2026, August 8). Follow-Up Analysis of the 29 December 2025 Energy Sector Incident. NASK – National Research Institute. Report

19. CERT Polska. (2026, August 8). Follow-Up Analysis of the 29 December 2025 Energy Sector Incident. NASK – National Research Institute. Report

20. CERT Polska. (2026, August 8). Follow-Up Analysis of the 29 December 2025 Energy Sector Incident. NASK – National Research Institute. Report

21. CERT Polska. (2026, August 8). Follow-Up Analysis of the 29 December 2025 Energy Sector Incident. NASK – National Research Institute. Report

22. CERT Polska. (2026, August 8). Follow-Up Analysis of the 29 December 2025 Energy Sector Incident. NASK – National Research Institute. Report

23. CERT Polska. (2026, August 8). Follow-Up Analysis of the 29 December 2025 Energy Sector Incident. NASK – National Research Institute. Report

24. CERT Polska. (2026, August 8). Follow-Up Analysis of the 29 December 2025 Energy Sector Incident. NASK – National Research Institute. Report

25. CERT Polska. (2026, August 8). Follow-Up Analysis of the 29 December 2025 Energy Sector Incident. NASK – National Research Institute. Report

26. CERT Polska. (2026, August 8). Follow-Up Analysis of the 29 December 2025 Energy Sector Incident. NASK – National Research Institute. Report

27. CERT Polska. (2026, August 8). Follow-Up Analysis of the 29 December 2025 Energy Sector Incident. NASK – National Research Institute. Report

28. Adomaitis, N. (2025, August 13). Norway Spy Chief Blames Russian Hackers for Dam Sabotage in April. Reuters. Report

29. SektorCERT. (2023). The Attack Against Danish Critical Infrastructure. SektorCERT. Report

30. Holding Slovenske elektrarne. (2023, November 30). HSE Successfully Resolves Situation Related to Hacking of HSE Information System. HSE. Official statement

31. Dragos, Inc. (2024, July 23). How to Protect Against FrostyGoop: ICS Malware Targeting Operational Technology. Dragos. Technical analysis

32. Societatea Energetică Electrica S.A. (2024, December 9). Current Report – Cyber Attack in Progress – 9 December 2024. Electrica. Regulatory disclosure

33. National Cyber Security Directorate of Romania. (2024, December 11). LYNX Ransomware Indicators of Compromise (IOCs). DNSC. Official alert

34. Adomaitis, N. (2025, August 13). Norway Spy Chief Blames Russian Hackers for Dam Sabotage in April. Reuters. Report

35. Geyer, G. (2025, June 26). Cyberattack on Norwegian Dam Highlights Password Exposure Risks. Claroty. Technical analysis

36. Sveriges Radio. (2026, April 15). Civil Defence Minister: Sweden Foiled Pro-Russian Cyber Attack on Heating Plant. Sveriges Radio. Report

37. AGERPRES. (2025, December 27). Oltenia Energy Complex’s Activity Partially Affected by Ransomware Cyber Attack. AGERPRES. Report based on company statement

38. CERT-EU. (2026). Cyber Brief 26-02 – January 2026. CERT-EU. Threat intelligence brief

39. CONPET S.A. (2026). Annual Report 2025. CONPET S.A.; Bucharest Stock Exchange. Regulatory filing

40. Government of Spain. (2025, June 17). The Government of Spain Presents the Report on the Causes of the Blackout, Which Was Due to a “Multifactorial” Surge. La Moncloa. Official report summary

41. European Commission. (2026). EU cybersecurity policies. Shaping Europe’s digital future. Official policy overview

42. European Parliament and Council of the European Union. (2022). Directive (EU) 2022/2555 on measures for a high common level of cybersecurity across the Union. Official Journal of the European Union. Official text

43. European Parliament and Council of the European Union. (2022). Directive (EU) 2022/2555 on measures for a high common level of cybersecurity across the Union. Official Journal of the European Union. Official text

44. European Parliament and Council of the European Union. (2022). Directive (EU) 2022/2555, Article 21(2)(d): supply-chain security. Official Journal of the European Union. Official text

45. European Commission. (2023). Directive on measures for a high common level of cybersecurity across the Union — NIS2 Directive FAQs. Shaping Europe’s digital future. Official guidance

46. European Commission. (2026). NIS2 Directive: securing network and information systems. Shaping Europe’s digital future. Official implementation page

47. European Cyber Security Organisation. (2026). NIS2 Directive Transposition Tracker. ECSO. Tracker

48. European Commission. (2026, July 8). Commission refers Ireland, Spain, France and the Netherlands to the Court of Justice for failing to transpose the rules on cybersecurity. European Commission. Infringement decision

49. European Commission. (2024). Commission Delegated Regulation (EU) 2024/1366 supplementing Regulation (EU) 2019/943 by establishing a network code on sector-specific rules for cybersecurity aspects of cross-border electricity flows. Official Journal of the European Union. Official text

50. European Network of Transmission System Operators for Electricity. (2026). Network Code on Cybersecurity. ENTSO-E. Implementation portal

51. European Network of Transmission System Operators for Electricity. (2026). Network Code on Cybersecurity. ENTSO-E. Implementation portal

52. European Parliament and Council of the European Union. (2024). Regulation (EU) 2024/2847 on horizontal cybersecurity requirements for products with digital elements (Cyber Resilience Act). Official Journal of the European Union. Official text

53. 4M4. (2026). Cyber Resilience Act: The New Product-Security Baseline. Random Bits of Knowledge. Article

54. European Parliament and Council of the European Union. (2024). Regulation (EU) 2024/2847 on horizontal cybersecurity requirements for products with digital elements (Cyber Resilience Act). Official Journal of the European Union. Official text

55. European Parliament and Council of the European Union. (2024). Regulation (EU) 2024/2847 on horizontal cybersecurity requirements for products with digital elements (Cyber Resilience Act). Official Journal of the European Union. Official text

56. European Commission. (2026). Cyber Resilience Act. Shaping Europe’s digital future. Official implementation page

57. 4M4. (2026). Cyber Resilience Act: The New Product-Security Baseline. Random Bits of Knowledge. Article

58. European Commission. (2026). Proposal for a Regulation on ENISA, the European Cybersecurity Certification Framework and ICT supply-chain security, repealing Regulation (EU) 2019/881 (Cybersecurity Act 2), COM(2026) 11 final. European Commission. Legislative proposal

59. De Zan, T. (2026, February 11). Protecting the ICT Supply Chain: A Step-By-Step Guide to the New EU Security Framework. Access Partnership. Analysis

60. European Commission. (2026). Strategic Roadmap for Digitalisation and AI in the Energy Sector, COM(2026) 501 final. European Commission. Official communication

61. European Commission. (2026). Proposal for a Regulation on ENISA, the European Cybersecurity Certification Framework and ICT supply-chain security, repealing Regulation (EU) 2019/881 (Cybersecurity Act 2), COM(2026) 11 final. European Commission. Legislative proposal