A device identity is only as strong as the weakest step in its lifecycle. When credentials are generated correctly but injected with the same test key across a production run, the cryptographic design is irrelevant: one extracted device unlocks the fleet. The backend cannot distinguish a genuine device from a clone, because the credential that should prove uniqueness is shared.
The problem rarely looks like a broken algorithm. It looks like a factory tool that kept using development keys, a provisioning process without per-device injection, or a secure element that stores a key which was generated on a build server. Each of these is invisible in the design document and only becomes visible when someone attacks the actual product.
The operational half of the lifecycle is even more often neglected. If a credential is compromised in the field, can it be rotated without a physical recall? Can revocation actually reach devices that operate offline or behind restricted networks? A product line where identity cannot be replaced is a product line where a single leak is permanent.
The identity property depends on several technical assumptions.
- Key generation Where is the key pair generated: inside the device's secure hardware, or externally and copied in during production?
- Per-device uniqueness Is every unit provisioned with its own credential, or do batches share secrets?
- Storage protection Does the private key live in a secure element or TPM, or as plaintext in flash that physical access can read?
- Provisioning separation Are factory test keys fully excluded from production units, or do test and production credentials overlap?
- Cloning resistance Can an extracted credential be replayed onto another device, and does the backend detect enrollment of duplicates?
- Backend revocation If a credential leaks, can the backend revoke it, and do constrained or offline devices actually honor that revocation?
- Rotation in the field Can identities be replaced without a physical recall, or is a leaked key permanent for the fleet?
The certificate is valid, and shared across 40,000 units.
Every device authenticates successfully. The backend accepts every unit, because the credential is genuine and correctly signed. The trust model breaks silently: the credential proves membership in the product line, not the identity of one device.
When one unit is physically compromised and its credential extracted, the attacker becomes indistinguishable from any other device. Revocation would disable the entire fleet, which is why, in practice, it is never triggered.
Verify the identity chain on the implemented product.
We map the actual provisioning path, from key generation through factory tooling to the shipped unit, and test each transition for uniqueness, protection and separability. On the device, we test whether private material can be extracted or misused. Against the backend, we test whether cloned or replayed credentials are detected, and whether revocation works under realistic conditions.
- New device identity or PKI architecture
- Manufacturing provisioning process defined or changed
- Secure element or TPM introduced into the product
- Fleet growth makes per-device credentials operationally critical
- A credential leak or cloned device is suspected
- Backend should distinguish individual devices but currently cannot
- Compliance or customer assurance requires evidence of unique device identity