Security1 min read
TLS 1.3 in device fleets
TLS 1.3 became mandatory in most compliance frameworks by 2025. Deploying it across a device fleet has some rougher edges than the browser story suggested.
The browser transition to TLS 1.3 was smooth. The device transition — for terminals, IoT devices, embedded systems — has been rougher. Old firmware doesn't support it. Middleboxes get confused. Certificate pinning behaves differently. The compliance calendar doesn't care about any of this.
Written November 2025 from a device fleet migration.
Where TLS 1.3 breaks in device fleets
- Static certificate pinning. Terminals that pinned to a specific intermediate certificate need updates when the pin path changes. TLS 1.3 doesn't cause this directly, but the migration usually happens alongside certificate infrastructure changes that do.
- Middleboxes assuming TLS 1.2 handshake shape. Corporate proxies, some MDM tools, and older acquirer gateways sometimes reject TLS 1.3 handshakes because the ClientHello looks unfamiliar.
- Zero round-trip mode complications. TLS 1.3's 0-RTT is disabled by default in most stacks, but where it's enabled it interacts poorly with idempotency assumptions.
What to do
- Audit the certificate chain your devices trust. If a root or intermediate is rotating, plan the trust anchor update before the TLS change, not with it.
- Test through every middlebox in the actual production path. Not the lab equivalent — the actual production one.
- Disable 0-RTT explicitly on both client and server. The performance benefit is small; the correctness risk is real.
- Keep TLS 1.2 available as a fallback for a defined transition period, and monitor which endpoints are still using it so you know when it's safe to disable.
The device-fleet TLS migration is unglamorous. The correctness bar is high because a broken terminal in the field costs real money.