MQTTS: Secure MQTT over TLS for Industrial IoT

MQTTS describes an MQTT connection wrapped in TLS encryption, typically running on port 8883 with the mqtts:// URI prefix. The term is shorthand for “MQTT over TLS”, which the OASIS specification prefers.

For IIoT operators, MQTTS has become the new baseline. Plain-text MQTT is increasingly hard to justify, both technically and under regulations such as NIS2, the EU Data Act and the Cyber Resilience Act.

MQTTS: Key takeaways

• MQTTS is an MQTT connection secured by TLS, encrypting credentials, topics and payloads in transit. The mqtts:// URI prefix tells the client library to negotiate TLS before any MQTT packet leaves the socket.
• The IANA-registered MQTTS port is 8883. Port 443 carries MQTTS over WebSockets through restrictive firewalls. Port 1883 is conventionally used for plain-text MQTT and should be disabled for production traffic.
• NIS2, the EU Data Act and the Cyber Resilience Act increasingly require appropriate security measures for industrial entities operating in the EU.
• Pro Mosquitto builds on the MQTTS and mutual-TLS support already in open-source Eclipse Mosquitto and adds the enterprise layer for production: RBAC, audit trails, certificate management with custom CAs, the Cedalo Management Center, and high-availability and high-performance clustering.

What does MQTTS mean and how does it differ from MQTT?

MQTTS is an MQTT connection secured by Transport Layer Security (TLS). The client sends every CONNECT, PUBLISH, SUBSCRIBE and PINGREQ packet through an encrypted TLS tunnel, so a network attacker sees ciphertext instead of broker credentials, topic names and payloads. The MQTT protocol itself stays identical to MQTT 3.1.1 or MQTT 5.0. Only the transport layer changes.

The shift from “MQTTS” to “MQTT over TLS” in the official OASIS specification reflects exactly that point. MQTT is a protocol; TLS is the transport security underneath it. Client libraries such as paho, mosquitto_pub, the Node.js mqtt package and the ESP-IDF MQTT client keep the mqtts:// URI prefix as a practical shorthand. When you point a client at mqtts://broker.example.com:8883, the library opens a TLS socket first, completes the handshake and only then starts speaking MQTT.

A useful mental model: MQTT relates to MQTTS the way HTTP relates to HTTPS. Same application protocol, encrypted transport.

Figure 1: Plain MQTT versus MQTTS. On port 1883 credentials, topics and payloads travel in the clear. On port 8883 a TLS tunnel encrypts the entire MQTT packet and the broker proves its identity with an X.509 certificate.

When should you use MQTTS port 8883, 443 or 1883?

Use port 8883 for direct MQTTS connections, port 443 when traffic has to cross corporate firewalls or browser environments, and never use port 1883 in production. Port 1883 is the original MQTT port and is normally used for plaintext MQTT rather than TLS-protected traffic. Choosing the right MQTTS port shapes how brokers, clients and network policies cooperate.

Port 8883 is the IANA-registered standard for secure MQTT

Port 8883 is registered with IANA as “secure-mqtt”. Eclipse Mosquitto, Pro Mosquitto and effectively every managed IoT broker default to 8883 for encrypted traffic. The transport is direct TLS over TCP with no extra encapsulation, which keeps latency low and the configuration straightforward. For any greenfield IIoT deployment, 8883 is the right starting point.

Port 443 carries MQTT over secure WebSockets for firewalled networks

Port 443 commonly carries MQTT packets inside WebSocket frames over TLS. The extra encapsulation costs a few bytes per packet, but the trade-off is worth it whenever corporate firewalls block 8883 outbound, a common pattern in OT networks behind strict egress filtering. Browser-based MQTT clients usually rely on WebSockets because browsers do not expose raw TCP sockets; port 443 is the most practical transport in many environments.

Why port 1883 stays plaintext and why you still close it

Port 1883 carries plaintext MQTT. Anyone on the network sees credentials, topic structures and payloads in the clear. Leaving 1883 open even for “internal” traffic is risky because of VLAN hops, container egress and lateral movement after an OT breach. The safer pattern binds 1883 only to localhost during local development and drops the listener entirely in production. Mosquitto and Pro Mosquitto support per-listener configuration, so you can run MQTTS on 8883 and keep 1883 fully disabled.

