If your user base is primarily IoT devices and your organization doesn’t want to manage passwords for each device, then it seems like a series of un-guessable passwords such as “d3v1ce [serial-number]” is the only solution. While that technically works, it isn’t the most user-friendly option. For a more elegant and effective solution, consider mutual TLS, or mTLS, authentication.

With mutual TLS authentication, the server authenticates the client at the TLS level before allowing encrypted application layer data to flow. While the server still presents a certificate that the IoT device validates against a trusted Root CA, the server now sends a CertificateRequest message asking the IoT device to do the same.

In the CertificateRequest TLS message, the server lets the IoT device know what Certificate Authorities it trusts. However, this step is where the server needs to be careful. The server may be a public-facing domain on the internet with a certificate issued by the Let’s Encrypt CA, but that does not mean the server should allow client certificates that are issued by Let’s Encrypt or any of the other typical Root CAs that are generally trusted.

IoT implementers must be fully cognizant of the PKI they use to verify their device fleet when using mutual TLS authentication. The only entity that can authenticate your devices safely is you. Utilize an Internal Certificate Authority that distributes certificates for the IoT fleet. Take additional precautions by ensuring your issuing CA is somewhere along the devices’ root-of-trust path, solidified by hardware via secure boot mechanism.