Sparkplug B fuzzing exposes protocol gaps in industrial control systems

At a glance

What this is: This is an analysis of a new Sparkplug B fuzzer for ICS and SCADA environments, with the key finding that systematic coverage of all 9 message types and 19 data types exposes protocol-handling weaknesses before attackers do.

Why it matters: It matters because Sparkplug B brokers and endpoints sit close to operational processes, so malformed payloads, bad alias handling, or weak topic controls can create availability and safety failures that IAM-adjacent access rules alone will not prevent.

By the numbers:

• A systematic Sparkplug B protocol fuzzer can cover all 9 message types, 19 data types, and 87+ unique field paths defined by the Eclipse Sparkplug specification.
• The improved fuzzer expanded coverage from 4 of 9 message types to all 9 message types.
• The initial script fuzzed only 2 data types, while the improved fuzzer exercised all 19 data types.

👉 Read Bishop Fox's analysis of Sparkplug B fuzzing in industrial control systems

Context

Sparkplug B is a protocol governance problem as much as a technical one: it standardises how industrial devices publish state, telemetry, and commands, but it also creates a large attack surface when brokers, topic namespaces, and payload validation are treated as trusted by default. In industrial control and SCADA environments, that trust can turn a parsing bug or alias-handling mistake into an operational outage or a safety event.

The identity connection is real even in an OT article like this. Sparkplug B environments depend on publisher and subscriber authorisation, broker access controls, and device-level trust decisions that resemble machine identity governance in other domains. Where devices, brokers, and controllers are implicitly trusted, defenders lose the ability to distinguish legitimate state changes from malicious or malformed traffic.

Key questions

Q: How should security teams test Sparkplug B deployments for protocol abuse?

A: Use a fuzzer that exercises births, deaths, telemetry, commands, topic namespaces, and raw protobuf structures, then compare results against broker logs and device behaviour. The goal is to find where the implementation accepts malformed traffic, not to prove the specification is safe. In industrial settings, a parser that fails quietly can be more dangerous than one that crashes immediately.

Q: Why do Sparkplug B environments create outsized blast-radius risk?

A: Sparkplug B uses publish-subscribe delivery, so one misbehaving or malicious publisher can reach every subscriber on a topic. If ACLs are broad and brokers are reachable from business networks, a single compromised publisher can influence many devices at once. That is why broker scope, namespace design, and authenticated access are central controls, not peripheral hardening.

Q: What do teams get wrong about alias handling in industrial telemetry?

A: They often treat aliases as a harmless compression feature instead of a trust boundary. If the alias-to-metric relationship changes unexpectedly, the system may write the wrong value into the wrong field or continue processing stale assumptions. Defenders should assume alias collisions can be both a bug and an attack technique until proven otherwise.

Q: What should operators do when Sparkplug B devices start rebirthing unexpectedly?

A: Investigate it as a state-integrity issue, not just a reliability problem. Repeated births, missing deaths, or orphaned sessions can indicate malformed traffic, unstable connectivity, or deliberate manipulation of device state. Operators should correlate broker events with asset records, isolate the affected namespace, and verify that no control decisions are being made from stale telemetry.

Technical breakdown

How Sparkplug B message structure creates fuzzing risk

Sparkplug B adds a fixed topic namespace, a defined lifecycle, and protobuf-encoded payloads on top of MQTT. That combination makes it efficient for constrained industrial links, but it also means every message must satisfy both topic expectations and schema expectations. The nine message types cover births, deaths, telemetry, commands, and host liveness, while aliases compress metric names into short identifiers. That is useful for bandwidth, but it also creates failure modes when type checks, sequence rules, or alias mappings are wrong.

Practical implication: validate both topic structure and protobuf schema before allowing a Sparkplug B message to influence plant state.

Why alias collisions and type mismatches matter in OT telemetry

Sparkplug B aliases can make telemetry compact, but they also create hidden coupling between the announced metric definition and later value updates. If a device declares a metric as a Float in NBIRTH and later accepts a String in DDATA, the parser has already failed in a way that can corrupt downstream logic. Sequence numbers and session transitions add another layer of statefulness. In an OT setting, stateful trust bugs are dangerous because they can survive long enough to influence control decisions before anyone notices.

Practical implication: enforce metric-type consistency, reject alias rebinding mid-session, and treat out-of-order sequence behaviour as a security signal.

Why passive discovery strengthens Sparkplug B attack validation

The fuzzer's passive discovery component matters because Sparkplug B networks often expose their own topology through NBIRTH and DBIRTH traffic. By subscribing to wildcard topics and building a live device map, a tester can identify metric definitions, broker reachability, and likely targets without active probing first. That is valuable for defenders too, because it shows how much operational intelligence an attacker can collect from normal protocol traffic. In other words, the protocol itself can leak the map needed to attack it.

Practical implication: assume topic subscriptions can reveal the environment and monitor for unexpected discovery behaviour on the broker.

NHI Mgmt Group analysis

