Port reference
Port 8883 (TCP) – MQTT over TLS
Default port for MQTT secured with TLS, the encrypted variant of the IoT publish/subscribe protocol that runs in plaintext on 1883.
Default state
Reserved for TLS-wrapped MQTT. Encryption is in place, but brokers may still permit anonymous access, accept weak certificates, or also expose plaintext 1883, undermining the protection.
Common attacks
- Anonymous or weak-credential login despite TLS being enabled
- Downgrade to plaintext MQTT on 1883 when both ports are open
- Exploitation of weak TLS configs or missing client-certificate checks
- Topic subscription with a # wildcard once authenticated
Hardening
- Require client authentication (passwords or mutual TLS certificates)
- Disable plaintext 1883 so clients cannot be downgraded
- Use modern TLS versions and strong cipher suites; validate certificates
- Enforce per-client topic ACLs to limit subscribe/publish scope
- Bind to a private interface, firewall 8883, and keep the broker patched
nmap snippet
nmap -p8883 --script ssl-cert,mqtt-subscribe <target>Replace <target> with the host or range you're authorized to scan.
What runs on port 8883?
Port 8883 is the default for MQTT over TLS — the encrypted form of the lightweight publish/subscribe protocol used by IoT devices. It is the same MQTT spoken on plaintext 1883, but wrapped in TLS so that topics, payloads, and credentials are protected in transit. Clients connect to a central broker to publish and subscribe over an encrypted channel.
Why it matters for security
8883 exists to fix the confidentiality gap of plaintext MQTT, but TLS alone is not access control. Brokers may still allow anonymous access, accept weak certificates, or also expose plaintext 1883, letting attackers downgrade. Because MQTT carries IoT telemetry and commands, a broker that authenticates weakly still leaks data and lets attackers control devices.
How it's attacked
Attackers attempt anonymous or weak-credential logins even over TLS, then
subscribe to # to read every topic. Where both ports are open they
downgrade clients to plaintext 1883. Weak TLS configurations and missing
client-certificate checks are probed to intercept or impersonate, and control
topics are abused to actuate devices.
Hardening checklist
Require client authentication — passwords or mutual TLS certificates — and disable plaintext 1883 so clients cannot be downgraded. Use modern TLS versions and strong ciphers, and validate certificates. Enforce per-client topic ACLs, bind to a private interface, firewall 8883, and keep the broker patched. Use the nmap snippet above to check exposure on brokers you are authorized to test.
Related ports
Frequently asked questions
- How is port 8883 different from 1883?
- Port 8883 carries MQTT inside a TLS tunnel, encrypting topics, payloads, and credentials. Port 1883 is the same protocol in plaintext. Use 8883 and disable 1883 where possible.
- Does TLS on 8883 make MQTT secure by itself?
- No. TLS protects data in transit but not access control. You still need authentication, per-client topic ACLs, and strong certificate validation, or an attacker can authenticate and read or inject messages.