· 3 min read

Why Your Industrial Messaging Layer is a Supply-Chain Risk

A typical OT platform pulls in hundreds of transitive dependencies. Each one is a potential SolarWinds.

security mqtt supply-chain iec-62443

A typical OT platform pulls in hundreds of transitive dependencies, the brokers below ship with anywhere from 15 to 200+. Each one is a potential SolarWinds.

The Dependency Problem in OT Networks

Your MQTT broker sits at the heart of your operational technology network. Every message between your SCADA host and your edge nodes flows through it. Every sensor reading, every control command, every alarm.

Now ask yourself: how many third-party libraries does your broker depend on?

BrokerRuntime Dependencies
Typical C-based broker~15 (including OpenSSL)
Typical Erlang-based broker200+ packages
Typical Java-based broker150+ packages
RelayQstd-only core; a small pinned set of crates, rustls only with TLS

What Happens When OpenSSL Has a CVE

When Heartbleed hit in 2014, every system using OpenSSL was vulnerable. That included every broker deployment linked against it.

The response required:

  1. Wait for OpenSSL patch (days to weeks)
  2. Rebuild the broker against patched OpenSSL
  3. Test the new build
  4. Deploy to every broker instance
  5. Verify no regressions

For a single broker in a lab, this is annoying. For 500 brokers across 50 industrial sites, it’s a multi-week emergency.

The IEC 62443 Supply-Chain Requirement

IEC 62443-4-1 (Secure Development Lifecycle) requirements SM-9 and SM-10 mandate:

  • SM-9: Identify and document all third-party components
  • SM-10: Monitor third-party components for vulnerabilities

When the runtime has no mandatory dependencies, compliance is a short list rather than a project: RelayQ’s SBOM is generated from the lock file of the signed build, every crate in it is pinned, and the TLS stack appears only in builds that enable it. No OpenSSL, no async runtime, no framework. Your auditor will thank you.

Zero Mandatory Dependencies is a Security Architecture Decision

RelayQ doesn’t avoid dependencies because we couldn’t find good libraries. We avoid them because every dependency is:

  • An attack surface you can’t fully audit
  • A supply-chain risk you can’t fully control
  • A compliance burden you must continuously monitor
  • A potential breaking change on every update

For a component sitting in the critical path of your OT network, that’s unacceptable.

What About TLS?

TLS (via rustls) is the one optional dependency, feature-gated behind a compile-time flag. If you don’t need TLS (e.g., air-gapped network), the Lite variant leaves the whole TLS stack out of the binary.

If you do need TLS, rustls is:

  • Written in Rust (memory-safe)
  • Audited by multiple security firms
  • A single, well-understood dependency

Compare that to OpenSSL’s 500K+ lines of C.

The Bottom Line

Your IEC 62443 auditor is going to ask: “Show me the SBOM for your MQTT broker.”

Which answer do you want to give?


RelayQ is a deterministic edge runtime with a fully conformant MQTT 3.1.1 and 5.0 broker, zero mandatory dependencies (std-only core, TLS optional), and Kani/Loom verification of its core state machines. Request evaluation access →

Ready to evaluate RelayQ?

Full-featured runtime. No credit card. Direct support.

Request Evaluation Access

Not ready to talk? Start with the evidence: conformance report · benchmarks