Enterprise IoT architects spend considerable time evaluating hardware and connectivity technology, and less time mapping the protocol stack that governs how devices, networks, and platforms communicate with each other. That imbalance tends to surface as integration problems after deployment: devices that can’t authenticate to the platform, data that arrives in formats the head-end cannot parse, firmware updates that fail because the OTA transport protocol was not validated against the device’s available memory, and security vulnerabilities that emerge from protocol mismatches between layers.
The IoT protocol stack is a layered set of standards, each governing a different aspect of how data moves from a physical sensor to an application. Choices at each layer constrain and allow choices at adjacent layers, and the interactions between those choices determine whether the full stack performs as a coherent system or as a collection of individually validated components that create friction at the interfaces.
This piece works through the IoT protocol stack from the physical connectivity layer up through the application layer, covering the standards relevant to enterprise deployments, the trade-offs at each layer, and the integration considerations that determine whether the stack holds together at scale.
Physical and Access Layer: Cellular Standards
The physical and access layer governs how a device establishes a radio connection to a network. For enterprise IoT, the relevant cellular standards and their positioning relative to each other are worth establishing, because marketing language around these technologies can be imprecise in ways that affect deployment decisions.
NB-IoT (Narrowband IoT, 3GPP Release 13 and later) operates in a 180kHz channel within licensed spectrum, either in-band within an LTE carrier, in the LTE guard band, or in standalone deployment on refarmed GSM spectrum. Key physical layer characteristics:
- Maximum downlink throughput: approximately 250kbps in single-tone operation
- Maximum uplink throughput: approximately 250kbps
- Link budget: 164dBm maximum coupling loss, approximately 20dB improvement over GPRS
- Latency: 1.6 to 10 seconds for a typical data transmission including setup, making it unsuitable for applications requiring sub-second response
- Duplex mode: half-duplex only
LTE-M (LTE-MTC, Cat-M1, 3GPP Release 13) operates in a 1.4MHz channel within LTE spectrum with full-duplex support. Key physical layer characteristics:
- Maximum downlink throughput: approximately 1Mbps
- Maximum uplink throughput: approximately 1Mbps
- Link budget: 155.7dBm maximum coupling loss, approximately 15dB improvement over GPRS
- Latency: 10 to 15ms for data transmission after connection establishment
- Duplex mode: full-duplex supported, enabling voice and bidirectional real-time data
5G NR for IoT introduces two relevant device categories: RedCap (Reduced Capability, 3GPP Release 17), targeting mid-tier IoT devices requiring higher throughput than LTE-M but lower power than full 5G NR UE, and standard 5G NR for high-bandwidth IoT applications. RedCap targets 5 to 25Mbps throughput with power and complexity reductions relative to full 5G NR, filling the gap between LTE-M and full 5G that has historically been occupied by 4G Cat-4 devices.
The physical layer choice sets the ceiling and floor for every layer above it. A protocol stack designed for sub-second bidirectional communication built on NB-IoT will fail at the physical layer before the application protocol has a chance to perform.
Network Layer: IP Addressing and Routing for IoT
Most enterprise IoT devices communicate over IPv4 or IPv6, but the network layer configuration governing how those addresses are assigned and managed carries operational implications that physical layer specifications do not surface.
Private APN architecture is the standard network layer configuration for enterprise IoT deployments with data security or regulatory requirements. Rather than routing device traffic over the carrier’s shared public APN onto the public internet, a private APN creates a dedicated network path from the device to the enterprise’s backend infrastructure. Traffic on a private APN does not traverse the public internet, which matters for:
- Regulatory compliance in verticals where data must not leave the enterprise network perimeter
- Reduced attack surface, since devices are not directly reachable from the public internet
- Deterministic routing, since private APN traffic follows defined network paths rather than public internet routing
IPv6 for IoT is relevant as IPv4 address exhaustion makes large-scale IoT deployments difficult to address individually. A deployment of one million smart meters, each requiring a routable IP address for head-end-initiated communication, runs into practical IPv4 allocation constraints that IPv6 eliminates. IPv6 also simplifies end-to-end addressability in architectures where devices need to be individually reachable without NAT traversal.
CGNAT considerations affect deployments where carrier-grade NAT sits between the device and the enterprise backend, which is the default configuration for most consumer and standard IoT rate plans. CGNAT prevents inbound connections to devices, which means any architecture requiring head-end-initiated communication to individual devices requires either a private APN, an always-on device-initiated connection, or a device that maintains a persistent session with the backend platform. Architects who do not account for CGNAT during design discover it during integration testing, at which point the remediation options are more expensive.
Transport Layer: Protocol Selection for IoT Data Delivery
The transport layer governs how data is packaged and delivered reliably (or intentionally unreliably) between the device and the platform. The dominant transport protocols in enterprise IoT each make different trade-offs that suit different application profiles.
MQTT (Message Queuing Telemetry Transport) is the most widely deployed IoT transport protocol for cellular-connected devices. Its publish-subscribe architecture, lightweight overhead (minimum 2-byte fixed header), and support for three QoS levels make it well-suited to constrained devices transmitting frequent small payloads over potentially unreliable connections:
- QoS 0 (at most once): fire and forget, no acknowledgment, lowest overhead
- QoS 1 (at least once): guaranteed delivery with acknowledgment, possible duplicates
- QoS 2 (exactly once): guaranteed single delivery, highest overhead
MQTT’s persistent session capability allows devices to reconnect after a connectivity gap and receive messages queued by the broker during the offline period, which is important for NB-IoT devices in PSM that are periodically unreachable.
CoAP (Constrained Application Protocol) is designed for the most resource-constrained devices where MQTT’s TCP requirement creates unacceptable overhead. CoAP runs over UDP, uses a request-response model similar to HTTP but with a binary header optimized for constrained environments, and supports observe functionality for publish-subscribe-like behavior. It is the right transport choice for NB-IoT devices where TCP connection management overhead would significantly affect power budget.
AMQP (Advanced Message Queuing Protocol) is relevant at the backend integration layer rather than the device-to-cloud layer. Its richer message routing, transaction support, and enterprise message broker compatibility make it the standard transport for connecting IoT platforms to enterprise backend systems: ERP, asset management, and operational technology platforms that expect AMQP-compatible message brokers.
HTTPS/REST remains relevant for IoT devices with sufficient compute resources and where the simplicity of REST API integration outweighs the overhead of HTTP. Higher-end IoT gateways, edge compute nodes, and devices with 4G or 5G connectivity commonly use REST for platform integration, particularly in deployments where the operations team managing the backend integration is more familiar with web API patterns than with MQTT broker configuration.
Security Layer: Authentication and Encryption Standards
Security protocol selection in IoT is complicated by the compute and memory constraints of edge devices, which make the security protocols standard in enterprise IT environments impractical or impossible to implement on constrained hardware.
TLS 1.2 and TLS 1.3 are the standard encryption protocols for IoT devices with sufficient compute resources. TLS 1.3 reduces handshake latency relative to TLS 1.2 by eliminating one round-trip from the handshake sequence, which matters for NB-IoT and LTE-M devices where each radio transmission has a measurable power cost. The cipher suite selection within TLS matters for IoT: ECDHE key exchange and AES-128-GCM are the recommended combination for IoT deployments balancing security strength with compute efficiency.
DTLS (Datagram TLS) is the appropriate security protocol for CoAP deployments, providing equivalent security guarantees to TLS for UDP-based transport.
X.509 certificate-based mutual authentication is the recommended device authentication mechanism for enterprise IoT deployments at scale. Pre-shared keys are simpler to implement but create key management problems at large device populations: rotating a compromised pre-shared key across millions of deployed devices is operationally intensive. X.509 certificates with individual device identities allow per-device certificate rotation and revocation without affecting other devices in the fleet.
Hardware Security Modules (HSM) and Trusted Execution Environments (TEE) are increasingly relevant for enterprise IoT devices handling sensitive data or operating in environments where physical device access by unauthorized parties is a risk. Storing private keys in a hardware-protected element rather than in firmware memory prevents key extraction even if the device firmware is compromised.
The security protocol stack needs to be validated end-to-end before deployment. A device that implements TLS correctly but connects to a platform endpoint that does not enforce mutual authentication has half a security architecture. Security validation in IoT needs to cover the full handshake path from device to platform, including the network layer (private APN), the transport layer (TLS configuration), and the application layer (authentication token handling and session management).
Data Formats and Device Management Protocols
The application layer is where protocol decisions have the most direct impact on platform integration complexity.
LwM2M (Lightweight M2M, OMA SpecWorks) is the device management protocol designed for IoT, covering device registration, firmware OTA update delivery, remote configuration, and telemetry reporting in a single protocol framework. Its data model uses a standardized object and resource hierarchy that allows device management platforms to interact with any LwM2M-compliant device without device-specific integration work. For enterprise deployments managing large, heterogeneous device populations, LwM2M’s standardized management model significantly reduces the integration overhead of adding new device types to the fleet.
FOTA (Firmware Over The Air) protocol considerations at the application layer are often underspecified during deployment design. Firmware update packages for IoT devices can range from tens of kilobytes to several megabytes. The FOTA protocol needs to account for:
- Interrupted transfer recovery, since an NB-IoT or LTE-M device may lose connectivity partway through a firmware download
- Delta update support, where only changed firmware segments are transmitted rather than the full image, reducing transmission size and power cost
- Rollback capability if the new firmware fails validation on the device
Data serialization format choices at the application layer affect transmission efficiency and platform integration complexity. JSON is widely supported and human-readable but carries significant overhead relative to binary formats for constrained devices. CBOR (Concise Binary Object Representation) provides JSON-equivalent expressiveness in a binary encoding that typically reduces payload size by 50 to 70 percent. For NB-IoT devices transmitting at high frequency or on tight power budgets, the payload reduction from CBOR versus JSON translates directly to longer battery life and lower data costs.
Protocol Stack Coherence at Enterprise Scale
The protocol stack decisions described above don’t operate independently. A deployment that selects NB-IoT at the physical layer, MQTT over TCP at the transport layer, and TLS 1.2 with full handshake at the security layer has created a stack where the transport and security layer overhead may dominate the device’s power budget in a way that undermines the power efficiency rationale for choosing NB-IoT in the first place. CoAP over UDP with DTLS would be the coherent stack for a power-constrained NB-IoT device, while MQTT over TCP with TLS is the appropriate stack for an LTE-M device with a more generous power budget.
Protocol stack coherence also matters for connectivity infrastructure. A deployment where devices connect over a private APN with static IP addressing, communicate via MQTT to a cloud broker, and use X.509 mutual authentication has specific requirements for the connectivity management platform: private APN provisioning, static IP assignment, and certificate lifecycle management that integrates with the device identity infrastructure.
KORE’s connectivity infrastructure provides the network layer foundation that enterprise protocol stacks depend on, including private APN configuration, static IP provisioning, and multi-carrier connectivity across 40+ carrier partnerships and 200+ countries. The ConnectivityPro platform provides the SIM lifecycle management and network policy controls that govern the connectivity layer underneath whatever application protocol stack the deployment runs. With 21M+ active SIMs deployed across verticals where protocol stack coherence directly affects operational outcomes, the infrastructure is built to support the full range of enterprise IoT connectivity configurations that production deployments require.
Getting the protocol stack right requires evaluating each layer in the context of the layers adjacent to it, and validating the full stack end-to-end before deployment commits to hardware at scale. The integration problems that emerge from protocol mismatches are solvable, but they are less expensive to solve on a bench than in the field.
Talk to a KORE connectivity engineer about the network layer infrastructure requirements for your IoT protocol stack.
Published May 29, 2026.