Field device TLS and VPN: which boundary protects what

A field device opens a connection to a service and the design question arrives as a choice between VPN and TLS. That framing is wrong, because the two do different jobs. TLS authenticates the application endpoint and protects the conversation; a VPN controls reachability and protects packets between peers. Walk the connection from the device outward and each layer has its own answer.

If you cannot say where TLS terminates, you cannot say what the application actually trusts.

Find where TLS actually terminates

Start at the device application and follow the connection to the process that completes the handshake. If a proxy terminates TLS before the mainframe, the protected path ends at the proxy. The remaining hop needs its own documented protection.

Calling that end-to-end by assumption is how a design review approves a gap. Draw the termination point and the trust anchor on the same diagram.

TLS carries requests and responses in both directions, so a bidirectional application does not inherently need a VPN instead of TLS. The reverse is also true: a deployment may still need a VPN for other protocols on the same device.

Decide what the device must authenticate

Configure server identity validation and the intended trust roots. If each device must prove its own identity, choose a supported client-authentication model and enroll a distinct credential per device. Shared credentials turn one stolen device into a fleet-wide problem.

Plan key protection, renewal, revocation and recovery before shipping. A device in the field that cannot be re-enrolled after a failed renewal becomes a truck roll, and that cost shapes the design more than the handshake does.

Use a supported library and current guidance. Modern TLS deployment guidance prohibits negotiating TLS 1.0 and 1.1, and a TLSv1 reference in an old design note is not a requirement.

Fail closed when the handshake fails

A failed handshake or identity check must not silently fall back to the original cleartext protocol. That fallback is the vulnerability the TLS work was meant to close. Make the failure visible to the device operator and to the service, and require the protected channel for sensitive operations. Then let application authorization decide what an authenticated device may do.

Define connection lifetime, framing, timeouts and retry behavior as part of the contract. Encryption does not make a repeated command safe, and a retry after an uncertain prior operation needs an application-level answer.

Write the fallback rule down. "It reconnects without TLS if the handshake fails" is a design decision, and it should be an explicit one.

Give the VPN only the job it can do

A VPN can restrict reachability and protect packets to its own peer. TLS protects the application relationship to the selected endpoint. Their termination points can differ, and neither secures the endpoint's stored data or administrative access.

Measure handshake cost, steady-state messaging and reconnection on the actual device rather than assuming one mechanism is faster. Then test the four cases that matter: the intended exchange, a wrong server identity, an unauthorized device, and a reconnect after an uncertain operation. Record the result for each case, including the error the device shows.