Because of the nature of my work, I prepare a number of technical and commercial proposals. In some of these proposals, I recommend the use of private APNs when there is a need for connectivity to remote sites.
That is why a recent report from CERT Polska caught my attention.
The report describes a cyberattack against a combined heat and power plant in Poland in December 2025. What particularly interested me was how the attackers eventually reached the plant's operational technology environment through a private APN.
I have recommended private APNs in some of the solutions I prepare, usually where an organisation needs to connect remote locations and dedicated connectivity would be expensive or difficult to provide. Reading that a private cellular network had been part of the attack path made me wonder whether I should reconsider that recommendation.
Rather than making a decision based on the headline, I wanted to understand exactly what happened.
A quick explanation of private APNs
Most of us use mobile data every day without thinking about how the connection is configured. If you look at the mobile network settings on a phone, however, you will normally find an APN.
APN stands for Access Point Name. It is part of the configuration that determines how a device connects to a mobile operator's data service.
For a normal mobile customer, that service will generally provide access to the Internet.
Businesses can use the mobile network differently.
A telecommunications provider can configure SIM cards for an organisation to use a private APN. Instead of sending the traffic to the public Internet, the operator can route it towards the organisation's network.
A simple example would be a company with a number of remote locations. A cellular router is installed at each location and a SIM card is placed in the router. The SIM is used to authenticate the device to the mobile network, while the private APN determines how the resulting data connection is handled.
The basic arrangement might look like this:
Remote equipment → Cellular router → Mobile network → Private APN → Organisation's network
For an organisation with many remote locations, using an existing cellular network can be considerably easier and less expensive than establishing dedicated fibre connections to every site.
The equipment being connected could vary considerably. It could be a branch-office router, CCTV equipment, an ATM, an IoT gateway, a monitoring system or equipment at an industrial facility.
Private APN services are not all implemented in exactly the same way. Behind the service, the mobile operator may use different routing and network-isolation mechanisms. Some deployments may use dedicated routing instances or other forms of logical separation, while others may rely on isolation within a shared service. The exact implementation depends on how the telecommunications provider has provisioned the service.
That distinction becomes important when assessing what security the APN actually provides.
What happened in Poland
The attack took place on 29 December 2025. CERT Polska published its follow-up investigation on 8 August 2026 after an investigation that lasted more than three months.
The incident involved a smaller combined heat and power plant supplying heat to around 50,000 residents. The attack resulted in the shutdown of a steam turbine and the water-treatment system used to produce process water, interrupting the cogeneration process. The prompt response by the plant operators prevented the incident from disrupting heat supplies to consumers.
The route the attackers used to reach the plant is what made the incident particularly relevant to me.
According to CERT Polska, the investigators identified the device from which the attacker conducted their operations and reconstructed the attack path. They concluded that the use of a private APN to gain access to the OT network was, to their knowledge, the first instance of this attack vector observed in a real-world cyberattack.
The private APN was not the attacker's original entry point.
The attacker had first gained access to infrastructure at a wind-farm environment. From that compromised environment, the attacker was able to reach a Teltonika cellular router and use it to gain access to the distribution system operator's private APN.
From there, the attacker could move within the private APN because its configuration allowed arbitrary devices within the network to communicate with one another. CERT Polska's surveys found that this type of configuration was commonly encountered among organisations using similar solutions in Poland and, according to CERT's assessment, is also widely used in other countries.
The investigation then reconstructed the path to a WAGO PFC200 controller at the CHP plant. The controller's web administration interface was accessible through the APN and was still using default administrator credentials.
The attackers subsequently moved further into the plant environment and interacted with Siemens PLCs. Three PLCs were placed into STOP mode, contributing to the shutdown of the steam turbine and water-treatment system.
The private APN wasn't itself a vulnerability that suddenly made the cellular network insecure. It became part of the attack path because of how access and communication had been configured around it.
This changed how I look at private APNs
When we describe something as a private network, it is easy to associate the word "private" with security.
A private APN does provide an important form of separation from the public Internet, but the term does not, by itself, tell us how well the connected devices are isolated from one another or what those devices can reach.
That applies well beyond industrial environments.
Imagine an organisation with twenty remote locations connected through a private APN. If a device at one location is compromised, the organisation needs to know whether that device can communicate with equipment at the other nineteen locations.
The same consideration applies within a location. A CCTV system may only need to communicate with its video management platform. An IoT gateway may only need to send information to a particular application. A remote office may need access to a limited number of corporate services.
There may be no operational reason for those systems to have broad access to everything else connected to the private network.
This applies to many types of organisations: banks connecting ATMs, companies connecting branch offices, logistics companies connecting vehicles, organisations connecting surveillance systems, and businesses deploying IoT equipment across multiple locations.
The technology being connected changes, but the security question remains the same: if one device is compromised, what can it reach?
That is what the Polish incident made me think about more carefully.
Where I think the security boundary should be
I don't think the answer is to stop using private APNs. They can still be a very practical connectivity option.
What I would change is the way the security architecture around them is considered.
The private APN should not automatically be treated as the point at which an organisation decides to trust the connected equipment.
Depending on the application, a remote connection could pass through appropriate security controls before reaching the organisation's internal systems.
For example:
Remote site → Cellular router → Private APN → Perimeter firewall/security gateway → Segmentation layer → Internal systems
The firewall provides a controlled point at which traffic can be inspected and permitted or denied according to the organisation's security policy.
For higher-risk environments, an organisation may also choose to use an encrypted overlay, such as an IPsec tunnel, between appropriate security gateways. This can provide cryptographic protection independently of how the carrier's private APN service is implemented.
The important distinction is that private routing and encryption are not necessarily the same thing.
From there, the internal environment should not necessarily be treated as one large trusted network.
Corporate IT, IoT and CCTV, and OT or industrial systems can have different security requirements and should be separated accordingly. Communication between those environments should be explicitly controlled rather than allowed simply because they belong to the same organisation.
For an OT environment, there may be additional layers of separation. A design could include an OT DMZ, an industrial firewall, the OT network and then the controllers, PLCs and field devices themselves.
For organisations operating industrial environments, recognised approaches such as IEC 62443 zones and conduits and the Purdue model can provide useful frameworks for deciding how systems should be separated and how communication between them should be controlled.
The exact architecture will depend on the organisation and the systems involved. A branch office, CCTV deployment, IoT installation and industrial facility will not all require the same design.
The APN therefore needs to be treated as one part of the connectivity architecture rather than the complete security architecture.
Client isolation matters
One of the controls I would specifically ask about is client isolation.
In practical terms, this means that one device connected to the private APN should not automatically be able to initiate communication with another device on the same APN. Where communication between sites or devices is not required, it should be explicitly blocked rather than assumed to be safe simply because all of the devices are on a private network.
The exact point at which that isolation is enforced depends on the carrier's architecture and the organisation's own network design. It may involve routing controls within the carrier environment, restrictions on the APN service and firewall policies at the enterprise termination point.
This is particularly important because CERT Polska identified the ability of arbitrary devices within the APN to communicate with one another as one of the factors that made the attack possible.
Other weaknesses in the attack
The APN configuration was important, but it wasn't the only issue.
The WAGO controller was accessible through the private APN and was still using default administrator credentials. Once the attackers found the device, those credentials gave them another opportunity to move forward.
It would be easy to interpret the incident as an argument against private cellular networks, but I don't think that is what the evidence shows.
The incident involved a combination of connectivity, network configuration, device exposure and weak credentials. A private APN cannot compensate for a poorly secured device, just as strong credentials cannot compensate for a network that permits unnecessary communication between unrelated systems.
The different layers therefore have to work together.
It also reinforces the importance of addressing security during procurement.
If a cellular router, PLC, RTU, IoT gateway or other remote device is going to provide a pathway into a corporate or operational network, requirements such as changing default credentials, disabling unnecessary services, restricting management access, maintaining firmware and supporting centralised logging should be considered in the technical specification rather than left entirely to the deployment stage.
There was also a monitoring and evidence-retention lesson in the incident.
The WAGO controller was rendered unbootable during the attack, which affected the availability of its local evidence. The investigation therefore relied on evidence from other devices and sources to reconstruct what had happened.
Important security logs should not live only on the device that might be compromised.
Where practical, logs from cellular routers, firewalls, gateways and other security-relevant devices should be forwarded to a central logging or SIEM platform. That way, if an attacker resets or destroys a field device, the organisation still has an independent record of what happened.
Monitoring is also important because network segmentation is not only about preventing an attack. It can also limit the attacker's options and give defenders more opportunities to detect unusual activity.
In an OT environment, appropriate monitoring can include visibility into unexpected connections, scanning activity and abnormal industrial communications. Where appropriate, protocol-aware OT monitoring can also help detect or restrict unauthorised commands and unusual behaviour.
The cellular router itself also needs to be treated as a security-relevant device. Management interfaces need to be protected. Credentials need to be changed from vendor defaults. Unnecessary services should be disabled. Firmware and software need to be maintained, and network activity needs to be monitored.
If the remote device provides a path into a more sensitive environment, the consequences of compromising that device need to be considered as part of the original design.
What I will look at differently in future proposals
This is probably the part of the incident that is most relevant to my own work.
When I propose a private APN for a customer, I don't think it is enough to simply specify the number of SIMs required, coverage, bandwidth and connectivity between the sites. I would also want the proposal to establish exactly how the APN has been provisioned and what security controls sit on either side of it.
Questions I would ask the telecom provider
- Is the APN dedicated to the organisation or shared?
- How is traffic isolation implemented?
- Is communication between SIMs or devices within the APN permitted?
- Can client-to-client communication be disabled?
- Where does the APN traffic terminate?
- What routing is available between remote sites?
- What security controls are provided by the carrier and which ones remain the customer's responsibility?
- What logging is available for APN access and network activity?
- How long are those logs retained?
- What happens if one of the connected devices is compromised?
I would then use the answers to determine what needs to be added to the customer's own security architecture and technical specification.
For example, if a device only needs to reach one application, there is little reason to give it access to everything else. If two remote locations don't need to communicate, that traffic can be restricted. If an IoT device doesn't need access to the corporate network, it shouldn't automatically receive that access simply because it uses the company's SIM card.
This is where the principles behind zero-trust architecture become useful.
The fact that a device is connected through a private APN should not, by itself, determine how much trust it receives. Access should be based on the identity of the device or user, the resource being accessed and the communication that is actually required.
Depending on the environment, this can be supported through device authentication, certificates, network segmentation, firewall policies, application controls and continuous monitoring.
Rethinking private APNs
After going through the CERT Polska report, I don't think private APNs need to be removed from remote connectivity solutions. They can still provide a practical and cost-effective way for organisations to connect remote locations without having to build dedicated connectivity to every site.
What needs to change is the assumption that private connectivity automatically means trusted connectivity.
The telecommunications provider provides the connectivity. The organisation still has to understand how that connectivity is configured, what devices can communicate with one another and what those devices are allowed to reach.
That is the part I will carry into the proposals I prepare going forward: a private APN can solve the connectivity problem, but the security architecture has to decide what that connectivity is allowed to access.