Brussels turns up the heat on laggards

The European Commission has filed legal referrals at the EU’s top court against four member states for failing to implement the bloc’s flagship cybersecurity law covering critical infrastructure. Ireland, Spain, France and the Netherlands are more than 20 months late in transposing the NIS2 cybersecurity law, which sets minimum security standards for hospitals, energy networks, transport operators and public administrations.

The Commission has asked the Court of Justice of the European Union to impose a lump sum and ongoing daily financial penalties on all four countries until each formally notifies full transposition. The move, announced Wednesday, marks a rare escalation in the EU’s enforcement of digital rules.

Why NIS2 matters now

NIS2 is an update of the original Network and Information Security Directive of 2016, a law that covered fewer sectors and was applied unevenly across the bloc. The newer directive widened its scope to 18 critical sectors and added risk management and incident reporting requirements that were not included in the original directive.

Few member states met the original October 2024 deadline for transposing NIS2 into domestic legislation. As of January 2025, only six of the EU’s 27 member states had transposed the directive. The delays have left glaring gaps in the bloc’s cyber defenses.

European officials have cast the risk in increasingly stark terms. Speaking in Munich in February, the Commission’s technology lead, Henna Virkkunen, warned the European Union could no longer afford to be “naive” about adversaries’ ability to switch off critical infrastructure, saying that power grids, hospitals and financial systems were all increasingly exposed.

Fines: real teeth or paper tiger?

In practice, the fines being sought by the Commission are rarely paid. Member states in previous cases have generally adopted the required legislation while proceedings are under way, prompting the Commission to withdraw before the court makes a ruling.

That pattern could repeat here. Ireland said its National Cyber Security Bill, which will transpose NIS2 and place the country’s National Cyber Security Centre on a statutory footing, is close to finalization, with the minister responsible expecting to notify transposition by end of 2026. Spain, France and the Netherlands had not published comparable statements at the time of writing.

The threat landscape: incidents are climbing

The filing comes as ENISA, the EU’s cybersecurity agency, has warned of thousands of cybersecurity incidents affecting the bloc in the year ending June 2025. ENISA identified public administration as the most-targeted critical sector at 38% of incidents, followed by transport at 7.5%.

Those numbers explain the urgency. A single breach in a hospital network can disrupt patient care; a compromised energy grid can shut down entire regions. The NIS2 rules are designed to force member states to take basic precautions seriously.

What NIS2 actually requires

• Risk management measures across 18 critical sectors
• Mandatory incident reporting to national authorities
• Supply chain security for ICT products and services
• Board-level accountability for cyber risks

NIS2 also underpins a broader legislative program on cybersecurity. The EU’s Cyber Resilience Act, which imposes security requirements on connected products and whose vulnerability-reporting obligations begin to apply in 2027, relies on the national response-team network that NIS2 establishes.

What’s next for the directive

In January, the Commission proposed revising the EU’s Cybersecurity Act to strengthen ENISA and reduce risks in critical technology supply chains, including a provision that would see member states phase out designated high-risk suppliers such as Huawei and ZTE from critical infrastructure.

Separately, the Commission proposed targeted amendments to NIS2 to provide greater legal clarity and ease compliance for companies — issues which officials have said contributed to delays in transposing the updated directive. Those amendments could soften some of the more burdensome requirements, but they don’t change the core obligations.

For businesses operating across the EU, the message is clear: NIS2 isn’t going away. Even if the court cases drag on, the directive’s requirements will eventually apply everywhere. Companies that haven’t started mapping their compliance obligations should treat this as a wake-up call.

The Commission’s legal action is a signal that Brussels is losing patience. Whether the fines ever get paid is almost beside the point. The real pressure is political and reputational — and for the four countries named, the clock is ticking.

The Breach That Started With a Build Artifact

It started with a single mistake buried in JavaScript. A valid AWS access key was left exposed in public build artifacts — and that was all an attacker needed to walk straight into the CRM systems of roughly 1,500 UK charities.

Beacon, the software provider behind the platform, confirmed the finding in an incident update on August 12. The company admitted the key was likely exposed during routine software development. In other words, this wasn’t a sophisticated nation-state operation. It was a preventable slip-up with outsized consequences.

