Is MQTT less secure than OPC UA?

MQTT itself has no mandatory built-in security model — authentication and encryption (typically TLS over port 8883) are optional and left to the implementation. OPC UA has security designed into the specification itself: certificate-based authentication, message signing, and encryption are core parts of the standard, not add-ons. In practice, well-configured MQTT deployments (TLS, client certificates, broker ACLs) can be quite secure, but the responsibility sits with the implementer rather than being enforced by the protocol.

What is Sparkplug B and why does MQTT need it?

Sparkplug B is a payload and topic-namespace specification, maintained under the Eclipse Foundation, that runs on top of standard MQTT. Because raw MQTT payloads are just opaque bytes with no required structure, Sparkplug B defines a consistent way to encode metric names, data types, timestamps, and device/node birth and death state, so that different vendors' MQTT clients and SCADA/historian software can interoperate meaningfully. It's essentially the semantic layer MQTT deliberately omitted to stay lightweight.

Can OPC UA run over MQTT?

Yes. Since OPC UA 1.04 added the PubSub extension, OPC UA's information model can be transported over several bindings including MQTT (as well as UDP and AMQP), rather than only the classic client-server binary TCP transport. This lets a system get OPC UA's semantic richness while still using a lightweight, broker-based transport for scale — which is part of why the two are increasingly complementary rather than competing.

Which one is better for a small factory floor integration to a local historian?

For a single-site integration where the SCADA server and historian are both on the plant network and need to exchange structured, typed data with strong security, OPC UA's client-server model is usually the more direct fit — it's designed exactly for that kind of system-to-system exchange. MQTT's broker-based scale advantages matter most once you're dealing with large device counts or WAN/cloud connectivity, which a single local historian integration typically doesn't need.

Does using MQTT mean giving up the OT-to-IT security boundary?

No, but it requires deliberate configuration. A well-designed MQTT architecture still respects Purdue-model segmentation — edge devices publish to a broker that sits in a DMZ or is otherwise firewalled from both the OT network and the open internet, with TLS and authenticated clients. The protocol's lightweight nature doesn't remove the need for the same network security architecture any IIoT data path requires; it just means security has to be added explicitly rather than assumed from the protocol.

← SCADA & Industrial Controls Studio

Concept Explainer · SCADA

OPC UA vs. MQTT

Both get lumped together as "the way OT data reaches IT and the cloud" — but one was designed to describe what a piece of data means, and the other was designed to move bytes as cheaply and fast as possible without caring what they mean at all.

OPC UA and MQTT show up on the same architecture diagrams so often that engineers new to IIoT design sometimes assume they're competing options for the same job. They aren't — they solve different problems, and most serious IIoT architectures end up using both, often together. OPC UA (Unified Architecture, from the OPC Foundation) is a rich information-modeling standard: it defines not just a value but a typed, browsable, self-describing structure around that value — units, data quality, historical access, method calls, security — and it supports both client-server request/response and, since UA became transport-flexible, publish-subscribe. MQTT is a minimal publish-subscribe messaging transport built for constrained devices and unreliable networks: a broker, topics, small binary payloads, three quality-of-service levels, and nothing said about what the payload actually contains. That gap is exactly why Sparkplug B exists — a payload specification layered on top of MQTT to give it some of the semantic structure it doesn't have natively.