IoT Identity, Access, and Key Management
Domain 4 is about knowing exactly who a device is, what it may do, and how its secrets are created, stored, rotated and revoked across a fleet of thousands.
Device identity building blocks
- IEEE 802.1AR DevID: a per-device X.509 identity installed at manufacture; the reference model for IoT device certificates.
- DICE / hardware root of trust: a device identity key derived from immutable hardware, enabling attestation rather than mere assertion.
- PUF: derives a key from physical silicon variation, so the key is never stored in memory at all.
- Private keys must be generated on-device inside a secure element and marked non-exportable. Vendor-installed or server-generated keys are a supply-chain exposure.
Onboarding and lifecycle
- BRSKI (RFC 8995) combines a manufacturer voucher with EST to bootstrap trust from vendor to owner PKI without a pre-shared secret.
- EST and SCEP issue certificates over the air; EST with TLS client authentication is the modern default.
- Certificate lifetime must match the device's renewal capability: short-lived with automated renewal, or long-lived with reliable revocation (OCSP/CRL) if the device cannot renew.
- Rotation covers keys, certificates and passwords; stagger it so the fleet completes rotation before expiry.
- Revocation at scale is the hard part: CRL size, and OCSP reachability from constrained networks. Short-lived certificates shrink the revocation problem.
Authorisation
Least privilege enforced at the broker or API gateway, per-device roles, and a zero-trust posture that authenticates and authorises every connection rather than trusting anything inside the perimeter.
Worked example
Five thousand field sensors need identities. A vendor proposes one shared key plus server-generated certificates. Reasoning: the shared key destroys attribution and per-device revocation, and server-side key generation exports every private key. Correct design: each sensor's secure element generates its own keypair, only the public key goes to the CA, EST issues a 90-day certificate, renewal begins at day 60, and the short lifetime keeps revocation manageable on an intermittent LPWAN.
Traps that cost marks
- Hard-coded or shared credentials across a product line.
- Long-lived self-signed certificates justified as internal traffic.
- Designing issuance but not revocation and renewal.
- Storing private keys in the firmware image or fetching them from a cloud secret store at every boot.