Definition
mTLS (Mutual TLS) is mutual TLS, where during the connection establishment the client and server mutually verify each other's X.509 Certificate to achieve strong authentication. The Device Management Platform can require devices to access using mTLS, suitable for high-security scenarios such as industrial and financial sectors.
Handshake process and verification
mTLS, based on the standard TLS handshake, requires the client to submit a certificate for server verification. The server verifies the client's certificate signature chain, validity period, revocation status (CRL/OCSP), and the binding relationship between the Subject and the device. The device needs to pre-install the root CA certificate to verify the server's identity, preventing man-in-the-middle attacks. Compared to one-way TLS, mTLS achieves mutual trust between devices and platforms, suitable for device access under a zero-trust architecture.
Integration with DMP
The Device Management Platform supports mTLS at access points such as MQTT Broker, HTTP API, and CoAP. Devices use X.509 certificates to establish connections, and the platform can resolve device identity based on the certificate Subject or SAN, implementing Device Authentication. Certificates can be issued by the platform CA or integrated with enterprise PKI; a complete process for certificate issuance, deployment, renewal, and revocation must be established, coordinated with Device Credentials management.
Use Cases
Suitable for high-security IoT scenarios such as industrial control, vehicle networking, financial terminals, and medical devices. mTLS is a strong security solution for device authentication, capable of meeting compliance requirements such as MLPS (Multi-Level Protection Scheme) and ISO 27001.
Mutual checks compared with a shared password
Mutual TLS, on top of ordinary transport encryption, also requires the device to present a certificate. The platform checks that the certificate was issued by a trusted signer, that it is inside its validity, and that it has not been revoked, and then checks whether the subject or a subject alternative name maps to exactly one device. The device likewise checks the platform certificate, so it does not connect to a service that only shares the name. A shared password or a product key can be copied onto another device and used there. If the private key exists only in secure storage on this device, copying the certificate file without the private key still cannot finish the handshake. What it proves is "the party that holds this private key," and the premise is that the private key has never left the device. A failed handshake should stop before authentication completes. Do not connect first and then look up identity in the application. A revocation list or an online status query needs a cache and a failure policy. When the query cannot be made, refusing and temporarily allowing have to be decided in advance. Each access point must not choose for itself. Used with MQTT, the connection layer has already identified the device, and the application layer should not trust a device name the client fills in at will.
When a certificate chain can finish the handshake
At the factory the device has to receive its own private key and certificate, and the trust anchor it will use to check the platform. The name on the certificate has to find a matching device on the platform. The scope of issuance should be limited to that product or that tenant, so one generic client certificate is not shared by every device. Validity should be short enough to rotate, and the device needs a path to replace the certificate before it expires. Once it has expired, the device cannot connect, and it also cannot replace the certificate online. That loop has to be broken in the design, for example by allowing a certificate that is close to expiry to perform one update. A device whose clock is badly wrong will treat a certificate that has not expired as expired, so time sync and a grace period have to be specified. The private key must not be exportable, and the write on the production line itself has to be auditable. Changing the trust anchor on the platform is a compatibility problem for every device. Run both anchors together, then retire the old one. Mutual authentication alone is not authorization. The certificate says who you are. One device, one secret, or an access policy, still has to decide which topics and APIs you may use. A long-lived certificate with no way to revoke it cannot be invalidated on a single device after it leaks.
When the subject does not match the device record
A certificate issued to a serial number, while the platform record uses a different asset number, passes the handshake and still cannot be bound to a device, so later permissions have to be left wide. A subject alternative name written as a wildcard for the whole product lets any device that holds a certificate for that product impersonate the others. Checking only the issuer, and not validity or revocation, lets an expired or reported-lost certificate still connect. A device clock set far in the past, so it will accept an expired certificate from testing, is left that way after go-live. A platform certificate that changed while the trust anchor in the device did not is a total failure to connect, and it is easy to misread as a network fault. If the device does not check the platform name, an intermediary can divert traffic with another certificate on the same chain. Treating a client certificate as encryption-only, with no digital-signature use, fails the handshake, and the log only says "network error." Revocation caches that differ across access points reject the same certificate in one place and accept it in another.