Device and IoT Identity Guide

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 that zero trust access decisions depend on. This guide covers how devices get strong identities, how to onboard and retire them at scale, the regulation that now bans universal default passwords, how to detect misuse and how device identity feeds access decisions. It is for IoT and OT engineers, PKI and IAM teams, device makers and the buyers who specify connected products.

Key takeaways

• Unique, hardware-protected identity per device: give each device its own private key and certificate, held in a TPM or secure element, rather than a shared secret. ETSI EN 303 645 says passwords "should not be used for machine-to-machine authentication".
• Separate manufacturer identity from operational identity: IEEE 802.1AR distinguishes the supplier's Initial Device Identifier (IDevID), which proves what the device is, from Local Device Identifiers (LDevIDs) that the owner issues to prove it belongs to you.
• Automate onboarding, renewal and revocation: FIDO Device Onboard, BRSKI (RFC 8995), EST (RFC 7030) and ACME (RFC 8555) remove the manual steps that do not scale to thousands of devices.
• Regulation has arrived: the UK PSTI regime has banned universal default passwords on consumer connectable products since 29 April 2024, and the EU Cyber Resilience Act's reporting obligations apply from 11 September 2026, with its main requirements from 11 December 2027.
• Device trust is an access signal, and management consoles are privileged: use device identity and posture in access decisions, and protect the platforms that can wipe or reconfigure every device as tier-zero systems.

Why device identity goes wrong

Most device identity failures come from decisions made at the factory or at procurement, which is why they are hard to fix once units are in the field.

• Default credentials: left unchanged, or identical across every unit of a product. ETSI EN 303 645 notes that universal default usernames and passwords such as "admin, admin" have been "the source of many security issues in IoT". MITRE ATT&CK tracks the abuse of factory accounts as T1078.001 Default Accounts and lists Ember Bear using default credentials on internet-facing IP cameras for initial access.
• Shared secrets in firmware: one key embedded in every unit, so extracting it from one device unlocks them all. ETSI EN 303 645 provision 5.4-3 says hard-coded critical security parameters in device software source code "shall not be used", because reverse engineering finds them.
• Keys behind the device as well as on it: cloud API keys in device or companion code are shared with everyone who gets a copy. In the Rabbit R1 Hard-Coded API Keys 2024 case, keys for text-to-speech, maps and email services were hard-coded in the code behind an AI gadget, and the leaked email key was used to send defamatory emails.
• No lifecycle: certificates that never expire, cannot be renewed remotely, or are never revoked when devices are retired, returned or resold.
• No inventory: devices nobody can attribute to an owner, a purpose or a patch level.
• Management channels as a weak point: device management consoles, vendor support tools and remote access become high-value targets because one identity can reach every device.

How devices get strong identities

A strong device identity is unique to one unit, its private key cannot be copied off the device, and a verifier can check it cryptographically.

Devices then authenticate with these identities using mutual TLS, 802.1X port-based network access control or signed tokens. NIST IR 8259A puts Device Identification first among the six capabilities in its core baseline (Device Identification, Device Configuration, Data Protection, Logical Access to Interfaces, Software Update and Cybersecurity State Awareness), a useful procurement checklist. ETSI EN 303 645 provision 5.4-2 adds that where a hard-coded unique per-device identity is used for security, it must resist physical, electrical or software tampering. See the Machine Identity, PKI and Certificate Lifecycle Guide for certificate management and the Firmware and Boot Security Guide for roots of trust.

Secure onboarding at scale

Onboarding is the moment a device first proves what it is and receives the credentials it will use in your environment. NIST SP 1800-36, finalised in November 2025, describes the two attacks this step must prevent: a device convinced to join an unauthorised network that then takes control of it, and a malicious device infiltrating your network. Trust comes from "attesting and verifying the identity and posture of the device and the network" before network credentials are handed over.

