The fundamental difference is the connection model
With HTTPS, every message is a standalone request. The device opens a connection, sends a payload, gets a response, and disconnects. There's no session. Each request carries its own authentication (typically a bearer token in the Authorization header) and its own routing information (the URL path).
With MQTT, the device opens a connection once and keeps it alive. Authentication happens at connect time (token passed in MQTT credentials or as a query parameter over secure WebSockets), and the session stays authenticated for its lifetime. The device publishes messages to topics and subscribes to topics, all over the same persistent connection. There's no request-response cycle. It's publish-subscribe.
This sounds like a minor protocol difference. In practice, it changes how you think about three things: how devices send data, how the platform reaches devices, and how you handle per-device authorization.
Authentication works differently than you'd expect
In HTTPS, auth is per-request. Every message includes the device token as a bearer token in the header. Your API validates it on every call. If a token is revoked, the next request fails. Clean and immediate.
In MQTT, auth is per-connection. The device authenticates once when establishing the session. In practice, this means using a custom authorizer (in AWS IoT Core, this is a Lambda function) that validates the token at connect time and returns a policy document defining what the device can do. That policy stays in effect for the session's duration.
Revoking access is less immediate. If you invalidate a device's token, existing MQTT sessions that authenticated with that token before revocation stay alive until they disconnect. You need a mechanism to force-disconnect a specific device if immediate revocation matters. This is a design consideration that doesn't exist in pure HTTPS architectures.
Topic design is your routing layer
HTTPS routes by URL. MQTT routes by topic. In an IoT platform, the standard pattern is to give each device its own topic namespace: devices/{deviceUid}. The device publishes telemetry to its namespace and subscribes to it for incoming messages (config updates, firmware metadata, commands).
Authorization is topic-scoped. A device can only publish to devices/{its-own-uid} and subscribe to the same. This is enforced by the authorizer policy at connect time. A device that tries to publish to another device's topic gets rejected. This gives you per-device isolation without needing separate credentials or separate endpoints.
If you're used to REST resource design, think of topics as a parallel addressing system. The difference is that topics are bidirectional. The same namespace a device publishes to is the one the platform uses to reach that device. There's no separate "push notification" endpoint. The topic is the channel.
Where each protocol fits in practice
In a real platform, the split usually looks like this:
HTTPS handles registration and provisioning. Device registration happens before deployment, typically during manufacturing. It's a one-time call made with manufacturer credentials (not device credentials) that creates the device identity, assigns a type and firmware version, and returns a device token. This is a classic request-response flow. MQTT adds nothing here.
MQTT handles ongoing telemetry. Once a device is deployed and has its token, it connects via MQTT and starts publishing. Periodic status updates, sensor readings, GPS coordinates, diagnostic data. High frequency, low overhead, persistent connection. The platform receives messages through the ingestion layer and routes them to processing.
MQTT handles platform-to-device communication. This is where MQTT earns its place. Firmware update metadata, configuration changes (reporting frequency, sensor thresholds, active vs. passive mode), and diagnostic commands all flow from platform to device over the same MQTT connection. The device subscribes to its topic and receives updates as they're published. No polling. No delay.
HTTPS stays available as a fallback. Some devices, some networks, and some use cases work better with HTTPS. Devices behind corporate firewalls that block MQTT ports. Low-frequency devices where maintaining a persistent connection wastes resources. One-off API calls for firmware downloads. A well-designed ingestion layer accepts both and normalizes them into the same processing pipeline.
Things that will save you time
Payload format should be identical across both protocols. JSON with the same required metadata (event type, timestamp, device uid). Whether a message arrives over HTTPS or MQTT, your processing layer shouldn't care. If you end up with protocol-specific payload formats, your parser logic doubles and your test surface explodes.
Timestamp quality matters more than you think. MQTT's at-least-once delivery means duplicates happen. Messages can also arrive out of order, especially when a device reconnects after a network drop and flushes its local buffer. Your state store needs timestamp freshness rules: only overwrite device state if the incoming message's timestamp is newer than what's stored. Without this, you'll write stale data over fresh data and not know it.
Plan for versioned payloads from the start. Firmware updates change what devices send. A device running firmware v2.1 might include fields that v1.8 doesn't. Your processing pipeline needs to handle multiple payload versions simultaneously. This is true regardless of protocol, but it becomes more urgent with MQTT because firmware updates propagate faster (the platform pushes, devices update sooner) and you'll have a mixed-version fleet for shorter but more frequent windows.
Test with real network conditions. MQTT over a cellular connection with 300ms latency and periodic drops behaves very differently than MQTT on your local network. Connection keepalives, reconnect backoff, message buffering during network loss, and session resumption are all things that work perfectly in dev and break in the field. If your devices use cellular, test on cellular.
This article is based on a production IoT communication platform built for connected field devices including asset trackers, telematics units, and industrial monitoring equipment. The patterns described here have been tested across devices using cellular, Wi-Fi, and Ethernet connectivity.