Protocol fuzzing belongs in industrial identity and access governance, not only in application testing. Sparkplug B broker access, publisher authenticity, and topic ACLs determine whether malformed traffic can reach critical endpoints. That means OT security teams should treat broker policy, device trust, and schema validation as part of the same control plane, because a permissive subscriber or anonymous publisher can create the same blast-radius problem that over-privileged machine identities create elsewhere.

Alias-state trust is a specific failure mode that many Sparkplug B deployments are likely to miss. The article shows how alias rebinding, type mismatches, and sequence handling bugs can all hide inside protocol convenience features. A system that trusts a publisher to keep the same alias-to-metric relationship over time is depending on behavioural consistency instead of enforcement. Practitioners should recognise this as a state-integrity problem, not just a parsing defect.

Passive reconnaissance inside MQTT-like industrial protocols should be assumed, not treated as exceptional. If a fuzzer can map devices, metrics, and message flows from normal traffic, then an attacker can do the same. That shifts the governance question from whether discovery is possible to whether the broker and network architecture leak too much by design. Defenders should respond by limiting subscription scope, segmenting brokers, and correlating protocol events with asset records.

Sparkplug B security debt is a control-maturity issue, not just a protocol-specification issue. The protocol is designed for interoperability, but interoperability without validation creates the conditions for unsafe automation. This is where NIST-CSF, NIST SP 800-53 controls for access and integrity, and MQTT broker hardening all intersect. Practitioners should view fuzzing results as evidence of governance gaps that need policy and operational change, not just code fixes.

What this signals

Protocol discovery is now part of the attack surface for industrial environments. When a security tool can build a live map of Sparkplug B devices from ordinary broker traffic, defenders should assume that attackers can do the same. The programme response is to reduce exposed namespace scope, tighten broker policy, and tie protocol events back to asset inventories so discovery does not become exploitation.

For teams already running MQTT-based OT systems, the practical shift is toward continuous validation rather than one-time design review. Broker ACLs, schema enforcement, and message logging need to be testable controls, not assumptions. That is where a fuzzer becomes useful as a governance tool, not just a research artifact.

For practitioners

• Harden broker authentication and topic scoping Require authenticated publishers and subscribers, disable anonymous MQTT in production, and scope ACLs to the smallest practical Sparkplug namespace rather than granting broad wildcard access.
• Validate Sparkplug payloads against the schema Reject malformed protobuf content before it reaches controllers or downstream applications, and verify that each metric value matches the type declared in birth messages.
• Treat alias rebinding as a security event Alert when aliases change mid-session, when sequence numbers arrive out of order, or when a device presents inconsistent metric definitions across births and data updates.
• Monitor for protocol-discovery patterns Watch wildcard subscriptions, repeated birth events, parse failures, and orphaned session patterns because they can indicate testing, reconnection instability, or active reconnaissance.
• Segment OT brokers from business networks Keep Sparkplug brokers off corporate network paths where possible, restrict who can reach them, and test that segmentation with a fuzzer rather than assuming the controls hold.

Key takeaways

• Sparkplug B creates a large and stateful attack surface, so fuzzing is a control validation exercise, not just a software test.
• The most dangerous failures here are malformed payload acceptance, alias misuse, and permissive broker access that widen blast radius across OT systems.
• Operators should pair protocol hardening with discovery monitoring, schema enforcement, and tightly scoped MQTT permissions before attackers find the gap first.

Key terms

• Sparkplug B: Sparkplug B is an MQTT-based specification for industrial systems that standardises how devices publish state, telemetry, and commands. It uses a fixed topic namespace and protobuf-encoded payloads to reduce bandwidth, but that structure also creates a rich surface for parser, state, and access-control failures.
• Protocol fuzzing: Protocol fuzzing is the practice of sending malformed, unexpected, or randomly altered messages to a system to see how it behaves. In industrial environments, it is used to uncover parsing errors, state-handling bugs, and unsafe assumptions before those flaws show up in production or under attack.
• Alias collision: Alias collision occurs when a short identifier that should map to one metric or value is reused, rebound, or misinterpreted. In Sparkplug B and similar protocols, that can cause one field to receive the wrong value or allow an attacker to exploit trust in a previously established mapping.
• Passive discovery: Passive discovery is the act of learning about devices, topics, and communication patterns by observing traffic rather than actively probing the target. It is especially relevant in brokered industrial protocols because normal messages can expose topology, asset names, and operational state.

What's in the full article

Bishop Fox's full analysis covers the implementation detail this post intentionally leaves for the source:

• The full Sparkplug B fuzzer code path, including how the tool constructs valid and intentionally invalid payloads
• The message-by-message coverage table that shows how each of the 9 Sparkplug B message types was exercised
• Operational examples from the automotive assessment that illustrate broker exposure, anonymous access, and alias rebinding
• The GitHub repository and usage details for teams that want to reproduce the testing workflow

👉 The full Bishop Fox post covers the fuzzer design, Sparkplug B coverage map, and OT validation examples.

Deepen your knowledge

NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course, the industry's only accredited NHI security programme. Explore nhimg.org for resources that connect identity governance to the broader security disciplines your programme depends on.