TLS

What is TLS?

TLS (Transport Layer Security) is a cryptographic protocol that protects a connection between two applications over a network by encrypting the data, verifying the identity of the other party with certificates and detecting any modification in transit. TLS is the successor to SSL (Secure Sockets Layer) and underpins HTTPS, secure email (SMTP, IMAP, POP3), many VPNs and a growing number of industrial protocols. In OT, TLS protects traffic between SCADA, HMIs, edge devices and the cloud, for example.

🧠 What exactly does TLS protect?

TLS provides three security properties for data in transit:

• Confidentiality (encryption) - data is unreadable to anyone eavesdropping on the traffic
• Authentication - the client uses an X.509 certificate to verify who it is talking to; with mutual TLS the server also verifies the client
• Integrity - any change or tampering with transmitted data is detected, which makes a man-in-the-middle attack or replay attack much harder

TLS only protects the connection itself. Data stored on a server or PLC is outside its scope, and TLS says nothing about what an authenticated party is then allowed to do; that requires authorisation and access control.

🕰️ Which versions of SSL and TLS exist?

TLS runs on top of TCP, between the transport and application layers of the OSI model; for UDP there is the DTLS variant. Over thirty years the protocol has been renewed several times:

TLS 1.3 was a major clean-up: weak algorithms such as RC4, CBC mode and static RSA key exchange were removed and the handshake needs only a single round trip. Every full handshake also uses short-lived keys, so forward secrecy is guaranteed. The term “SSL” lives on in “SSL certificate” and “SSL VPN”, but technically it almost always means TLS.

⚙️ How does the TLS handshake work?

Before any application data flows, client and server perform a handshake. In TLS 1.3 it works like this:

1. ClientHello - the client sends its supported versions and cipher suites, plus a key share for the key exchange straight away (usually ECDHE with X25519, and already hybrid X25519MLKEM768 in modern browsers)
2. ServerHello - the server chooses the parameters and returns its own key share; both sides now derive the same session keys
3. Certificate and proof - the server sends its certificate chain and proves with a digital signature that it holds the private key
4. Validation - the client checks the chain up to a trusted root CA, the validity period and the server name
5. Encrypted session - all further data travels encrypted and integrity-protected over the connection

By default only the server presents a certificate. With mutual TLS (mTLS) the server also requests a client certificate, so both sides prove their identity. This is common in OT for machine-to-machine traffic, because there is no user to type a password. TLS 1.3 also offers a 0-RTT mode for resumed sessions; it is vulnerable to replay and should therefore never carry commands that control a process.

🔐 What role do certificates and cipher suites play?

A certificate binds a public key to an identity and is signed by a certificate authority (CA). On the internet a browser trusts public CAs; in a plant you usually work with your own private CA in a PKI. Self-signed certificates are not cryptographically weaker, but every client has to trust each one individually, which becomes unmanageable across hundreds of devices.

A cipher suite defines which algorithms a session uses. The Dutch TLS security guidelines from the NCSC, first published in 2014 and updated in version 2025-05, rate settings as good, sufficient, to be phased out or insufficient:

Managing all these certificates, from issuance and renewal to revocation, is covered in Certificate Management.

🏭 How is TLS used in OT environments?

TLS is increasingly built into industrial protocols, although its exact role differs per protocol:

A common mistake is to assume that OPC UA means “OPC UA over TLS”. The binary protocol on port 4840 has its own certificate-based security layer; TLS only comes into play with the HTTPS and WebSocket variants. Brokers such as Mosquitto support TLS out of the box, but it is by no means always switched on.

⚠️ What challenges does TLS face in OT?

• Expired certificates - many devices ship with a certificate that expires after a few years. If a client then refuses the connection, process data disappears without any attack taking place.
• Incorrect time - certificate validation requires a reliable clock. Without NTP or PTP, a valid certificate can appear expired or not yet valid.
• Legacy equipment - older PLCs and HMIs support only TLS 1.0 or no TLS at all. Place a gateway or proxy in front of them and compensate with network segmentation.
• Limited processing power - small embedded controllers struggle with RSA-4096; ECDSA and hardware crypto, for example via a Trusted Platform Module, help.
• Network visibility - encrypted traffic makes deep packet inspection by an industrial firewall or IDS harder; plan monitoring at the endpoints or through TLS inspection.
• Disabled validation - integrators sometimes switch off certificate checking “to get it working”. Encryption without validation offers no protection against a man-in-the-middle.

🧭 How do you implement TLS step by step in an OT network?

1. Take inventory - use your asset inventory to map which devices support TLS, which version and which certificates (including expiry dates).
2. Set up a private PKI - one internal root CA kept offline, with an issuing CA per zone or site.
3. Choose a profile - TLS 1.3 where possible, TLS 1.2 with ECDHE and AES-GCM where necessary; follow the NCSC guidelines.
4. Use mTLS for machine traffic - give each device its own client certificate instead of shared passwords.
5. Automate renewal - use protocols such as EST or ACME and choose lifetimes that fit your maintenance windows.
6. Monitor - alert on certificates that expire within 60 days and on handshake failures in logging and security monitoring.

This approach aligns with the requirements for communication integrity and confidentiality in IEC 62443-3-3 and IEC 62443-4-2, with the duty of care under NIS2 and with the Cyber Resilience Act, which obliges manufacturers to ship products with secure default settings. On the internet, the CA/Browser Forum is reducing the maximum lifetime of public certificates step by step from 398 days to 47 days in 2029; this mainly affects OT equipment that uses publicly trusted certificates.

❓ Frequently asked questions

What is the difference between SSL and TLS?

SSL is the original version of the protocol, developed by Netscape in the 1990s. TLS is the standardised successor from the IETF, starting with TLS 1.0 in 1999. All SSL versions are deprecated and insecure; what is called “SSL” today is in practice TLS.

Which TLS version should I use?

Use TLS 1.3 wherever possible and TLS 1.2 only for devices or clients that do not yet support 1.3. The Dutch NCSC rates TLS 1.3 as good and TLS 1.2 as sufficient. TLS 1.0 and 1.1 have been formally deprecated since 2021 and no longer belong in an OT network.

What is mutual TLS (mTLS)?

Mutual TLS is a TLS connection in which not only the server but also the client proves its identity with a certificate. In OT, mTLS is the usual way to authenticate devices, gateways and brokers to each other without passwords. Modbus/TCP Security and many MQTT deployments require it.

Is TLS the same as a VPN?

TLS and a VPN are not the same. TLS protects a single connection between two applications, whereas a VPN provides an encrypted tunnel for complete network access. Some VPNs, such as OpenVPN and SSL VPNs, do use TLS as their underlying technology.

What happens when a certificate expires?

A correctly configured TLS client refuses the connection as soon as the server certificate has expired. In OT, this can mean that a SCADA system or historian suddenly stops receiving data. Certificate monitoring and timely renewal therefore belong in routine maintenance.

Is TLS resistant to quantum computers?

Classic TLS key exchange with ECDHE will eventually be vulnerable to quantum computers, and encrypted traffic can already be recorded today to be decrypted later. That is why hybrid key exchange such as X25519MLKEM768 has been developed for TLS 1.3; it combines X25519 with the post-quantum algorithm ML-KEM. Browsers already use it by default and the Dutch NCSC rates it as good.

📌 In summary

TLS is the standard protocol for encrypting network connections and authenticating the other party with certificates, making it a core building block of Defense in Depth in both IT and OT. Choose TLS 1.3 or well-configured TLS 1.2, use mTLS and your own PKI for machine traffic, and manage certificates actively so that security does not come at the expense of availability.