Sparkplug B protocol security: what MQTT's SCADA layer protects, and what it doesn't

Per the Eclipse Sparkplug project's own FAQ, "Sparkplug is an open software specification that provides MQTT clients the framework to seamlessly integrate data from their applications, sensors, devices, and gateways within the MQTT Infrastructure," and, more precisely, "Sparkplug is simply a specification that defines how best to use MQTT in real-time, mission-critical industrial infrastructures." It does not modify MQTT itself. Instead, the specification (current version 3.0.0, dated 21 October 2022) layers three conventions on top of a standard MQTT broker: a structured topic namespace (spBv1.0/group_id/message_type/edge_node_id/device_id), a Google Protocol Buffers payload format for typed metrics, and a session-state management model built around what the spec calls Birth and Death certificates. The specification's own reference architecture diagram shows why this matters for OT specifically: it places SCADA/IIoT "Primary Application," "MES," "Historian" and "Analytics" host applications side by side on the same MQTT broker, all consuming the identical Sparkplug-formatted data stream from every connected Edge Node.

No — and the specification is unusually direct about this. Chapter 7, titled simply "Security," opens with: "This chapter is provided for guidance only and is non-normative." Its three subsections each point outward rather than defining a Sparkplug-specific control. Section 7.1 (TLS) explains that "the MQTT specification does not specify any TCP/IP security scheme as it was envisaged that TCP/IP security would (and did) change over time," so Sparkplug "will not specify any TCP/IP specific security requirements" either, offering only non-binding examples of securing a deployment with TLS. Section 7.2 (Authentication) states that "from a pure MQTT client perspective, the client does need to provide a unique Client ID, and an optional username and password" — a description of what MQTT's CONNECT packet already supports, not a new requirement. Section 7.3 (Authorization) notes that "although access control is not mandated in the MQTT specification for use in MQTT Server implementations, Access Control List (ACL) functionality is available for many MQTT Server implementations," and Section 7.4.3 walks through an example ACL for a single Edge Node, concluding that properly scoped ACLs "offer some security in preventing compromised credentials from being able to be used to spoof Edge Nodes, write to other Edge Node outputs, or see all messages flowing through the MQTT Server." Every one of those controls has to be configured on the broker; Sparkplug supplies the worked example, not the enforcement.

Sparkplug's most distinctive feature is what the spec calls Continuous Session Awareness — a way for a Host Application to always know whether an Edge Node is online, which legacy poll/response SCADA protocols handled by simply asking again. Sparkplug instead uses the MQTT "Will Message" feature so that a Death Certificate is delivered even if a client disconnects ungracefully. The specification requires that "Birth Certificates MUST be the first MQTT messages published by any Edge Node or any Host Application," using the NBIRTH topic verb for an Edge Node coming online and NDEATH (registered as the MQTT Will) for it going offline. Each NBIRTH includes a bdSeq number that "MUST start at zero and increment by one on every new MQTT CONNECT packet," letting a Host Application match a later NDEATH back to the NBIRTH session it belongs to. Every subsequent NDATA message then carries its own sequence number, which "MUST have a value of one greater than the previous MQTT message from the Edge Node... unless the previous MQTT message contained a value of 255," in which case it resets to 0 — a simple rolling counter a Host Application uses to detect a gap or an out-of-order delivery.

None of this is an integrity or authenticity control. A bdSeq or sequence number only tells a subscriber that a message arrived in the expected order relative to the last one it saw from that same authenticated connection; it says nothing about who actually holds that connection. Any MQTT client authorized to publish on a Group ID and Edge Node ID's topics — whether the genuine device or an attacker using its credentials — can publish a perfectly well-formed NBIRTH, NDATA or forged NDEATH, sequence numbers included, and every downstream Host Application, Historian or Analytics consumer will treat it as legitimate.

Inductive Automation's Ignition is one of the most widely deployed SCADA/IIoT platforms shipping native Sparkplug B and MQTT modules for the Primary Host Application role the specification describes — the single application an Edge Node waits for before publishing its NBIRTH and DBIRTH messages. NVD's record for CVE-2025-13911 (CISA ICSA-25-352-01, CVSS v3.1 base score 6.4, CWE-250 Execution with Unnecessary Privileges) describes the flaw: "Ignition by Inductive Automation with default OS service account settings may expose elevated code execution risk via gateway backup restore. An authenticated Gateway Administrator can import a malicious .gwbk file containing crafted resources, scripts, or modules, resulting in code execution with system-level privileges on Windows (NT AUTHORITY\SYSTEM) or root/elevated privileges on Linux." Inductive Automation's own Trust Center confirms the mechanism in its own words: "The default Ignition installation on Windows grants greater operating system permissions than is needed in most cases. An Ignition administrator importing malicious project resources could lead to a system level compromise or other significant effects." The same Trust Center page states the vendor's disclosure posture plainly: "Inductive Automation already operates a coordinated vulnerability disclosure program. We coordinate directly with CISA. Our findings are formally scored and cataloged in the NIST National Vulnerability Database for the broader security community."

This is a privilege-escalation flaw in the host platform's default Windows service-account permissions, reachable only by an already-authenticated Gateway Administrator — not a break of Sparkplug's topic namespace, payload format, or Birth/Death mechanism, and the two should not be confused. What it does illustrate is that the Primary Host Application a Sparkplug deployment designates — the one piece of infrastructure every Edge Node's Birth and Death certificate is specifically addressed to — is itself a high-value target that needs the same hardening discipline as any other privileged OT server, independent of whatever ACL scoping is applied to the Sparkplug topics it consumes.

Sparkplug's own reference architecture diagram lists an "Analytics (Sparkplug)" application sitting on the identical MQTT broker as MES, Historian and SCADA host applications — the specification was built so that every consumer, human-facing or automated, reads the same typed metric stream from the same Edge Nodes. That design is exactly why Sparkplug B has become a common data backbone feeding predictive-maintenance and anomaly-detection models in IIoT: the Birth certificate's typed, self-describing metric list and the NDATA stream's change-only reporting give a model-training or inference pipeline a structured, low-noise feed without a separate historian export step. But because Chapter 7 leaves every authentication and authorization decision to the broker, an Analytics consumer has no Sparkplug-level way to know whether an NBIRTH or NDATA message it is about to train on, or act on, came from the genuine Edge Node or from a client that obtained valid broker credentials — a gap that matters more, not less, once the consumer on the other end is a model making an unattended decision rather than a person reading a dashboard. The fix is the same one the specification already names: broker-side authentication, TLS, and ACLs scoped per Edge Node, because nothing in the Sparkplug payload itself will ever flag a well-formed but illegitimate message as suspicious.