In short: A strong IoT device identity is a unique X.509 certificate baked into each device, ideally at manufacture. It lets devices authenticate with mutual TLS, encrypt data and receive signed updates — provided the certificate is provisioned securely and rotated before it expires.
A connected device with no verifiable identity is a liability. It can be cloned, spoofed or hijacked, and there is no reliable way to tell a genuine sensor from an attacker's. Passwords and shared API keys do not scale to millions of devices, which is why a certificate-based IoT device identity has become the default for serious deployments.
This article covers how to give IoT and OT devices a trusted identity across their lifecycle — from the birth certificate issued at manufacture to secure onboarding, renewal and revocation in the field.
What a strong IoT device identity looks like
At its core, an IoT device identity is an X.509 certificate and a matching private key stored on the device — ideally in a secure element or TPM so the key cannot be extracted. The certificate binds a unique identifier to a public key and chains back to a trusted issuing CA.
With that identity, a device can prove who it is using mutual TLS, encrypt its telemetry, and verify that firmware updates are signed by the manufacturer. Without it, every other control is guesswork. A device with no cryptographic identity cannot be reliably distinguished from an impostor, however strong the surrounding network controls are.
Birth certificates and secure onboarding
The strongest model provisions identity at manufacture. During production, each device receives a 'birth certificate' — an initial credential injected in a controlled environment. When the device first connects, it uses that credential to authenticate and enrol for an operational certificate, a pattern often called secure onboarding or bootstrapping.
Enrolment protocols such as EST and SCEP automate this exchange, so a device can request and renew operational certificates without manual steps. The goal is that no device ever joins the network without proving a trusted birth identity first.
Managing device certificates at scale
Provisioning is only the start; the identity must be governed for years. The key practices:
- Generate and store device private keys in a secure element or TPM so they never leave the hardware.
- Issue from a dedicated device-issuing CA, kept separate from your human and server PKI hierarchies.
- Automate renewal with EST or SCEP so certificates rotate before expiry, even for devices deployed for a decade.
- Maintain a live inventory of every device certificate so you can find and revoke a compromised fleet quickly.
- Plan revocation and re-provisioning for devices that are lost, decommissioned or resold.
- Design for crypto-agility so constrained devices can migrate to new algorithms as post-quantum standards arrive.
Why device identity is the foundation of IoT security
Certificate-based identity turns a fleet of anonymous endpoints into named, authenticated participants. That is what makes zero trust possible in operational technology: each device authenticates per connection, and access follows identity rather than network location. It also underpins machine and workload identity across cloud and edge.
The failure mode is almost always operational — an expired or unmanaged certificate that silently drops a device offline. Treating IoT device identity as a lifecycle, not a one-time setup, is what keeps large deployments running. Getting device identity right at the start — unique keys in hardware, a clean chain back to a trusted CA, and automated renewal — is far cheaper than retrofitting trust into a fleet already in the field.
How CRYPTAS helps
CRYPTAS designs and operates the PKI behind large-scale device identity — dedicated device-issuing CAs, HSM-protected roots, and automated enrolment that fits constrained hardware and manufacturing lines. We help teams provision IoT device identity at the factory and manage it in the field without drowning in expired certificates.
Building an IoT deployment that needs identity you can trust?