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?
| Broker | Runtime Dependencies |
|---|---|
| Typical C-based broker | ~15 (including OpenSSL) |
| Typical Erlang-based broker | 200+ packages |
| Typical Java-based broker | 150+ packages |
| RelayQ | std-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:
- Wait for OpenSSL patch (days to weeks)
- Rebuild the broker against patched OpenSSL
- Test the new build
- Deploy to every broker instance
- 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 AccessNot ready to talk? Start with the evidence: conformance report · benchmarks