NeuralWired

MQTT vs HTTP: The 2026 Enterprise IoT Protocol Guide

MQTT vs HTTP vs CoAP: The 2026 IoT Protocol Decision
Enterprise IoT / Protocol Architecture

MQTT vs HTTP vs CoAP: The 2026 IoT Protocol Decision

Two deadlines, one aging protocol, and a decision most teams thought they’d already made.

Somewhere on a factory floor or a shipping container right now, a sensor is waking up, trying to phone home over a 2G connection that’s about to be switched off for good. If it’s still using HTTP to do that, it’s about to have a very bad year. MQTT vs HTTP has been debated in IoT circles since before most current architects graduated. What’s new in 2026 is that the debate has a deadline attached to it, and ignoring it now carries real financial and legal consequences.

Two things converged this year to force the issue. Carriers are shutting down the 2G and 3G networks that millions of legacy IoT devices still poll over HTTP. And the European Union’s Cyber Resilience Act starts requiring incident reporting in September, two months from now, which means how you architect device connectivity is suddenly a compliance question, not just a performance one. This piece is for the people who have to make that call this quarter, not the ones debating it as theory.

Why this is a 2026 problem, not a 2019 one

Forty six carriers had fully shut down their 2G networks by late 2025, and 80 had killed 3G entirely, according to Ericsson’s mobility tracking. Dozens more are retiring service through this year. That’s not a distant planning exercise. It’s a fleet of devices going dark unless someone replaces the radio hardware, and if they’re replacing the hardware anyway, they’re facing a second decision at the same time: do they keep the old HTTP polling architecture, or rebuild around a persistent-connection protocol like MQTT while they’re in there?

Layer the EU Cyber Resilience Act on top of that. It entered into force in December 2024, but the part that matters for the next 90 days is Article 14: starting September 11, 2026, manufacturers must report actively exploited vulnerabilities within 24 hours and a fuller notification within 72 hours. Full compliance follows in December 2027, with penalties reaching 15 million euros or 2.5% of global turnover, whichever is higher. If your device fleet talks over an unauthenticated MQTT broker (and as you’ll see below, a lot of them do), that’s now a regulatory exposure, not just an engineering embarrassment.

Meanwhile the underlying market is maturing, not exploding. Global cellular IoT connections reached 4.7 billion in 2025, up 13.3% year over year, the slowest growth rate since 2020, according to IoT Analytics’ Spring 2026 update. NB-IoT was the single leading cellular IoT technology by shipment volume that year, ahead of general 4G. That’s precisely the low-bandwidth, high-latency, intermittent-connection category MQTT was built for in the first place.

What MQTT, HTTP, and CoAP actually do differently

The three protocols aren’t competing versions of the same idea. They solve different problems, and the confusion in most comparison articles comes from treating them as interchangeable.

MQTT was designed in 1998 and 1999 by Andy Stanford-Clark, then at IBM, and Arlen Nipper, then at Eurotech, to monitor oil pipeline telemetry over satellite links that were slow, expensive, and unreliable. It’s a persistent, bidirectional publish-subscribe protocol brokered through a central server, standardized today as ISO/IEC 20922 and maintained through OASIS. A device opens one connection and keeps it open, publishing small messages to topics that any number of subscribers can receive.

HTTP predates MQTT by years and was built for pulling documents off the web, not for telemetry. It’s stateless and strictly client-initiated: request, response, connection closed. Every new data point means a new handshake, and for HTTPS, a new TLS negotiation on top of that.

CoAP, defined in IETF RFC 7252 in 2014, is the protocol most comparison pieces skip past, and it’s the one that matters most for the smallest devices. It’s a RESTful sibling to HTTP that runs over UDP instead of TCP, built for microcontrollers so constrained that they can’t run a full MQTT or HTTP/TCP stack at all.

Here’s the same decision compressed into a single table, which happens to be exactly the format that AI answer engines and Google’s featured snippets tend to lift directly:

FactorMQTTHTTPCoAP
TransportTCP, persistent connectionTCP, new connection per requestUDP, connectionless
ModelPublish/subscribe via brokerClient-initiated request/responseRESTful request/response
Best forFrequent telemetry, fleet coordinationInfrequent transfers, firmware downloadsSub-64KB RAM microcontrollers
Server-to-device pushNativeRequires polling or a second channelPossible via observe pattern
Cloud supportNative in AWS IoT Core, Azure IoT HubUniversalRequires a gateway (Californium, libcoap)

