19 September 2026 · 8 minutes

From One Site to Another Through a Private APN

Start reading ↓
Engineering study related to this note

A field device is not exposed to the internet. It communicates with the control center through a private APN. If a device at another site using the same connectivity service is compromised, could that provide a route into our site?

An internet-facing check may not answer that question. A connection closed to the outside can still contain an unexpected path between sites. That path may carry more than measurements: it may also reach the communications device’s management interface.

An investigation published by CERT Polska in 2026 shows this access path.

What is an APN, and why use it in the field?

Two meanings of one connection
Site AField routerControl centerTelecontrolSite BManagement interfacePrivate APN · access policy

Control center → field telecontrol / Site A → Site B management

The control center’s telecontrol connections to field endpoints are shown.

Conceptual illustration · No operations are performed on real devices.

APN means Access Point Name: a name identifying the network used for a mobile data connection. When a cellular router connects, the operator considers the subscription’s permissions and selected APN, then routes the data session to the corresponding network. The APN used for internet access on a phone is an everyday example of the same idea. Knowing a private APN’s name is not sufficient, by itself, to gain admission. Hologram, how APNs work

With a private APN service, the operator can carry traffic from a defined group of SIMs in a separate network arrangement. Field routers connect to the control center through it. The operator’s SIM admission control applies here; it does not enforce the field applications’ user permissions. Deutsche Telekom, IoT Connectivity Guide, p. 30

Think of distributed pumping stations, substations or power generation sites. Rather than installing a dedicated fixed line to every location, an RTU or PLC can communicate through a cellular router. The mobile connection may be designed as the primary link or a backup. The control center talks to the field through the permitted addresses and services.

Simple private APN architecture. A field RTU connects to a cellular router. The radio connection reaches a base station and the operator’s core network. Routing and policies for the private APN carry traffic to the organization’s boundary firewall and control-center SCADA. The APN is not a separate physical device; the handoff connection depends on the service.

The APN in the diagram is not a security appliance installed at the site. It is a connection and routing arrangement defined by the operator. Internet breakout, addressing and communication between endpoints depend on the service configuration. Using a private APN does not establish that all field endpoints are isolated from one another. Hologram, private APNs and connectivity policies

Is the connection encrypted?

“We have a private APN” does not answer this question. We need to identify which part of the path is protected, and between which endpoints:

ProtectionWhere does it apply?What should we not assume?
Mobile radio encryptionIf enabled, on the air interface between the modem and base station.That the entire RTU-to-SCADA path is encrypted.
Private APNWithin the operator’s defined network separation and routing arrangement.That the APN itself provides end-to-end encryption.
IPsec VPNBetween the two configured tunnel endpoints.That field connections outside the tunnel are protected too.
TLSBetween the endpoints of the application connection using TLS.That TLS terminating at a gateway also encrypts the next connection.

Mobile network encryption and application protection cover different parts of the path. The network generation, security settings and tunnel termination points matter. GSMA discusses the air interface, operator network and application connection separately. GSMA, cryptography in IoT connectivity, §4.2

Can the operator see this traffic?

The operator controls the private APN’s transport infrastructure. If the service supports it, our organization’s RADIUS server can participate in deciding which subscriptions are admitted to the APN. RADIUS is part of the access decision; it does not encrypt the RTU’s data. Authenticating a SIM to the mobile network and authorizing access to the corporate APN are also separate controls. Cisco, corporate AAA and APN mapping, pp. 9-35–9-36

If the RTU-to-center content is not separately encrypted, it can be read at a point in the operator infrastructure where that traffic is accessible. Radio encryption does not conceal the content from the operator itself. A compromise at such a point may affect confidentiality and, if not separately protected, integrity. The operator’s transport network therefore belongs within the trust boundaries considered in an OT security assessment.

Data we also want to conceal from the operator needs encryption before it enters the operator’s network. One option is an IPsec tunnel between the field router and the organization’s central firewall, with endpoints and keys under the organization’s control. Encryption, peer authentication and integrity protection should be configured together. A tunnel running only from the operator’s gateway to the control center does not conceal from the operator the content arriving at that gateway. IETF, IPsec ESP protection scope, §1 and §3.1.2

