• 4 min read

IoT device authentication options

Picking the right security for the job is a challenging issue. Obviously, everyone wants their security for IoT solutions to be maximized. But issues such as hardware limitations, cost consciousness, lack of security expertise, and more all play into which security option is ultimately chosen for how your IoT devices connect to the cloud.
Update: For the most relevant information regarding Azure IoT devices, please visit documentation for Security practices for Azure IoT device manufacturers.​

Picking the right security for the job is a challenging issue. Obviously, everyone wants maximum security for IoT solutions. But issues such as hardware limitations, cost consciousness, lack of security expertise, and more all play into which security option is ultimately chosen for how your IoT devices connect to the cloud. There are many dimensions of IoT security and in my experience authentication type tends to be the first one customers encounter, though all are important.

In this blog post, I'm going to discuss the authentication types supported by the Azure IoT Hub Device Provisioning Service and Azure IoT Hub. There are other authentication methods out there, but these are the ones we have found to be the most widely used.

Azure IoT published a whitepaper about evaluating your IoT security, and we also offer the Security Program for Azure IoT. This security program helps you find the right security auditor for your situation and who can help you figure out how much security you need for your solution. These companies are experts at evaluating IoT security; if you have any in-depth questions around security, I highly recommend you give them a try. You can also learn about how to select secure hardware in this blog post “Whitepaper: Selecting the right secure hardware for your IoT deployment” or in the accompanying whitepaper.

This blog post is not a replacement for a security audit, and it is not meant as a recommendation for any specific form of security. I want you all to be as secure as possible and cannot in good conscience recommend anything less. Take this blog post as a lay of the land to help you understand at a high level what all is possible, and what you should keep in mind as you embark on your IoT security journey. Remember: when in doubt, find an expert.

X.509 certificates

X.509 certificates are a type of digital identity that is standardized in IETF RFC 5280. If you have the time and inclination, I recommend reading the RFC to learn about what makes X.509 certificates useful in IoT scenarios. Learn about installing certs in devices.

There are several ways certificates can be authenticated:

  • Thumbprint: A hex string uniquely identifying a cert generated by running a thumbprint algorithm on the cert.
  • CA authentication based on a full chain: Ensuring the certificate chain was signed by a trusted signer somewhere in the cert.


  • Most secure key type supported in Azure IoT.
  • It allows lots of control around management.
  • There are lots of vendor options.


  • Many customers rely on external vendors for certificates.
  • Management comes at a price, adding to the overall solution cost.
  • Lifecycle management can be a challenge due to the logistical complexities involved.

Trusted Platform Module (TPM)

TPM can refer to a standard for securely storing keys used to authenticate the platform, or it can refer to the I/O interface used to interact with the modules implementing the standard. TPMs can exist as discrete hardware, integrated hardware, firmware-based modules, or software-based modules. Some of the key differences between TPMs and symmetric keys (discussed below) are that:

  • TPM chips can also store X.509 certificates.
  • TPM attestation in the Device Provisioning Service uses the TPM endorsement key (EK) which is a form of asymmetric authentication, whereas symmetric keys are symmetric authentication.


  • TPMs come standard on many Windows devices, with built-in support in Windows if you're using Windows as your OS.
  • TPM attestation is more secure than SAS token-based symmetric key attestation.
  • You can also blow away credentials pretty easily, and the Device Provisioning Service auto-rolls the IoT Hub credentials whenever a TPM device comes to re-provision.


  • TPMs are difficult to use in general if you're not familiar with them.
  • Difficult to develop for without either a physical TPM or a quality emulator.
  • May require board re-design to include in hardware.
  • You can't roll the EK without essentially destroying the identity of the chip and giving it a new one. It's like if you had a clone, your clone would have the same physical characteristics as you but they are ultimately a different person. Although the physical chip stays the same, it has a new identity in your IoT solution.

Symmetric key

A symmetric key is known to both the device and the service, and the key is used to both encrypt and decrypt messages sent between parties. Azure IoT supports SAS token-based symmetric key connections. The best way to protect symmetric keys is via a hardware security module.


  • Easiest to get started.
  • Nothing extra required to generate.


  • Less secure than X.509 certificates or TPM because the same key is shared between device and cloud, which means the key needs protecting in two places. For certificates, TPM, and PKI in general the challenge is all about proving possession of the key without ever revealing the private portion of the key.
  • Easy to have bad security practices. Folks using symmetric keys tend to hardcode the keys in the clear (unencrypted) on devices, leaving the keys vulnerable. It's possible to mitigate some risk by securely storing the symmetric key on the device, but in general, folks using symmetric keys aren't necessarily following best practices around key storage. It's not impossible, just uncommon.

Shared symmetric key

Using the same symmetric key in all your devices. Don't do this ever!


  • Easy to produce at scale.


  • Really, don’t use the same symmetric key in all devices. The risks far outweigh the benefit of easy implementation. It would be security malpractice to suggest that shared symmetric key is a serious solution for IoT authentication.
  • Very vulnerable to attack.
  • Anyone can impersonate your devices if they get a hold of your key.
  • You will likely lose control of devices if you rely on shared symmetric key. Just don’t do it, you can read more on botnets if you’re not convinced that shared symmetric key is a bad idea.

Making the right choice for your devices

You have to evaluate your specific risks and benefits to make your IoT authentication decision. This blog post is too short to cover everything, but Azure IoT offers the Security Program for Azure IoT if you need help making this decision. You can also read our whitepaper about evaluating your IoT security to learn more about your options.

To sum things up with a limerick:

Security means lots of things
As varied as types of machines
Just how much of it
You need for your…stuff
Depends on your specific needs