Out of the box, MQTT sends your plant's telemetry - and its credentials - across the network in plaintext, with authentication optional; security researchers routinely find tens of thousands of wide-open brokers on the public internet. Yet MQTT has become the connective tissue of industrial IoT - the lightweight publish-subscribe protocol carrying telemetry from gateways, RTUs, and sensors into SCADA platforms and historians everywhere, a position it earned by being simple, efficient, and tolerant of bad networks. This guide covers the full hardening stack for industrial MQTT - TLS on 8883, per-device credentials, topic ACLs, broker hardening, signed payload envelopes with replay protection, and what Sparkplug B does and does not solve - so your telemetry backbone is not your weakest link.
Part of our SCADA security guide library - 60+ articles on securing industrial operations.
MQTT was designed in 1999 to move oil pipeline telemetry over expensive, unreliable satellite links, and its virtues are exactly what industrial IoT needs: a tiny wire footprint, publish-subscribe decoupling so producers and consumers never need to know each other, quality-of-service levels for delivery assurance, and graceful handling of flaky connections. That is why it is one of the seven protocol families Merobix ships drivers for, alongside Modbus, OPC-UA, DNP3, BACnet/IP, EtherNet/IP, and HTTP.
But the OASIS MQTT 5.0 specification deliberately left security to the implementer. The protocol defines a username and password field in the CONNECT packet - and does not require anyone to use it. It mandates no encryption. Topic authorization does not exist in the spec at all; it is a broker feature. The result is predictable: internet scans regularly turn up enormous numbers of brokers accepting anonymous connections, some cheerfully publishing industrial process data to anyone who subscribes to the wildcard topic. MQTT security is therefore not one setting - it is a stack you assemble deliberately, layer by layer.
Think of industrial MQTT hardening as four layers, each defeating a different attacker. The table below is the map for the rest of this guide:
| Layer | Control | Defeats | Without It |
|---|---|---|---|
| 1. Transport | TLS 1.2+ on port 8883, certificate validation, plaintext 1883 disabled | Eavesdropping and man-in-the-middle on the network path | Readings, topics, and credentials cross the wire readable by anyone on the path |
| 2. Identity | Per-device credentials or client certificates; no anonymous access; no shared fleet secrets | Unauthorized connections; one leaked credential compromising the fleet | Anyone who finds the broker can connect; one leak exposes every site |
| 3. Authorization | Topic ACLs - least-privilege publish and subscribe patterns per client | Compromised or misbehaving clients reading fleet-wide data or injecting into other sites' topics | Every authenticated client can read and write everything |
| 4. Payload integrity | Signed envelopes: per-device signing keys, sequence numbers, timestamps, digests, replay detection | Forgery, tampering, and replay - even via a compromised broker or stolen broker credential | The platform must blindly trust whatever the broker delivers |
Every production MQTT listener should be TLS on port 8883, with the plaintext 1883 listener disabled entirely - not left running "for testing." TLS 1.2 is the floor; prefer TLS 1.3 (RFC 8446) where your stack supports it. Two failure modes deserve special attention because they are epidemic in field deployments:
For gateways on cellular or other untrusted networks, TLS is non-negotiable - the radio link's own encryption terminates inside the carrier and protects nothing end-to-end, a point we cover in depth in our guide to cellular SCADA gateway security. Merobix uses TLS across its cloud, MQTT, and industrial connections as standard behavior.
Anonymous access should be disabled on any industrial broker - that much is obvious. The subtler rule is one credential per device. Field deployments drift toward a single "gateway" username shared across the fleet because it is easy to provision; the price is that one leaked credential - from a decommissioned device, a contractor's laptop, a config file in a repo - silently compromises every site, and revoking it means touching the whole fleet at once.
Per-device identity inverts that: each gateway or sensor registers with its own credentials, a compromise is contained to one device, and revocation is surgical. This is how Merobix provisions devices - every gateway is registered individually with unique credentials, and each carries its own device-generated signing identity on top (more on that in layer 4). Client certificates (mutual TLS) are the strongest broker-level identity where your devices and broker support them; username-password over TLS is acceptable when certificate management is impractical, provided the credentials are unique, strong, and rotatable. Either way, the lifecycle matters as much as the mechanism - device credentials need the same offboarding discipline as user accounts, a theme our credential security guide expands on.
Authentication without authorization is half a control. On a broker without ACLs, any authenticated client can publish to any topic and subscribe to everything - one wildcard subscription vacuums up your entire operation's data stream, and one compromised device can publish forged readings into any other site's topics or inject into command topics. Topic ACLs close this by granting each client the narrowest publish and subscribe patterns it needs:
ACLs are also your noisy-neighbor and blast-radius control: they turn "a device was compromised" from a fleet-wide data breach into a single-site incident. If your broker cannot express per-client topic ACLs, that is a broker selection criterion, not a footnote.
Here is the gap most MQTT deployments never close: TLS protects the hop, not the message. Encryption runs from one client to the broker, and from the broker to each subscriber - but inside the broker, and everywhere downstream, the payload is plaintext with no provenance. The receiving platform cannot prove which device produced a reading, that nothing altered it after the broker, or that it is not a replayed copy of yesterday's healthy value played back to mask today's problem. A stolen broker credential is sufficient to publish convincing forgeries.
Payload signing closes the gap by making integrity travel with the message. In the Merobix pipeline, each device holds its own Ed25519 (RFC 8032) signing identity and wraps telemetry in a signed envelope carrying sequence numbers, timestamps, sample IDs, and payload digests. The platform verifies the signature against the device's registered identity and runs replay detection on sequence and time - so a forged message fails verification, a tampered message fails its digest, and a replayed message fails sequence checks, even if the broker or a broker credential is compromised. Accepted telemetry is persisted durably before historian processing, and each sample keeps its identity - sample ID, timestamp, quality, device, site, tenant - end to end. Merobix is also extending mandatory signed telemetry across all ingestion paths, including migrating legacy gateway paths to signing, as part of its current engineering roadmap. The full argument for why unsigned telemetry is a business risk - not just a technical one - is in our deep dive on telemetry integrity in cloud SCADA.
Sparkplug B comes up in every industrial MQTT conversation, so let's place it precisely. Sparkplug is an interoperability specification on top of MQTT: it standardizes the topic namespace, a compact payload encoding, and - its best idea - session state management through birth and death certificates, so subscribers always know whether a device is online and what its metrics mean. If you are wiring multi-vendor equipment into a common namespace, it is genuinely useful.
What Sparkplug is not is a security layer. It specifies no encryption, no authentication scheme, and no payload integrity - it inherits whatever the underlying MQTT deployment provides. A Sparkplug system still needs all four layers above. Its contribution to security is indirect but real: a predictable topic structure makes tight ACLs much easier to write, and the birth/death state model gives you fast, reliable detection of devices that drop offline. Treat it as a data architecture decision that slightly eases security work - never as a checkbox that substitutes for it.
The broker is the choke point of the whole architecture, so operate it like the critical infrastructure it is - with the same defense-in-depth posture the NIST SP 800-82 Rev. 3 guide to OT security recommends for any OT choke point:
Key takeaway: MQTT earns its place in industrial IoT, but it is secure only as a deliberately assembled stack: TLS 1.2+ on 8883 with real certificate validation, one unique credential per device, deny-by-default topic ACLs, a hardened broker that never faces the internet - and signed payload envelopes with replay protection, because TLS alone still forces your platform to trust the broker blindly. That last layer is where most deployments stop and where Merobix keeps going: per-device Ed25519 identities and signed, replay-protected envelopes are standard platform behavior, documented on our security page. Ask any vendor which of the four layers they implement - then watch the whole pipeline live in a demo.
No. Out of the box, MQTT is a plaintext protocol on port 1883 with optional authentication - the specification defines a username and password field but does not require its use, and it mandates no encryption at all. A default MQTT deployment sends every reading, credential, and command across the network readable by anyone on the path, and an open broker will accept connections from anyone who finds it. Security researchers regularly find tens of thousands of unauthenticated MQTT brokers exposed on the internet. Every production industrial deployment needs, at minimum, TLS on port 8883, authentication for every client, and topic-level authorization - none of which are on by default.
Secure MQTT uses port 8883, the IANA-registered port for MQTT over TLS, instead of the plaintext default of 1883. TLS on 8883 encrypts everything in transit - payloads, topics, and the credentials the client presents at CONNECT, which on port 1883 would cross the network in cleartext. Best practice is to disable the plaintext 1883 listener entirely rather than run both, require TLS 1.2 or newer, use certificates from a trusted authority with proper hostname validation on the client side, and never disable certificate verification to make an error go away - an MQTT client that skips verification will happily hand its credentials to an impostor broker.
Topic ACLs (access control lists) are per-client authorization rules on the broker that define which topics each authenticated client may publish to and subscribe from. They matter because MQTT authentication alone is all-or-nothing: without ACLs, any authenticated client can publish to any topic and subscribe to everything - including wildcard subscriptions that vacuum up your entire data stream. With ACLs, a field gateway can publish only its own site's topics and read only its own command topics, so one compromised device cannot impersonate other sites, snoop fleet-wide data, or inject commands. Scope ACLs to the narrowest topic pattern each client needs, and deny by default.
No - Sparkplug B is an interoperability specification, not a security layer. It standardizes topic namespaces, payload encoding, and state management (birth and death certificates) so SCADA platforms and devices from different vendors can understand each other's MQTT data. That structure indirectly helps security - predictable topics make tight ACLs easier to write, and its state model detects devices that disappear - but Sparkplug itself adds no encryption, no authentication, and no payload integrity. A Sparkplug deployment still needs TLS, per-device credentials, topic ACLs, and ideally signed payloads, exactly like any other MQTT deployment.
TLS protects data between one client and the broker - but the protection ends at the broker's edge. Once a message is inside, the broker and everything downstream see plaintext, and the receiving application has no way to verify which device originally produced a reading, whether it was altered after the broker, or whether it is a replayed copy of an old message. Signed payload envelopes close that gap: the device signs each message with its own private key (Merobix uses per-device Ed25519 identities) and includes sequence numbers, timestamps, sample IDs, and payload digests, so the platform can verify origin and integrity end to end and reject replays - even if a broker or credential in the middle is compromised.
TLS everywhere, per-device Ed25519 identities, and signed, replay-protected MQTT envelopes - see what verifiable telemetry looks like from field device to dashboard.