All that said, it is important to note that many of MQTT’s advantages can also create vulnerabilities. Being lightweight with bi-directional communication and the ability to scale to millions of devices with minimal security means MQTT creates cyber vulnerabilities, which is one of the top reasons it is not adopted.
While traditional machine-to-machine (M2M) communication features an endpoint that requests data from a server, and the server sends the data to the endpoint, MQTT works on a publish and subscribe model by separating the message sender (the publisher) from the message receiver (the subscriber). In the middle is a message broker, moving the messages between all of the publishers and subscribers. Think of the message broker as the kid in the middle of the class that was told to pass the notes from one student to another and back – publisher to broker to subscriber, and back.
Here is where it gets interesting: Unlike traditional systems, where the network is paramount, with MQTT, it is not. The broker combines networks that are unaware of each other's network (space), inconsistent network connectivity (time), or network collisions due to too much network traffic at either the publisher or subscriber (synchronization).
Like the kid in class, MQTT just waits until the recipient is listening to pass the note.
Why it Matters: Open Architecture
“Open Architecture” is a term thrown around by many manufacturers and software developers in the security industry, and to be frank, many legacy security companies seem very fearful of this term.
To legacy players, open architecture means losing market share. From the integrator, consultant, and end-customer standpoint, “open” typically increases their willingness to adopt that company's technology. Companies have built platforms; now it is time for platforms to be more open.
How did we get here? Why weren’t technologies “open” to begin with?
If you’ve ever wondered why systems break every time an update comes out, it is because for years, the security industry has relied on software development kits (SDKs) or Application Programming Interfaces (APIs) to communicate and integrate. These methods require deliberate action, engineering costs, and typically, a hefty fee for the convenience of communicating with the other company's software. If you want an integration certified, meaning that the primary software will support the integration, there may be an additional fee.
Here's the thing: Most of the data being requested or used between security systems is contained in small packets relaying messages back and forth – for example, system B monitors system A for a change so that system B can do something about it. In this sense, there is no need for integration if the two systems could freely communicate back and forth.
This is the exact reason MQTT was invented.
MQTT does not remove the need for SDKs, APIs, or certified integrations; however, it does give a way for companies looking to communicate “openly” across technologies for security and smart buildings.
MQTT has made its way into the security industry over the last three or four years, and finally, security manufacturers and software developers are beginning to look at MQTT as a pathway for interoperability.
So far, software developers in access control, IoT, telemetry, fleet management, smart cities, along with ONVIF Profile T (streaming video), and BACNet (Building Automation and Control and HVAC), are leading the way to MQTT adoption.
In the end, MQTT is poised to open a pathway for technologies and software to be able to communicate – not simply integrate – with a vast number of systems with minimal breakage. This will enable integrators and consultants, and ultimately end-users, to find a viable path to “open.”