Once the attacker had the credentials, they didn’t need to break through layers of defense. They simply logged in and downloaded everything: the entire CRM database, including attachment files. Beacon’s assessment is blunt — the full customer base of charitable organizations was impacted.

What Kind of Data Was Taken?

The affected charities operate in some of the most sensitive corners of the sector. Healthcare. Victim support. Rape and sexual abuse services. The data held by these groups isn’t just names and emails — it’s the lifeblood of trust between a charity and its supporters.

Specifically, the breach exposed supporters’ names, email addresses, telephone numbers, and donation records. That combination is a gift for social engineering attacks. Armed with donation history, a scammer can craft a convincing phishing email referencing a past gift. It’s chillingly easy.

There’s some relief, though. Beacon says the CRM system did not hold sensitive patient information, payment card details, or bank account numbers. That limits the damage — but it doesn’t erase it.

Encryption Didn’t Save the Day

Here’s the uncomfortable part: the data was encrypted at rest in AWS. It should have been safe. But because the attacker used valid credentials, AWS decrypted the data on download. So the encryption was effectively a non-factor.

This is a critical lesson for any organization storing data in the cloud. Encryption at rest is a baseline, not a silver bullet. If an attacker has legitimate keys, they get the data in readable form. No exceptions.

Beacon’s own analysis of AWS Cost & Usage reports shows the malicious activity began on July 27 at 01:20:16 UTC and lasted about one hour and 27 minutes. That timing aligns with a sharp spike in data downloads on July 27–28. The attack was quick, targeted, and over before most people even noticed.

Charities Cleared, But Scams Loom

Beacon’s charity customers have all been advised to report the breach to the UK’s Information Commissioner’s Office (ICO). One of the confirmed victims, The Survivor’s Trust, already has. In a statement on August 13, the charity said the ICO reviewed its case and concluded the charity holds no responsibility for the breach.

That’s a small comfort. The charity, which provides specialist rape and sexual abuse support services, has urged supporters to stay alert to potential scams in the coming weeks. Expect phishing emails referencing your donations, your support, your history with the cause. That’s the playbook.

Other charities have gone public with their own disclosures: Shrewsbury and Telford Hospital Charity, the British Deaf Association, and Yorkshire’s Brain Tumour Charity. They join Sheffield Hospital Charity, Priscilla Bacon Hospice Charity, the Clock Tower Sanctuary, and Victim Support in admitting supporter data was compromised.

What Beacon Did Next

Beacon says it has not detected any attempts by the attacker to maintain persistence in its environment. That’s the one piece of good news. The attacker took the data and left — no backdoors, no lingering access.

The company has reset all credentials for services and accounts integrated with AWS to prevent repeat unauthorized access. It’s also monitoring for any signs the stolen data has been published or misused. So far, nothing has surfaced.

But the damage is done. For 1,500 charities, the trust equation has shifted. Supporters who gave their personal details now have to wonder: who’s got my information, and what will they do with it?

The Cloud Security Lesson No One Wants to Learn

This incident is a textbook example of a cloud misconfiguration leading to a data breach in the charity sector. It’s not about sophisticated malware or zero-day exploits. It’s about a developer accidentally leaving a key in a public file.

If you’re responsible for AWS security best practices, take note: credential scanning should be part of your CI/CD pipeline. Secrets should never live in build artifacts. And access keys should be rotated regularly, with least-privilege policies enforced.

Beacon’s customers are now left to deal with the aftermath — notifying supporters, managing reputational fallout, and hoping the ICO doesn’t come knocking with fines. The charities themselves were cleared of responsibility, but that doesn’t help the person whose donation history is now in the hands of a stranger.

One exposed key. 1,500 organizations. Countless individuals. That’s the cost of a single oversight.

The Attack That Took Three Months to Unravel

In late December 2025, a large combined heat and power (CHP) plant in Poland — one serving 50,000 residents — suddenly lost its steam turbine and water treatment system. The cause wasn’t a mechanical failure. It was a cyberattack, and it took Polish CERT (CERT.PL) investigators three months to piece together exactly how it happened.

