📅 February 6, 2026 | ⏱ 8 min read | 🔐 Category: Critical Infrastructure Security
Right at the end of 2025, attackers managed to get inside the operational networks of several Polish energy and industrial organizations.
They did it the way a lot of attackers are breaking into critical systems these days: through remote access that was supposed to be “secure,” but was exposed in just the wrong way.
The targets included renewable energy sites, a combined heat and power plant, and at least one industrial company. The attackers were able to disrupt some of the communication between these sites and the grid operators who manage them. What they did not manage to do was cut off power or heat to customers.
On the surface, that sounds like a near miss. In reality, it is a very clear warning about how much risk is hiding in VPNs and other remote access paths into OT environments.
Let’s walk through what happened, what we know about the entry point, and what you should be doing if you run anything that looks like a plant, grid, or large industrial site.
What Happened In Poland
According to public reporting from Polish authorities and incident responders, the main wave of activity hit on December 29, 2025. The victims were not just a single “national control center,” but a mix of:
- Renewable generation sites, mainly wind and solar
- A combined heat and power plant
- At least one industrial organization tied into the wider energy ecosystem
The attackers got far enough into these environments to interfere with how some sites talked to their distribution network operators. In practice, that meant telemetry and control signals between the plants and the grid side were disrupted for a period of time.
At the CHP plant, the attackers appear to have tried to interrupt heat delivery to customers. That attempt failed. Heat and power continued to flow, and the operator was able to keep the plant online while responding to the incident.
The national CSIRT and Poland’s cybersecurity authorities coordinated the response, together with vendor teams brought in to help with forensics and cleanup. Public statements were quite clear on two points:
- Yes, attackers reached operational technology environments.
- No, they did not cause blackouts or heat outages this time.
If you work in critical infrastructure, that second point is comforting. The first one should be keeping you awake.
The Entry Point: Remote Access That Was Too Open
The key technical detail that matters here is how the attackers got in. Investigation and reporting point to exposed VPN access used to reach systems that talk directly to energy control infrastructure.
Energy and industrial environments rely heavily on remote access. Operators on call, field engineers sitting in substations, vendors who manage SCADA software and protection systems from their own offices. All of that traffic has to come in somehow, and that “somehow” is usually a VPN or a similar remote gateway.
In the Polish case, at least one of those paths was exposed in a way that left it open to abuse. Think of a VPN concentrator reachable from the internet, using usernames and passwords that had not all been rotated or locked down, with inconsistent or missing multi factor authentication.
Once you have that, the rest of the story is sadly predictable. An attacker collects or guesses credentials for an operator or vendor account. They log into the VPN from outside the country. The portal accepts the login because it looks like any other remote session. From there, they can see and reach systems that are much closer to OT than they should be.
We do not have a packet by packet breakdown of the intrusion, but the pattern lines up very closely with previous attacks against utilities:
- Steal or guess VPN or remote access credentials.
- Log in as a “trusted” user.
- Move from the VPN landing zone into SCADA servers, gateways, or engineering workstations.
- Interfere with how field sites talk to the control side.
That is basically what we saw in Poland, just with the added twist that the targets were not only central grid assets but also distributed wind, solar, and CHP facilities.
Why Renewable And Industrial Sites Were Interesting Targets
One interesting detail in this case is who the attackers chose to go after. This was not just about big transmission operators. They clearly spent time on renewable energy sites and on a CHP plant that provides both electricity and heat.
There are a few reasons that makes sense from an attacker’s point of view.
First, modern renewable sites tend to be more connected. They use central management systems, remote monitoring, and integration with grid balancing platforms. That means more remote access paths, more VPNs, more places where credentials and exposed services can go wrong.
Second, combined heat and power plants are tightly coupled to local communities or industrial customers. If you manage to knock one offline in the middle of winter, the impact is very visible, even if the national grid keeps running.
Third, distributed assets can sometimes sit just outside the tightest security controls. The crown jewel control center may be locked down and heavily monitored, while smaller plants and corporate environments are one or two hops away from the same OT networks.
Put all of that together, and targeting renewables, CHP, and a connected industrial site looks like a smart way to test how a country responds without immediately hitting the largest, most protected systems.
“No Outage” Is Not The Same As “No Problem”
It is important to repeat: Poland did not lose power because of this incident. The renewables kept generating. The CHP plant kept feeding heat into the network. Customers did not suddenly find themselves sitting in the dark.
That is good news, but it is not the whole story.
The fact that attackers got far enough to disrupt communications between plants and grid operators is a serious issue on its own. Those communication paths are the nervous system of a modern energy system. If you can’t fully trust what you are seeing from your sites, or your commands are not getting through reliably, you are already in a degraded state.
You also have to assume that the people behind this attack were watching how Poland reacted. How quickly did operators notice something was wrong? How fast did incident response teams get engaged? How easy was it to pull logs and reconstruct what happened?
Those answers are valuable to an adversary even if nothing breaks the first time. It lets them refine their playbook for a future incident, whether in Poland or somewhere else.
What This Should Make You Do If You Run OT
If you are responsible for an energy, utilities, or industrial environment, you do not need every last technical detail from Poland to learn from this. A few very clear action items fall out of this story.
Look hard at your OT facing VPNs and remote access. Make a list of every gateway that can reach anything on, or adjacent to, your control networks. For each one, ask three blunt questions: Is it exposed directly to the internet? Is strong MFA always on and enforced? What exactly can a successful login reach?
If the true answers to those questions make you uncomfortable, that is a good sign you have some work to do.
Next, check how far a user can move once they are logged in. A VPN session should land in a controlled zone, not in the middle of a flat network that leads straight to SCADA or engineering workstations. If you can walk from a VPN landing subnet to a plant network or a CHP control room with only basic routing, you have the same exposure Poland just got a taste of.
Then, think about your monitoring. If an attacker logged in with valid credentials at 2 a.m. from an unusual country and started talking to systems that manage your wind or CHP sites, would anyone see that in close to real time? Or would it end up in a log file that only gets touched after something breaks?
Finally, bring OT teams into this conversation in a real way. In a lot of organizations, remote access for OT started out as a convenience project. Security teams came in later, after the tunnels and workflows were already in place. This is a chance to reset that. Treat remote access like any other high risk system design decision, not like “plumbing” that lives below the security radar.
Simple Changes That Make A Big Difference
You will not rebuild your entire remote access model overnight, but some relatively straightforward changes can dramatically lower your risk:
- Put strong, enforced multi factor authentication on any account that can reach OT through a VPN or similar gateway.
- Restrict VPN access so that sessions land in a small, dedicated network segment, and then force users through a jump server to reach anything sensitive.
- Turn vendor access into a time bound thing. Give partners accounts that expire by default and have to be renewed or reapproved.
- Wire VPN and jump host logs into your existing monitoring so that OT remote access shows up on the same dashboards as your other high risk activity.
None of this is exotic. It is the same kind of hygiene that has been discussed for years on the IT side. The Poland incident is a reminder that you have to apply it to OT as well, especially anywhere that VPN access can touch energy control systems.
Final Thoughts
Poland just got a very public lesson in what happens when exposed VPN access meets determined attackers in a modern energy system. The country was lucky, and also prepared enough, that the attackers did not manage to cut power or heat.
But “we stayed online” is not the standard you should be happy with. The better question is: if someone walks in through your remote access path tomorrow, how far can they get, and how fast will you notice?
If you can start to answer that honestly, and then make some concrete changes based on what you find, you are already ahead of where a lot of organizations were when Poland’s phones started ringing on December 29.
Written by: Logan Elliott
Cyberix
https://www.cyberixsafe.com
