What this article covers, and what it does not claim
This article explains what a private APN does at the network layer and what it leaves undefended.
It is written for the people who configure APNs, IP pools and IPSec tunnels, not for a board audience.
It maps the gaps to the technical controls in NIS2 Article 21(2), so you know which of them your APN evidences and which it does not.
It does not argue that private APNs are bad engineering. A private APN is the right foundation for an IoT fleet. A foundation is not a building.
It does not claim that IXT makes you NIS2-compliant. Several measures in Article 21(2) stay with you no matter which connectivity provider you choose, and this article names them.
"A private APN answers one question. Where does the traffic go. It does not answer the question an auditor asks, which is what talked to what, and who authorised it." - Henning Solberg, CTO, IXT
The problem your APN was built to solve
Rewind to the deployment decision. A few thousand devices going into the field, a security team that refused to sign off on IoT traffic crossing the public internet, and a requirement to land that traffic in your own data centre. A private APN solved it. Traffic separation in transit, a private IP range you control, a routed path to your systems.
It did the job it was specified for. The trouble starts when the fleet grows, when devices cross borders, when hardware vendors ask for remote access, and when someone asks you to prove device control instead of describing it.
Private APN hides traffic but doesn't defend it. Here is the mechanical reason why.
What a private APN gives you
The IMSI on each SIM binds to an APN name in the carrier's subscriber database. When the device attaches, the PDN context lands in an isolated routing domain, not the carrier's internet breakout. Your device receives an address from a private pool. An IPSec tunnel or IP-VPN carries that traffic to your data centre or cloud VPC.
Three properties come out of that. Traffic separation from the public internet. Addressing you control. A defined path to your systems.
Read the list again and notice what is absent. There is no statement of which device is allowed to reach which host. There is no record of what each device did. There is no enforcement point between one device and the next.
Risk 1: inside the APN, the network is flat
Devices on the same APN sit in one routing domain. East-west traffic between them goes unfiltered because there is nothing in the path to filter it.
That matters because IoT hardware is the weakest material on your network. Headless devices run firmware that ships with default credentials, an open telnet or SSH port, or a web interface never meant to face anything hostile. No operating system to harden, no memory for an agent, a patch cycle measured in years.
So the blast radius of one compromised sensor is the entire APN, plus everything reachable on the far side of your tunnel. An attacker who lands on a device with a default password does not need to break your APN. They are already inside it, addressed, routed, and trusted by your data centre.
The private APN removed the front door and left every internal door open.
Risk 2: you have routing data, not traffic data
Your carrier portal shows SIM status and a data counter. Device 4,211 used 38MB last month.
That is billing information. It is not a security record. It does not tell you which host that device contacted, on which port, at what time, or whether the pattern changed. Anomaly detection needs a baseline of normal behaviour per device. Without flow-level data there is no baseline to compare against.
Add the reporting delay. Most IoT platforms surface usage data on a 24 to 48 hour cycle. When a device starts behaving unlike itself at 02:00, a 36 hour reporting window means the investigation begins the day after next.
You can't attack what you can't see. The inverse holds too. You do not defend what you cannot observe.
Risk 3: remote access reintroduces the ports you removed
Field devices need inbound reach. Firmware updates, diagnostics, a technician pulling logs from a charger that will not come back online. The APN does not provide that, so teams build it. A public IP on a subset of SIMs. A port forward through the tunnel. A jump host inside the APN with SSH open to the office range. A VPN concentrator and client software, which the devices are unable to run anyway.
Every one of those is a reversal of the decision that led you to a private APN. The exposed port moved. It did not disappear.
Risk 4: third-party access is all or nothing
A European EV charging operator working with 8 hardware vendors has 8 organisations that need to reach their own units and nothing else.
On a flat APN the standard answer is a VPN account into the APN. That grants network-wide reach to a contractor's laptop you do not manage. There is no record of the session. There are IP range conflicts between vendors. And when the engagement ends, the credential outlives the contract.
NIS2 Article 21(2) names supply chain security and access control as separate measures for a reason. A shared VPN credential satisfies neither.
Risk 5: policy drifts across borders
One APN in one country stays coherent. Multiply it.
Each carrier relationship brings its own APN configuration, IP addressing convention, inbound rules and interpretation of what the private routing domain includes. Permanent roaming restrictions in several markets force local IMSI arrangements, which means another carrier, another APN, another configuration to keep in step.
Nobody sets out to run inconsistent security policy across 6 countries. It arrives one country at a time.
Risk 6: the audit trail does not exist
Bring the risks above to an auditor and the question comes back in one form. Show me the evidence.
A private APN evidences isolation. It does not evidence control. It produces no per-device access policy, no flow records, no session logs, and no account of which third party touched which device and what they did while connected.
What closing the gap looks like
Four layers, and they are worth keeping separate instead of blending into one claim about a clever SIM.
The SIM identifies the device. Identity starts at the IMSI, not at an application credential that a headless device has no way to store safely.
SecureNet keeps the device off the public internet. Private APN or DNN, static private addressing, 2 IPSec tunnels, direct connection into AWS, Azure, GCP or Alibaba, IXT-managed NTP and DNS. This is the APN layer done properly, and it remains the architectural prerequisite for everything above it.
TheZero Trust layer checks every session, enforced in the network and cloud, not on the device. Traffic is device-initiated only, so there are no exposed ports to scan. Each device reaches the specific application it needs and nothing else, which is what contains a compromise to one device. Third-party access runs through a browser session that is time-limited and recorded, with no client to install and no network reach beyond the target device.
Monitoring sits across all of it. Real-time traffic mapping shows what each device talks to, anomaly detection flags the device that starts behaving unlike its peers, and the IXT CMP shows every SIM live, not on a 24 to 48 hour delay.
Together that addresses the NIS2 Article 21(2) technical controls: access control, network segmentation, incident detection, supply chain access, audit trail, and continuous authentication.
Zero Trust is how IXT ships. For teams that decide against it, SecureNet on its own is the lighter option, with the flat-network limitation above understood and accepted.
What stays your responsibility
Being explicit here is more useful than over-claiming.
IXT does not certify NIS2 compliance. Risk documentation, incident response planning, staff training, supplier governance and any CRA conformity assessment remain yours. The Zero Trust layer is not a SIEM and not a SOC, and it does not patch device firmware.
Traffic mapping covers IXT-connected devices, so non-IXT traffic stays outside the picture. Device types and protocols need a technical assessment before deployment, not an assumption.
FAQ
Is a private APN insecure?
No. It is incomplete. It gives you traffic separation and addressing control. It gives you no per-device policy, no flow visibility and no audit trail, because those were never what an APN was built to produce.
We run a VPN on top of the APN. Does that close the gap?
A VPN encrypts transit and grants broad network access to whatever holds the credential. The devices that most need protection are the ones unable to run a client. The gap that stays open is east-west movement between devices, which a VPN does not address.
Does this require new hardware or software on our devices?
No. Enforcement happens in the network and cloud. There is no client on the device, no customer-side appliance, and remote access is browser-based.
Our IT team already runs Zscaler. Does that cover our IoT estate?
Not today, because agent-based Zero Trust does not reach devices that are unable to run an agent. IXT extends Zscaler ZTNA to IoT and OT devices over cellular. IXT has been a named Zscaler partner for Zscaler Cellular since July 2025.
How do we migrate without a flag day?
Segmentation policy goes in on monitor mode first, so you see the traffic map and the flows your APN never showed you before any rule starts blocking. Groups of devices move to enforcement after that.
What changes for an auditor?
You move from describing isolation to producing records. Per-device policy, session logs, third-party access history and a live device inventory.
Bring your current APN design to the conversation and we will map it against the 6 gaps above, on your device types and your countries.
Book a demo at ixt.io
