Polish authorities disclosed in mid-August 2026 the details of an attack on a district heating plant serving approximately 50,000 residents, carried out the previous winter. The disclosure is unusual in two respects: the intrusion path had not previously been observed in a real-world attack, and the incident spent more than three months misclassified as a contractor error before anyone recognised it as sabotage.

For compliance teams in scope of NIS2, this incident is close to a purpose-built case study. It touches entity classification, supply chain security obligations, incident detection and reporting timelines, and the specific problem of an OT environment that was, on paper, correctly segmented.

The attack chain

The sequence, as reconstructed by Polish CERT and reported by multiple outlets:

Entry — the wind farm. The attacker had access to a FortiGate appliance at a wind farm, operating as both firewall and VPN concentrator. The internet-facing VPN accepted locally configured accounts without multi-factor authentication. This is the entire initial access story: an edge device with local accounts and no MFA.

Lateral movement — the private APN. From the wind farm the attacker pivoted across a private cellular network — a private Access Point Name — into the network of an unrelated district heating plant. The two facilities had no operational relationship. They shared a private APN, almost certainly provided by the same mobile network operator, and that shared APN provided routable connectivity between them.

Polish CERT states that reaching an industrial control network through a private APN is, to the best of its knowledge, the first instance of this attack vector being observed in a real-world cyberattack. That is worth pausing on, because private APNs have been actively recommended as an OT security control. The reasoning was intuitive: a private APN keeps industrial telemetry off the public internet, on a carrier-managed network segment, with no public IP addressing. What that reasoning omitted is that a private APN is a shared private network — and unless the carrier and the customer explicitly configure isolation between endpoints on it, everything on the APN can reach everything else on the APN.

Reconnaissance — eleven days. The attacker spent eleven days inside the heat plant’s environment, probing equipment and testing credentials against the plant’s firewall. Eleven days of credential testing against a firewall generated no response.

Impact — Christmas and the days after. On Christmas Day the attacker connected to three Siemens programmable logic controllers. On 29 December they disabled the controllers running the steam turbine and the water treatment system, and locked operators out by setting new passwords.

Aftermath — three months of misclassification. The plant treated the outage as a contractor error. Heat was restored. No incident was reported as a cyber event. It was more than three months before the true cause was identified.

The four compliance failures

1. MFA on the edge device

The initial access requires no sophistication to describe and none to prevent. An internet-facing VPN concentrator accepting locally configured accounts without MFA is a control failure that every framework in current use addresses explicitly — NIS2 Article 21(2)(j) mandates multi-factor authentication, IEC 62443 requires it for remote access to industrial zones, and CISA has placed VPN appliance credential attacks in its most-exploited categories for several years running.

The recurring detail worth flagging is local accounts. Organisations that have deployed MFA via their identity provider frequently leave locally configured accounts on the appliance itself — break-glass accounts, vendor accounts, accounts created during initial commissioning and never removed. These bypass the identity provider entirely and therefore bypass MFA entirely. Every MFA attestation should be tested against local account authentication paths specifically.

2. The private APN as an unexamined trust boundary

This is the novel and generalisable failure.

A private APN is not a network you own. It is a network segment operated by a mobile carrier, on which the carrier places endpoints belonging to multiple customers or multiple sites. Whether those endpoints can reach each other depends on the carrier’s configuration and on what the customer specified when the service was ordered — which, in most procurement processes, is nothing at all.

The consequence is a trust boundary that sits outside the organisation’s asset inventory, outside its network diagrams, and outside its penetration testing scope. The heat plant’s own segmentation may well have been correct. Its IT/OT boundary may have been properly enforced. It was reached from a direction its architecture did not contemplate, through a service its security team probably regarded as a connectivity line item rather than a network peer.

Under NIS2 Article 21(2)(d), supply chain security includes security-related aspects of the relationships between each entity and its direct suppliers or service providers. A mobile carrier providing a private APN into an OT environment is a direct service provider whose configuration determines your network perimeter. That relationship needs the same treatment as any other supplier: documented security requirements, contractual assurances, and verification.

Concretely, operators using private APNs should establish, in writing from the carrier:

  • Which other endpoints exist on the APN, and whether they belong to the same organisation.
  • Whether endpoint isolation is enabled — that is, whether devices on the APN can route to each other.
  • What routing exists between the APN and any other carrier network segment.
  • Whether the carrier logs and can provide traffic records between APN endpoints.
  • What the carrier’s own access controls to the APN management plane are.

Then implement compensating controls on the assumption that the answer is unfavourable: firewall the APN interface as an untrusted network, authenticate every session across it, and monitor it as an external boundary.

3. Eleven days of credential testing, undetected

The reconnaissance phase involved sustained credential testing against a firewall inside an industrial control network. This should be among the highest-signal, lowest-noise detections available in an OT environment.

Industrial networks are the easiest place in enterprise IT to detect anomalies precisely because their traffic is so stable. A heat plant’s OT network carries a small, well-defined set of protocols between a small, well-defined set of endpoints. Repeated authentication failures against the firewall from an unusual source is not a subtle signal buried in noise; it is an obvious deviation from a highly predictable baseline.

