A Private Cellular Network Became the Attack Path into a Polish Power Plant

A private connection. An industrial controller still using default credentials. Days of quiet reconnaissance. Then direct access to Siemens PLCs and a turbine at a standstill.

The CERT Polska investigation into an attack on a Polish combined heat and power plant is worth reading closely, and not because of a spectacular vulnerability. There wasn't one. The attack path was built from connectivity, trust and a sequence of reasonable-looking decisions.

Private does not automatically mean trusted.

Technically this involved a private cellular APN used to reach remote industrial equipment. Worth stating plainly, because the coverage invited the shortcut: the investigation does not blame 5G, or cellular technology as such. It is about the security architecture around private connectivity — which is exactly what IEC 62443 is for.

What happened at the plant

On 29 December 2025 attackers hit a plant supplying heat to roughly 50,000 residents. A steam turbine and the process-water treatment system were shut down, interrupting cogeneration. Recovery began while the attackers were still inside the network. Customers ultimately lost neither heat nor electricity.

The disruption matters. The more useful question for defenders is how an attacker who started somewhere else entirely ended up at the industrial control layer.

The answer starts outside the plant.

From a wind farm into someone else's OT

CERT Polska traced the path back to a compromised wind-farm environment. From there the attacker reached a cellular router on a private APN operated by the distribution system operator. The APN existed for a good reason: dedicated connectivity to remote operational equipment.

The problem was that devices on that private network could talk to each other. A compromise at one site therefore became a route toward systems at another.

The attacker used that reach to look around — management interfaces, remote-access services, industrial protocols including S7 and Modbus. A WAGO PFC200 controller turned up with its web management interface reachable over the APN and its administrative account still on default credentials. That controller became the pivot into the plant's OT environment.

At that point this stops being an incident report and becomes an architecture lesson.

The real weakness was implicit trust

It is tempting to pick a single cause: default credentials, an exposed management interface, thin segmentation, an over-permissive private network. None of them explains the incident on its own. The risk emerged because several weaknesses could be chained.

A private connection existed for a legitimate operational function. Once an attacker held one connected environment, that same connection carried him toward others.

So the question is not "is this network private?" but "if one connected system is compromised, what else can it reach?" Those are very different questions. Private connectivity describes how systems communicate. Trust still has to be designed, limited and verified.

Why this belongs on the management agenda

OT security conversations drift quickly toward firewalls, PLCs, patches and protocols. Management needs to sit one level above that, because an organisation can hold a great many technical controls and still rest on assumptions nobody has ever tested:

• that a private network is trusted by definition;
• that a supplier connection will only ever be used as intended;
• that a compromise at a remote site cannot reach another site;
• that an industrial controller only performs its primary process function;
• that an attacker becomes visible the moment he gets in.

If one trusted connection, supplier or remote site is compromised tomorrow, does our critical OT environment stay protected? That is not only a cybersecurity question. It is a question about operational continuity.

Seven practical lessons for industrial environments

1. Treat private connectivity as its own trust boundary

A private APN, MPLS link, supplier tunnel or remote-access connection is not inherently insecure. It should simply not inherit the trust level of the OT zone it connects to. Establish who operates the connection, which systems are on it, whether participants can reach each other, which communication is actually required, and what happens when one participant is compromised.

2. Segment on function and risk

A system that needs to exchange operational data does not need broad access to PLCs, SCADA, engineering workstations and management interfaces. Segmentation should ensure that one compromised connection does not expose an entire process environment. This is the IEC 62443 idea of zones and conduits: group systems by security need, and control communication between them deliberately.

3. Allow only the communication operations actually require

Define it explicitly — source → destination → protocol → function. Anything without an operational reason does not need to be reachable. That applies to the external OT firewall, but just as much to internal networks, private connectivity and remote management paths.

4. Separate management from operational traffic

A device can legitimately need an operational data connection without exposing its web interface or SSH service over the same route. Management access deserves its own path, its own authentication and explicit authorisation. That is what stops a process connection from doubling as an administrative one.

5. Make hardening part of commissioning

Default credentials are not a hygiene footnote when the device concerned can reach industrial systems. Changing credentials, disabling unnecessary services and verifying the final configuration belong in commissioning and acceptance — not in a backlog.

6. Detect the attacker before the impact

The disruption happened on 29 December. The attacker had been exploring for days: CERT Polska observed scanning and successful connections to Siemens PLCs well before the destructive activity.

Would we recognise abnormal behaviour before someone changes the state of the process? OT monitoring therefore has to look past malware, at unexpected communication, new network paths, unusual administrative activity and odd use of entirely legitimate industrial protocols.

7. Test the ecosystem, not just the plant

An assessment that stops at the plant firewall misses the paths that matter. Private cellular networks, remote sites, supplier access, telecom dependencies and gateway devices belong in risk assessments, architecture reviews, penetration tests, red-team exercises and incident-response scenarios. The security boundary of a modern industrial environment rarely stops at the fence.

Where could this attack have been stopped?

The stronger lesson is not that one control failed, but that several weaknesses could be combined. From a management perspective, four questions stand out:

1. Did we know which external connections could ultimately provide a route to critical OT systems?
2. Had we considered the impact of a compromised supplier, remote site or trusted connection?
3. Were there enough independent layers to stop or detect further movement?
4. Could we isolate the incident and restore operations safely if prevention failed?

That is what defence in depth actually means: not one firewall, one private network or one product, but making sure that a failure in one place does not become a route into the industrial process.

Where IEC 62443 helps

IEC 62443 matters because it treats industrial cybersecurity as a programme rather than a pile of technical controls: identifying critical assets and processes, assessing risk in terms of operations and safety, designing zones and controlled communication paths, assigning roles, managing suppliers, organising vulnerability and patch management, arranging monitoring and incident response, testing the controls and improving them.

That is the difference between having security controls and managing industrial cyber risk.

Questions worth asking about your own environment

The most useful response to an incident like this is not another checklist. It is a shorter list of harder questions:

• Which private or externally managed connections reach our OT environment?
• Which of those do we trust without controlling their security ourselves?
• Could a compromise at one remote site create a route into another?
• Which management interfaces are reachable over remote connectivity?
• Would we spot unusual OT communication before it has operational impact?
• Could we safely continue or restore critical processes if a connection or controller were compromised?

If those are hard to answer, that is useful information in itself.

From incident report to implementation

An incident report shows what can go wrong. The next step is learning to prevent, limit, detect and manage these risks systematically — zones, connectivity, access, monitoring and governance around a real industrial environment.

The CyberBusters takeaway

This attack does not prove that private cellular networks are unsafe. It shows something more useful: a private connection only becomes a security boundary once you design and manage it as one.

That takes segmentation, hardening, strong authentication, controlled communication, monitoring, logging, testing and the ability to recover. Above all it takes one architectural principle: a compromise in one place must not automatically create a route to the critical process.

Private connectivity created the path here. Implicit trust widened it. Implementation decides where an attack stops — and that is where IEC 62443 turns from a standard into a working capability.

Sources

• The Hacker News — Hackers breach Polish power plant controls via private cellular network
• CERT Polska — Incident follow-up report: energy sector 2025
• CyberBusters — PECB ISA/IEC 62443 Lead Implementer training