How should device identity be established and maintained for a fleet, and what fails when it is done casually?

Why device identity is different

A device's credential lives in a physical object the operator does not control, potentially for a decade, possibly in an attacker's hands. Every assumption that holds for a server workload — rotation on deploy, a secrets manager, revocation taking effect immediately — is weaker or absent.

Establishing identity

• A unique per-device credential, provisioned at manufacture where possible. A shared credential across a fleet means a single extracted key compromises everything, and it is the most consequential and most common mistake.
• Hardware-backed key storage — a secure element or trusted platform module — so the private key cannot be extracted even with physical access. This is what makes long-lived device identity defensible, and software-stored keys should be treated as eventually compromised.
• Certificate-based rather than password-based, with the device proving possession of a key rather than transmitting a secret.
• Attestation where the platform supports it, so the device proves not only who it is but that its software is genuine and unmodified.
• A provisioning process that does not require trusting the factory network, since manufacturing environments are frequently the weakest link.

Maintaining it

• Certificate rotation that works in the field, tested — a fleet whose certificates all expire on the same date is a scheduled outage, and this has happened to large deployments.
• Staggered expiry, so renewal load and failure are spread.
• Revocation that scales: certificate revocation lists do not, so short-lived certificates with regular renewal are usually the practical answer, making revocation a matter of not renewing.
• Renewal that survives extended disconnection, since a device offline past its expiry must have a path back — and a device that cannot re-enrol after expiry is bricked from a security perspective.
• Per-device authorisation, not just authentication. A device proving its identity should be permitted only what that device needs — so a compromised device cannot publish as another or subscribe to the whole fleet's data.

What fails when it is casual

• A shared credential, where one extraction compromises the fleet and rotation requires touching every device.
• Software-stored keys on physically accessible hardware, extracted and used to impersonate.
• Synchronised certificate expiry, producing a fleet-wide outage on a known date that nobody had diaried.
• No renewal path for long-disconnected devices, so they return and cannot authenticate.
• Authentication without authorisation, so any valid device can publish as any other or read everything.
• Revocation lists that grow unmanageably, so revocation is theoretical.
• Identity tied to a mutable attribute — a serial number that gets reused, a MAC address that changes — producing ambiguity about which device is which.
• No way to decommission, so a sold, scrapped or stolen device retains valid access indefinitely.

The framing that helps: a device credential is a standing credential in the worst possible environment — long-lived, physically accessible, and unrotatable by ordinary means. Every mitigation is an attempt to bound what that credential can do and how long it remains valid, which is the same reasoning as short-lived workload identity, applied where the constraints are much harder.