Definition
One Type One Secret refers to sharing a ProductSecret among devices of the same product model. When a device connects for the first time, it completes authentication by obtaining a DeviceSecret through Dynamic Registration. It is suitable for mass production and pre-burned scenarios and complements One Device One Secret.
Process and Security Considerations
When devices leave the factory, the ProductKey, ProductSecret, and unique device identifiers (such as DeviceName, MAC, or SN) are pre-burned. During the first connection, the device uses the ProductSecret to sign a request and applies to the platform for registration; after verification, the platform issues a DeviceSecret and sets up a device profile. Subsequent connections use the DeviceSecret for authentication. Leakage of the ProductSecret will affect all devices of the same model and must be strictly protected; measures such as a secure production line environment and segmented key storage can reduce risks. This approach is suitable for large-scale production scenarios where DeviceSecrets cannot be burned individually on the production line.
Integration with DMP
The Device Management Platform provides the Dynamic Registration interface, supporting batch device activation based on ProductSecret. The platform needs to verify device unique identifiers, prevent replay attacks, and record audit information such as registration time and IP. It works with the Device Onboarding process to achieve automation of the "burning—registration—activation—online" sequence. In high-security scenarios, devices may require secondary confirmation or human-machine interaction when connecting for the first time after registration.
Use Cases
Suitable for mass-produced devices such as consumer electronics, smart meters, and industrial sensors. The one-type-one-secret approach simplifies production line burning processes and reduces key management complexity; the one-device-one-secret method meets different security level requirements.
A model key only buys a device key
The product key in one type, one secret is not the login credential the device will use for a long time afterward. It is the material devices of the same model use, on first registration, to prove to the platform that they belong to this authorized product. At the factory the device carries a product identifier, this shared product key, and its own serial number or name, which must not repeat. On the first connection the device protects the registration request with the product key. The platform checks the product, checks that the serial number is not already taken, and checks that the request is not a replay, then issues a device key that belongs only to this unit and creates the record. Authentication after that should switch to the device key. The product key has done its job. Its permission should be narrow enough only to register. It must not be used to publish telemetry, subscribe to someone else's commands, or call a management API. The registration API needs replay protection and a rate limit. Otherwise, once the shared key leaks, an attacker can occupy serial numbers in bulk. Relative to device credentials, the product key is the threshold for collecting a credential, and the device key is the credential after it has been collected. An audit log should at least keep the registration time, the serial number, the source network, and the result of issuance, so an abnormal bulk registration can be seen.
What must be true before dynamic registration is opened
This approach fits volume production where the line cannot burn a different key into each unit, and where the product key can be kept out of public material. The serial number has to be unique before registration, and the platform has to be able to reject a repeat or to state whether a repeat overwrites or is refused. The product key should be rotatable by batch: an old batch registers with the old key, a new batch with the new key, rather than one key for the whole model that can never be retired. The registration window can be limited to the line network, or to a short time after first power-up, so a device sold months ago is not still accepted as a new record using the product key. After a successful registration, the device has to store the new key persistently and stop presenting the product key on later connections. If a module may be replaced in the field, state how the old record is retired, so one serial number does not point at two modules. If the product key cannot be protected, and unique serial numbers cannot be guaranteed either, a public registration address should not be opened. A high-risk device should not trade a shared key for a long-term permission just because the line finds per-unit keys inconvenient.
Treating the product key as a long-term password
If the device still logs in directly with the product key on every reconnect, and the platform accepts that, then a key read out of any one unit can impersonate any serial number, and one type, one secret falls back to a shared password. A registration API that does not bind uniqueness of the serial number lets an attacker, with a leaked product key, register in advance. The real device then fails when it powers on, or it is bound to a key the attacker holds. Replaying a captured registration request makes the platform issue a second key, and both the old device and the new requester can claim to be legitimate. A product key printed on the silkscreen, in the manual, or inside public firmware opens registration to everyone. Rotating the product key with no overlap for the line that is still in production makes every device being built fail registration. A registration that succeeds, while the device does not write the new key into persistent storage, comes back with the product key after a reboot. If the platform has already closed that path, the device stays offline for good. A log that prints the product key and the device key from the registration response together leaks both secrets at once. Closing a device by only deleting the record, and not refusing that serial number if it registers again with the product key, lets a retired device be activated once more.