Definition
One Device One Secret refers to each device having an independent key (ProductKey + DeviceName + DeviceSecret). During device authentication, the device uses its own key, so the compromise of a single device does not affect other devices. Compared with One Type One Secret, the security is higher.
Key Management and Distribution
DeviceSecret is usually pre-generated by the platform during device production and burned into the device, or delivered via Dynamic Registration after dynamic registration. The platform must ensure the randomness of key generation, encrypted storage, and secure transmission. When rotating keys, the platform can support strategies such as devices requesting new keys and a transition period for old keys. Together with Device Credentials management, it enables full lifecycle management of keys; in high-security scenarios, it can be upgraded to X.509 certificate authentication.
Integration with DMP
The Device Management Platform generates or imports DeviceSecret when a device is created, supporting batch import and production line integration. During authentication, it verifies device identity and key, supporting multiple forms such as mTLS and Token. The platform must record the history of key issuance, rotation, and revocation to meet Audit Log and compliance requirements. When a single device is compromised, its credential can be revoked separately without affecting other devices.
Use Cases
Suitable for high-security scenarios such as industrial control, connected vehicles, and financial terminals. One Type One Secret is a recommended practice for device authentication, capable of meeting MLPS (Multi-Level Protection Scheme), ISO 27001, and other compliance requirements, ensuring the overall security posture of the IoT.
What a per-device key proves during the handshake
One device, one secret is a way of issuing credentials. Besides a product identifier and its own name, each device has a device key that is not shared with any other device. At authentication, the platform checks the device's proof against the key in the record. A successful check only shows that the other party holds this key. It does not by itself show that the device has not been opened or that the firmware has not been changed. If the key leaks from the line, is written into a log, or is copied onto a repair fixture, the proof no longer holds. The value of the key depends on it existing only on this one device and in controlled storage on the platform. Unlike a product key shared by a whole model, the scope of handling a single leak should be this one device: revoke, rotate, and write again, none of which should force every unit of the model back for rework. The platform record has to be able to tell issuance, activation, rotation, and revocation apart, or an audit can only see that authentication once succeeded. Paired with device onboarding, the sign that onboarding is complete should be that this key has been written and the first check has passed, not that a work order was ticked as shipped. MQTT, or an API, is only the channel that carries the proof. Encrypting the channel does not replace "one key per device."
When the line can write a key to each device
Using this approach requires a production line, or a secure delivery channel, that can write a different key by serial number, and that can redo one unit on failure rather than the whole batch. When the platform generates a key it has to be unpredictable, and the path to the writer must not pass through plaintext logs or a shared directory that can be copied at will. After the write, an ordinary debug port on the device should not be able to read the key back. The record should be marked authenticable only when the write succeeds, so the platform does not enable it while the device has not been written yet and a mass of failed logins follows. Replacing a board or a secure element needs a procedure that revokes the old key and binds the new one. Whether historical telemetry stays under the original device identity or moves to the new one has to be decided in advance. If a fixture in a technician's hands can export the key, the approach falls back to a shared secret. A product that cannot yet write a key per unit should say plainly that it uses another way of issuing credentials, rather than copying one key into every device and still calling it one device, one secret.
Copies, rotation, and revocation out of step
A key left in a placement file, in email, and on the platform at the same time means a leak at any one of those places can forge the proof for that device, and it is hard to see which place it was. If rotation has already switched the platform to the new key while the device still holds the old one, the device suddenly cannot come online. If the fallback then also accepts the old key, the rotation did not happen. Deleting the record on the platform without revoking the key lets a party that holds a copy still log in through a cache that has not expired. A bulk import that swaps the key columns of two devices lets both "authenticate" with their identities exchanged, and history is attached to the wrong physical unit. Debug firmware that prints the key into a log and uploads it hands the credential to whoever collects the logs. Deriving the key from a predictable serial number means the keys of neighboring devices can be calculated. A revocation list that is not pushed to every access point rejects the device at one entrance and still accepts it at another. Storing the product key and the device key in the same field clears every device key when the product material is rotated.