A technical guide for engineers, developers, and deployment managers who need to understand what happens between a device powering on and data reaching the cloud.
Most IoT connectivity guides focus on choosing the right SIM type, comparing radio technologies, or selecting a provider.
This guide goes deeper. It explains what actually happens when an IoT device powers on and attempts to connect, including the authentication sequence, the network attach procedure, how APNs route traffic, how IP addresses are assigned, how firmware behaviour affects reliability, and where the most common connectivity failures occur.
Understanding these mechanics is not academic. It is the difference between a deployment that works reliably at scale and one that generates constant support tickets. When a device authenticates successfully but cannot pass data, when battery life is half of what was expected, or when devices intermittently drop offline after firmware updates, the answers are in this technical layer.
This guide is written for engineers, developers, and technical decision-makers who design, deploy, or troubleshoot IoT systems. It assumes familiarity with cellular connectivity concepts but explains each mechanism from first principles.
How IoT SIM authentication works
Every IoT device begins its connectivity journey by proving its identity to the mobile network. This authentication process determines whether the device is permitted to access network services.
The authentication sequence
When the device powers on and detects a cellular network, the following sequence occurs.
The SIM (or eSIM) presents its IMSI (International Mobile Subscriber Identity) to the network. This is the device’s primary credential, a unique identifier tied to a specific carrier subscription. The network’s authentication centre (AuC) receives the IMSI and generates a cryptographic challenge using a random number (RAND). This challenge is sent to the SIM.
The SIM uses its Ki (authentication key), a 128-bit secret key stored securely on the SIM and never transmitted over the air, to compute a response (SRES) and a session key (Kc) using the network’s authentication algorithm.
In modern 4G and 5G networks, this process uses AKA (Authentication and Key Agreement), which provides mutual authentication. The device verifies the network identity as well, reducing the risk of rogue base station attacks. Older 2G and 3G networks used one-way authentication models.
The network compares the SIM response against its own expected value. If they match, the device is authenticated and permitted to proceed to the attach phase. If they do not match, the attach request is rejected.
Why this matters for IoT deployments
The Ki key is the most sensitive credential in the system and it never leaves the SIM. If a SIM profile is corrupted during provisioning, authentication fails and the device cannot connect. For eSIM deployments using remote provisioning, the integrity of the profile download process is critical.
For large fleets, authentication must work reliably for devices that frequently transition between sleep and connected states. Every time a device wakes from deep sleep and re-attaches, this authentication sequence runs again. Poorly designed wake cycles that trigger excessive re-authentication can cause network-side throttling.
An additional security layer used in enterprise IoT is SIM-to-IMEI locking, where the network verifies that the SIM IMSI is paired with the expected device IMEI (International Mobile Equipment Identity). This prevents a SIM from being extracted and used in an unauthorised device.
IoT device identifiers: ICCID, IMSI, IMEI, and MSISDN
IoT devices carry several unique identifiers, each serving a different function. Confusing them is one of the most common sources of provisioning errors and troubleshooting delays.
ICCID (Integrated Circuit Card Identifier) is the SIM serial number. It is used for provisioning and inventory management, not for network authentication. When you order SIMs from a provider, the ICCID is how individual SIMs are tracked and activated.
IMSI (International Mobile Subscriber Identity) is the subscriber identity stored on the SIM. It identifies the subscription to the mobile network and is used during authentication and attach. In multi-IMSI SIMs, multiple IMSIs are stored and the device presents the appropriate one depending on the network it is connecting to.
IMEI (International Mobile Equipment Identity) identifies the modem hardware, not the SIM. It is used for device tracking, blacklisting stolen equipment, and SIM-to-IMEI locking.
MSISDN is the device phone number. In IoT it is frequently unused, and many data-only SIMs do not have an MSISDN. It is only required for devices using SMS or needing to be reachable via a phone number.
When these identifiers are mismatched, for example when a SIM is moved to a different device without updating the IMEI lock, or when a multi-IMSI SIM presents the wrong IMSI, the device will fail to connect or will be rejected by security policies.
Maintaining a clean mapping of ICCID, IMSI, and IMEI across your fleet is essential for troubleshooting at scale.
The network attach procedure
Once authenticated, the device must complete the attach procedure before it can exchange data. This is a multi-step negotiation between the device and the network.
Radio technology selection
The modem scans available frequencies and selects a radio access technology, typically NB-IoT, LTE-M, 4G LTE, or 5G, based on signal strength, firmware configuration, and band-locking rules set by the deployment.
Many IoT devices are configured to prefer a specific technology. For example, a low-power sensor may prefer NB-IoT and only fall back if NB-IoT is unavailable.
Misconfigured band-locking is a common cause of connectivity failures. A device locked to NB-IoT bands in a location where the carrier only provides LTE-M will fail to attach even though service is technically available.
Attach request and acceptance
The device sends an attach request to the network’s mobility function. The network validates the subscription, checks restrictions, and returns an attach accept message that includes a temporary identity, network timer values for idle and connected states, and carrier-specific policies.
PDP context activation: the step that enables data
Authentication and attach do not automatically provide data connectivity.
The device must establish a PDP context (3G and 4G terminology) or PDN connection (4G and 5G terminology). This is where the APN comes into play. The device requests a data connection by specifying its configured APN. The network routes the request to the appropriate packet gateway. The gateway assigns an IP address and establishes the data path according to the APN configuration, such as public internet routing, private network routing, VPN tunnel, or enterprise firewall rules.
If the APN is misconfigured, wrong name, wrong authentication type, or the SIM is not provisioned for that APN, PDP context activation fails. The device appears authenticated and attached but cannot pass data.
This is the most common cause of the connected but no data symptom.
APNs explained: The backbone of IoT data routing
The Access Point Name (APN) determines how a device’s data reaches its destination.
An APN is a logical identifier that tells the carrier network which packet gateway to use, what IP addressing scheme to apply, what security policies to enforce, and where to route traffic.
What an APN consists of
An APN has two components, a network identifier and an operator identifier. In practice, most IoT deployments use a single APN string provided by the connectivity provider.
Public APNs
A public APN routes traffic to the open internet through the carrier’s standard gateway.
Public APNs are simple to configure and broadly compatible, but they expose device traffic to the public internet, provide limited isolation, and offer limited control over routing and IP addressing. They are generally unsuitable for sensitive data.
Private APNs
A private APN creates an isolated data path between the device and an enterprise network. Traffic does not traverse the public internet. It is routed via VPN tunnel, MPLS, or direct peering.
Private APNs provide controlled IP addressing, traffic isolation, VPN support, firewall integration, and the ability to enforce access control policies at the network level. Private APNs are effectively mandatory for payments and EFTPOS, utilities and smart grid, security and surveillance, industrial control systems, healthcare, and any environment with data sovereignty or compliance requirements.
How APN configuration works in practice
The APN is configured in the modem, either in firmware, via AT commands during manufacturing, or through SIM platform configuration. When the device requests PDP context activation, it presents the APN. The carrier validates that the SIM is provisioned for that APN and routes the connection accordingly.
If the APN is wrong, the device attaches successfully but fails at the PDP context stage. The device appears connected at the radio level but has no working data path.
When troubleshooting data connectivity failures, verify the APN configuration first.
IP addressing for IoT devices
How a device is assigned an IP address has significant implications for security, reachability, and fleet management.
Private dynamic IP
The most common configuration. The device receives a private IP from a carrier NAT pool each time it connects. The device cannot be reached from the internet, which provides inherent security. Suitable for devices that only push data outbound.
Public dynamic IP
The device receives a public IP that can change each time it reconnects. This increases exposure and is rarely appropriate for IoT unless strict firewalling is in place.
Public static IP
The device receives a fixed public IP. This is required for inbound access, such as remote management or certain camera and controller use cases. It must be combined with strict firewall policies and is often better implemented through a private APN.
VPN-terminated addressing
The device connects through a private APN and the carrier gateway terminates an IPSec VPN tunnel into the enterprise network. The device receives an address from the enterprise address space and remains isolated from the public internet. This is the most secure model for sensitive deployments.
IPv6 considerations
5G networks natively support IPv6. IPv6 simplifies addressing for large fleets by removing IPv4 exhaustion constraints. As 5G IoT deployments scale, IPv6 adoption will accelerate. Ensure devices, management platforms, and cloud infrastructure support it.
Device behaviour: The hidden driver of IoT reliability
The network provides connectivity infrastructure, but device firmware determines how effectively that infrastructure is used.
Poor device behaviour is one of the most underestimated causes of IoT connectivity problems.
Attach and detach cycles
Every attach consumes signalling resources. Devices that repeatedly attach and detach due to aggressive wake cycles, poor signal, or firmware bugs generate excessive signalling traffic. Carriers monitor this and may throttle or temporarily bar devices that exceed thresholds.
Design firmware to use PSM or eDRX rather than frequent detach and reattach cycles.
PSM and eDRX
NB-IoT and LTE-M devices rely on PSM and eDRX to achieve multi-year battery life. PSM allows deep sleep while remaining registered. The device does not need to re-authenticate when it wakes. eDRX extends the interval at which the device listens for paging messages.
Incorrect timer configuration is the most common cause of worse-than-expected battery life. Values must match the reporting cadence and acceptable downlink latency. Test with the target carrier because timer negotiation varies by network.
Retry logic
Retry behaviour determines whether devices recover or enter destructive loops.
Constant interval retries generate excessive signalling, drain battery, and can trigger carrier barring.
Implement exponential backoff and define maximum intervals and attempt limits before extended sleep.
Firmware updates over the air
FOTA updates must be designed for cellular constraints. Use delta updates where possible, schedule updates during strong signal and available power, and prefer LTE-M over NB-IoT for larger payloads.
A common failure mode is an update that resets APN settings or band-locking, causing devices to go offline immediately after updating. Firmware update processes must preserve and re-apply network configuration.
Antenna design and selection
Antenna issues are one of the most common physical causes of IoT connectivity failure and one of the least discussed.
Poor antenna performance increases current draw during transmission, reduces throughput, increases attach failures, and creates intermittent connectivity that is difficult to diagnose.
Validate antenna performance in the actual deployment housing. Metal enclosures can attenuate signal significantly.
Security layers in IoT connectivity
Modern IoT security operates across five layers. A weakness in any layer can compromise the deployment.
SIM-level security
Cryptographic authentication via Ki and AKA. SIM-to-IMEI locking prevents extraction misuse. For eSIM, secure profile provisioning integrity is essential.
Network-level security
Licensed spectrum reduces interference and eavesdropping risk. Radio transport is encrypted. APN isolation separates IoT traffic from other network domains.
IP-level security
Private addressing reduces exposure. IPSec VPN tunnels protect data in transit. Firewalls enforce access control.
Application-level security
TLS protects payloads. IAM controls service access. Payload signing supports integrity.
Device-level security
Secure boot ensures only signed firmware runs. Encrypted storage protects credentials. Firmware signing prevents unauthorised code during updates.
A comprehensive architecture addresses all five layers. Network security alone is not sufficient.
Common IoT connectivity problems and how to diagnose them
These are the most frequent issues seen in real deployments.
Device authenticates but cannot pass data
Symptoms: The device shows registered or attached status, but no data flows and the cloud receives nothing.
Root cause: Almost always an APN issue. The device attached successfully but failed PDP context activation because the APN is wrong, the SIM is not provisioned for the APN, or authentication type does not match requirements.
Resolution: Verify the APN string exactly as specified, including case and spacing. Confirm the SIM is provisioned for that APN in the management platform. Reboot the modem after correction.
Device drains battery faster than expected
Symptoms: Battery life is far below design target.
Root cause: Weak signal forcing high transmit power, incorrect PSM or eDRX values keeping the device active too often, or aggressive retry loops after failures.
Resolution: Measure signal strength at the deployment location. Improve antenna performance or placement if required. Tune power mode configuration to match reporting needs. Implement exponential backoff retry logic.
Device connects intermittently
Symptoms: The device cycles online and offline with no obvious pattern.
Root cause: Often a radio technology mismatch or an antenna installation issue. The device may be configured to prefer NB-IoT where only LTE-M is available, or signal conditions may vary enough to break attach reliability.
Resolution: Confirm which technologies are available at the deployment location. Configure modem preferences appropriately. Validate antenna performance in the installed housing.
Roaming works internationally but not domestically
Symptoms: The device connects overseas but fails in the home market.
Root cause: Missing domestic roaming rules or an incorrect preferred network list. Some global SIMs support international roaming but lack domestic carrier agreements.
Resolution: Update the SIM profile to include domestic carrier access. Verify preferred network lists and provisioning for multi-carrier domestic use.
Devices go offline after a firmware update
Symptoms: Many devices lose connectivity after a FOTA rollout.
Root cause: Updates reset APN, band-locking, or network preference rules to defaults.
Resolution: Ensure updates explicitly re-apply modem configuration after reboot. Test updates on a subset of devices before rollout. Include post-update health checks for APN and network configuration.
Excessive data consumption
Symptoms: Fleet data usage is far above expected.
Root cause: Usually application-layer behaviour, chatty protocols, repeated handshakes, overly frequent heartbeats, poor retry logic, or TLS renegotiation.
Resolution: Use lightweight protocols such as MQTT or CoAP for small payloads. Implement TLS session resumption. Extend heartbeat intervals. Configure SIM-level usage alerts to detect anomalies early.
Designing a reliable IoT connectivity architecture
A reliable deployment requires deliberate decisions at each layer.
SIM and carrier selection
Choose the SIM type and carrier access model based on geography, uptime requirements, and long-term flexibility.
Radio technology selection
Match the radio technology to the application and configure band-locking to reduce unnecessary scanning.
APN and IP routing configuration
Define public vs private routing, VPN termination requirements, and IP addressing based on security and reachability needs.
Device firmware tuning
Tune PSM and eDRX to real reporting cadence, implement backoff retry logic, preserve configuration during updates, and validate antenna performance in deployment housing.
Security across all layers
Address SIM authentication, APN isolation, VPN transport, application TLS, and device secure boot and signing. Do not rely on a single security layer.
Monitoring and diagnostics
Use a SIM management platform that provides real-time visibility into status, usage, session history, and failure patterns. Implement alerts and diagnostic workflows for common failure modes.
Frequently asked questions
What happens if the APN is configured incorrectly?
The device will authenticate and attach successfully, but PDP context activation will fail. The device appears connected at the radio layer but cannot send or receive data. Correct the APN and reboot the modem.
What is the difference between IMSI and IMEI?
IMSI is the subscriber identity stored on the SIM and used for network authentication. IMEI identifies the modem hardware. They serve different functions, and SIM-to-IMEI locking uses both.
Why does my IoT device battery drain faster than expected?
Most commonly weak signal causing high transmit power, poorly tuned PSM or eDRX timers, or aggressive retry logic after failed connections. Measure signal strength and tune power modes and retry behaviour.
What is a private APN and when do I need one?
A private APN creates an isolated data path between devices and your enterprise network, bypassing the public internet. It is effectively mandatory for sensitive deployments and strongly recommended for enterprise fleets requiring traffic control.
What protocols should IoT devices use for data transmission?
For small payloads, MQTT or CoAP are typically better than HTTPS because they reduce overhead and suit NB-IoT and LTE-M constraints. HTTPS fits higher bandwidth use cases on 4G or 5G.
What is the difference between PSM and eDRX?
PSM allows deep sleep while remaining registered, so the device does not re-authenticate on wake. eDRX extends paging listen intervals. PSM minimises power during long idle periods, while eDRX manages downlink latency in an intermediate power state.
Conclusion
IoT connectivity is an engineering discipline, not a configuration checkbox. The difference between a deployment that works at scale and one that generates constant operational issues comes down to technical fundamentals: how SIM authentication establishes trust, how APNs route traffic, how firmware behaviour affects battery life and reliability, and how security must be addressed across every layer from SIM to cloud.
Organisations that invest in understanding these mechanics, or partner with specialists who do, build deployments that are more reliable, more secure, more cost-efficient, and significantly easier to troubleshoot when issues arise.
M2M Connectivity provides the technical infrastructure and specialist support IoT deployments require, including enterprise-grade SIM authentication, private APN configurations, multi-network failover, eSIM provisioning, advanced diagnostics, and a local Australian team with deep experience in IoT connectivity engineering.
Need help designing your IoT connectivity architecture?
Talk to an IoT expert →
