Notifications
Clear all
Topic starter
11/08/2026 3:18 pm
TL;DR: Malformed-traffic testing in the MQTT-based protocol used across ICS and SCADA can now cover all 9 message types, 19 data types, and 87+ field paths, turning it into something operators can apply before broken parsing or state handling becomes a plant-floor problem, according to Bishop Fox. For IAM and OT defenders, the point is not the tool itself but the control gap: publish-subscribe trust, broker permissions, and protocol validation still determine blast radius.
NHIMG editorial — based on content published by Bishop Fox: Sparkplug B fuzzing for industrial control systems and SCADA
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.
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
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
👉 Read Bishop Fox's analysis of Sparkplug B fuzzing in industrial control systems →
Sparkplug B fuzzing in ICS environments: what security teams need now?
Explore further
11/08/2026 3:30 pm
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.
A question worth separating out:
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.
👉 Read our full editorial: Sparkplug B fuzzing exposes protocol gaps in industrial control systems
