MQTT can move industrial telemetry across network boundaries without giving every IT system direct access to control systems. That outcome depends on the architecture around the broker, clients, identity, and operations—not merely on choosing an encrypted port.
The first security question is: which components must communicate, in which direction, and for what narrowly defined purpose? Answer it before choosing a broker location or writing a firewall request. A secure collection design limits each publisher and subscriber to the connections and topic scope it actually needs.
Treat the broker as a trust boundary, not just a relay
An MQTT broker receives publications, matches subscriptions, and distributes messages. Whether and how it authenticates clients and authorizes their actions depends on the deployment. Its placement determines which systems need a route to it. It does not remove the need to protect the OT sources that publish data or the IT systems that consume it.
A common conceptual pattern is:
OT device or edge gateway
|
| authenticated MQTT connection
v
Broker in an approved OT, DMZ, or controlled service zone
|
| separately authorized subscriber connection
v
Historian collector or IT application
This is not a universal topology. A site may place a broker near sources, in an industrial DMZ, or in another approved service zone based on its threat model, available services, reliability needs, and operating ownership. The important constraint is that a subscriber in IT should connect to an approved broker endpoint; it does not need unrestricted inbound reachability to controllers or the wider OT network.
NIST’s Guide to Operational Technology Security emphasizes that OT security must account for performance, reliability, and safety as well as conventional cybersecurity risk. Use the site’s approved zone-and-conduit design, rather than copying an example broker placement into every plant.
Separate transport protection from client identity and authorization
TLS can provide confidentiality and integrity in transit and let a client validate the server certificate. It does not decide whether a connected client should publish to a command topic, read a whole site, or continue to use a compromised credential.
Build the broker connection policy in layers:
| Control | Question to answer |
|---|---|
| Server authentication | Does the client validate the expected broker certificate and hostname? |
| Client authentication | Is every gateway, collector, and application using a unique managed identity? |
| Authorization | Which exact topic patterns may that identity publish or subscribe to? |
| Network exposure | Which hosts and routes can reach the broker listener? |
| Operations | How are credentials, certificates, logs, alerts, and revocation handled? |
The MQTT specification deliberately leaves the chosen authentication and authorization technologies to the implementation and deployment. It describes security needs such as client authentication, resource authorization, message integrity, and privacy, but broker ACL syntax and enforcement are not standardized. Validate them on the deployed broker.
Use certificate validation deliberately. Accepting any certificate to make commissioning easier removes a core server-identity check. Where mutual TLS fits the site’s identity and lifecycle model, client certificates can authenticate both ends; where managed user credentials are used, protect them in transit, limit their topic scope, rotate them, and remove them promptly when a device or service is retired.
Keep publisher and subscriber permissions separate
One client identity should not receive broad rights merely because it can publish a useful telemetry stream. A gateway that publishes industrial/site-a/line-2/filler-07/telemetry may need no right to subscribe to commands. A historian collector may need to subscribe to approved telemetry patterns but should not publish to operational-control topics.
Define these permissions separately in the broker’s policy model:
- Publish: exact source branches a device or gateway is allowed to send.
- Subscribe: exact telemetry, event, or health branches a collector may receive.
- Administrative access: distinct operator identities for broker configuration, account changes, and audit access.
Avoid #-style broad access policies when a narrow topic filter can express the purpose. The hierarchy matters because it helps ACLs be readable and reviewable, but a topic design alone is not an access-control system. The broker must actually enforce the policy and log failed attempts.
Shared brokers also need ownership rules. Development, test, and production workloads should not rely on easily confused names and permissive credentials. At minimum, separate environments by endpoint, identity realm, or well-governed namespace; confirm that a test client cannot subscribe to production data through an accidental wildcard.
Manage client identities and certificates as operational assets
Give each connection a unique, traceable client identity. Reused IDs make it harder to attribute activity and can cause client-session conflicts. Associate identities with an owner, source system, allowed topic scope, credential type, expiry date, and revocation procedure.
Certificate and credential rotation needs an operational test, not just a policy. Test a new certificate before expiry, confirm the client rejects an untrusted replacement, and rehearse revoking a lost gateway credential. Keep time synchronization healthy: certificate validity, log correlation, and incident analysis all depend on usable clocks.
For TDengine TSDB Enterprise’s documented MQTT ingestion connector, the current configuration supports broker username/password and TLS verification choices including one-way server-certificate verification and mutual TLS. It also requires unique client IDs for clients connecting to the same MQTT address. These controls apply to the connector-to-broker connection; they do not define the broker’s ACL policy or secure every other path. Verify the deployed edition and version against the current MQTT ingestion documentation before relying on a specific option.
Monitor the access path and test denial cases
Logs should let an operator answer: which identity connected, from where, under which certificate or account, which subscription was granted or denied, and which publication was rejected? Correlate broker events with gateway and collector logs, but do not put secrets or full sensitive payloads into logs by default.
Test negative cases in a safe environment: a client with an expired certificate, a publisher attempting an unauthorized topic, a collector requesting an overbroad subscription, and a connection from an unapproved network path. Confirm that the failure is denied, logged, and alerted according to the operating procedure.
For systems collecting industrial history in TDengine TSDB, this design keeps the data route intentional: sources publish only to an approved broker path, collectors authenticate separately, and the historian receives only the data it is authorized to ingest. TLS is an important layer, but the secure outcome comes from the combined design of network exposure, identity, topic authorization, lifecycle management, and monitoring.
