Definition
Device Authentication is used to verify the identity of terminals and prevent unauthorized devices from accessing the system. It supports One Device One Secret (pre-burned Device Credentials), One Type One Secret + Dynamic Registration, X.509 Certificates (mTLS), and other methods.
Comparison of Authentication Methods
One Device One Secret: Each device is pre-burned with a unique ProductKey + DeviceName + DeviceSecret, offering high security, suitable for scenarios requiring strict security, but the production line needs to manage credentials for each device. One Type One Secret: Devices of the same model share a ProductSecret and obtain device-level credentials through Dynamic Registration, simplifying production, but the ProductSecret must be kept confidential. X.509 + mTLS: Certificate-based mutual authentication, suitable for high-security scenarios such as industrial and automotive IoT.
Collaboration with Access Layer
Device authentication is the first gate at the Device Access access layer. MQTT connections are verified through Username/Password or certificates; LwM2M uses Pre-Shared Key or certificates. After authentication, the platform establishes a device session, assigns Topic permissions, and allows data reporting and command reception. Authentication failures can be logged in audit records, with support for blacklists and rate limiting to prevent brute-force attacks.
Best Practices
In production environments, TLS encrypted transmission must be used; credentials or certificates should be rotated regularly; alerts should be issued for abnormal authentication attempts (such as frequent failures); in conjunction with the Device Lifecycle lifecycle, credentials for decommissioned devices should be revoked to prevent misuse of leftover devices.
Where each of the three identity materials holds
Device authentication means confirming, before uplink data is accepted and before downlink control is carried out, that the secret or certificate held by the other side belongs to the device in the record. A per-device secret uses a device key unique to each unit. It fits a product whose line can write different material into each unit, and where leaking one unit should not affect the others. A per-product secret first exchanges a product-level secret for a device-level secret. It fits high volume where the line does not want to keep a key for every unit, but once the product-level secret leaks, the registration step is no longer trustworthy. A certificate uses a key pair and a certificate chain. It fits cases that need rotation, revocation, and mutual authentication. All three answer “who you are.” None of them answers “whether you are still allowed to be used.”
Which one to choose depends on what the line can program, whether the device can store a private key safely, and whether the field allows a certificate to be replaced. Material must be submitted over an encrypted channel. It must not appear in a debug password or in a clear-text log. After authentication succeeds, the session should grant only this device’s own uplink path and control scope. When clock skew is large, a certificate that depends on a validity period fails. That is a time problem, not a key written wrong. Used with the audit log, failure reasons should be recorded by class, such as material mismatch, certificate expired, and device disabled, so an attack can be told from a configuration error.
When the key is still valid but the device has been disabled
A likely mistake is to allow the session as soon as the key matches. A device that has been disposed, transferred, or whose product has been discontinued still has a key that is mathematically correct, and policy should still refuse a new session. Another mistake is to bake the product-level secret into every device and keep using it. The device-level secret that dynamic registration should have issued was never stored, so every unit connects with the same secret, and reading one unit means the whole batch is lost. An incomplete certificate chain, or an issuer from the wrong environment, also makes every production device fail in production while the test environment looks normal.
Replay has to be prevented as well. Comparing only the key, with no nonce or time window, lets a captured old registration request succeed again. If a session is not authenticated again for a long time after it succeeds, a module pulled out and moved into another enclosure keeps the session. During key rotation there must be an explicit handover of old and new material, not two keys valid forever at the same time. When the device lifecycle enters retirement, refuse new sessions first, then revoke the material. Deleting the record without revoking leaves the field device able to connect to another environment. Frequent failures need an alarm, but the threshold has to follow how the device reconnects, so a retry on a weak network is not treated as credential stuffing.
A product secret should not remain a long-term login password
The product-level material in a per-product secret scheme should be used only to issue each device its own device key. If the device takes a shortcut and still presents the product secret on every later connection, reading any one unit means the whole batch can be impersonated. Authentication policy should refuse that long-term reuse, and should require the device to switch to its own key after registration completes. A per-device secret is the opposite: each key is different from the factory, and authentication should not also accept the product-level secret as a substitute. A certificate scheme has to check the chain, the validity period, and whether it has been revoked. Checking only the public-key format is not enough. In every case, correct material finishes only the identity step. A device that has been retired, transferred, or whose product has been discontinued should still be refused a new session.
Failure reasons must distinguish written wrong, expired, disabled, and replayed. Otherwise the line treats a policy refusal as a programming failure and rewrites again and again. A certificate failure caused by clock skew should prompt a time correction, not a key replacement. Replay protection depends on a nonce or a short window. Too wide a window lets an old request still register a new device. Too narrow a window, with a line clock that is off, fails every unit. Rotation needs a clear end to the handover. Two keys must not stay valid indefinitely, and the old key must not be invalidated before the device confirms it has stored the new one. Frequent failures can alarm, but the threshold should leave room for a weak-network device’s normal reconnect, so recovery is not reported as credential stuffing.