The post-mortem, published in March 2026, reveals a chain of novel techniques that allowed Russian-linked attackers to reach the plant’s operational technology (OT) network through a private Access Point Name (APN). It’s the first documented case of threat actors using a private APN to breach an OT environment, CERT.PL claims.

This wasn’t an isolated incident. The attack came during a broader Russian campaign targeting 30 Polish renewable energy facilities and another large CHP plant, with the strikes occurring on December 29 and 30, 2025. The earlier report, released in January 2026, detailed wiper malware attacks attributed to Sandworm, a Russian state-backed APT group. This latest report adds a new chapter to that story.

The Intrusion Chain: From Wind Farm to CHP Plant

The attackers didn’t start at the CHP plant. They first compromised a FortiGate VPN and firewall at a wind farm elsewhere in the country. From there, they used a Teltonika cellular router on the same network to pivot toward a private APN managed by a distribution system operator (DSO), establishing an SSH tunnel into that network.

Once inside the APN, they scanned it repeatedly. Eventually, they found a WAGO PFC200 programmable logic controller (PLC) at the CHP plant. Its web interface was exposed via the APN and protected only by default admin credentials. A quick login later, and they were in.

From the WAGO controller, the attackers used SSH to hop into the plant’s OT network. They scanned for and found three Siemens PLCs — the devices that control the steam turbine and water treatment system.

Sabotage and Destruction

According to plant personnel, the PLCs were switched to STOP mode and password-protected, preventing any changes to their operating state or control logic. The result was a shutdown of the steam turbine and the water treatment system used to produce process water, interrupting the cogeneration process entirely.

To stall recovery efforts, the attackers went further. They sabotaged several Moxa network devices, destroyed logs, damaged the WAGO controller, reset the Teltonika router, and restored the FortiGate device to factory settings. It was a deliberate, multi-layered effort to make the investigation as difficult as possible.

Fortunately, the outage didn’t last long, and no customers lost power. But the incident exposed a glaring weakness in how private APNs are often configured.

Why Private APNs Are a Soft Target

Private APNs are supposed to be secure — a closed cellular network for industrial devices. But as this attack shows, they’re often treated as trusted environments, with little to no segmentation from OT systems.

In this case, the APN was a direct bridge from a compromised wind farm to the CHP plant’s most critical controllers. The default credentials on the WAGO PLC were the final, glaring gap.

CERT.PL’s report stresses that organizations using private APN solutions need to rethink their assumptions. The APN should be treated as an untrusted network, not a safe haven.

CERT.PL’s Recommendations for Securing Private APNs

The Polish CERT has issued a detailed list of actions for organizations relying on private APNs. Here’s what they recommend:

• Conduct an audit of private APN configuration and enable client isolation between end devices connected to the APN
• Treat the private APN as an untrusted network and segment it from the OT environment
• Strictly limit communications between the OT network and the device acting as the gateway to the private APN
• Monitor traffic between the OT network and the private APN, flagging any abnormal activity
• Implement centralized logging and monitoring of events generated by devices serving as gateways to the private APN
• Minimize the number of open ports accessible via interfaces reachable from the private APN
• Change default credentials for all services available on devices connected to the private APN, especially administrative services
• Include private APNs and the devices providing access to them within the scope of penetration tests, red team exercises, and security architecture reviews

That last point is crucial. Many organizations simply never test their APN security. A penetration test might reveal the kind of default credential issue that proved fatal here.

The Bigger Picture: Sandworm’s Campaign Against Polish Energy

This attack didn’t happen in a vacuum. It was part of a coordinated campaign by Sandworm, the Russian GRU-linked group known for destructive attacks on Ukraine’s power grid and, more recently, cyberattacks on critical national infrastructure across Europe.

The December 2025 attacks targeted renewable energy facilities and CHP plants across Poland. The wiper malware attacks documented in the January 2026 report were just one piece of the puzzle. This APN-based intrusion shows the group’s willingness to innovate and exploit overlooked attack paths.

For energy companies, the lesson is clear: the perimeter isn’t just the firewall anymore. It’s also the cellular router, the APN, and the PLC with a default password. If you’re responsible for OT security, take a hard look at your private APN configuration today — before someone else does it for you.