MQTT connects devices and applications through topics, sessions, and often a long-lived network relationship. A broker observation can identify where to begin an inventory, but it cannot tell a team which topics are readable or whether a device is authorized to publish commands. Those questions need the broker configuration and controlled clients.
The observed query
This measurement used the Mosquitto application fingerprint:
app="Mosquitto"
The query used sub_type=all, page 1, and pagesize=1. At 20:40:11 UTC on 28 October 2026, ZoomEye returned 1,176,535 matching records. This is a broad record count, not a count of anonymous brokers, unique deployments, or vulnerable devices.
Mosquitto is one implementation of MQTT. A matching product record should be connected to the organization's broker inventory and to the application or device fleet that relies on it. The query does not prove which MQTT version, authentication method, or ACL configuration is in use.
Map listeners and identities
Identify every listener, including TLS, WebSocket, internal bridges, and test endpoints. Record the certificate issuer and the authentication mechanism for each. Distinguish device identities from operator identities and from the application services that publish or consume messages.
MQTT 5.0 describes post-connect authorization for publication topics and subscription filters. It also highlights the risk of broad topic filters such as #. Review the broker's actual policy rather than assuming a valid username grants access to the whole hierarchy.
Test topic boundaries with a harmless payload
Use an isolated broker and non-production topics. Connect as a device, a tenant dashboard, and an operator. Confirm that the device can publish only to its permitted topic and cannot subscribe to another tenant. Confirm that a dashboard cannot publish control messages. Check whether a new client can reuse a stale client identifier and affect session state.
Record the allow and deny results with the identity and topic involved. Do not publish to a topic on an unknown public broker, and do not test a real control command. The goal is to verify authorization, not to demonstrate impact.
Treat bridge and retained state as data flows
A bridge can aggregate many topics under one connection. Its permissions may be broader than an individual device. Review bridge routes and credentials, and restrict which upstream topics may cross the boundary.
Retained messages and last-will messages can also carry state into a later session. Check that a new device cannot receive a command or configuration value intended for an earlier deployment. Apply tenant and topic rules consistently to live, retained, and will messages.
Use the measurement as an inventory trigger
Compare owned ZoomEye matches with DNS, cloud, and device records. A new match may be a test broker or an application that was never added to the inventory. A missing match may reflect a firewall change or a fingerprint change, not automatically a remediation.
ZoomEye supplies a broad external starting point for finding MQTT services. The broker owner supplies the evidence that matters for authorization: which identity connects, which topics it may use, and whether the session and bridge state obey the same policy. That sequence keeps discovery useful and keeps an observed service from being mislabeled as a confirmed exposure.