Your PLCs, gateways, and remote sensors sit behind a private APN. Traffic leaves the device, crosses the mobile network, and arrives in your data centre without touching the public internet. Your security team signed that design off years ago.
Then an auditor asks which devices talked to which systems last Tuesday, and what a third-party service engineer did during a maintenance window. Nobody has the answer.
A private APN does real work. It also stops well short of where most industrial buyers assume it stops. This is where the line sits.
What a private APN does
An Access Point Name is the gateway your SIM uses to reach a data network. A public APN drops device traffic onto the open internet. A private APN routes it somewhere you control instead.
In an industrial deployment, that gives you four things.
- Isolation from the public internet. Device traffic travels across the mobile core and into your environment over a dedicated path, so your sensors are not reachable from a scan of public IP space.
- Private IP addressing. Devices get static or dynamic private IPs instead of public ones, which removes the exposed ports that make internet-facing industrial kit an easy target.
- A defined route to your systems. Traffic lands where you decide, whether that is a data centre over IPSec or a direct connection into AWS, Azure, GCP, or Alibaba.
- Identity at the connection level. The APN is bound to the IMSI on the SIM, so a device that is not on your subscription does not get onto the network.
That is a stronger starting point than a public APN with a VPN bolted on. It is a starting point, not a security architecture.
Where the protection stops
A private APN hides traffic. It does not defend it. Inside the APN you have a flat network, and every device on it is reachable by every other device on it.
Four gaps follow from that.
Lateral movement is unrestricted
One compromised gateway sits on the same flat network as the rest of your estate. The APN gave that gateway a private address and a clean route into your systems. An attacker who owns the device inherits both.
You have no view of device-to-device traffic
Isolation is not visibility. A private APN tells you nothing about which devices communicated with which applications, when, or whether that pattern changed last week. You know the traffic stayed private. You do not know what it was.
Access is network-wide, not application-specific
Devices on a private APN reach whatever the routing allows. A water-quality sensor that needs one MQTT broker gets a path to the whole subnet. Least privileged access is the opposite arrangement: each device reaches the one application it was authorised for, and nothing else.
Third-party access forces a choice you do not want to make
Your hardware vendors need to reach their own equipment. On a private APN the options are a VPN into the network, which grants far more than the device, or physical site visits. Neither produces a record of what the engineer did.
What this looks like in a real industrial estate
Consider an operator running 3,000 remote units across six countries with eight hardware suppliers behind them.
An auditor arrives and asks for the access log for one asset over the previous quarter. The private APN produces routing records and data volumes. It does not produce a list of users, sessions, and actions, because it never collected one.
A firmware flaw is disclosed in one supplier's controller. The security team needs to know which units run that controller, what those units have been communicating with, and whether anything unusual started before the disclosure. Answering that from APN records alone is guesswork.
A supplier engineer needs SSH access to 40 controllers on a Tuesday afternoon. The network team issues VPN credentials with a scope far wider than 40 controllers, then relies on the supplier's own hygiene to keep those credentials safe. The Verizon 2024 Data Breach Investigations Report puts third-party involvement in breaches at 15%, up 68% year on year.
What sits on top of a private APN
The fix is not a better APN. It is enforcement above the APN, applied in the network rather than on the device, because headless industrial hardware runs no security agent and never will.
At IXT the layers stay separate, and it is worth naming them separately.
SIM identity. The SIM identifies the device on the mobile core. One SIM covers 600+ mobile networks across 190+ countries, so a unit shipped to Poland behaves the same way as one installed in Portugal.
SecureNet. This is the private networking layer: private APN or DNN, private IP addressing, two IPSec tunnels, managed DNS and NTP, and direct cloud connections. It keeps the device off the public internet. It is the architectural pre-requisite for everything above it, and on its own it inherits the flat-network limits described above.
Zero Trust enforcement. Zscaler ZTNA delivered through the SIM means no exposed ports and device-initiated traffic only, with no client software installed on the device. Third-party access becomes a clientless browser session over SSH, VNC, or RDP, time-limited and recorded. Illumio-based Zero Trust Visualisation maps traffic across every IXT-connected device in real time, flags anomalies, and applies policy-based segmentation, so a compromised controller stays a compromised controller instead of becoming a compromised fleet.
Monitoring. The IXT CMP shows every SIM in real time: status, usage, location, session logs. Many provider portals report on a 24 to 48 hour delay. That gap matters at 2am when a unit drops off.
How to assess your own deployment
Five questions separate a private network from a defended one.
- If one device on your APN is compromised, what else does it reach?
- Name the applications each device class is authorised to talk to. Is that written as policy anywhere the network enforces it?
- When a supplier engineer accesses a device, what record exists afterwards?
- How long after a device starts behaving differently do you find out?
- If an auditor asked for the access history of one asset over three months, where would you get it?
Answers that depend on trusting the devices already inside the APN point to a flat network with a private address range.
Frequently asked questions
Is a private APN enough to secure industrial IoT traffic?
Not on its own. It removes public internet exposure, which addresses one class of attack. It leaves lateral movement, traffic visibility, per-application access, and third-party access unresolved.
What is the difference between a private APN and a VPN?
A VPN encrypts traffic that still crosses public infrastructure. A private APN removes the public internet from the path. A VPN also needs client software, which most industrial sensors and controllers do not run.
Does a private APN satisfy NIS2?
It contributes. NIS2 Article 21(2) asks for access control, network segmentation, incident detection, supply chain access management, and audit trails. A private APN addresses none of those five directly.IXT Zero Trust addresses the technical controls, and your risk documentation, incident response plans, staff training, and supplier governance remain yours to own.
Do we need to replace our private APN?
No. SecureNet is the layer Zero Trust enforcement is built on. Private networking stays, and segmentation, visibility, and session-level access sit above it.
Our devices are on a private APN and have never been breached. Why change anything?
The question an auditor or an incident response team asks is not whether you were breached. It is what you would be able to see and contain if you were. A flat network answers neither question well.
The short version
A private APN is worth having. It hides your traffic from the public internet and gives you a controlled route into your own systems. Inside that boundary, every device still trusts every other device, and nothing is watching what they say to each other.
Ask us how the layers fit your deployment, or book a demo at ixt.io.
