Open / standardized
MQTT
A lightweight publish/subscribe protocol used heavily for industrial telemetry, often with the Sparkplug B specification to add a standard topic namespace and state management.
1883/TCP (plain), 8883/TCP (TLS)TCPEncryption: Optional
How it works
Clients connect to a broker, publish to topics and subscribe to topic filters; the broker performs routing and retains state per the QoS level.
Communication patternEdge publisher → broker → SCADA / cloud subscriber.
Fact sheet
TransportTCP
Ports1883/TCP (plain), 8883/TCP (TLS)
AuthenticationOptional
PurdueLevel 3.5 and above
EnvironmentsIIoT telemetry, Edge to cloud, Remote sites
DevicesIIoT gateway, Edge device, Broker, SCADA (Sparkplug B)
IndustriesOil & Gas, Water / Wastewater, Manufacturing
Why should I care?
Understanding MQTT is what lets you tell a routine poll from a process-affecting command. Detection here depends on knowing which peers, function codes and timings are normal for your plant.
Key functions and operations
- Connect
- Publish
- Subscribe
- Will messages
- Retained messages
Security concerns
- Anonymous brokers on 1883/TCP are commonly found exposed to the internet
- Topic-level authorisation is frequently unimplemented
- Write-capable command topics can reach control systems if bridged inward
What normal looks like
- TLS on 8883 with per-client credentials
- Stable client IDs and topic sets
What deserves attention
- New client ID subscribing to wildcard topics
- Plaintext 1883 sessions
- Inbound command topics from unexpected sources
Hunting ideas
- unexpected-internet-connectivity
- historian-data-exfiltration
Defensive controls
- TLS plus per-client credentials and topic ACLs
- Outbound-only data flow from OT where possible
- Broker in the DMZ, not in the control zone
Related ATT&CK for ICS techniques
T0885T0811
Sources & further reading