MQTTS port comparison at a glance

How does MQTTS work?

MQTTS works by performing a TLS handshake before any MQTT CONNECT packet leaves the client. The client and broker negotiate a TLS version and cipher suite, the broker presents its certificate (and, for mTLS, the client presents one too), both sides derive symmetric session keys, and only then do they start exchanging encrypted MQTT traffic. The handshake takes one to two round trips depending on the TLS version, after which throughput approaches plain TCP.

The TLS handshake step by step

The steps below describe a TLS 1.2 handshake. In TLS 1.3 the client already includes its key share in the ClientHello and the server certificate is sent encrypted, which collapses the exchange to a single round trip.

1. The client opens with a ClientHello, the first handshake message, which advertises the TLS versions and cipher suites the client supports.
2. The broker responds with a ServerHello, its X.509 certificate and, for mTLS, a CertificateRequest.
3. The client validates the broker certificate against trusted CAs and verifies the hostname.
4. Both sides perform the key exchange (ECDHE in TLS 1.2, simplified to a single RTT in TLS 1.3).
5. Both sides switch to encrypted records and the client sends the MQTT CONNECT packet.

Figure 2: A TLS 1.2 handshake on port 8883. The client and broker agree on a TLS version and cipher suite, the broker proves its identity with an X.509 certificate, both sides derive session keys, and only then does the encrypted MQTT CONNECT travel across the wire. TLS 1.3 collapses this to a single round trip.

Server-only TLS vs. mutual TLS

With server-only TLS, the broker proves its identity through a CA-signed certificate. The client trusts the broker, and the broker still authenticates the client through username and password inside the MQTT CONNECT packet.

Mutual TLS (mTLS) adds a second certificate exchange. The broker requests a client certificate, validates it and accepts the CONNECT packet only if the certificate chains back to an approved internal CA. mTLS can replace password-based authentication and is common in high-security OT environments and Zero Trust architectures.

Why TLS 1.3 matters for MQTT brokers

TLS 1.3 reduces the handshake to a single round trip, removes legacy cipher suites and enforces forward secrecy by default. For battery-powered IoT devices that reconnect frequently, the savings in latency and energy are tangible. Pro Mosquitto and the Eclipse Mosquitto 2.x line support TLS 1.3 natively. Older brokers limited to TLS 1.2 need careful cipher configuration to avoid legacy options.

Cipher suites and certificate authorities for IoT deployments

Prefer AEAD ciphers such as ECDHE-ECDSA-AES256-GCM-SHA384 in TLS 1.2 or TLS_AES_128_GCM_SHA256 in TLS 1.3. Use ECDSA P-256 certificates over RSA-2048 wherever firmware allows, because the smaller payload and faster signature operations matter on constrained devices. For OT environments, run an internal PKI with an offline root and short-lived device certificates. For cloud-facing brokers, a public CA with ACME automation is a workable path.

Why is MQTTS now a practical security baseline under NIS2, Data Act and CRA?

MQTTS is now a practical baseline for many operators of essential and important entities in the EU. The NIS2 Directive, the EU Data Act and the Cyber Resilience Act require appropriate technical and organisational measures to protect relevant data and systems. Plain MQTT may no longer meet security expectations for essential and important entities when it carries sensitive or operational data.

NIS2 Directive obligates cryptography for industrial operators

EU member states had to transpose the NIS2 Directive (Directive (EU) 2022/2555) into national law by 17 October 2024. Article 21 requires “policies and procedures regarding the use of cryptography and, where appropriate, encryption” for all essential and important entities. Manufacturing, energy, transport, water and digital infrastructure operators fall in scope. Running an unencrypted MQTT broker that carries production telemetry can become a documentable compliance risk.

EU Data Act demands secure data sharing between industrial systems

The EU Data Act (Regulation (EU) 2023/2854) applies from September 2025 and governs how connected products and related services share data. The Data Act requires appropriate safeguards for data access and sharing. Article 32 specifically addresses protection against unlawful third-country government access to non-personal data. MQTTS with TLS 1.3 and mTLS for partner connections has become the practical baseline.

