On December 29, 2025, while Poland endured sub-zero temperatures and snowstorms, attackers systematically compromised approximately 30 wind farms, solar installations, and combined heat and power facilities across the country. They bricked remote terminal units (RTUs), wiped Windows systems, and cut communications between distributed energy resources and grid operators.

The grid stayed up. But not because the security worked.

This incident, attributed with moderate confidence to the Russian-linked ELECTRUM threat group by Dragos and overlapping with “Static Tundra” infrastructure according to CERT Polska, represents a watershed moment for critical infrastructure security. It’s the first major coordinated cyberattack targeting distributed energy resources (DER) at scale, and it exposes fundamental gaps in how we think about OT security, regulatory frameworks, and the relationship between cyber risk and physical consequences.

What Actually Happened

The Attack Surface

The attackers exploited a depressingly familiar pattern. According to CERT Polska’s detailed incident report:

  • Every affected facility had a FortiGate device serving as both VPN concentrator and firewall

  • Every VPN interface was exposed to the internet and allowed authentication without multi-factor authentication

  • Credentials were reused across multiple facilities, a “common practice in the industry” per CERT Polska

  • Hitachi RTU560 controllers were configured with default credentials, including an account literally named “Default” with administrative privileges

The attackers were in one CHP plant’s network for 5-9 months before executing the destructive phase. They conducted reconnaissance, stole Active Directory databases, and mapped the environment. On December 29, they pulled the trigger.

The Cyber-Physical Bridge

Here’s where it gets interesting for anyone who thinks “cyber-physical” requires a Hollywood blackout.

The attackers bricked RTUs by uploading corrupted firmware. CERT Polska’s analysis is precise: they modified the firmware file so that 240 bytes of 0xFF were inserted at the program entry point. When the RTU loaded this firmware, the processor hit an invalid instruction, faulted, and entered a reboot loop. The device was physically bricked, requiring hardware replacement or complex field recovery.

The Hitachi RTU560 actually had firmware signature verification available since version 13.2.1. None of the affected devices had it enabled.

For the CHP plant, attackers deployed “DynoWiper” malware via Group Policy Objects to over 100 workstations. The EDR solution detected and blocked it, one of the few bright spots in this incident. At the wind and solar farms, they used a PowerShell-based wiper that CERT Polska assessed was “likely generated using an LLM model.”

Let that sink in: LLM-generated malware, default credentials, and exposed VPNs combined to brick critical infrastructure at 30 sites.

Why No Blackout?

The grid stayed up because of physics, not security.

When RTUs lose communication, most industrial equipment continues operating in its last known state. Generation didn’t stop because the attackers cut the monitoring and control layer. They didn’t (or couldn’t) issue malicious operational commands to the underlying equipment.

Dragos notes that “the attack appears to have been ‘opportunistic’ rather than fully targeted and well planned.” The compressed timeline from reconnaissance to execution left little room for developing the custom payloads needed to actually manipulate power generation.

But make no mistake: this was not a failed attack. It achieved significant operational disruption:

  • Loss of remote monitoring and control at 30 sites

  • RTUs bricked beyond field repair

  • Windows systems wiped

  • Recovery requiring hardware replacement, site visits, and maintenance windows

As Dragos put it: “An attack on a power grid at any time is irresponsible, but to carry it out in the depths of winter is potentially lethal to the civilian population dependent on it.”

The Regulatory Reality Check

This incident landed in a regulatory transition period. The EU Cyber Resilience Act (CRA) was adopted in 2024 but won’t be fully enforceable until December 2027, with vulnerability reporting requirements kicking in September 2026. NIS2, which covers operators like utilities, has been transposed but enforcement varies by member state.

What CRA Would (and Wouldn’t) Address

If CRA were fully in force, manufacturers like Hitachi Energy would face potential fines up to €15 million or 2.5% of global revenue for:

  1. Shipping products with default credentials: CRA explicitly requires “secure by default” configurations, including “banning weak default passwords”

  2. Failure to report actively exploited vulnerabilities within 24 hours: CRA mandates early warning notification to ENISA and national CSIRTs within 24 hours of becoming aware of active exploitation, with full notification within 72 hours and final report within 14 days of patch availability

  3. Inadequate firmware integrity mechanisms: CRA requires products to “protect integrity of commands/config” and provide secure update mechanisms

But CRA would NOT address:

  • Operators choosing not to enable available security features

  • Operators failing to patch known vulnerabilities for years

  • Operators reusing credentials across 30 facilities

  • Operators exposing OT systems to the internet without segmentation

CRA targets manufacturers. It shifts liability upstream to the supply side. That’s appropriate for “default credential” and “firmware integrity” failures. Hitachi shouldn’t ship RTUs with a “Default” admin account in 2025.

But CRA cannot fix operator negligence.

NIS2: What It Means for Utilities and Their Suppliers

