• United States




IoT messaging protocol is big security risk

Jul 14, 20173 mins
Cloud SecurityData and Information SecurityInternet of Things

Popular IoT messaging protocol lacks encryption and sufficient device authentication security.

wifi iot
Credit: Thinkstock

The insecure implementation of the MQTT (Message Queue Telemetry Transport) protocol, an Oasis standard for IoT communication, by many IoT product vendors is contributing to the high risk of IoT devices on enterprise and home networks.  Although TLS is recommended by the Cloud Security Alliance for secure communication with MQTT, most vendors appear to ignore transport security, making all communication open and available.  Further, authentication is often ignored.

MQTT defined 

MQTT is a lightweight protocol that connects a device to a server or other management system when messaging is required.  This makes it a good choice for networks where bandwidth use is tightly controlled.  However, the MQTT standard does not include encryption.  Vendors or businesses must add encryption as part of their solution.  In addition, while servers can authenticate devices, no mechanism exists in the Oasis standard to allow devices to authenticate servers.

The risk

A authentication issue, however, is the failure to implement any available device authentication.  An example of the risk was reported by Lucas Lundgren last year. Lundgren claimed he discovered around 60,000 IoT message brokers that allowed access without authentication (McAuley, 2017).  With the fast growth of IoT, we can assume that this number has significantly increased.  Lundgren demonstrated that he can quickly compromise hospital, prison, and satellite control systems because of insecure configuration of MQTT.

Some vendors do provide encryption for their MQTT solutions.  Also, third-party vendors provide solutions to which any IoT device can securely attach, making IoT proliferation much safer.  The problem is that owners and managers of most businesses, especially small and home businesses, don’t ask the right questions or have the budget for third-party security.

Meeting the challenges

So who is responsible for IoT security.  Ultimately, it is we security professionals who have to perform the necessary risk assessments and make the necessary controls adjustments.  But this is not a long-term solution given the use of IoT across businesses, homes, and organizations of all sizes… including those with no security teams.  I agree with the Department of Homeland Security principles (below) in its Strategic Principles for Securing the Internet of Things that it is everyone’s responsibility to meet IoT challenges:

1.     IoT developers to factor in security when a device, sensor, service, or any component of the IoT is being designed and developed

2.     IoT manufacturers to improve security for both consumer devices and vendor managed devices

3.     Service providers, that implement services through IoT devices, to consider the security of the functions offered by those IoT devices, as well as the underlying security of the infrastructure enabling these services

4.     Industrial and business-level consumers (including the federal government and critical infrastructure owners and operators) to serve as leaders in engaging manufacturers and service providers on the security of IoT devices [in other words demand security]


It would be nice to see these principles voluntarily followed, but that is unlikely to happen unless consumers and businesses demand it.  Microsoft and Adobe, for example, were largely pushed to more secure practices by consumers and bad public relations related to breaches.  I hope it doesn’t take several highly destructive events to get IoT developers, manufacturers, service providers, and users on board with IoT security.  Even if it happens in the near future, security professionals must fill the gap with education and analysis whenever IoT is included in a project. 


Tom Olzak is an information security researcher and an IT professional with more than 34 years of experience in programming, network engineering and security. He has an MBA and a CISSP certification. He is an online instructor for the University of Phoenix, facilitating 400-level security classes.

Tom has held positions as an IS director, director of infrastructure engineering, director of information security and programming manager at a variety of manufacturing, healthcare and distribution companies. Before entering the private sector, he served 10 years in the U.S. Army Military Police, with four years as a military police investigator.

Tom has written three books: Just Enough Security, Microsoft Virtualization, and Enterprise Security: A Practitioner's Guide. He is also the author of various papers on security management and has been a blogger for, TechRepublic, and Tom Olzak on Security.

The opinions expressed in this blog are those of Tom Olzak and do not necessarily represent those of IDG Communications Inc. or its parent, subsidiary or affiliated companies.