Sparkplug B fuzzing exposes protocol gaps in industrial control systems

At a glance

What this is: This is an analysis of Sparkplug B fuzzing for ICS and SCADA, showing that systematic malformed-traffic testing can now cover the protocol’s full message and field surface.

Why it matters: It matters because OT teams need to test broker trust, schema handling, and state transitions before a malformed payload or bad parser becomes an operational outage.

By the numbers:

• The improved fuzzer maps all 9 message types, 19 data types, and 87+ unique field paths defined by the Eclipse Sparkplug specification.
• The initial script covered only 4 of 9 message types and fuzzed just 1 metric with string data.

Context

Sparkplug B is a protocol governance problem as much as a transport problem. In industrial settings, MQTT brokers, topic namespaces, and protobuf payloads become part of the control plane for telemetry and commands, so parser tolerance and message validation directly affect operational reliability. For identity and access practitioners, the relevant question is who and what is allowed to publish, subscribe, and mutate state across that shared broker boundary.

The article’s core point is that protocol fuzzing closes a security test gap that specifications alone do not address. When a device, broker, or edge service accepts malformed Sparkplug B traffic, the failure mode is not just software instability. It can become a state integrity problem in the plant, which is why OT security, access control, and protocol validation intersect here.

That starting position is typical of modern unified namespace deployments: efficiency and interoperability arrive faster than defensive testing maturity.

Key questions

Q: What breaks when Sparkplug B messages are not strictly validated?

A: Devices and brokers can accept malformed payloads, mis-handle aliases, or process out-of-order state changes as if they were valid. In OT, that can corrupt telemetry, crash an edge node, or cause a command to be interpreted in the wrong context. The control failure is not just parsing, but allowing bad state to become operational truth.

Q: Why do broad MQTT topic permissions increase risk in Sparkplug B deployments?

A: Broad permissions let one misbehaving publisher reach many subscribers through a shared broker, so a single malformed or malicious message can spread widely. That expands blast radius across devices, edge nodes, and downstream applications. Least-privilege topic scoping matters because publish-subscribe architectures amplify whatever the broker is allowed to trust.

Q: How can security teams tell whether Sparkplug B fuzzing is finding real exposure?

A: Look for parser failures, silent acceptance of invalid payloads, unexpected rebirths, orphaned sessions, and devices that keep operating after malformed traffic. Those signals show whether the environment rejects bad messages or merely tolerates them. If the same defects appear across representative devices, the issue is architectural, not isolated.

Q: Should organisations treat Sparkplug B validation as an OT control or an application test?

A: Both, but the governance owner should treat it as an OT control because the failure mode affects safety, availability, and process integrity. Application testing alone misses the broker, topic, and lifecycle assumptions that make industrial telemetry trustworthy. The practical answer is to test protocol handling as part of operational resilience.

Technical breakdown

How Sparkplug B structures trust in MQTT-based OT traffic

Sparkplug B adds a fixed namespace, lifecycle messages, and protobuf-encoded payloads on top of MQTT. That combination gives operators a common way to represent devices, metrics, and commands, but it also creates a strict parser dependency: every message type, field, alias, and data type has to be handled correctly by both broker and endpoint. In practice, the security boundary is not just network reachability. It is whether the implementation accepts only valid state transitions and schema-compliant payloads. When those checks are weak, malformed traffic can shift from a test artifact into an operational control risk.

Practical implication: Validate Sparkplug B payloads against schema and state rules before they affect device logic.

Why alias handling and sequence rules are attack surfaces

Sparkplug B uses aliases to compress metric names and sequence numbers to preserve ordering. Those mechanisms improve efficiency, but they also create ambiguity if a device accepts alias rebinding, out-of-order delivery, or type mismatches without protest. A fuzzer can deliberately violate those assumptions to see whether a parser crashes, silently maps the wrong value, or keeps an invalid session state alive. In OT, silent acceptance is often worse than a crash because it hides integrity loss. The core technical lesson is that compact protocol design often expands the surface for malformed-state bugs.

Practical implication: Treat alias rebinding, sequence gaps, and type mismatches as security events, not normal protocol variation.

Why broker ACLs and publish-subscribe scope determine blast radius

Sparkplug B rides on shared brokers, so one poorly controlled publisher can affect many subscribers at once. If anonymous access is allowed, topic ACLs are too broad, or the namespace is flat, a single malformed or malicious message can propagate beyond its intended device group. That is a classic publish-subscribe amplification problem. The testing value of a Sparkplug B fuzzer is that it exposes whether the environment is actually enforcing publisher identity, topic scoping, and protocol validation, or merely assuming well-behaved devices. In OT, those assumptions are the difference between a contained defect and a plant-wide disruption.

Practical implication: Restrict broker permissions by group and role, and verify that invalid traffic cannot fan out across subscribers.

Threat narrative

Attacker objective: The objective is to disrupt or manipulate industrial device state and telemetry by exploiting weak Sparkplug B parsing and broker trust controls.

