Is port 8883 (MQTT over TLS) exposed, and does encryption alone protect it?
Port 8883 is the default port for MQTT over TLS, the encrypted version of the same publish-subscribe protocol that runs in plaintext on port 1883. Encryption protects the data in transit between a client and the broker, but it says nothing about who is allowed to connect: a TLS-wrapped broker that still accepts anonymous connections is just as readable to an attacker as an unencrypted one, once they've connected.
By AdminKit team, Netbase JSC · Updated October 23, 2026
Why TLS doesn’t automatically fix MQTT’s auth gap
MQTT on port 8883 wraps the same publish-subscribe protocol that runs on 1883 in a TLS connection, encrypting the data between client and broker so it can’t be read or tampered with in transit. The OASIS MQTT 5.0 standard treats transport encryption and client authentication as two separate, independent controls — TLS on port 8883 only guarantees the first. A broker can run on 8883 with a perfectly valid TLS certificate and still accept anonymous CONNECT requests with no username or password at all, which is a common default in broker software aimed at easy setup.
What’s actually at risk
If an 8883 broker accepts anonymous connections, an attacker who finds it can subscribe to every topic and read everything being published — sensor data, camera trigger events, door-lock states — or publish messages of their own that connected devices may act on, exactly as with an unencrypted 1883 broker. The only thing TLS prevented was someone sniffing the connection in transit; it did nothing to stop someone from connecting directly and asking nicely.
How to check your own exposure
AdminKit’s MQTT exposure check tests both the plain (1883) and TLS (8883) ports and specifically checks whether the broker’s CONNACK response allows an anonymous connection, which is the detail that actually matters — not just whether the TLS handshake succeeds. Confirm your public IP first with what is my IP.
How to fix it
- Require authentication (username/password, or client certificates) on the broker regardless of which port it listens on — TLS and auth are configured separately in most broker software, and both need to be turned on.
- Disable anonymous access explicitly; most brokers ship it enabled by default for ease of first-time setup.
- Use per-client credentials or certificates rather than one shared password, so a single leaked credential doesn’t expose every device.
For the full step-by-step fix, including why anonymous access is the default in the first place, see our guide on is port 1883 (MQTT) open on my router, which covers both ports in depth.
Defensive use only
Every check this page links to is for assets you own or are explicitly authorized to test. Never scan, probe, or attempt to connect to a network or device you don’t control — AdminKit’s active checks only ever run against the IP making the request or an asset you’ve verified ownership of. See our Disclaimer and Acceptable Use Policy for the full terms.
This guide is general information, not a security audit of your specific network — see our disclaimer for what AdminKit's guidance does and does not commit to.
Frequently asked questions
If 8883 uses TLS, why would it still be a problem?
TLS encrypts the connection but doesn't by itself require a username or password — a broker can have a valid certificate and still accept anonymous connections, which is a common default aimed at easy first-time setup.
How do I know if my broker on 8883 actually requires authentication?
AdminKit's MQTT exposure check tests the broker's response to an unauthenticated CONNECT request on both port 1883 and port 8883, rather than just checking whether the TLS handshake succeeds.
Should I run 1883 or 8883 if I need remote access at all?
8883 (TLS), paired with authentication, not instead of it — plaintext 1883 should never carry credentials or sensitive topics across the open internet, and TLS alone on 8883 still needs authentication turned on to be meaningfully safer.
Does closing 1883 and only running 8883 fix the underlying issue?
No — if anonymous access is still enabled on the broker, moving to 8883 only stops someone from reading the connection in transit; they can still connect directly and read or publish to every topic.
Want AdminKit to watch this for you?
Free checks tell you the state today. Protective DNS and monitoring tell you when it changes.