Device and IoT Identity Guide: Certificates and Onboarding

Every connected device needs an identity, and most still ship with a weak one. Cameras, sensors, medical devices, industrial controllers, network gear and employee laptops all authenticate to networks, cloud services and each other. Too often that identity is a shared default password, a key baked identically into every unit, or nothing at all. Device identity matters twice: devices are non-human identities that can be stolen and abused, and device trust is a signal zero trust access decisions depend on. This guide covers how devices get strong identities, how to onboard and retire them at scale, the regulation now banning default passwords, and how device identity feeds access decisions.

Key takeaways

Give each device a unique, hardware-protected identity, usually a private key and certificate, rather than a shared secret.
Separate manufacturer identity from operational identity: a factory-installed identity proves what the device is; an owner-issued identity proves it belongs to you.
Automate onboarding, renewal and revocation. Manual certificate handling does not scale to thousands of devices.
Default and universal passwords are now banned in some markets, and the EU Cyber Resilience Act brings security obligations for connected products.
Use device identity and health as inputs to access decisions for people and workloads.

Why device identity goes wrong

Default credentials left unchanged, or identical across every unit of a product.
Shared secrets embedded in firmware that, once extracted from one device, unlock them all.
No lifecycle: certificates that never expire, cannot be renewed remotely, or are never revoked when devices are retired or resold.
No inventory: devices on the network that nobody can attribute to an owner, a purpose or a patch level.
Management channels as a weak point: device management consoles and vendor remote access become high-value targets. The Stryker attack used a hijacked admin account in a device management platform to wipe devices.

How devices get strong identities

Mechanism	What it provides
Hardware root of trust (TPM, secure element)	Stores private keys so they cannot be copied, and can attest to device state
Manufacturer identity (IEEE 802.1AR IDevID)	A factory-installed key and certificate proving the device's make, model and serial number
Operational identity (LDevID)	A certificate issued by the owner after onboarding, used for day-to-day authentication
Attestation	Signed evidence about the device's hardware, firmware and configuration, checked before trust is granted
Ecosystem attestation certificates	Standards such as Matter use device attestation certificates chained to recognised roots

Devices authenticate with these identities using mutual TLS, 802.1X network access control or signed tokens. The Machine Identity, PKI and Certificate Lifecycle Guide covers certificate management.

Secure onboarding at scale

Zero-touch onboarding: standards such as FIDO Device Onboard let a device prove its manufacturer identity to an owner's onboarding service and receive credentials without anyone typing a password.
Automated enrolment: protocols such as EST (RFC 7030) and ACME issue and renew operational certificates automatically.
Ownership transfer: record and verify who owns each device as it moves through the supply chain, so a device cannot be onboarded by the wrong party.
Least privilege from the start: put new devices in a restricted network segment until they are verified and classified.

Managing the device identity lifecycle

Inventory: discover devices and link each to an owner, purpose, location and identity.
Issue: unique operational identity, protected in hardware where possible.
Renew: automatically, well before expiry, with alerts when renewal fails.
Update: signed firmware updates, verified by the device before installation. Protect the code signing keys. See the Cryptographic Key Management Guide.
Revoke and retire: revoke certificates and remove access when devices are replaced, lost, resold or decommissioned, and wipe credentials from them.

Regulation

This is an orientation, not legal advice.

UK PSTI Act: since 29 April 2024, consumer connectable products sold in the UK must not use universal default passwords, must publish a way to report vulnerabilities and must state a minimum security update period.
EU Cyber Resilience Act: manufacturers of products with digital elements must report actively exploited vulnerabilities and severe incidents from 11 September 2026, with the main security requirements applying from 11 December 2027. Requirements include secure-by-default configuration and protection against unauthorised access.
EU Radio Equipment Directive: cybersecurity requirements for internet-connected radio equipment apply from 1 August 2025.
Standards: ETSI EN 303 645 sets a baseline for consumer IoT, and NIST IR 8259A describes core device cybersecurity capabilities, including device identification.
Sector rules: medical devices and industrial systems have their own expectations. See the Healthcare Identity Security Guide and the OT and ICS Identity and Access Guide.

Device trust in access decisions

In a zero trust architecture, the device a person or workload uses is part of the access decision:

Managed laptops and phones carry a device certificate or hardware-bound key that the identity provider can check.
Posture signals, such as disk encryption, patch level and endpoint protection, adjust what the session can reach.
Unknown devices get limited or browser-only access.
Sessions can be bound to the device so stolen cookies do not work elsewhere. See the Token and Session Security Guide.

See the Zero Trust Identity Guide for how device signals fit the wider architecture.

Devices, NHIs and AI

A device identity is a non-human identity, with the same governance needs: an owner, least privilege, rotation and offboarding. Devices also host other NHIs, such as cloud connection keys, API tokens and service accounts, which are often the real target. Edge devices increasingly run AI models and agents that call cloud services; give those workloads their own scoped identities rather than reusing the device's. See the NHI Lifecycle Management Guide and the AI Infrastructure Workload Identity Guide.

Practitioner checklist

Inventory devices and assign each an owner, purpose and identity.
Require unique, hardware-protected identities in procurement, and reject products with shared default credentials.
Use manufacturer identity and attestation for zero-touch onboarding, then issue your own operational identity.
Automate certificate enrolment and renewal, and monitor expiry.
Sign firmware and protect the signing keys.
Revoke identities and wipe credentials when devices are retired or resold.
Protect device management platforms with phishing-resistant MFA and multi-admin approval for destructive actions.
Use device identity and posture in access decisions.

Device and IoT Identity Guide