• Ownership transfer: record and verify who owns each device as it moves through the supply chain, so it cannot be onboarded by the wrong party. The FIDO Alliance has published a Voucher Transfer Protocol review draft to standardise how vouchers move between vendors.
• Least privilege from the start: keep new devices in a restricted segment until they are verified and classified.

See the Network Access Control (NAC) Guide for 802.1X admission and the IoT Security Guide for the wider device programme.

Managing the device identity lifecycle

A device identity lives as long as the device, often a decade in industrial and medical settings, so plan each stage before deployment.

1. Inventory: discover devices and link each to an owner, purpose, location, firmware version and identity. NIST IR 8259A notes that a unique logical identifier supports automated device management and monitoring.
2. Issue: a unique operational identity, generated and kept in hardware where possible, with a validity period your PKI can actually renew.
3. Renew: automatically, well before expiry, with alerts when renewal fails.
4. Update: signed firmware updates that the device verifies before installation. ETSI EN 303 645 provision 5.3-10 requires devices to verify updates delivered over a network interface. Protect the signing keys: in the MSI Signing Keys Leak 2023, firmware image signing keys for 57 products and Intel Boot Guard keys for 116 products were found in data leaked by a ransomware gang, according to Binarly. See the Cryptographic Key Management Guide.
5. Re-key after incidents: have a tested way to replace device credentials in the field if a CA, a signing key or a batch of devices is compromised.
6. Revoke and retire: revoke certificates and remove access when devices are replaced, lost, returned, resold or decommissioned, and wipe credentials from them before disposal.

Regulation

This section summarises the rules for orientation and is not legal advice; check the legal text for your obligations.

Sector rules add their own expectations for medical devices and industrial systems. See the EU Cyber Resilience Act Guide, the Healthcare Identity Security Guide, the Medical Device 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. NIST SP 800-207 says access is determined by dynamic policy "including the observable state of client identity, application/service, and the requesting asset", and that "no asset is inherently trusted".

• Device-bound credentials: managed laptops and phones carry a device certificate or hardware-bound key that the identity provider can check at sign-in.
• Posture signals: disk encryption, patch level and endpoint protection status adjust what the session can reach. See the Device Compliance and Endpoint Posture Guide.
• Unknown devices: get limited or browser-only access.
• Session binding: bind sessions to the device so stolen cookies do not work elsewhere. See the Token and Session Security Guide.
• The management plane itself: the console that enforces device trust can also wipe every device. In the Stryker Cyberattack 2026, a source told BleepingComputer the attacker compromised an administrator account, created a new Global Administrator and used Intune's wipe command on nearly 80,000 devices in about three hours. Phishing-resistant MFA, least privilege and multi-admin approval for bulk actions limit this.

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. The Verkada Camera Breach 2021 shows the pattern from the vendor side: according to Verkada, attackers found admin-level support credentials on an internet-facing Jenkins server and used them to view cameras at 97 customers.

Edge devices increasingly run AI models and agents that call cloud services. Three practices keep that manageable:

• Separate identities for separate workloads: give each AI workload or agent on the device its own scoped credential rather than reusing the device certificate, so revoking one does not take down the other and audit logs show which acted.
• Release models and keys on attestation: RFC 9334 describes a manufacturer service that releases a machine learning model, or the key to decrypt it, only after the device's protected environment passes remote attestation.
• No model provider keys in firmware: AI API keys embedded in device code are shared secrets with a cost attached; broker calls through a backend that holds the key, or issue short-lived tokens per device.

See the NHI Lifecycle Management Guide and the AI Infrastructure Workload Identity Guide.

Detection and monitoring

Strong identities tie every connection to one known device, which makes misuse visible. Watch for:

• Default and shared credential use: successful logons with factory usernames, or one credential used from many devices at once (MITRE ATT&CK T1078.001).
• Identity anomalies: the same device certificate presented from two places, a certificate presented after revocation, or a device authenticating with an IDevID where an LDevID is expected.
• Enrolment anomalies: EST or ACME requests for devices that are not in the inventory, unusual re-enrolment volumes, or failed attestation.
• Firmware and configuration drift: firmware versions that do not match the signed release list, or configuration changes outside a change window.
• Management console actions: new global administrators, role changes and bulk wipe, retire or reset commands should page someone immediately.

