Private Connectivity, Public Consequences

OT consultants, please stop spreading fear. Focus on solutions.

I am borrowing Ralph Langner recent distinction: “some in OT security [are] focusing on the problem, and others focusing on solutions.”

The threat is serious, but our credibility depends on turning incidents into engineering action. We do not need to call every destructive event “the next Stuxnet.” Operators need an accurate attack path, a defensible risk decision, and verifiable controls.

The Follow-up analysis published on August 8, 2026 provides exactly that opportunity.

What happened, and what did not

On December 29, 2025, coordinated cyberattacks affected Poland’s energy sector. The follow-up describes an additional incident at a smaller combined heat and power plant supplying heat to approximately 50,000 residents.

Three PLCs were reportedly placed in STOP mode and protected with passwords that prevented operators from changing their state or logic. Other industrial communications and network devices were reset or reconfigured. A steam turbine and the process-water treatment system stopped, interrupting cogeneration.

The installation experienced a short outage, but customers did not lose heat or electricity. Prompt action by plant personnel limited the consequence. That is evidence that operational response and recovery worked under pressure.

Because maintenance was underway, the event was initially suspected to be a contractor error. It was still reported, allowing CERT Polska to investigate it alongside other activity.

That is an important operational lesson. Unexplained process interruptions, device resets, communications losses, or configuration changes should enter cyber-incident triage even when a non-malicious explanation appears plausible.

The attack crossed an assumed trust boundary

This was not simply an Internet-exposed PLC story.

CERT Polska reconstructed a path beginning in a compromised wind-farm environment. The attacker had access through a perimeter firewall and VPN, although the report does not establish how that access was first obtained.

From the local network, the attacker reached the administrative services of a cellular router used to communicate with the distribution system operator. Logs indicate that the attacker most likely used SSH tunneling through the router to enter a private cellular access point network, or APN. The APN permitted communication between arbitrary connected devices instead of isolating clients or enforcing a defined reachability matrix.

Beginning on December 18, the attacker scanned the APN for HTTP, VNC, S7, and Modbus. The scan identified an industrial controller associated with the CHP plant. Its web interface was reachable through the APN and retained default administrative credentials.

CERT Polska assesses that the attacker enabled SSH and most likely established a second tunnel into the plant’s OT network.

Reconnaissance continued between December 18 and 25. On December 29, activity inside the CHP environment lasted nearly five hours, and plant recovery began while the attacker was still active. Later actions disrupted PLCs, reconfigured industrial devices, and damaged or reset gateway equipment, delaying recovery and removing evidence. The evidence levels must remain visible.

Device access, scanning, configuration changes, PLC interactions, and process interruption are supported by logs, artifacts, or plant statements. The two tunnels are CERT Polska’s most-likely reconstruction based on correlated evidence. The initial compromise method remains undetermined, and the follow-up report does not attribute this specific intrusion to a named actor. Accuracy strengthens the case. It does not weaken it.

Private connectivity is not trusted connectivity.

A private APN can reduce direct Internet exposure and provide reliable communications for distributed sites. Those are legitimate benefits.

But “private” describes how connectivity is delivered. It does not automatically provide client isolation, endpoint authorization, secure management services, traffic allowlisting, or asset-owner visibility.

In this case, a pathway intended to connect field equipment with a distribution operator became a route between operational environments.

The decisive issue was not cellular technology alone. It was the combination of:

• Shared reachability between APN-connected devices.
• Exposed administrative services.
• Default credentials.
• A device connected to both the APN and the plant network.
• Insufficient restriction between the APN and the CHP OT environment.

This is also a governance problem. The asset owner, distribution operator, telecommunications carrier, integrator, and equipment supplier may each control only part of the architecture. Every party can satisfy its individual scope while the assembled system still creates an unintended attack path.

“The carrier says it is private” is not end-to-end security assurance.

If the asset owner cannot verify a network’s configuration and security controls, that network should be treated as external to the OT environment.

How operators should identify comparable exposure

The objective is not to run an aggressive vulnerability scan across live controllers.

OT vulnerability identification must combine architecture, configuration, reachability, operational function, and consequence. Start with the pathway.

1. Reconstruct every external and provider-managed connection

