Device Identity: Why Shared Credentials Put the Fleet at Risk

Ask a product team how their devices authenticate to the backend, and the honest answer is often a shrug: "there's a key in the firmware". Ask what happens when one device lands on a lab bench, and the shrug stops. That question, what does the extraction of one device cost you?, is the entire argument for per-device identity. A shared credential can expose every identity that relies on that secret. A unique per-device key initially exposes one identity. Whether the damage stays there depends on authorization and revocation, not uniqueness alone.

This note is about the distance between those two answers in real products: why shared credentials survive far longer than they should, what per-device identity actually buys, and what it costs to operate.

Why shared credentials fail at scale

Shared credentials start reasonable. A pre-shared key baked into the firmware image, a client certificate shipped in every unit, one API token for the whole product line, one thing to provision, one thing to rotate, one thing to debug. Even at 10 devices, a leak affects all uses of the shared secret. As the fleet grows, both the potential damage and the cost of replacing that credential grow with it.

If a shared secret is extracted from one device, an attacker can use it wherever that credential is accepted. The required effort depends on the hardware and protection configuration (see Firmware Extraction). Authentication based only on that shared secret cannot distinguish the devices using it. Revocation is possible, but interrupts the dependent functions of every device still using the credential. This can become a fleet-wide authentication incident; it does not automatically mean code execution on every device.

What per-device identity buys

Per-device identity means every unit holds a credential that exists nowhere else: a key pair generated on-chip or injected during manufacturing, with a certificate that names that device, not the product line. The properties this buys are concrete:

• A separable identity. Extracting a unique device key compromises that identity, not automatically its peers. Damage stays within its intended scope only if permissions are also restricted to that device.
• Attribution. Backend logs can identify the authenticated credential for device #4711, not just "some device". After key extraction, those logs alone cannot distinguish the legitimate unit from an impersonator.
• Differentiated response. You can quarantine one device, push a targeted update, or refuse one serial number, instead of choosing between "ignore the incident" and "rotate the fleet credential".
• Meaningful revocation. Individual credentials enable targeted revocation if every relevant verifier enforces it. Revoking a shared credential also interrupts legitimate users of that credential.

Identity is not authorization

Certificate-based authentication must verify possession of the corresponding private key; presenting the public certificate alone is not enough. Authorization is a separate decision. The backend must bind the authenticated identity to allowed device resources, tenant boundaries and operations. Device A must not obtain access to device B merely by supplying its ID, choosing a different MQTT topic or invoking a service function. Test those boundaries with two independently provisioned identities. Unique keys without those checks can still enable fleet-wide damage.

Provisioning is the real problem

Teams underestimate not the cryptography but the factory. Somewhere in production, every device must receive a unique credential, and the process must guarantee three things: the key is generated or injected without anyone outside the device seeing it, the certificate is issued to the correct serial number, and the provisioning step cannot be skipped or replayed. In practice we find provisioning stations with debug logs of injected keys, HSMs used as expensive random number generators, and "unique" credentials derived deterministically from the serial number, a scheme that converts a label printer into a key oracle.

The cleanest pattern: generate the key pair on the device (in a secure element or TEE), export only the public key, sign it against the device's attestation certificate, and issue the identity certificate from that. The private key never exists outside the chip, not in a database, not in a log, not in a factory PC's temp folder.

Revocation without re-provisioning

Per-device identity only pays off if revoking one device is operationally boring. That means the backend has a revocation path that does not require touching other devices, the relevant services enforce the revoked state, and the design states what happens to established sessions and derived tokens. Someone must rehearse the process before the first incident; refusing a new TLS connection does not necessarily terminate an existing session. A revocation architecture that has never been exercised is a hypothesis, not a control.

Migrating off a shared PSK

For products already in the field with a shared credential, migration is a design exercise in its own right. The usual shape: new firmware trusts both the legacy shared credential and per-device certificates during a transition window; devices obtain their identity over a mutually authenticated channel; the shared credential is then demoted, then removed. The transition window is itself a risk window, it extends the shared secret's life, so it deserves a deadline, telemetry on adoption, and a story for devices that never update. This is one of the conversations where being early is dramatically cheaper: the same migration after an incident includes an attacker in the transition design.

Where the key lives matters as much as the scheme

A readable private device key can enable impersonation of that device. It remains a per-device key: unique credentials plus correctly scoped permissions can still contain the damage. Storage protection, secure element, TPM, TEE or encrypted storage, separately determines how difficult extraction is and does not replace backend authorization. We treat that question in detail in Secure Element vs. Secure Storage and in the field note on what we check behind the sentence "the key is in a secure element".

The summary is short: identity is an architecture, not a credential. Credential uniqueness, provisioning, authorization, revocation and key protection must work together. A product security review needs to test the links between them.