Skip to content
Start free evaluation

Modbus/TCP Security

Modbus itself has neither authentication nor encryption: anyone on the network can send requests and read the values in transit. Modbus/TCP Security fixes this by carrying the Modbus TCP ADU inside a TLS (Transport Layer Security) connection. The MBAP header and the PDU don’t change. This page is based on the MODBUS/TCP Security Protocol Specification.

Threat Countermeasure
Eavesdropping TLS encrypts the traffic.
Tampering TLS checks message integrity.
Impersonation Client and server verify each other’s X.509v3 certificates (mutual authentication).
Unauthorized operations The server allows or denies each function code according to the role in the client certificate.
  • It requires TLS 1.2 or later.
  • The standard port is 802, distinct from 502 for plain Modbus TCP.
  • Moving to port 802 doesn’t turn on TLS by itself; both sides need a security configuration.

The specification carries the client’s role in a certificate extension:

  • The extension OID is 1.3.6.1.4.1.50316.802.1.
  • Its value is a single ASN.1 UTF8String, such as reader or operator.
  • The standard doesn’t define role names. The server’s authorization rules decide which functions each role may use.
  • When the server denies a request it returns exception 01 (Illegal Function). The TLS connection stays open.
client certificate server authorization rules
role = "reader" --> reader : FC 1, 2, 3, 4
operator : FC 3, 6, 16
request FC 06 (write) --> 06 not allowed for reader --> exception 86 01

Each side of a TLS connection needs three files:

File Server Client
Trusted CA certificate (trust) The CA that issued the client certificates The CA that issued the server certificate
Own certificate chain (chain) Server certificate + intermediate CAs + root CA Client certificate + intermediate CAs + root CA
Private key The server certificate’s key The client certificate’s key
  • The server certificate’s SAN (Subject Alternative Name) must contain the name or IP address clients use to reach it.
  • A client certificate carries its role in the extension. A certificate without a role can still connect; the server then applies its rule for clients without a role.
  • Keep each private key on its own host only.

PDComm enables Modbus/TCP Security with the security object of the configuration. The object holds file paths only, never key material, including when you save it in a project file.

Field Meaning
mode encrypted (default) or authentication_only
chain, private_key, trust PEM file paths. chain starts with your own certificate and must end with the root CA.
hostname Name or IP address the client checks in the server certificate. Defaults to localhost.
roles Server only. The function codes each role name may use.
null_role Server only. The function codes a client without a role extension may use. Defaults to none.
crls, require_revocation Certificate revocation list (CRL) files and whether revocation checking is mandatory

The two modes:

Mode TLS version and cipher Protection
encrypted TLS 1.3 (AES-GCM), TLS 1.2 (ECDHE, AES-GCM) Encryption, integrity, mutual authentication
authentication_only TLS 1.2, NULL-SHA256 (needs RSA certificates) Integrity and mutual authentication; no encryption
  • Both sides must use the same mode. PDComm never falls back from encrypted to authentication_only or plain TCP when a connection fails.
  • The server always requires a client certificate, and certificate validation can’t be turned off.
  • PDComm adds no role semantics of its own, such as splitting a value at commas into several roles: the whole extension value is one role name.
  • A role extension that isn’t a single UTF8String makes the server reject the connection.

To create certificates and check per-role permissions yourself, follow Modbus/TCP Security.