A temperature sensor in a factory sends a reading every 30 seconds. It runs on a microcontroller with 256KB of RAM and a 2G cellular connection. It can’t maintain a persistent HTTP connection. It can’t handle TLS handshakes with 10KB certificates. IoT devices require a protocol built for constrained environments. MQTT is that protocol, and device registration is the first problem you solve before any data flows.

MQTT Basics#

MQTT is a publish/subscribe protocol over TCP, designed for low-bandwidth, high-latency, unreliable networks. A broker sits between publishers and subscribers. Devices publish to topics: factory/line-3/sensor/temp. Backend services subscribe to topics. The broker routes messages.

The protocol overhead is tiny: a PUBLISH packet has a 2-byte fixed header plus topic and payload. Compare to HTTP where headers alone are often 500+ bytes. For a device sending 50-byte temperature readings every 30 seconds over a 2G connection (50kbps), this matters.

MQTT has three QoS levels: 0 (fire and forget), 1 (at least once, requires ACK), 2 (exactly once, four-packet handshake). Most IoT deployments use QoS 1: reliability without the overhead of exactly-once delivery.

graph TD A[IoT sensor: temperature reading] --> B[MQTT PUBLISH: factory/line3/temp, payload=23.4C] B --> C[MQTT Broker: route by topic] C --> D[Backend subscriber: data ingestion service] C --> E[Backend subscriber: alert service] D --> F[Write to time-series database] E --> G[Check threshold: alert if over 80C] style A fill:#000000,stroke:#00ff00,stroke-width:2px,color:#fff style B fill:#000000,stroke:#00ff00,stroke-width:2px,color:#fff style C fill:#000000,stroke:#00ff00,stroke-width:2px,color:#fff style D fill:#000000,stroke:#00ff00,stroke-width:2px,color:#fff style E fill:#000000,stroke:#00ff00,stroke-width:2px,color:#fff style F fill:#000000,stroke:#00ff00,stroke-width:2px,color:#fff style G fill:#000000,stroke:#00ff00,stroke-width:2px,color:#fff

Device Registration#

Before a device can publish, it must be authenticated. Two approaches:

Certificate-based: each device has a unique X.509 certificate provisioned during manufacturing. The broker validates the certificate on connection. Revocation is handled via CRL or OCSP. Secure but certificate rotation on millions of devices is operationally complex.

Token-based: device authenticates with a shared secret or one-time provisioning code, receives a short-lived JWT, and reconnects with the JWT periodically. Simpler rotation but requires the device to handle token refresh.

Device identity maps to a thing record in a device registry: (device_id, firmware_version, last_seen, location, owner_account). This is the source of truth for device metadata. Registration writes to this registry; the broker validates against it on connection.

Broker Scaling#

A single MQTT broker handles 100,000 concurrent connections. At 10 million devices, you need 100+ broker instances. Devices must reconnect to the same broker instance for session persistence (QoS 1 requires the broker to store undelivered messages). Use consistent hashing to route device_id to broker instance.

At Oracle#

Oracle IoT Cloud Service was an MQTT broker platform for enterprise IoT. The device registration challenge was brownfield: customers had existing devices without pre-provisioned certificates. We implemented a bootstrap provisioning flow: device connects with a factory-default credential, receives a device-specific credential, disconnects, and reconnects with the new credential. The two-step flow allowed secure provisioning without per-device manufacturing customization. Used for 2+ million device registrations.

What I’m Learning#

MQTT solves the protocol constraints of IoT devices, but device registration at scale is the first operational challenge. The authentication model you choose at registration time is hard to change later — certificate-based is more secure but operationally heavier; token-based is easier to manage but adds token refresh complexity to the device firmware.

Have you managed device registration at scale, and what was the hardest part to get right operationally?