1. Entry occurs when a malformed Sparkplug B message reaches an MQTT broker or endpoint that trusts the namespace and accepts the payload for processing.
2. Credential or publisher trust abuse occurs when the broker allows overly broad publishing or subscribing, letting the malformed traffic reach many devices or subscribers.
3. Escalation happens when alias collisions, type mismatches, or sequence violations are accepted as valid state changes instead of being rejected.
4. Impact is operational, with crashes, corrupted telemetry, or broken command handling disrupting industrial processes and requiring manual recovery.

Breaches seen in the wild

• Anthropic GTG-1002 AI espionage campaign: A state-sponsored group ran Claude Code agents to attack about 30 organisations, harvesting and reusing credentials at machine speed.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Protocol fuzzing has become a control validation discipline for OT, not just a software-testing exercise. Sparkplug B shows why specifications are not enough when the protocol itself sits inside the operational path. The meaningful question is whether parsers, brokers, and device logic fail safely when traffic is malformed. Practitioners should treat fuzz results as evidence about control effectiveness, not as isolated bug reports.

Malformed-traffic tolerance is the real failure mode this article exposes. The most important governance gap is not whether Sparkplug B can be fuzzed, but whether the environment assumes that publishers behave correctly. That assumption collapses quickly in shared MQTT brokers, where one weakly authenticated or overly trusted source can reach many subscribers. Practitioners should review where trust is inferred from protocol structure instead of enforced at the broker boundary.

Sparkplug B creates a named concept: publish-subscribe blast radius. In OT, the combination of broad topic reach, shared brokers, and stateful device lifecycles means one faulty message path can affect many assets at once. That is especially relevant where identity controls for publishers and subscribers are coarse or absent. Practitioners should map broker scopes, topic ACLs, and device state transitions as a single governance surface.

The right security question is not whether Sparkplug B is efficient, but whether efficiency has outrun validation. The article makes clear that the protocol’s structured design can hide fragile implementations beneath a clean interoperability layer. That matters for industrial defenders because operational reliability depends on rejecting invalid messages before they become state changes. Practitioners should align protocol testing with the actual device and broker behaviors in production.

For identity teams working with OT, the lesson is that machine-to-machine trust still needs lifecycle control. A broker or device that can publish, subscribe, or rebind state without narrow authorization is effectively operating with standing machine privilege. That should be governed with the same discipline used for other non-human identities. Practitioners should ensure that publisher identity, topic scope, and session state are all continuously constrained.

From our research library:

• Claude Code-assisted commits leaked secrets at a rate of 3.2%, more than double the human-only baseline of 1.5%, with peaks reaching 31 secrets per 1,000 commits in August 2025, according to the State of Secrets Sprawl 2026.
• Read next: OT and ICS Identity and Access Guide

What this signals

Publish-subscribe blast radius is the key governance concept here: Sparkplug B turns one broker into a shared trust boundary for telemetry, commands, and device state, so ACL design matters as much as parser quality. OT teams should test the broker path, not just individual endpoints, because the weakest permission model determines how far malformed traffic can travel.

Sparkplug B deployments should now be assessed with the same scrutiny as other machine-to-machine identity paths. When publishers, subscribers, and rebinding behaviour are not tightly constrained, the environment effectively grants standing machine privilege to whatever can speak the protocol. That is an identity governance problem hidden inside an OT protocol problem.

For practitioners

• Harden MQTT broker authentication and topic ACLs Require authenticated publishers and subscribers, disable anonymous access, and scope topic permissions to the minimum Sparkplug B namespace needed for each role.
• Validate Sparkplug B payloads before state changes Check protobuf structure, metric types, alias reuse, and sequence ordering before a message can alter device or application state.
• Log lifecycle transitions across the fleet Record NBIRTH, DBIRTH, NDEATH, DDEATH, and STATE events so orphaned devices, stale sessions, and unexpected rebirths are visible quickly.
• Use fuzzing to test the deployed broker path Run malformed-traffic tests against representative brokers and endpoints, then compare crashes, parse failures, and silent acceptances across environments.
• Segment OT brokers from business networks Prevent corporate workstations, shared admin paths, or internet-reachable services from talking directly to Sparkplug B brokers unless there is a tightly controlled need.

Key takeaways

• Sparkplug B testing exposes a wider operational risk than broken parsing alone, because broker trust and state handling determine whether malformed traffic stays contained.
• The article shows that the improved fuzzer covers all 9 message types, 19 data types, and 87+ field paths, which is far beyond the original script’s limited coverage.
• Industrial defenders should validate broker permissions, schema enforcement, and lifecycle logging together, because protocol efficiency without control verification creates avoidable blast radius.

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.
• Publish-Subscribe Blast Radius: Publish-subscribe blast radius is the extent to which one message or one publisher can affect many recipients through a shared broker. In industrial environments, broad topic reach can turn a single malformed payload into a multi-system operational event.
• Machine Identity: The digital identity of a machine, device, or workload, such as a server, container, or VM, used to authenticate it within a network. Sometimes used interchangeably with NHI, though NHI is the broader category.

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. Explore nhimg.org for resources that connect identity governance to the broader security disciplines your programme depends on.