Reconcile physical site inspections, SIM and carrier records, firewall and switch configurations, engineering drawings, remote-access accounts, and passive network observations.

Identify every cellular router, gateway, RTU, controller, engineering workstation, and device connected to more than one network. The inventory must show not only what equipment exists, but what each device can reach and which organization controls the pathway.

2. Verify APN isolation with evidence

Obtain the actual routing, client isolation, access control, and logging design from the distribution operator or carrier.

Define which endpoint may initiate communication, the permitted destination, protocol, port, and direction. Validate that matrix through a controlled test coordinated with operations and the service provider. A contractual statement is not a reachability test.

3. Separate management from process communications

A process may require a serial or industrial-protocol connection while web administration, SSH, Telnet, or vendor services remain unnecessary.

Disable unused services and prevent management interfaces from being reachable through shared or provider-managed networks.

Where remote administration is required, use a controlled access zone, attributable identity, strong authentication, time-bound approval, and session logging.

4. Eliminate default and shared credentials

Check every service available from the APN-facing interface, not only the device’s primary application.

Use unique credentials, controlled storage and rotation, and certificates where supported. Credential requirements should extend to gateways, cellular routers, protocol converters, switches, and other devices that may be overlooked during a PLC-focused assessment.

5. Allowlist operational communications

Permit only the sources, destinations, directions, protocols, and commands required for an approved operational function. A device reporting information to a distribution operator does not necessarily need to accept connections from peer devices, expose a web console, or route traffic into the plant network.

6. Test detection against the reconstructed path

Confirm that the organization can detect:

• APN scanning and unexpected peer-to-peer communication.
• New SSH sessions or tunnels.
• Administrative logins.
• PLC operating-mode changes.
• Logic or configuration downloads.
• Password changes.
• Factory resets.
• Unexpected IP-address changes.

Centralize gateway logs outside the device so an attacker cannot erase the only available evidence by resetting or damaging the equipment.

7. Recover without destroying the investigation

Maintain and restore-test verified PLC logic, network-device configurations, gateway settings, and engineering files.

During an incident, coordinate urgent operational recovery with evidence preservation. When process conditions allow, collect logs and volatile information before factory resets or reconfiguration; remove them.

These activities should follow an OT-approved method of procedure. Begin with configuration review, passive discovery, and narrowly scoped reachability testing. Active testing of production equipment must account for the process state and have an agreed stop condition.

What leaders should require

Executives do not need to review every firewall rule. They should require an assurance case for every external or provider-managed OT pathway.

That assurance should answer five questions:

• Can we identify every asset and service reachable through the connection?
• Can one customer, site, or field device communicate with another when it should not?
• Which organization owns configuration, monitoring, incident notification, and emergency isolation?
• Can we detect administrative activity and control changes before they become process disruption?
• Can we restore safely while preserving the evidence needed to understand what happened?

Leadership should measure private connections with tested client isolation, APN-facing interfaces governed by allowlists, gateways forwarding logs centrally, default credentials eliminated, and critical configurations restored successfully during exercises.

These indicators provide stronger assurance than vulnerability counts or the number of assets discovered.

Architecture must earn trust.

In my earlier article, A Protection Relay Is Not Another Endpoint, I argued that a severity score cannot determine an operational response without understanding function, reachability, dependencies, and remediation risk.

The same principle applies here.

A private network is not a security conclusion. It is one component within an architecture that must be examined end-to-end.

CERT Polska’s report should not be used to promote fear or to argue that all private APNs are unsafe. It should be used to ask a precise engineering question:

Can a compromised device in one remote environment reach the management plane or control network of another, and can we prove that it cannot?

The solution is not to remove every connection. Industrial operations depend on remote telemetry, engineering support, coordination with grid operators, and access to distributed sites.

Each pathway must be explicit, necessary, isolated, monitored, removable, and recoverable.

Private connectivity can create public consequences. Architecture, not assumption, must determine trust.

Sources

• CERT Polska, “Follow-Up Report of the December 2025 Energy Sector Incident,” August 8, 2026
• CERT Polska, “Follow-Up Analysis of the 29 December 2025 Energy Sector Incident”
• CERT Polska, “Energy Sector Incident Report, 29 December 2025,” January 30, 2026