Properly configured TLS at both application endpoints can also protect content. The requirement is cryptographic protection between endpoints controlled by the organization; IPsec is one way to provide it. The operator can still observe tunnel endpoints, timing and traffic volume. Encryption does not prevent an operator-side connectivity outage either.

If the device at the far end of an encrypted connection is compromised, which devices and management functions can it reach? A tunnel can securely carry traffic from that endpoint. Whether that traffic may reach another site’s management interface requires a separate decision.

From a wind farm to another facility

CERT Polska’s follow-up report, published on 8 August 2026, examines an incident affecting a combined heat and power plant on 29 December 2025. Its findings show how access at a compromised wind farm extended to the other facility through the distribution system operator’s private APN.

At the wind farm, the cellular router used a serial DNP3 connection to the RTU. Its Ethernet management interface was nevertheless reachable from the local network. At the other facility, a WAGO PFC200 controller’s web management interface was reachable from the APN and used default administrator credentials. The report states that communication between APN endpoints was permitted. Logs suggest that SSH tunnels were most likely used to reach the local OT network; the method used to obtain access to the first cellular router was not established.

According to plant personnel, PLCs were put into STOP mode. The steam turbine and process water system shut down, interrupting cogeneration. The report describes access extending from one field endpoint to another endpoint’s management interface, rather than an APN password being cracked. CERT Polska, follow-up report, pp. 7–11

Simplified topology based on CERT Polska’s report. At Site A, the compromised firewall/VPN device can reach the cellular router’s Ethernet management interface. The router’s RTU business connection uses DNP3 over RS485. Through the private APN, Site B’s controller/gateway management interface is reachable. That device has connections to local SCADA and the process network. Blue paths show central telecontrol; red shows management access between sites. Tunnel use to reach the local network is the report’s likely interpretation. The drawing does not show every device or cable.

The blue connections show the control center communicating with field endpoints. The red connection runs from one field endpoint to another endpoint’s management interface. This requires APN-side reachability and a management connection accepted by the target. Continuing into the network behind the target also depends on its connections and tunneling, proxy or routing capabilities. Sharing an APN does not, by itself, grant access to every PLC.

Serial telecontrol does not close Ethernet management

From the automation side, we might say, “The RTU communicates over a serial link.” From the security side, another question matters: Which operations does the device carrying that communication accept on its Ethernet interfaces?

Traffic passing through a router and traffic addressed to the router itself encounter different controls. Teltonika’s RUTX50 documentation distinguishes them explicitly: INPUT applies to packets addressed to the device; FORWARD applies to packets it routes to another network. A rule restricting transit traffic should not be assumed to restrict the router’s web or SSH management as well. Check how that distinction is implemented in the product and firmware. Teltonika, RUTX50 Firewall

Listing only telecontrol services therefore leaves part of the architecture out. Management interfaces, maintenance access and connections initiated by the device also belong in the assessment. Permission to communicate with the control center should not become permission to manage other sites. Defining required business flows and configuring boundary controls accordingly is also consistent with NIST’s approach to OT network segmentation. NIST SP 800-82 Rev. 3, §5.2

What should we look for in traffic?

In an architecture where the control center normally polls field devices, a connection initiated by another field endpoint toward a management interface has a different meaning. “It comes from the APN” is not sufficient to classify it as expected traffic.

Observed connectionQuestion to ask
Control center → field telecontrol serviceDo the source, target and service match a defined business flow?
Site A → Site B management interfaceIs there a real maintenance requirement between those sites?
Gateway → local OT deviceWas this connection initiated by the device’s own application or by another session?

This table is an aid to reading records, not the output of a packet capture. A connection record alone does not establish which operation was performed. A sensor outside a tunnel may not see the inner target. With NAT or a proxy, local OT records may show the gateway as the source; identifying the earlier connection may require matching operator and gateway records by time.

Source, destination, direction, service and time can still inform the analysis of encrypted traffic. But treating the IP address we observe as the original source can also be wrong if we do not know what our observation point conceals.

We know which APN the field SIM uses. We also need to know who can arrive from the other end of that connection:

If another site on this service is compromised, which of our devices and management functions could it reach?