A device stops reporting. Your management dashboard shows the SIM as active. Your cloud platform has seen nothing from it for six hours. Between those two facts sit four layers of architecture, and the fault lives in one of them.
Most IoT teams inherit an architecture rather than design one. The hardware came from one vendor, the connectivity from a carrier, the management platform from an integrator, and the cloud from whoever the developers already knew. Each part works on its own. The joins are where uptime goes.
Layers are not an academic exercise. They are a map of accountability. When a fleet of meters goes quiet in one country and stays online in three others, the layer model tells you where to look first and who owns the answer.
The layer model also settles a question that decides your security posture: where a control is applied. A control written into firmware lives on the device. A control written into routing lives in the network. Those two choices produce different systems, different audit trails, and different outcomes when a device is compromised.
This layer is the physical estate. Sensors, meters, cameras, chargers, gateways, and the radio module inside each one. It collects data and it acts on instructions.
Two properties of this layer shape everything above it. First, the hardware is fixed at the point of manufacture, and most of it has a service life measured in years, not release cycles. Second, the majority of it is headless. No operating system worth the name, little memory, no user to approve a prompt.
That second property has one consequence worth stating plainly. Devices at this layer cannot defend themselves. They cannot run a security client, they cannot flag anomalous behaviour, and they cannot be patched on the schedule an IT estate would expect. Any architecture that assumes otherwise has a gap in it from day one.
The network layer moves data from the device to wherever it needs to arrive. For cellular IoT that means the SIM profile, the radio access network, the mobile core, and the routing path out to your systems.
Three decisions live here, and each one has a long tail.
A device that ships to Germany, Poland, and Norway arrives on somebody else's network, and rarely the same one twice. One SIM with access to 600+ mobile networks across 190+ countries removes the per-country carrier contract from the design. It does not remove the roaming rules of each market, which belong in your deployment plan rather than your architecture diagram.
By default, cellular IoT traffic crosses the public internet. A private APN or DNN takes it off that path and routes it directly to your data centre or cloud environment. IXT SecureNet does this with a private APN, static or dynamic private IPs, two IPSec tunnels, and direct connections into AWS, Azure, GCP, and Alibaba.
The SIM is the strongest identity primitive available in a cellular deployment, because it is issued by you, provisioned before the device ships, and tied to the IMSI rather than to anything a compromised application could rewrite.
This layer is where you see and change the estate. SIM lifecycle, data usage against thresholds, session logs, connectivity diagnostics, IMEI lock, device grouping, and the API that pulls all of it into your own systems.
The design question here is latency of information. Many provider portals show usage and status on a 24 to 48 hour delay. That is workable for billing reconciliation and useless for an operations team answering the question of why a charger in Warsaw dropped off at 02:00. IXT CMP shows live status, usage, and session data, with API access so the fleet view lives inside your tooling rather than only in ours.
The top layer turns data into something a business acts on. Ingestion, storage, processing, dashboards, alerting, and the integrations into billing, field service, or an energy trading system.
This layer is the best understood of the four, because it is built with the same tools as the rest of your software estate. It is also where the most damaging assumption gets made: that the data arriving has already been through a security boundary. Whether that is true depends entirely on what layer 2 was configured to do.
The layer model makes the security answer more precise than the phrase "IoT security" allows. Four separate controls, four separate homes.
The SIM identifies the device before any session opens. That identity is what every policy above it references.
SecureNet keeps the device off the public internet. A private APN hides traffic but does not defend it. It is still a flat network, so isolation on its own is one control, not a posture.
Zero Trust for IoT works because enforcement moves off the device. IXT Zero Trust checks every session in the network and cloud through Zscaler ZTNA, with device-initiated traffic only, no exposed ports, and no client installed on the hardware. Each device reaches the specific application it is authorised to reach and nothing else, which is what stops lateral movement across a fleet after a single unit is compromised.
Traffic mapping and anomaly detection across the estate come fromIXT Zero Trust Visualisation, built on Illumio. That produces the record of which device, which user, and which third-party contractor reached what, and what they did there. Operational reporting from the management layer is a different artefact and does not substitute for it.
The failure patterns repeat across sectors.
Draw the four layers for your own deployment and write one owner against each control. Identity, routing, enforcement, evidence. Where a control has no owner, you have found the work.
For most IoT deployments, the practical conclusion is that identity, routing, and enforcement sit better in the network than on the hardware, because the hardware outlives the assumptions made about it. That is the architecture IXT runs on its own mobile core built for IoT.
No. Three-layer models group perception, network, and application. Four and five-layer models split out edge processing, management, and business logic. The count matters less than assigning every control an owner.
It means device traffic avoids the public internet. Inside the APN the network is still flat, with no per-session policy and no traffic visibility. Segmentation and enforcement are separate controls.
The network, using SIM identity, for any device that cannot hold a credential securely or run an agent. Application-level authentication sits on top of that rather than in place of it.
Mostly in layers 2 and 3. IXT Zero Trust addresses NIS2 Article 21(2) technical controls: access control, network segmentation, incident detection, supply chain access, audit trail, and continuous authentication. Risk documentation, incident response plans, staff training, and supplier governance remain yours.
Layer 2 absorbs the complexity. Roaming rules, local IMSI options, and carrier relationships all sit there, which is why consolidating them behind one SIM keeps the upper layers stable as the deployment grows.
Map your own four layers against the controls above. If identity, routing, and enforcement land on hardware that cannot carry them, that is the conversation to have. Ask us how it works for your deployment, or book a demo at ixt.io.