The three-question decision tree architects actually use

Forget the abstract “which protocol is better” framing. In practice, the choice comes down to three variables, and most teams can answer this in an afternoon.

  1. How often does the device talk? Below roughly once a minute, HTTP is genuinely viable and simpler to operate. Above roughly ten times a minute, MQTT’s persistent-connection overhead advantage compounds fast.
  2. Does the backend ever need to push a command to the device? If yes, HTTP forces you into polling or a second channel to fake it. MQTT handles this natively through its publish-subscribe model.
  3. What’s the RAM and power budget? Devices under roughly 64KB of RAM may not be able to run an MQTT/TCP stack at all. That’s where CoAP over UDP becomes the only realistic option, not just the theoretically cleaner one.
The pattern most production architectures land on Most resilient 2026 deployments aren’t single-protocol. Sensors at the extreme edge speak CoAP because that’s all their hardware can run. An edge gateway bridges to MQTT for fleet-wide coordination. MQTT-to-HTTP translation happens at the cloud API boundary where developer tooling expects REST. Designing for this three-tier pattern from day one avoids a rebuild later.

The security claim that isn’t quite true

MQTT is routinely marketed as more secure than HTTP because the device initiates the connection, so there’s no open inbound port to attack. That’s true as far as it goes, and it’s also misleading, because MQTT ships with no mandatory encryption and no mandatory authentication by default. Both have to be configured deliberately: TLS, client certificates, topic-level access control lists. None of it is automatic.

A large-scale internet scan cited in a 2026 academic security analysis found roughly 425,000 publicly reachable MQTT backends. Of those, 59% allowed direct client connections with no authentication at all, and 99.84% used unencrypted transport. A separate scan by OT security vendor TXOne Networks independently identified more than 47,000 exposed brokers reachable through authentication-free ports. The protocol can absolutely be secured. In practice, at scale, it very often isn’t.

That gap is exactly what turns from an engineering embarrassment into regulatory exposure under the EU CRA’s September reporting deadline. NeuralWired has covered the compliance side of this directly in our EU Cyber Resilience Act deadline explainer, and the broader enforcement pattern regulators are now applying to connected devices in our coverage of CISA’s IoT security directive. Worth reading both before your next architecture review, not after.

Where the “MQTT always wins” narrative breaks down

Most vendor content treats MQTT as the settled answer and HTTP as the legacy loser. The more useful framing, made directly in engineering commentary from the FlowFuse team, is that the MQTT versus CoAP debate specifically is mostly noise, because the two protocols solve incompatible constraint sets rather than competing on the same axis. MQTT requires infrastructure you can reach and a connection you can sustain. CoAP exists because some devices physically cannot afford that: a microcontroller with 16KB of RAM cannot run an MQTT/TCP stack, full stop.

Our read: picking MQTT for a genuinely constrained device isn’t a stylistic mistake, it’s an operational one. Batteries that should last years drain in months, and the fix isn’t a firmware patch, it’s a protocol swap you should have made at design time.

One more thing worth flagging honestly: market-size figures for the MQTT broker software market vary by 30 to 60% depending on which research firm you ask, ranging from roughly 1.14 billion to 1.8 billion dollars for the same period, with growth projections reaching anywhere from 6.3 billion to 9.7 billion dollars by the early 2030s. None of the published summaries disclose their sample size or methodology. Treat any single “the MQTT market is worth X billion” claim as a directional estimate, not an audited fact, and be skeptical of anyone citing one number as if it settles anything.

What the people who built these protocols say

Andy Stanford-Clark, MQTT’s co-inventor, now an IBM Distinguished Engineer and CTO for IBM UK and Ireland, has described the protocol’s design intent consistently across interviews over the years: keep messages small and infrequent enough that the connection survives a bad link, then trust the broker to deliver. He’s used the same analogy repeatedly, comparing it to handing a small parcel to a postal service and trusting it to get there rather than demanding a receipt for every step of the journey.

