Definition
Device Credentials (Device Credentials / Triplet) refer to the identity information required for a device to access the platform, usually including ProductKey, DeviceName, DeviceSecret or ProductSecret. In a one-device-one-secret scenario, each device has individual credentials; in a one-model-one-secret scenario, devices of the same model share the ProductKey + ProductSecret, and obtain the DeviceSecret through Dynamic Registration.
Types of Credentials and Security
One Device One Secret One Device One Secret: Each device is preloaded with ProductKey + DeviceName + DeviceSecret. Leakage of a single device does not affect other devices. One Type One Secret One Type One Secret: Devices of the same model share a ProductSecret, and DeviceSecret is obtained through Dynamic Registration. For high-security scenarios, it can be upgraded to X.509 Certificate authentication. Credentials need to be securely stored (on-device TEE/SE), transmitted with encryption (TLS), and stored encrypted on the platform. Supports credential rotation and revocation, meeting Audit Log requirements for auditing and compliance.
Integration with DMP
The Device Management Platform generates or imports credentials when devices are created, supporting bulk import and production line integration. It provides management capabilities such as credential query, reset, and revocation; supports the Dynamic Registration process. Together with Device Access and Device Authentication, it achieves device identity verification and access control. In case of credential leakage, it supports rapid revocation and device re-authentication.
Use Cases
Suitable for all device access scenarios. Credentials are the foundation for establishing trust between devices and the platform, and their security and manageability directly affect the overall IoT security posture.
How the triplet is split between the line and the cloud
Device credentials are the material that lets the platform recognize a connection as one specific terminal. The usual parts are a product identifier, a device name, and a device secret. In a certificate scheme they are a private key and a certificate. The product identifier answers which kind this is. The device name answers which unit of that kind. The secret or private key answers whether the holder can prove it. The line writes, into secure storage, the part the device must keep for a long time. The cloud generates, registers, disables, and rotates. The identifier both sides use for the same device must agree. Creating the record only in the cloud, with nothing written in the device, or programming the device only, with nothing registered in the cloud, both fail authentication.
A per-device secret requires each unit to have its own key before it leaves the factory. It fits a line that can inject keys one by one. A per-product secret requires the device to hold product-level material first, exchange it for its own device key on the first connection, and not use the product-level material as the everyday login key afterward. Using credentials assumes storage that cannot be read out through an ordinary debug port, encryption for the whole transfer, and a cloud query screen that shows whether a secret exists and does not echo the original. Resetting a secret is issuing new identity material. The old material should stop working at once. Linked with the device lifecycle, the credentials of a retired device must be disabled, not merely hidden from the list.
When a secret is written into a log or a firmware package
A common mistake, made to ease repair, is to put the triplet into the firmware package, a clear-text QR code, or the serial boot log. Once the package is copied, the secret no longer belongs only to that one unit. Another is a spreadsheet left in a shared directory after a bulk import. A duplicated device name lets the later import overwrite the earlier secret, and one of two devices in the field fails authentication forever. Credentials from a test environment copied into a production device fail as “the key is correct but the product does not match.”
During rotation, if the new secret has been delivered and the cloud invalidates the old secret before the device confirms it has written the new one, the device goes offline and cannot rescue itself with the old material. The switch point should be the device confirming that the save succeeded. Permission to view credentials should be separate from permission to view telemetry. Not every operations account needs to see or reset a secret. A reset has to be checked after provisioning: the rotation is complete only when the device connects again with the new material. Writing a secret into a work-order note or a chat record copies it outside the credential system, and revocation cannot clear that copy.
A secret reset counts only after the device confirms it saved
Issuing a new device secret is only an action in the cloud. It counts only when the device has written the new secret into secure storage, which is known when the device completes authentication again with the new material. If the cloud invalidates the old secret immediately after delivery, and the device has no power, did not finish the write, or lost the response, the device loses every usable material and needs someone on site. The safe switch point is the device explicitly confirming a successful save, or already opening the next session with the new key. Until then, the old key should still be able to complete one controlled retry. The query screen should show only whether the secret exists and when it was rotated. It should not echo the original to an operations account. Permission to view and to reset should be separate from permission to view telemetry.
If the line puts the secret into a firmware package, a clear-text QR code, or the boot log, that is another copy outside secure storage. Revoking the cloud record later cannot clear the copy in the field. The spreadsheet used for import should be removed from the shared directory after the import ends. When a device name is duplicated, the later import must not silently overwrite the earlier secret. It should report a conflict. Material from a test environment copied into a production device shows up as a key that calculates correctly while the product or the environment does not match. Writing the secret into a work order or a chat record is also a copy. Reset, revocation, and joining again should be separate records, so it is possible later to explain why a device suddenly failed authentication, rather than being left with only the sentence that it was already handled.