This is where NIS2 becomes critical. While CRA targets product manufacturers, NIS2 (Network and Information Security Directive 2) directly governs the Polish utilities and creates cascading obligations for their supply chain.

Utility Obligations Under NIS2

Polish energy operators are classified as “essential entities” under NIS2 Article 3, subjecting them to the directive’s most stringent requirements. Based on the Poland incident, several NIS2 obligations appear to have been violated:

Potential penalties for essential entities under NIS2: up to €10 million or 2% of global annual turnover, whichever is higher.

NIS2 also introduces personal accountability. Article 32 allows member states to hold management bodies personally liable and temporarily ban individuals from management positions for compliance failures. This is new territory for OT security.

Supply Chain Obligations: The Cascade Effect

NIS2 Article 21(2)(d) requires essential entities to address “supply chain security, including security-related aspects concerning the relationships between each entity and its direct suppliers or service providers.”

This creates obligations flowing in both directions:

For utilities (downstream):

  • Must assess cybersecurity practices of RTU vendors, integrators, and service providers

  • Required to include security requirements in procurement contracts

  • Must verify that suppliers maintain appropriate security measures

For suppliers like Hitachi, Fortinet, and system integrators (upstream):

  • Subject to security requirements imposed by utility customers

  • May face contractual liability for products shipped with insecure defaults

  • Increasing pressure to demonstrate IEC 62443 certification or equivalent

The Poland attack exposes a gap: utilities cannot outsource accountability. Even if Hitachi shipped devices with default credentials, NIS2 places the burden on the utility to verify and remediate before deployment.

Incident Reporting Under NIS2

NIS2 establishes strict notification timelines that parallel CRA but apply to operators:

  • Early warning: Within 24 hours of becoming aware of a significant incident

  • Incident notification: Within 72 hours, including initial assessment

  • Final report: Within one month, with root cause analysis and mitigation measures

For the Poland incident, affected utilities would be required to report to Poland’s national CSIRT (CERT Polska) and potentially to ENISA if the incident had cross-border implications.

The IEC 62443 Gap

IEC 62443 is the OT-native standard that addresses what neither CRA nor NIS2 fully specify: system architecture, remote access controls, segmentation, monitoring, and the technical details of asset owner responsibilities.

The key difference? IEC 62443 has no mandatory timelines and no regulatory penalties. It requires manufacturers to “have a vulnerability handling process” and “publish cybersecurity advisories” but doesn’t specify 24 hours, 72 hours, or 14 days. It’s a voluntary standard with certification/audit consequences, not legal enforcement.

You said: review this article about the polish cyber attack by Russia. Pull up the link to the direct Dragos research. Add reference to key elements, key take away. what would EU CRA provide vs just 62433 provide to help mitigate risk (if anything). Other contrarian perspectives worth highlighting

What DER Operators Should Do Monday Morning

Based on CERT Polska’s findings and Dragos’s recommendations:

Immediate:

  1. Audit all internet-exposed OT devices, especially FortiGate and similar VPN concentrators

  2. Verify MFA is enabled, not just available, on all remote access paths

  3. Check RTU credentials against default values. Yes, actually check.

  4. Confirm firmware signature verification is enabled where available

Near-term:
5. Implement network segmentation between IT and OT
6. Enable logging sufficient to detect 5-9 month dwell times
7. Review credential management and eliminate shared accounts across sites
8. Establish RTU spares inventory and recovery procedures

Strategic:
9. Treat cybersecurity as grid reliability engineering
10. Include truck-roll logistics and hardware replacement timelines in your threat model
11. Assess NIS2 compliance gaps, particularly Articles 21(2)(d-j) on supply chain and access control
12. Prepare for CRA and NIS2 enforcement as operational improvements, not checkbox exercises

Looking Forward: The Convergence of CRA and NIS2

Poland’s attack is a preview of the regulatory environment taking shape in Europe. By December 2027, manufacturers will face CRA enforcement for insecure defaults. Utilities already face NIS2 obligations for operational security.

The convergence creates a more complete picture:

  • CRA ensures products arrive with secure configurations and manufacturers respond quickly to vulnerabilities

  • NIS2 ensures operators deploy, configure, and maintain those products securely

  • IEC 62443 provides the technical framework both can reference for OT-specific guidance

For DER operators, the lesson is clear: secure remote access, segmentation, and device integrity controls are now reliability controls, just with more packet captures and fewer hard hats.

CRA (2027) will fine manufacturers like Hitachi for shipping RTUs with “Default” admin accounts. NIS2 already empowers regulators to fine the operators who left those credentials unchanged for years while exposing them to the internet. The enforcement gap between “you must have appropriate measures” and “here’s what appropriate means for DER environments” is where attackers live.

Closing that gap requires both better products and better operations. Poland proved it.

Sources

Primary Technical Reports:

Coverage:

Regulatory:

Tim McAllister is Senior Director of Digital Trust at DigiCert, focusing on Device Trust, PKI infrastructure, and IoT security. Views expressed are his own.