The design goal was never “fastest possible protocol.” It was “the protocol that still works when the connection barely works at all.” Paraphrased from Andy Stanford-Clark’s recurring framing of MQTT’s design intent, IBM Distinguished Engineer and MQTT co-inventor, in interviews via the Inductive Automation podcast and IBM Developer podcast
Dominik Obermaier, CTO and co-founder of HiveMQ and a member of the OASIS Technical Committee that maintains the MQTT 3.1.1 and MQTT 5 standards, is one of the few people with the standing to say authoritatively what MQTT 5 actually changed, as opposed to what vendor marketing claims it changed. His committee seat covers the metadata handling, session state management, and error reporting improvements that separate the real MQTT 5 feature set from looser “MQTT 5 support” claims made by tools that aren’t standards-affiliated.

The strongest skeptical voice in this space isn’t arguing MQTT is the wrong protocol. It’s the academic security researchers behind the 425,000-broker scan referenced above, whose framing is that MQTT’s security model is opt-in and implementation-dependent, not protocol-guaranteed. That’s a deployment failure happening at production scale, not a flaw in the spec.

A cautionary precedent worth remembering

Google Cloud IoT Core shut down. So did Cisco Kinetic and SAP Leonardo, as the broader agnostic IoT platform market consolidated hard around a handful of cloud hyperscalers, which now control roughly 60% of that market according to IoT Analytics, up from 39% in 2020. Teams that built deep dependencies on any one platform’s proprietary conventions faced expensive rebuilds when those platforms disappeared. It’s a reasonable argument for leaning on open standards like MQTT and CoAP rather than platform-specific alternatives, precisely because the standard outlives the vendor.

For a sense of how far MQTT’s reach extends beyond industrial telemetry: Facebook Messenger adopted it for its low battery impact at consumer scale, a widely cited example of a protocol built for oil pipelines in 1999 turning out to be anything but narrow.

Frequently asked questions

Is MQTT better than HTTP for IoT?

For most IoT scenarios involving frequent telemetry, unreliable networks, or battery-powered devices, MQTT is generally the better fit due to its lightweight header, persistent bidirectional connection, and built-in delivery guarantees. HTTP remains preferable for infrequent, large, or one-off transfers like firmware downloads.

What is the difference between MQTT and CoAP?

MQTT runs over TCP using a broker-based publish-subscribe model, ideal for coordinating large device fleets with delivery guarantees. CoAP runs over UDP in a RESTful request-response style, designed for ultra-constrained microcontrollers where even a TCP stack is too resource-heavy to run.

Why is MQTT used in IoT?

MQTT was designed in 1998 and 1999 specifically for unreliable, low-bandwidth telemetry links, originally oil pipeline monitoring. That gives it minimal packet overhead, persistent connections that reduce reconnect costs, and delivery guarantees that survive intermittent network drops, properties that map directly onto modern battery-powered IoT constraints.

Is MQTT secure?

MQTT supports TLS encryption, client certificates, and topic-level access control lists, but none of it is enabled by default. A large-scale scan found roughly 425,000 public MQTT backends, with 59% allowing unauthenticated connections and over 99% using unencrypted transport, meaning real-world MQTT security depends entirely on deployment discipline, not the protocol itself.

What replaces 2G for IoT devices?

Carriers are steering legacy 2G and 3G IoT devices toward NB-IoT and LTE-M, the two 3GPP-standardized Low Power Wide Area technologies built for long battery life and wide coverage, with 5G RedCap emerging as a mid-tier option for devices needing more bandwidth than NB-IoT but less power draw than full 5G.

What to watch next

The protocol argument was never really about which one is objectively “best.” It’s about matching the protocol to the constraint in front of you, and in 2026, two of those constraints (the carrier sunset and the CRA deadline) come with a calendar attached instead of just an engineering preference.

Three things to watch over the next 6 to 18 months:

  • Whether more hyperscalers add native CoAP support to close the gateway gap, or whether the market settles on CoAP-to-MQTT bridging as the permanent pattern.
  • How the first wave of CRA enforcement actions in late 2026 treats unauthenticated MQTT deployments specifically, since that’s the most concrete, most measurable gap regulators can point to.
  • Whether 5G RedCap adoption accelerates fast enough to give architects a genuine mid-tier option, rather than forcing a binary choice between NB-IoT’s tight constraints and full 5G’s cost.
If you’re making this call for your own fleet this quarter, the honest answer is rarely “rip and replace with MQTT everywhere.” It’s usually a tiered architecture, chosen deliberately, with the security configuration treated as a requirement from day one rather than an afterthought before an audit.

Want the next deadline before it becomes urgent? Subscribe to The Neural Loop at neuralwired.com/newsletter.

Written by

Team_Neuralwired

in

More posts