Feed onboarding, PKI and management platform logs into the SIEM alongside network telemetry. See the OT Asset Visibility Guide.

Framework mapping

Indicative alignment by NHI Mgmt Group, not an official mapping. Control IDs were checked against NIST CSWP 29 (CSF 2.0), the NIST SP 800-53 Rev. 5 catalogue, the CIS Controls v8.1 control list, a published ISO/IEC 27001:2022 Annex A list and the OWASP NHI Top 10 2025.

Common failure patterns

• The factory password survives deployment: changing it on hundreds of units is slow, so nobody does. Buy products with unique per-device credentials or no passwords.
• One key for the whole product line: a shared secret in firmware means one teardown compromises every customer. ETSI EN 303 645 rules this out for consumer products.
• Signing keys stored like ordinary files: the MSI Signing Keys Leak 2023 put firmware and Boot Guard keys in the hands of a ransomware gang; signing keys belong in HSMs with tightly limited access.
• Vendor support credentials with reach into every customer: the Verkada Camera Breach 2021 turned one exposed support credential into camera access across many customers.
• Certificates that cannot be renewed in the field: renewal was never built, so a compromised key stays valid for years.
• Destructive actions without a second approver: one compromised administrator in the device management platform can wipe the estate, as in the Stryker Cyberattack 2026.
• Retired devices keep their identity: returned, resold or scrapped units still hold valid certificates and Wi-Fi or cloud credentials.

Metrics that show progress

See the Identity Security Metrics Guide for how to report these.

Implementation roadmap

Practitioner checklist

• Inventory devices and assign each an owner, purpose, location and identity.
• Require unique, hardware-protected identities in procurement, and reject products with universal default credentials.
• Use manufacturer identity (IDevID) and attestation for zero-touch onboarding, then issue your own operational identity (LDevID).
• Automate certificate enrolment and renewal with EST or ACME, and alert on failed renewals and upcoming expiry.
• Remove hard-coded keys from firmware and companion apps; broker cloud and AI API calls through a backend.
• Sign firmware, verify updates on the device, and keep signing keys in HSMs.
• Segment new and unverified devices until they are classified.
• Protect device management platforms with phishing-resistant MFA, least privilege and multi-admin approval for destructive actions.
• Monitor for default credential use, revoked certificates, enrolment anomalies and bulk management actions.
• Revoke identities and wipe credentials when devices are retired, returned or resold.
• Use device identity and posture in access decisions for people and workloads.

Standards and references

• IEEE: 802.1AR Secure Device Identity
• ETSI: EN 303 645 V3.1.3 Cyber Security for Consumer Internet of Things: Baseline Requirements
• NIST: IR 8259A IoT Device Cybersecurity Capability Core Baseline
• NIST: SP 1800-36 Trusted IoT Device Network-Layer Onboarding and Lifecycle Management
• FIDO Alliance: FIDO Device Onboard (FDO) Specifications
• IETF: RFC 8995 Bootstrapping Remote Secure Key Infrastructure (BRSKI)
• IETF: RFC 7030 Enrollment over Secure Transport (EST)
• IETF: RFC 9334 Remote ATtestation procedureS (RATS) Architecture
• European Commission: The Cyber Resilience Act, Summary of the legislative text
• UK Government: The UK Product Security and Telecommunications Infrastructure (Product Security) regime
• European Commission: Radio Equipment Directive (RED)
• MITRE ATT&CK: T1078.001 Valid Accounts: Default Accounts

Related NHI Mgmt Group resources: Machine Identity, PKI and Certificate Lifecycle Guide · IoT Security Guide · OT and ICS Identity and Access Guide · Zero Trust Identity Guide · Human vs Non-Human Identity