A row of store gateways in three time zones. A dozen Raspberry Pis inside warehouse cabinets. Two industrial controllers on a customer's plant floor. They all talk to your backend, and none of them sit behind a firewall you control. A VPN back to headquarters becomes a part-time job past a few dozen nodes, especially when the devices live on cellular links behind carrier NAT.
Mutual TLS changes the shape of that problem. Identity travels with the connection in both directions, and authorization happens per request instead of per network. Here's how to build it.
Why mTLS Fits Edge Fleets Better Than a VPN
A VPN treats the network as the trust boundary. Once a node is on the tunnel it can usually reach the metrics server, the internal API, sometimes the build system. Edge deployments break that model in three ways: hardware sits where you can't secure it physically, links drop and reconnect constantly, and one compromised device gets a clear path inward.
mTLS moves authentication into the connection itself. Client and server each present a certificate and verify the other against a CA they trust. There is no "inside" to reach. A node can do only what its certificate maps to in policy, and you can change that policy without touching the device.
Consider a fleet of 300 cellular-connected gateways. With a VPN, each one needs a tunnel endpoint, a static route, and a certificate or key for the tunnel. When a carrier reassigns an IP or a device reboots, the tunnel has to re-establish. With mTLS, the device opens an outbound TLS connection to the API, presents its client certificate, and starts sending data. No inbound port, no tunnel concentrator, no network route to maintain. The API knows exactly which gateway is calling because the certificate says so.
That outbound-only pattern also survives carrier NAT and CGNAT. If the device can reach the internet, it can reach your endpoint. You can run the same model over Wi-Fi, Ethernet, or a private APN without changing your authorization logic.
What mTLS Proves, and What It Doesn't
A completed handshake proves one thing: whoever opened the connection holds the private key for a certificate your CA issued.
It does not prove the device is patched, that its container wasn't tampered with, that the application running on it is trustworthy, or that a human operator is not standing next to it with a debug cable. It also does not prove the device is in the location you expect. A certificate is an identity, not a statement of health.
That distinction matters. If an attacker extracts a private key from a device, they can impersonate that device until you revoke the certificate. If the key lives in a TPM or secure element, extraction is much harder. If the certificate is short-lived, the window of abuse is small. If the key is a file on the filesystem, assume it can be copied.
Use mTLS as the front door, then add layers: signed firmware, measured boot, container image signing, least-privilege authorization, rate limiting, and audit logs that record the certificate identity on every request.
The Certificate Authority You Actually Need
Do not use a public CA for internal device identity. You need a private CA that you control. The shape is usually the same: an offline root, one or more online intermediates, and an issuance service that authenticates devices before signing CSRs.
Keep Roots Offline
The root key should live on hardware that is rarely powered on. Use it to sign intermediate CAs, then put it back in the safe. If the root is compromised, every certificate you ever issued is suspect. Intermediates can be rotated or revoked more easily.
Separate Environments and Fleets
Use different intermediates for production, staging, and development. If you manage multiple customers or regions, consider separate intermediates per trust domain. A staging device should never be able to authenticate to production, even if someone copies a certificate.
Issue Short-Lived Certificates
Edge certificates should be measured in hours or days, not years. A 24-hour certificate that rotates automatically limits the damage from theft. Long-lived certificates force you to build revocation infrastructure and hope devices check it. Short-lived certificates turn revocation into an operational detail instead of a crisis.
Put Identity in the SAN
Encode the node identity in a URI Subject Alternative Name, such as spiffe://edge/region-a/store-142/gateway. Avoid relying on Common Name. Modern TLS libraries and authorization engines expect SANs, and URI SANs are easy to map to policy. The certificate should say what the node is, not just that it is valid.
A Practical Setup Walkthrough
- Define
Photo: Tima Miroshnichenko / Pexels
