Device identity: certificates, secure elements, TPMs and provisioning
In short: Every device needs its own identity that cannot easily be copied. The best practice is a unique key pair per device, created and kept inside a secure element or TPM, with a certificate signed by a trusted CA. Provisioning is the process of giving devices that identity safely, at the factory or on first connection.
Why identity matters
When a message arrives saying "temperature 4.2 degrees", the platform must know which fridge sent it and that it really came from that fridge. When the platform sends "unlock door", the lock must know the command came from the real platform. Weak identity leads to spoofed data, hijacked devices and the inability to cut off one compromised unit without affecting all the others.
Many early products used one API key or password baked into every unit. Extracting it from one device let an attacker impersonate the whole fleet. The modern approach is a unique asymmetric key pair per device with an X.509 certificate, used in mutual TLS (mTLS), where both client and server present certificates.
Protecting the private key in hardware
| Option | What it is | Typical use |
|---|---|---|
| Secure element | A small tamper-resistant chip that generates and stores keys and performs signing inside itself; the key cannot be read out | Microcontroller sensors, locks, payment devices |
| TPM 2.0 (Trusted Platform Module) | A standardised security chip (or firmware function) from the Trusted Computing Group with key storage, measured boot and attestation | Gateways, industrial PCs, Linux and Windows devices |
| On-chip secure enclave | A protected area inside the main processor, such as Arm TrustZone, holding keys away from normal code | Higher-end microcontrollers and system-on-chip designs |
| PUF (physically unclonable function) | Derives a key from tiny manufacturing differences in the silicon, so no key is stored at all | Low-cost chips needing anti-cloning |
| Software key in flash | Key stored as a file, ideally with flash encryption | Prototypes only; easy to extract |
The standard IEEE 802.1AR describes a useful pattern: an IDevID (initial device identity) installed by the manufacturer for life, and an LDevID (locally significant identity) issued by the owner's own CA once the device is deployed. The factory identity proves what the device is; the local one proves it belongs to you.
Provisioning
Provisioning is getting an identity onto the device and registering it with the platform. Common approaches:
- Factory provisioning: keys and certificates are created on the production line. Ideally the key is generated inside the secure element, and only a CSR (certificate signing request) leaves the chip.
- Pre-provisioned secure elements: chip vendors can ship parts that already contain a key and certificate, and give you the certificate list to upload to your cloud.
- Just-in-time or fleet provisioning: devices connect with a limited "claim" credential, prove who they are, and receive their long-term certificate on first contact.
The commands below show the CSR step in software for a lab gateway. On a real product the key generation happens inside the secure hardware.
# lab only: create a device key and a CSR with the device ID as the common name
openssl ecparam -name prime256v1 -genkey -noout -out device-0042.key
openssl req -new -key device-0042.key -subj "/O=Example Ltd/CN=device-0042" -out device-0042.csr
# the CA signs it (on the CA machine)
openssl x509 -req -in device-0042.csr -CA ca.crt -CAkey ca.key -CAcreateserial -days 825 -sha256 -out device-0042.crtRunning identity across the lifecycle
- Keep an inventory linking each device ID, certificate serial number and owner.
- Plan certificate renewal well before expiry, because devices in the field cannot be visited easily.
- Revoke a device's certificate (or remove it from the platform's allow list) when it is stolen, faulty or retired.
- Protect the CA private key in an HSM and use a separate intermediate CA for manufacturing.
- Use attestation, where available, so the platform can check the device's boot state as well as its identity.
Tip: put a device identifier, not a person's name or a MAC address the user can see, in the certificate subject. It keeps logs useful without leaking personal data.
Practice
Why should the private key be generated inside the secure element?
What is the difference between an IDevID and an LDevID?
A single device in a fleet of 50,000 is stolen. With per-device certificates, what do you do?
Key takeaways
- Each device needs a unique identity that cannot easily be copied.
- Per-device key pairs with X.509 certificates and mutual TLS are the norm.
- Secure elements, TPMs and enclaves keep private keys out of reach.
- Provisioning should create the key inside the device and certify only the public key.
- Track, renew and revoke certificates across the device lifecycle.
Original content written by Mohamed Fayas for FM TecHub. © 2026 FM TecHub. You're welcome to share a link to this page; please don't copy the text elsewhere without permission.