Cyber Resilience Act enforces security by default for connected products

The Cyber Resilience Act (Regulation (EU) 2024/2847) entered into force in December 2024 and applies fully from December 2027. Annex I requires that products with digital elements ship secure by default and protect the confidentiality of stored and transmitted data through state-of-the-art mechanisms. Devices that ship with plain MQTT enabled by default may face CRA compliance issues if relevant transmitted data is not adequately protected.

IEC 62443 and ISO/IEC 27001 reinforce MQTTS as the baseline

IEC 62443-3-3 System Requirement SR 4.1 addresses confidentiality of information in transit, especially where risk assessments require protection across zones. ISO/IEC 27001:2022 Annex A 8.24 requires rules for the effective use of cryptography in line with business, legal and security requirements. Auditors increasingly check broker listener configurations and certificate inventories during ISO 27001 certifications.

How do you configure MQTTS in Mosquitto, paho and cloud brokers?

You configure MQTTS by adding a TLS listener on port 8883 to your broker, loading a server certificate and private key, and pointing your clients at the mqtts:// URI with the matching CA bundle. The setup takes only a few minutes for a single broker and longer for a fleet with mutual TLS.

Setting up an MQTTS listener in Mosquitto

A few lines turn a Mosquitto broker into an MQTTS broker. Append the following to mosquitto.conf:

listener 8883
certfile /etc/mosquitto/certs/server.crt
keyfile /etc/mosquitto/certs/server.key
cafile /etc/mosquitto/ca/ca.crt
require_certificate false

Set require_certificate true and use_identity_as_username true when you want mutual TLS. Restart Mosquitto and verify with mosquitto_sub -h broker.example.com -p 8883 --cafile ca.crt -t test/#. Combine this with the patterns from the Mosquitto Docker configuration guide when you run the broker in containers.

Connecting paho-mqtt clients over TLS

The paho Python client picks up TLS through the tls_set() method:

import paho.mqtt.client as mqtt
import ssl

# paho-mqtt 2.x requires the callback API version as the first argument
client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id="plant-edge-01")

client.tls_set(
    ca_certs="/etc/ssl/ca.crt",
    certfile="/etc/ssl/client.crt",   # mTLS only
    keyfile="/etc/ssl/client.key",    # mTLS only
    tls_version=ssl.PROTOCOL_TLS_CLIENT,  # negotiates up to TLS 1.3
)

client.username_pw_set("plant-edge-01", "secret")
client.connect("broker.example.com", 8883, 60)

Pair TLS with the broker-side policies described in the MQTT authentication and authorization guide to lock down topic-level access for each client.

Running MQTTS on managed and cloud-hosted brokers

Managed cloud brokers generally require TLS-protected connections and do not expose plain MQTT on port 1883, so 8883 (or 443 for firewalled and browser clients) is the norm rather than the exception. The practical work is the same everywhere: load a server certificate and private key, point clients at the mqtts:// URI with the matching CA bundle, and enable client-certificate authentication where the trust model calls for it.

How do you scale MQTTS in enterprise architectures?

You scale MQTTS by separating certificate lifecycle, broker topology and TLS performance into three distinct engineering tracks. A single-broker MQTTS setup works well until certificate lifecycle management and multiple environments turn manual handling into a liability. Enterprise scale then needs PKI automation, broker clustering and TLS-aware load balancing.

Certificate lifecycle management at scale

Manual certificate handling fails at the second renewal cycle. For fleets above 100 devices, automate the full lifecycle. Stand up an internal PKI with an offline root and online intermediates. Issue device certificates via SCEP, EST or ACME through an automated certificate authority.

Rotate certificates on a fixed schedule, around 90 days for clients and 12 months for brokers. Monitor expiry through Prometheus exporters tied into your MQTT monitoring stack. Build CRL or OCSP distribution so revoked certificates lose access within minutes rather than at the next rotation window.

Hybrid edge-to-cloud deployments with broker bridges and clustering

Production fleets rarely live on one broker. The standard pattern places edge brokers near the OT zone, bridges them via MQTTS to a central broker cluster in the cloud and feeds downstream IT systems from the cluster. Each hop uses its own certificate set, so a compromised edge broker cannot impersonate the cloud cluster. For high-volume environments, the enterprise MQTT broker needs to support native clustering, store-and-forward queueing that rides out bridge outages, and shared subscriptions for load balancing.

