IIoT Interoperability OPC UA vs MQTT

OT BRIEF: We compare using MQTT Sparkplug emerging technologies verses established OPC UA for industrial estate applications - each has a place in the OT stack.

OPC UA and MQTT are not equivalents. That said, some advocates point out that MQTT Sparkplug provides a viable alternative to OPC UA for foundational device level communications architecture. On the positive side it does provide a flexible model that is relatively easy to develop assuming devices have native MQTT support built in. That said, OPC UA is an information model, a security model and two transports; MQTT is a transport with no semantics and no authorization model, and the comparison only becomes coherent once Sparkplug is added to the MQTT side. Sparkplug helps to get to a point of coherence to be enable any comparison between them.

The discussion is not whether MQTT and Sparkplug can be used, it certainly can be but the TCO profiles are much difference between them in addition to aforementioned capabilities deficits. Here the standard formulation of that cost is wrong. It is usually stated as a trade of governance effort for flexibility — cheap to implement, expensive to audit. That understates it by a multiplier. The specification contains no abstraction mechanism: no type to inherit from, no reference binding an instance to a definition, no versioning construct in the payload. Consequently, the integration work does not amortize. It is performed per vendor, per model, and then again per firmware revision, and the resulting artifact is a gateway configuration rather than anything that can be published, versioned or reused.

MQTT with Sparkplug is cheap initially and expensive to audit. It is also cheap initially and expensive N times more, where N is the number of distinct equipment models in the estate multiplied by the rate at which their vendors revise them.

This distinction is materially different from the typical one related to cost effectiveness, and it changes the recommendation. It means the reason to require OPC UA companion-specification conformance or a published NodeSet is not architectural purity or semantic richness in the abstract — it is that those are the only constructs in either stack that make the second instance of an equipment class approximately free is where the money goes, and that burden is invisible in every business case we have reviewed because it arrives eighteen to thirty-six months after the pilot that justified the decision.

It also means the maintenance burden, not the initial integration, is where the money goes, and that burden is invisible in every business case we have reviewed because it arrives eighteen to thirty-six months after the pilot that justified the decision.

In the remainder of this article, we establish the current specification position of both options, sets out the abstraction gap, models the cost consequence, locates where the resulting artefact accumulates, and then we look at the security and regulatory positions that a supplier will be asked to provide evidence.

Specification Position Between the Two

OPC UA

Standardized as IEC 62541. The current series is 1.05 (August 2026), with maintenance releases running through 1.05.06 and 1.05.07 during 2026. Two transports are in scope: client/server, session-bound with a secure channel and per-session security context; and PubSub (Part 14), mapping UADP binary or JSON payloads onto UDP, MQTT or AMQP. OPC UA over MQTT is therefore a specified configuration rather than a hybrid, which is worth stating plainly because it removes the transport question from the argument entirely.

Three items come to bear on any specification written later this year. Certification support for OPC UA 1.03 ends at the end of 2026, so equipment certified against 1.03 profiles is being purchased against an expiring basis. The Field Level Communications initiative continues its staged UAFX 1.00 release, with release candidate V1.00.04 introducing Part 81 (connecting devices and information model) and Part 84 (profiles), a multi-vendor controller-to-controller interoperability event hosted at Beckhoff in February 2026, controller-to-device and device-to-device prototypes under validation, and a showcase targeted for SPS in November 2026. And the OPC UA Safety compliance test tool has been completed and TÜV-certified, with work under way to stand up a safety certification lab — which converts OPC UA Safety from a specification into an auditable conformity route.

MQTT and Sparkplug

MQTT v5.0 has been an OASIS standard since 2019; only v3.1.1 carries an ISO/IEC number, 20922:2016. MQTT specifies connection handling, quality-of-service levels, retained messages, and specifies nothing about payload structure, types or authorization.

Sparkplug 3.0 was ratified in October 2022 as the first release under the Eclipse Foundation Specification Process and has since been published as ISO/IEC 20237, with a Technology Compatibility Kit and compatible-products listing. It defines a topic namespace, a protobuf payload and a session-state discipline built on birth and death certificates and the broker LWT mechanism. That discipline is genuinely valuable and is what makes MQTT usable for SCADA-grade staleness semantics rather than best-effort telemetry. It is also the limit of what the specification supplies.

Sparkplug 4.0 remains unreleased. The working group targeted a release candidate for late 2024 or early 2025, splitting the birth certificate so that metadata is published separately. As of August 2026, the published revision history still shows 3.0 as current. Treat 4.0 as unscheduled and do not carry a dependency on it with a date attached.

The Abstraction Gap

Abstraction, in this context, means one specific capability: the ability to define an equipment class once and then bind instances to that definition, such that a consumer which understands the class understands every instance without further work. Everything downstream in this aticle follows from whether a stack has that capability.

