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.
What this article covers, and what it does not
- The layers of a modern IoT connectivity architecture and what each one is accountable for.
- Where device identity, private routing, policy enforcement, and evidence belong.
- The failure modes that appear when two layers each assume the other owns a control.
- It does not argue for one correct number of layers. Three-layer, four-layer, and five-layer models describe the same system at different resolutions.
- It does not cover firmware development, device certification, or application design.
Why the architecture is described in layers at all
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.
Layer 1: the device and the edge
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.
Layer 2: the network
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.
Which networks the device reaches
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.
Where the traffic goes
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.
What identifies the device
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.
Layer 3: management and control
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.
Layer 4: application and cloud
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.
Where security and control belong
The layer model makes the security answer more precise than the phrase "IoT security" allows. Four separate controls, four separate homes.
Identity belongs to the SIM
The SIM identifies the device before any session opens. That identity is what every policy above it references.
Private routing belongs to the network
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.
Enforcement belongs to the network and the cloud
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.
Evidence belongs above the traffic, not inside it
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.
Three places the layers break in practice
The failure patterns repeat across sectors.
- Security assigned to a layer that cannot hold it. A VPN client is specified for devices with 64KB of RAM, and the requirement quietly disappears during integration. Nobody records the decision.
- Vendor access cut through the whole estate. Eight hardware vendors need to reach their own units. Each gets a VPN into the network, so each has a path to all of it. Session-level access at the enforcement layer solves what network-level access created.
- Compliance evidence requested from the wrong layer. An auditor asks who accessed a device and when. The management platform shows the SIM was active. Those are different questions, and only the enforcement layer answers the one that was asked.
What this means for your architecture decisions
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.
Questions architects ask
Is there a fixed number of IoT architecture layers?
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.
Does a private APN mean the deployment is secure?
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.
Which layer should handle device authentication?
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.
Where does NIS2 land in this model?
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.
What changes when the fleet crosses borders?
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.
Next step
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.
