Both protocols give you security features, and neither makes you use them. MQTT 5.0 says implementations should offer authentication, authorization and secure communication options. OPC UA lists authentication, authorization, confidentiality, integrity and more as security objectives. In both cases, the protection depends on how you deploy it.
MQTT 5.0
Section 1.6 of the MQTT 5.0 specification says implementations SHOULD offer authentication, authorization and secure communication options, such as those in Chapter 5. It adds that applications handling critical infrastructure or personal data are strongly advised to use them.
Chapter 5 includes sections on authentication of clients by the server, authorization of clients by the server, authentication of the server by the client, integrity of application messages and control packets, and privacy of messages and control packets. It also has profiles for secured network communication and secured transport.
Note the word SHOULD. A broker can be compliant and still accept anonymous connections. For a robot fleet publishing telemetry or receiving commands, check these on your broker:
- Clients must authenticate, and each robot has its own credential.
- The server is authenticated by the client, so a robot does not send data to an impostor.
- Authorization limits each client to its own topics. A robot should not be able to publish to another robot's command topic.
- Traffic is protected in transit.
This post does not cover the contents of Chapter 5 in detail, so read it before you design.
OPC UA
The OPC UA specification, Part 2, lists these security objectives: authentication, authorization, confidentiality, integrity, non-repudiation, auditability, availability and perfect forward secrecy.
The list is a useful checklist for a review. Ask of each connection between a robot, a controller and a supervisory system which of these is provided, by what setting, and whether it is turned on. Auditability and non-repudiation deserve attention in plants, because they affect your ability to reconstruct who changed what.
How to review a deployment
- Draw the connections between devices, brokers and servers.
- For each, write down the authentication method and whether traffic is protected.
- Look for shared credentials across many devices.
- Look for permissive defaults left from a proof of concept.
- Record certificate or key lifetimes and who renews them.
What the specifications cannot do
A protocol cannot protect a host with weak passwords, an exposed management interface or an unpatched operating system. It also cannot fix a flat network. Combine protocol security with the segmentation and access controls in CISA primary mitigations.
Testing what you built
After configuration, test as an attacker would. Try to connect without credentials. Try to subscribe to a wildcard topic. Try to publish to a topic that belongs to another device. For OPC UA, check which security modes the server offers and whether it accepts the weakest one. Record the results and rerun the tests after each upgrade, because a configuration change can quietly reopen what you closed.
Quick check
Is MQTT insecure?
The specification describes security options and advises using them for critical infrastructure. Whether a given broker is secure depends on its configuration.
Does OPC UA guarantee a secure connection?
It defines security objectives and mechanisms. A deployment can still be misconfigured, so verify what is enabled.
Sources
Last reviewed: 19 October 2026.