That it went unnoticed for eleven days, and that PLC access on Christmas Day went unnoticed for four more, indicates that OT network monitoring was either absent or unmonitored. NIS2 Article 21(2)(b) requires incident handling capability; Annex I obligations for the energy sector assume detection capability sufficient to support the reporting timelines. Neither is satisfied by a SIEM that covers corporate IT and stops at the OT boundary.

4. Incident classification — the three-month failure

This is the failure with the largest compliance consequence, and it is the one most likely to be replicated elsewhere.

The plant experienced an operational disruption. Controllers stopped. Operators were locked out of them. The event was classified as a contractor error and handled through operational channels. No security investigation was triggered. No incident report was filed.

Under NIS2, entities must submit an early warning within 24 hours of becoming aware of a significant incident, an incident notification within 72 hours, and a final report within one month. A disruption affecting heat supply to 50,000 people is a significant incident by any reading of the significance criteria.

None of those clocks started, because “becoming aware” never happened. And it never happened because operational fault triage and security incident triage were separate processes with no bridge between them.

This is the pattern to take away. Most OT operators have mature processes for diagnosing equipment failure. Those processes are built around the overwhelmingly common case: equipment fails because equipment fails. The processes are optimised to restore service, and they attribute cause to the most probable explanation. A malicious actor deliberately disabling a controller and changing its password produces symptoms that a fault-triage process will map onto “misconfiguration” or “contractor error,” because those are the explanations in the process’s vocabulary.

The fix is procedural rather than technical: specific fault signatures must mandatorily trigger a security assessment regardless of the operational diagnosis. At minimum:

  • Any credential or password change on a control device that no one can attribute to a named, authorised person.
  • Any operator lockout from a control device.
  • Any controller stop, configuration wipe or logic change without a corresponding change record.
  • Any unexplained loss of communication with control devices.

Each of these should generate a security ticket in parallel with the operational one, with the security ticket closable only by the security function. The cost of a false positive here is a few hours of analyst time. The cost of a false negative was demonstrated in Poland.

NIS2 scope: was the plant even in scope?

A district heating plant serving 50,000 residents raises the entity classification question directly.

Under NIS2, district heating and cooling is explicitly named in Annex I (sectors of high criticality) under Energy. Entities in Annex I sectors are essential entities if they exceed the medium-sized enterprise thresholds (250+ employees, or turnover above €50 million and balance sheet above €43 million), and important entities otherwise — with Member States retaining discretion to designate smaller entities as essential where disruption would have significant impact.

A plant serving 50,000 residents may well sit below the size thresholds. Many district heating operators are municipal utilities with modest headcount. So it is entirely plausible that this facility is an important entity rather than an essential one — which changes the supervisory regime (ex post rather than ex ante supervision) and the maximum administrative fine (at least €7 million or 1.4% of global turnover, rather than €10 million or 2%).

What it does not change is the substantive obligation. Article 21 risk management measures and Article 23 reporting obligations apply identically to essential and important entities. The difference is entirely in how the regulator supervises and how hard it can hit you — not in what you must do.

This matters because a great many smaller critical infrastructure operators have concluded, incorrectly, that falling below the essential-entity threshold means falling outside NIS2. It does not. And as the Polish incident shows, an attacker’s targeting has no relationship to your classification: the wind farm was collateral, the heat plant was the objective, and the shared APN was the reason both were relevant.

We examined the broader supervisory picture in our analysis of DORA enforcement and the NIS2 October deadline.

Actions for energy and OT operators

Immediate

  1. Enumerate every internet-facing VPN and remote access appliance. For each, verify MFA is enforced on all authentication paths including local accounts. Test it; do not read the config.
  2. Inventory every private APN, private LTE/5G network, and carrier-managed connection into an OT environment. Obtain written confirmation from the carrier on endpoint isolation.
  3. Treat every such connection as an untrusted external boundary until proven otherwise. Firewall it. Log it.

Within the quarter

  1. Extend network monitoring into the OT environment with baselines for authentication events and control-device access. Alert on deviations.
  2. Build the bridge between operational fault triage and security incident triage. Define the mandatory security-assessment triggers listed above and put them in the operational runbooks, not the security policy.
  3. Re-run your NIS2 entity classification and confirm you have applied the correct Article 23 reporting timelines. If you concluded you were out of scope, re-check against Annex I and Annex II by sector, not by size alone.

Ongoing

  1. Add carrier-provided network services to your supplier security review programme under Article 21(2)(d).
  2. Test the reporting capability. A 24-hour early warning obligation is not satisfiable by a process that requires an executive decision meeting.
  3. Run a tabletop specifically on the misclassification failure: present the team with an operational fault that is actually an intrusion, and see how long it takes anyone to ask the question.

The thing to remember

The most instructive detail in this incident is not the private APN, novel as it is. It is that a heat plant serving 50,000 people had its steam turbine controller disabled by a hostile actor and concluded that a contractor had made a mistake.

Every control discussed above — MFA, segmentation, monitoring, supplier review — is a preventive measure that reduces the probability of an intrusion. The classification failure is different in kind: it is what determines whether you ever find out. An organisation can implement every Article 21 measure and still lose three months, and its entire reporting obligation, because the first person to see the symptom had no reason to consider the cause.

Detection is not only a technology. It is also a question that somebody has to be required to ask.

This article is provided for informational purposes only and does not constitute legal advice. Organisations should consult qualified counsel regarding their specific obligations under NIS2, national transposing legislation, and applicable sectoral regulation.