Mutual TLS is the gold standard for IoT device authentication, but operating a public key infrastructure for millions of devices is fundamentally different from managing certificates for a handful of web servers. The scale, the device constraints, and the operational reality of field-deployed hardware introduce challenges that most PKI guides do not cover.
Having designed and operated PKI for IoT fleets ranging from hundreds to millions of devices, here are the patterns that work and the pitfalls to avoid.
Device Identity vs TLS Certificate
The first decision is whether each device has a unique identity that is bound to its certificate, or whether devices share a common certificate. For security-critical applications such as alarm panels, industrial controllers, and medical devices, each device must have a unique identity. This allows individual revocation, audit trails, and accountability. For low-cost sensors where the consequence of compromise is low, group certificates may be acceptable.
Unique identity requires a registration authority (RA) that issues certificates during manufacturing or deployment. The RA must be offline or air-gapped to protect the root CA private key.
Certificate Lifecycle for IoT
- Provisioning: The ideal time to install device certificates is during manufacturing. The device generates a key pair on its secure element, sends the CSR to the RA, and receives a signed certificate. This avoids transporting private keys across any network.
- Operational use: The device presents its certificate when connecting to the cloud or peer devices. The server validates against its trusted CA store and checks revocation status via OCSP stapling or CRLs.
- Renewal: IoT device certificates should have shorter validity periods than server certificates (1 to 3 years) because devices are harder to patch if a vulnerability is discovered. Renewal is typically handled via a lightweight protocol like EST (Enrollment over Secure Transport) or ACME for constrained devices.
- Revocation: This is the hardest problem at scale. CRLs can grow large. OCSP requires devices to be online and adds latency. The practical approach for most IoT deployments is short-lived certificates combined with a real-time blocklist pushed to the edge (e.g., via the OTA update channel).
Constrained Device Considerations
- Memory: Full X.509 certificate chains can exceed 4 KB. For devices with limited flash, consider certificate compression or storing only the leaf certificate and trusting the CA pin on the server side.
- CPU: ECDSA is significantly faster than RSA on constrained MCUs. ECDSA P-256 or P-384 should be the default for new IoT designs.
- Secure element: If your device handles sensitive data or control commands, use a dedicated secure element (ATECC608A, SE050) for key storage and signing operations. This protects the private key even if the main MCU is compromised.
Operational Tooling
Managing PKI at scale requires automated tooling. We recommend:
- EJBCA or cfssl for the CA backend
- Vault PKI for cloud-native deployments with automatic certificate rotation
- A custom registration authority that integrates with your manufacturing test fixture for certificate provisioning during production
- Monitoring: track certificate expiry across the fleet and alert when renewal rates deviate from expected
At Altirratech EU, we design and operate PKI for IoT fleets. If you are planning a secure device deployment, we can help architect the certificate infrastructure.