What OPC UA provides

OPC UA provides it through several reinforcing constructs. Object types and variable types establish class definitions with inheritance. References bind an instance to its type, so a client can traverse from a device to the definition it conforms to. Companion specifications standardize those definitions across vendors for an equipment class, and NodeSet2 files make a definition a publishable, versionable, diffable artefact that can be a contractual deliverable. The compliance regime tests against it: UACTT Lite performs a gap analysis between the information model a server claims to support, and the address space it actually exposes.

The consequence is that the second machine of a class costs near zero to onboard, provided the OEM conformed. The consumer already knows the type. The work performed for the first instance was performed against the definition, not against the instance, so it is reused rather than repeated. Where no companion specification exists the guarantee weakens to whatever the OEM published — but a published NodeSet is still a definition, still versionable, and still reusable across that vendor's range.

What Sparkplug does not provide

Sparkplug has a flat metric namespace. A birth certificate enumerates metrics with names, datatypes and current values. There is no type of construct to inherit from, no reference that binds an instance to a class definition, and no mechanism by which a definition can exist independently of the instances that carry it. Two identical machines from the same OEM publish two independent metric lists that happen to agree, and nothing in the protocol asserts or verifies that agreement.

Three specific absences are noteworthy, and they are worth naming separately because they fail differently.

•      No instance-to-definition binding. A consumer cannot ask what class a device belongs to, because the concept is not in the payload. Every consumer therefore learns each device individually, and the learning is embodied in consumer-side or gateway-side configuration rather than in a shared artefact.

•      No versioning construct in the payload. There is no field carrying a model or definition version that a consumer can check and act on. A metric set that changed between firmware revisions is indistinguishable, at the protocol level, from one that did not.

•      Aliases are per-session and positional. The alias mechanism that keeps payloads small binds an integer to a metric name for the duration of a session, re-established at each birth. It is an efficiency device, not an identifier. Anything that consumes aliases without re-reading the birth is coupled to a numbering the publisher may reorder at any revision, without notice and without error.

OPC UA has a mechanism for defining a class once and binding instances to it. Sparkplug has none. That single difference, and not payload efficiency or security posture, is what determines whether integration work amortizes across an estate.

This is not a defect in Sparkplug relative to its design intent. it was designed to be lightweight, and it was scoped to give MQTT session state and a topic convention for SCADA-grade telemetry, and it does that well. It is a defect only relative to how it is now being sold, which is as an interoperability layer for a whole estate.

The TCO Consequences

The practical shape of the cost is easier to see when the initial integration and the maintenance obligation are separated, because they are usually presented as one number and only the first is ever estimated.

Onboarding New Equipment

Under Sparkplug, onboarding an equipment model requires deciding a topic and metric naming for it, mapping the source tags to those metrics, deciding units and state enumerations, encoding all of that in a gateway configuration, and communicating the result to every consumer that needs it. That work is repeated for the next model, and for the same model from a different OEM, because nothing was defined that the second exercise could inherit. Under OPC UA with companion-specification conformance, the equivalent work is performed once per class rather than once per model, and the marginal instance is a connection. An estate with thirty distinct equipment models across four OEMs carries thirty mapping exercises rather than a smaller number of class definitions, and the count only ratchets upward, because equipment is added faster than it is retired.

Maintenance - where it compounds

Maintenance is the larger cost and the one absent from business cases. Four triggers recur.

•      Firmware revision changes the metric set. A metric is renamed, added, removed or reordered. Nothing in the protocol detects this, because there is no definition to compare against and no version field to compare on.

•      Alias renumbering. A revision that reorders metrics reassigns aliases. A correctly implemented consumer re-reads the birth and is unaffected; a consumer that cached aliases across sessions — a common optimisation — now reads the wrong metric, silently.

•      Unit and enumeration drift. A vendor changes a unit or a state code between revisions. The value continues to arrive, correctly typed, and is wrong. Type checking does not catch semantics.

•      OEM substitution. A replacement machine from a different vendor performing the identical function arrives with an entirely different metric set, and the mapping exercise restarts at zero.

The failure mode common to all four deserves emphasis, because it determines who finds the problem and when. These do not fail as errors. They fail as wrong numbers arriving in a system that has no basis for rejecting them, discovered downstream by whoever consumed them, often long after the revision that caused it. In a plant that is an operational annoyance. Where the consumer feeds a compliance report, a quality record, an energy declaration or a safety-adjacent decision, it is an evidentiary problem, because no artefact in the chain defines it.

The absences fail silently. Not as protocol errors, but as correctly typed wrong values arriving in systems with no basis to reject them — discovered downstream, after the fact.

