TLS, PKI, and secure transport
Review TLS settings alongside certificate provisioning, validation, renewal and recovery. Check the identity and trust requirements of each device and service.
Sources and scopeSource record 25 August 2026
Technical source record: 25 August 2026. Check the linked documentation for current product requirements.
General PKI baseline; each application protocol's TLS profile and product certification override generic assumptions.
On this page
Overview#
TLS protects a transport connection against eavesdropping and modification and authenticates endpoints according to the selected credential/profile. TLS 1.3 is RFC 8446. The current TLS deployment BCP, RFC 9325, prohibits TLS 1.0/1.1 and gives guidance for TLS 1.2/1.3 and algorithm selection.12
“TLS enabled” isn't enough. Record application protocol/profile, client/server roles, permitted TLS versions, cipher/signature/key exchange algorithms, SNI/ALPN if applicable, expected peer identity, trust anchors, certificate profile, client authentication, revocation/time policy, and failure behaviour.
Server and client identity#
Path validation proves that a chain terminates at a trusted anchor under PKIX rules; service identity verification proves the certificate represents the endpoint actually requested. Apply the protocol's defined identity rules, with RFC 9525 as the general service identity baseline when applicable.34
- Match the configured service name using the defined subjectAltName type; don't fall back to IP/source address or a user approved warning.
- Don't disable validation for self signed certificates. Trust a deliberately provisioned self signed certificate or private CA anchor with explicit scope.
- Separate trust anchor selection from intermediate certificates supplied by the peer.
- Enforce key usage, extended key usage, name constraints, validity, algorithm strength, and application/profile identifiers as applicable.
- Mutual TLS authenticates both TLS peers, but application authorisation must still map the client identity to permitted resources and actions.
Lifecycle#
Inventory issuer, serial, subjectAltName/application identity, fingerprint, key location, owner, issuance method, validity, renewal window, trust path, revocation method, deployed endpoints, and replacement history. Generate unique private keys on device or in protected provisioning, prefer non exportable hardware backed keys, and never clone keys in images/backups.
Rotate trust anchors with an overlap procedure: distribute new trust, issue/test new leaves, switch identities, remove old trust only after evidence, and preserve recovery. Clock failure can make valid certificates appear expired/not yet valid. Monitor expiry, unexpected issuers, chain/identity failure, algorithm downgrade, trust store change, private key export, and repeated handshakes.
OCSP is defined by RFC 6960, while CRLs are part of PKIX.5 Decide hard/soft failure and caching from consequence, availability, privacy, and the application profile; an unreachable responder must not silently produce an undocumented forever valid state. Short lived certificates may reduce but don't erase compromise response requirements.
Protocol boundary#
Don't substitute a generic reverse proxy or VPN for protocol specific secure modes such as BACnet/SC, Modbus Security, CIP Security, KNX IP Secure, or OPC UA SecureChannel. A proxy terminates identity and protection; document the downstream cleartext/reauthentication boundary. TLS doesn't validate payload semantics, prevent authorised dangerous commands, attest firmware, or prove physical completion.
Validate handshakes, chain construction, revocation behaviour, clock faults, algorithm policy, certificate rotation, and rollback against the target implementations.