Wednesday 10th December 2025
Summary
In keeping with Lucid’s aim to use commonly available standards, the protocol provides security through TLS. This article reviews the options for security and future plans for additions to the security model.
This article describes the current state of play with security in Lucid version 3. It also then addresses possible future extensions to improve the security of the protocol, the reasons why the Lucid team are thinking about them and what form they may take.
The Lucid Protocol Specification (version 3, which is available here) describes the security it offers in Section 8. This article reviews the information in that section and adds a little background.
The protocol defines six levels of security:
The levels of security that a Field Device supports are published in its Device Profile as a list. As of Lucid version 3, the security level used by the Field Device is not selectable within its configuration. As the Field Device acts as the client in the connection to the broker, it can decide whether to use no encryption (Level 0) or some form of TLS (Levels 1-4) in the connection. In the latter case the type of TLS used will be dictated by the TLS Handshake, which is something the Field Device can control when publishing its capabilities in the handshake.
Level 0 (no encryption) could be appropriate when using a fully trusted network. Such unsecured use of the protocol should be a decision for the security staff to make at the organisation implementing the system.
TLS is a well-known standard for IP connections and therefore compatible with MQTT connections (which form the basis of Lucid). The selection of TLS is also in keeping with the aims of Lucid; that it tries to leverage existing open standards which have accessible libraries, in turn minimising barriers for vendors when implementing the protocol. From the security perspective, utilising a pre-existing software stack which has been tried and tested is more likely to be secure than a vendor writing their own implementation.
The following table, presents a high-level overview of what the security in the different levels of Lucid equate to in terms of CIA (Confidentiality, Integrity and Availability), encryption and authentication.

The table lists the 6 different levels within Lucid by their number and name. The “Confidentiality”, “Integrity” and “Availability” columns provide an indication of how strongly the level in Lucid provides that feature. As “Availability” is largely a function of the method of implementation of hardware and software the Lucid protocol has little bearing on the and so “Availability” is marked as “Not Applicable”.
The table also shows whether each level supports encryption and whether authentication is provided. Where “Authentication” is marked as “Single”, this means that the trust is not mutual as only one of the parties is able to definitely trust the other. The following list summarises how security increases from Level 0 (giving the least security) up to Level 5 (which gives the most security):
As the level of security increases, so does the effort required to implement that level of security. At Level 0 there is no effort required but you get no security! Level 5 is the hardest to implement but offers the highest level of security. It is important that users of the protocol assess the various levels against their security requirements and select the most appropriate level for use.
As of version 3 of Lucid, the security provided is based entirely on TLS, and, more specifically, on TLS version 1.2 or greater. Lucid Levels 1 to 4 (as listed above) provide TLS security as follows:
So how exactly does Lucid use TLS? You may be most familiar with the common use of TLS to secure access to websites which have a URL starting with “HTTPS” – for example, when buying something from an online retailer. In this case, you chose to navigate to the retailer’s website on a port which says “I want a secure connection”. This happens because you or the browser have added the S to HTTP to give HTTPS; conventionally HTTP connects on port 80 whilst HTTPS connects on port 443.
A TLS handshake between the client (your browser) and the server (the retailer’s web server) causes the server to send its certificate to the client. The certificate is a digital document which proves that the server is who they say they are, through digital signatures from other trusted bodies. The client (your browser) then checks the certificate to ensure it can trust the server, and if all is OK, the TLS connection continues and you go ahead and browse the retailer’s site.
Lucid Level 2 security (TLS encryption with Broker Authentication) uses the same mode of TLS and is one of the options for using TLS with Lucid.
TLS only secures a link between a client and a server. In Lucid, either the Field Device or Supervisory Application can act as a client, whilst the MQTT broker always acts as a server. Therefore, TLS only secures the link between the Field Device and MQTT broker or Supervisory Application and MQTT broker, as shown in the following figure where independent TLS sessions are shown for each link.

Whether the Field Device to MQTT Broker connection or the Supervisory Application to MQTT Broker connection are protected with TLS is a policy decision for an organisation. As the two connections are independent (due to the asynchronous nature of MQTT), none, one or both connections could be secured using any of Lucid Levels 1 to 4.
One outcome of this is that the broker will have access to, and possibly store, the unencrypted data being sent between the Field Device and Supervisory Application; the broker is aware of the contents of every message. Care should therefore be taken to secure the broker. If using Lucid Level 2 or 4 security, then the MQTT broker will also need its own signed certificate.
Level 5 security within version 3 of the Lucid is only a proposal. The details of this level are not included within the protocol specification and are expected to be added in a future version; therefore, vendors will not be able to implement this in version 3.
Level 5 is intended to provide end-to-end encryption between the Field Device and Supervisory Application. This would mean that, although the broker would be aware of traffic in the various topics, it would not know the contents of the messages being sent. Work is still underway to determine exactly how this will work. It will likely require certificates to be shared and managed, so some form of Certificate Authority architecture and management would have to be put in place by users.
This article has taken a quick dip into the security provisions of Lucid. Lucid can be deployed with no security or using a variety of modes within TLS. However, the most capable mode of TLS (Lucid Level 4 security) with a fully mutually authenticated TLS mode, provides the strongest security guarantee. Who wouldn’t want that!
Mark Davison (Terzo Digital) and Dave Howarth (NWL)
December 2025
Terzo Digital and NWL have collaborated on a number of articles about Lucid in support of the protocol. You find find a list of those articles with a brief summary of their contents here.
Articles · 8 minutes
Articles · 4 minutes
Articles · 4 minutes
Articles · 12 minutes
Articles · 7 minutes
Articles · 5 minutes
Articles · 4 minutes
Articles · 6 minutes
Lucid is a free, open source protocol that bridges a gap between Operational Technology (OT) and IoT technology.