The mitigations are all available and all external: a schema registry, topic and metric linting in CI, contract tests against each OEM revision, a versioned internal naming standard, a change-control gate on firmware acceptance. Every one is achievable and none is supplied by the specification, which means each is a budget line someone must defend against the claim that the protocol was chosen because it was simple.

Where the Artifact Accumulates

The mapping has to live somewhere, and it lives in the gateway configuration. This matters more than it appears to, for three reasons.

1. It is not a published artifact. Unlike a NodeSet2 file, a gateway mapping is not a definition anyone else can consume, diff or conform to. It is configuration in a product, expressed in that product's idiom, and its portability is whatever the vendor's export function permits.

2. It is where the accumulated estate knowledge ends up. After three years, the mapping layer is the only complete statement of what the plant's data means. Replacing the gateway means re-deriving that statement, which is a project nobody funds. The switching cost is not the licence; it is the semantics held hostage in the configuration.

3. It is the point at which openness inverts. Both protocols are open. The translation layer joining them is where proprietary semantics, tag-count licensing and platform economics sit — and it is precisely where the un-amortized integration work accretes. The absence of abstraction in the wire protocol and the concentration of lock-in in the gateway are the same phenomenon observed from two ends.

Any evaluation that scores OPC UA against MQTT and treats the gateway as an implementation detail has scored the wrong artefact. The gateway is the product decision. The protocols are the constraint it operates under.

Specified Security Versus Deployed Security

Two further capabilities sit outside the MQTT and Sparkplug specifications, and they follow the same pattern as abstraction: available, achievable, and carries the obligation as self-service.

Authorization is absent from both specifications. Per-client publish and subscribe ACLs are broker product features, so the control satisfying IEC 62443-4-2 CR 2.1 does not port between brokers and cannot be evidenced by conformance to anything — only by attestation against a specific product configuration. Integrity terminates at the broker: TLS protects the hop, the broker sees and can alter every payload, and there is no message-level signature or provenance for a metric. Where a downstream consumer acts on a value with physical or regulatory consequence, the integrity claim rests on the broker being trusted infrastructure rather than on the data being verifiable.

None of that makes MQTT insecure. It relocates the obligation. And the counterweight is real: a Sparkplug edge node holds a single outbound session, so the zone-and-conduit story is materially easier to defend than client/server OPC UA, which assumes an inbound conduit unless Part 6 Reverse Connect is specified — and it is rarely specified, because it is rarely known.

Bitsight's TRACE team identified 14,220 unique internet-exposed OPC UA servers during its 2025 scan year across 99 countries. Over half — 51.74 per cent — accepted anonymous access; just over 80 per cent advertised an unencrypted None security mode; close to 90 per cent supported at least one deprecated security policy. The correct reading is not that OPC UA is insecure but that the specification permits a None endpoint and the deployment selects it. In-spec security is not deployed security.

The equivalent MQTT picture is worse in kind if weaker in source quality, with unauthenticated broker counts in the tens of thousands recurring across scan-engine studies. For evidentiary purposes the distinction that survives is whether a control sits inside a citable conformance boundary or in a configuration you must attest to.

62443-4-2 requirement	OPC UA	MQTT + Sparkplug 3.0
CR 1.1 / 1.2 — identification and authentication	In specification: user token types and application-instance certificates; testable against profiles	Broker feature: credentials or mutual TLS; not specified by MQTT or Sparkplug
CR 1.5 — authenticator management	In specification: GDS certificate lifecycle, trust lists, revocation	Product- and PKI-dependent; no specified lifecycle
CR 2.1 — authorization enforcement	In specification: role-based authorization in the 1.05 series; per-node access	Absent from the specification; broker ACLs only, non-portable
CR 3.1 — communication integrity	In specification: secure channel signing at message level	Transport only; integrity ends at the broker
CR 4.1 — information confidentiality	In specification: Sign & Encrypt security mode	TLS hop-by-hop; broker sees plaintext payloads
CR 6.1 — audit log accessibility	In specification: OPC UA auditing events	Broker logging; content and retention vendor-defined
CR 7.1 / 7.2 — DoS protection and resource management	Stack-dependent; historically the weakest area (fuzzing-discovered DoS across ~15 stacks)	Broker-dependent; mature products handle it well at scale

OPC UA carries its own liabilities here and they should not be minimized. Claroty's Team82 has disclosed on the order of fifty CVEs across roughly fifteen stacks, with exploits demonstrated at three Pwn2Own ICS competitions; the protocol implemented a bespoke cryptographic transport rather than reusing TLS, which drew the Zerologon researcher at DEF CON 33 in 2025 and produced CVE-2024-42512 and CVE-2024-42513 against the .NET Standard stack. A large, optional-heavy parsing surface terminating inside the control network is a structural exposure. The table above distributes obligation; it does not rank safety.

Allocation by Traffic Class