Figure 3: A hybrid edge-to-cloud MQTTS architecture. Edge brokers sit near the OT zone and bridge over MQTTS (port 8883) to a broker cluster in the cloud, which feeds downstream systems. A central PKI issues the X.509 certificates that secure every hop, so each connection is independently authenticated.

Avoiding TLS performance pitfalls

A single TLS handshake is cheap on its own, but the asymmetric key operations add measurable CPU cost that only becomes visible at scale, for example when tens of thousands of devices reconnect per minute. Four levers reduce the cost. Enable TLS session resumption with session tickets so reconnecting clients skip the full handshake. Move to TLS 1.3 to drop one round trip.

Consider terminating TLS on a dedicated HAProxy or NGINX layer in front of the MQTT broker cluster where this fits the trust and network model. Use ECDSA P-256 certificates instead of RSA-2048 for smaller payloads and faster signature operations.

Security by design as layered defense for production brokers

MQTTS only covers the transport layer. A production-ready broker setup combines it with strong identity through mTLS or short-lived JWTs instead of static passwords, fine-grained ACLs per topic and per client, audit trails for every connect, subscribe and publish retained for the period your compliance framework demands, network segmentation so the broker sits behind a dedicated firewall zone with explicit allow-lists, and regular penetration tests targeting the broker config, certificate chain and authentication flow.

How does Cedalo secure MQTTS at enterprise scale?

We build Pro Mosquitto on the same Eclipse Mosquitto foundation that has surpassed 600M+ Docker pulls worldwide. On top of the TLS and mutual-TLS support already in open-source Mosquitto, the enterprise edition adds RBAC, audit trails, the Cedalo Management Center, and both high-availability and high-performance clustering for production deployments.

For teams that already trust Mosquitto for prototypes, Pro Mosquitto removes the manual work of running a compliant MQTT broker in production.

MQTTS: Frequently Asked Questions

Does MQTTS encrypt MQTT topic names?

Yes, MQTTS encrypts the full MQTT packet including topic names, payload, client ID, username and password. A network observer sees only TLS records, never the topic structures or business data underneath. Topic hierarchies that reveal internal plant architecture stay private as long as the TLS session holds.

How much bandwidth overhead does MQTTS add compared to plain MQTT?

The initial TLS handshake adds a few kilobytes, mostly from the certificate chain (smaller with ECDSA certificates, larger with full RSA-2048 chains). After that, each TLS record adds roughly 20 to 40 bytes of framing. For small telemetry payloads this can be a large relative overhead; for larger messages it is negligible. TLS session resumption keeps the per-reconnect cost low on constrained networks.

Can I use self-signed certificates for MQTTS in production?

Self-signed MQTTS certificates work in test environments. In production they can create audit risks unless they are part of a documented and trusted internal PKI. Use certificates from a public CA for cloud-facing brokers or an internal PKI with a documented root CA for OT environments.

What happens when an MQTTS certificate expires?

Clients normally reject new TLS handshakes once the broker certificate has expired, so reconnects can fail and telemetry may stop after disconnections. Production fleets stop publishing telemetry, dashboards go dark and alarms fire. Automated rotation through ACME or an internal PKI greatly reduces the risk of this outage.

Does Cedalo Pro Mosquitto support MQTTS clustering across multiple data centers?

Yes. Pro Mosquitto offers two clustering modes. High Availability runs active-passive: one node serves traffic while standby nodes take over on failover, synchronizing broker state via the RAFT protocol. High Performance Clustering runs active-active: all nodes accept client connections at once, so a single logical broker scales to millions of concurrent clients. Both modes secure their inter-node and bridge links with MQTTS, though guaranteeing every subscription across geographically separate data centers still depends on your latency and topology constraints.

Can the Cedalo Management Center automate MQTTS certificate rotation?

The Cedalo Management Center handles certificate management with custom CAs, alongside users, access policies, audit logs and security events. Automated rotation itself is typically driven by an external PKI (via ACME, EST or SCEP), with the Management Center handling the broker-side certificate configuration.