The allocation below follows from the preceding argument rather than standing independently of it. Where semantics must be reused across instances, the stack with an abstraction mechanism wins by construction; where the requirement is distribution of telemetry to many consumers across a constrained boundary, it does not apply and the broker model wins.

Traffic class	Allocation	Rationale
Deterministic closed loop within a cell	Neither	Existing fieldbus, or UAFX over TSN once multi-vendor production maturity is demonstrated. Broker-mediated pub/sub has no bounded-latency claim.
Controller-to-controller	OPC UA (UAFX)	The specified horizontal exchange. No MQTT competitor exists at this layer.
Safety-related exchange	OPC UA Safety	Black-channel profile with a TÜV-certified compliance test tool and a certification lab being stood up. Sparkplug has no equivalent and will not acquire one.
Configuration, methods, alarms, historical access	OPC UA client/server	Requires types and methods. Sparkplug cannot express them without an out-of-band convention that is itself unversioned.
Equipment semantics reused across instances	OPC UA at source	The amortisation case. Companion specification or published NodeSet is the only construct that makes the second instance near-free.
Site-to-enterprise telemetry	MQTT + Sparkplug	Outbound-only conduit, report-by-exception, many consumers, one publication. The strongest case for the MQTT side, and it is a strong one.
Multi-site estates and intermittent WAN	MQTT + Sparkplug	Session state, LWT, store-and-forward at the edge. OPC UA client/server degrades badly here.
Cloud and analytics fan-out	MQTT + Sparkplug	Decoupled subscription model. Note that some cloud IoT endpoints implement a restricted MQTT subset and will not carry Sparkplug faithfully — verify before committing.

Overall Trends and Findings

Semantics are the scarce asset, and AI consumption is making that visible. The OPC Foundation republished its online reference in June 2026 with an MCP server for agentic tooling and downloadable specification formats for offline models. This is a signal for clearer direction. Consumers that reason over plant data need types and relationships; a flat metric list forces that context to be reconstructed downstream, by hand, once per consumer. Where an analytical or agentic consumer is anywhere in the roadmap, the abstraction gap stops being a maintenance cost and becomes a capability ceiling.

Convergence has already happened; the protocol debate is stale. Part 14 maps OPC UA PubSub onto MQTT with UADP or JSON payloads. The question is where the boundary between the UA model and the Sparkplug wire sits, and who owns the gateway spanning it. T

The market has converged on an effective pattern: OPC UA at the machine, Sparkplug above it, an edge platform performing contextualization — which is precisely the arrangement that concentrates the un-amortised mapping work in one proprietary place.

Sparkplug governance velocity is low. Version 3.0 ratified October 2022 and standardized as ISO/IEC 20237; version 4.0 targeted a release candidate for late 2024 or early 2025 and has not shipped as of August 2026. The MetaBirth split it proposes would improve the metadata story but would not supply a type system. Assess as working-group throughput rather than installed-base risk: specify 3.0, treat 4.0 as unscheduled, and do not expect the abstraction gap to be closed by it.

OPC UA is migrating downward while MQTT migrates upward. UAFX is pushing into the field level — Part 81 and Part 84 release candidates, C2D and D2D prototyping, TSN milestones, the February 2026 interoperability event, an SPS showcase targeted for November 2026 — while safety certification infrastructure comes online and O-PAS alignment continues. Vendors continue to improve device level OPC UA Server support across their portfolios. MQTT and Sparkplug have taken the enterprise and unified-namespace layer and are not contesting the field layer.

The certification asymmetry is an evidence asymmetry, not a quality one. OPC UA offers a compliance test tool at 1.05.06, UACTT Lite information-model gap analysis, accredited labs, and conformance units at profile granularity. Sparkplug offers a TCK and a self-service compatibility listing. For engineering quality this proves little; for a supplier qualification file or CRA technical documentation it is the difference between citing a conformance artefact and asserting one.

The 1.03 sunset is a forced-migration event inside the client base. Certification support for OPC UA 1.03 ends at the end of 2026. Equipment specified today against 1.03 profiles is bought against an expiring certification basis — one line in a specification now, a factory acceptance test later.

Regulatory pull is becoming a deciding variable and is not resolved. For CRA, obligations start in September 2026, full application in December 2027, and the harmonized standards that would give manufacturers a stable technical target have slipped and are uncited. Protocol selection is now partly a documentation-strategy decision: which choice produces artifacts that survive a notified body or a customer audit.

The differences between OPC UA and MQTT Sparkplug are not as important as how they are utilized. Right now, the industry seems to be pulled in the hybrid direction already noted where devices are serviced via an OPC UA layer in the field and MQTT provides contextuality at the Edge. The primary purpose of this paper is to show how they differ and demonstrate the contexts where TCO may be significantly impacted depending on the topology of the estate.