An IoT fleet is thousands or millions of non-human identities that must be created in a factory, claimed by an owner, rotated in the field and retired, usually with no person present at any step. Most fleet compromises trace back to identity shortcuts: one credential shared across a product line, a claim key that never expires, certificates that cannot be renewed over the air, or devices resold with their old identity intact. This guide is about operating device identity at fleet scale: the provisioning models, the credential types, rotation and renewal, decommissioning and ownership transfer, monitoring, and what UK PSTI, ETSI EN 303 645 and the EU Cyber Resilience Act now expect. It is written for IoT platform engineers, product security teams and the identity teams who increasingly own device credentials. For the foundations of device identity and how device trust feeds access decisions, see the Device and IoT Identity Guide.
Key takeaways
- One device, one key pair, generated on the device. Per-device asymmetric keys in a secure element or TPM limit a compromise to a single unit; a shared secret turns one extracted device into a fleet compromise.
- Separate birth identity from operational identity. A manufacturer certificate proves what the device is; the owner should then issue its own operational credential that it can rotate and revoke.
- Bootstrap credentials are the weakest link. Claim certificates, enrolment group keys and setup codes must be scoped to provisioning only, time-limited and revocable.
- Plan rotation before shipping. If a device cannot renew its certificate over the air, its identity has a fixed death date, and a CA or root expiry can brick the fleet.
- Retirement is part of the lifecycle. Revoke credentials and remove registry entries when devices are decommissioned, returned or resold, or the old identity keeps working.
Why fleet identity is different
- Scale and automation: credentials are issued in a manufacturing line or at first connection, with no help desk and no human to approve each one.
- Long lives, constrained hardware: devices stay in service for a decade or more, often with limited storage, no real-time clock and intermittent connectivity, which complicates certificate validity checks and renewal.
- Physical exposure: attackers can buy a device and take it apart. Any secret stored in plain flash memory should be assumed extractable.
- Several parties: chip vendor, contract manufacturer, brand owner, cloud platform, installer and end customer each touch the identity, and each handover is a point where keys can leak or ownership can go unrecorded.
- Shared and composite devices: a gateway may present identities on behalf of dozens of sensors behind it, and a shared kiosk or medical cart may be used by many people. The device identity, the user identity and any child device identities need to be distinct in logs and policy, or identities drift and actions cannot be attributed.
Credential types for devices
| Credential | Strength | Weakness | Use it for |
|---|---|---|---|
| Per-device X.509 certificate, key generated in a secure element or TPM | Private key never leaves hardware; revocable individually; works with mutual TLS (for example MQTT over TLS on port 8883) | Needs a PKI, renewal process and clock handling | Default choice for connected fleets |
| Per-device X.509 certificate, key in software | Unique per device, revocable | Key can be extracted from flash by anyone holding the device | Low-value devices where hardware is not available, with short lifetimes |
| TPM endorsement key attestation | Hardware-rooted proof of a specific chip | Ties identity to platform support for TPM attestation | Gateways and industrial PCs |
| Per-device symmetric key (for example derived from a group key) | Simple, supported by constrained devices | Service holds the same secret; compromise of the group master key exposes every derived key | Prototypes and constrained devices, with a migration plan |
| Shared fleet key or default password | Easy to manufacture | One extraction compromises all devices; banned for consumer products under PSTI and ETSI EN 303 645 for passwords | Never |
| API key or cloud token embedded in firmware | None for identity | Same value in every unit, cannot be rotated per device | Never; issue per-device tokens from a per-device credential |
Hardware matters most where an attacker can gain physical access. ETSI EN 303 645 provision 5.4-2 says a hard-coded unique per-device identity used for security must resist tampering, and provision 5.4-3 rules out hard-coded critical security parameters in device software source code.
Provisioning models at fleet scale
Factory provisioning
The key pair is generated inside the secure element during manufacturing and a certificate is issued by the manufacturer's CA. This gives each device a birth certificate (an IDevID in IEEE 802.1AR terms) before it leaves the line. Control the manufacturer CA as tightly as any production signing key: whoever holds it can mint genuine-looking devices.
Claim-based provisioning
Devices ship with a bootstrap credential and swap it for a permanent one at first connection. AWS IoT fleet provisioning is an example: the device connects with a claim certificate whose policy only allows the provisioning topics, calls CreateCertificateFromCsr (keeping the private key on the device) or CreateKeysAndCertificate (the service generates the key), then calls RegisterThing within the one-hour lifetime of the certificate ownership token. A pre-provisioning hook can check the serial number against a manufacturing allowlist and deny unknown devices. AWS's guidance is to protect claim private keys, scope claim policies tightly, monitor their use and disable a claim certificate if it is compromised.
Trusted-user provisioning
An installer signs in to an app, which requests a temporary claim certificate (five minutes in AWS IoT) and passes it to the device with network settings. This avoids a long-lived claim key in every unit, at the cost of making the installer's account part of the trust chain, so protect it with strong authentication and least privilege.
Enrolment groups and attestation services
Azure IoT Hub Device Provisioning Service accepts X.509, TPM endorsement key or symmetric key attestation. Enrolment groups cover many devices sharing a CA or group key; individual enrolments cover single devices or TPM-only devices. For X.509 enrolments the certificate subject common name becomes the registration ID, so naming rules belong in the manufacturing specification. Microsoft recommends hardware security modules for device secrets.
Zero-touch onboarding into the owner's PKI
BRSKI (RFC 8995) lets a new device (the pledge) authenticate with its manufacturer IDevID to the owner's registrar. The registrar obtains a signed voucher (RFC 8366) from the manufacturer's MASA service, the pledge verifies the voucher, and then requests an owner-issued LDevID certificate over EST. Matter follows the same split for smart home devices: each device carries a unique Device Attestation Certificate chained to a Product Attestation Intermediate and a Product Attestation Authority listed on the Connectivity Standards Alliance Distributed Compliance Ledger; during commissioning the device proves possession of the attestation key, generates a new operational key pair and receives a Node Operational Certificate for the fabric.
| Model | Best for | Main risk | Control |
|---|---|---|---|
| Factory-issued certificate | Products with secure elements, regulated devices | Manufacturer CA or line compromise | CA in an HSM, issuance logs reconciled against production counts |
| Claim certificate | Large consumer and commercial fleets | Claim key extracted and used to register fake devices | Provisioning-only policy, allowlist hook, rate limits, revoke and reissue claims per batch |
| Trusted user | Installer-led deployments | Installer account takeover | Strong authentication, short claim lifetime, per-template permissions |
| Voucher based (BRSKI, Matter) | Enterprise network gear, smart home ecosystems | Weak voucher or attestation checks by the owner | Validate the full chain, check revocation, reject development certificates in production |
Rotating and renewing device credentials
- Decide lifetimes deliberately: birth certificates often last the life of the device; operational certificates should be short enough that rotation is exercised routinely across the fleet, and renewal should be tested on real hardware before launch.
- Renew with proof of the current key: the device generates a new key pair, signs a CSR and authenticates with its current certificate. Never let renewal fall back to a shared bootstrap secret.
- Handle offline devices: renew early (for example at half of lifetime) so devices that connect monthly still renew in time, and define a grace path for devices that return after expiry, such as re-attestation with the birth identity.
- Time: devices without a trusted clock cannot judge validity reliably. Get time from an authenticated source or design validity checks around it.
- Roots and intermediates: ship devices with more than one trusted root where possible, and make the trust store updatable. The expiry of Let's Encrypt's DST Root CA X3 cross-sign in 2021 broke IoT clients that did not trust the newer root. See the Certificate Expiry Outages and 47-Day TLS Certificates Guide.
- Do not use public TLS certificates for device identity: publicly trusted certificates are moving to 47-day lifetimes under the CA/Browser Forum schedule; device fleets need a private CA whose lifetimes you control.
- Rotate the backend too: cloud credentials, signing keys for firmware and the CA keys behind device certificates need their own rotation plan. See the Firmware and Boot Security Guide.
Decommissioning and ownership transfer
- Revoke the operational certificate and remove the device record, policies and group memberships from the IoT registry.
- Invalidate tokens and any cloud credentials derived from the device identity.
- Wipe owner data and operational keys on the device with a factory reset that returns it to its birth identity only.
- Record the change of custody for returns, refurbishment and resale, so a second owner cannot inherit the first owner's identity, data or cloud binding.
- Reconcile: regularly compare registry entries with devices that have actually connected, and retire identities that have been silent beyond a set period.
Treat this as the device version of leaver processing. See the NHI Offboarding and Decommissioning Guide.
Regulation and standards that shape fleet identity
- UK PSTI: since 29 April 2024 the Product Security and Telecommunications Infrastructure (Security Requirements for Relevant Connectable Products) Regulations 2023 require passwords on consumer connectable products to be unique per product or defined by the user, and unique passwords must not be based on incremental counters, public information or identifiers such as serial numbers unless processed with accepted encryption or keyed hashing. Cryptographic keys and API keys fall outside the regulation's definition of passwords, so key handling is governed by good practice rather than this rule. See the UK PSTI Act Guide.
- ETSI EN 303 645 V3.1.3: the consumer IoT baseline, including 5.1 no universal default passwords, 5.4 secure storage of sensitive security parameters and 5.5 secure communication.
- EU Cyber Resilience Act: in force since 10 December 2024, with the main obligations applying from 11 December 2027 according to the European Commission. See the EU Cyber Resilience Act Guide.
- NIST IR 8259A: the IoT device cybersecurity capability core baseline, whose capabilities include device identification, logical access to interfaces and software update.
Detection and measurement
- Duplicate identities: the same certificate or client ID connecting from two places at once indicates cloning or a shared credential. AWS IoT Device Defender audits include "Device certificate shared" and "Conflicting MQTT client IDs".
- Bootstrap misuse: claim certificates used outside the factory or installation windows, or registering devices whose serials are not in manufacturing records.
- Stale and revoked identities: revoked certificates still active, devices silent for months, and certificates past their expected age (Device Defender has checks for revoked device certificates still active and device certificate age).
- Over-permissive policies: device policies with wildcard topics or actions allow one compromised device to read or command others.
- Management console activity: bulk wipes, reprovisioning and policy changes by administrators.
| Metric | Target |
|---|---|
| Share of fleet with unique, hardware-protected keys | Rising; 100% of new products |
| Devices sharing a credential or client ID | Zero |
| Operational certificates renewed before expiry | Above 99%, with the remainder explained |
| Decommissioned devices with identities still active | Zero after the reconciliation cycle |
| Claim credentials older than their planned batch lifetime | Zero |
| Devices on policies flagged as overly permissive | Falling to zero |
A phased rollout for an existing fleet
- Inventory: list every device class with its credential type, where keys live, lifetimes, renewal capability and owner.
- Stop the bleeding: remove shared secrets from new firmware builds, scope bootstrap credentials to provisioning only and set an expiry on each claim batch.
- Stand up a private device PKI with the CA keys in an HSM, separate issuing CAs per product line or region, and published revocation.
- Pilot renewal on a small ring of devices in the field, including devices that are offline for long periods, and measure failures before widening.
- Migrate in waves by firmware release, keeping the old credential accepted only until the device has proved it holds the new one; roll back by re-enabling the previous credential for that wave only.
- Retire the legacy path once the share of devices on it is near zero, and treat stragglers as decommissioning candidates.
Small versus large fleets: a few hundred devices can use the IoT platform's built-in provisioning and CA integration; large or multi-cloud fleets usually need their own PKI, manufacturing integration and a voucher or attestation scheme that is not tied to one cloud.
Framework mapping
| Framework | Reference | How it applies |
|---|---|---|
| NIST SP 800-53 Rev. 5 | IA-3 Device Identification and Authentication | Unique identification and authentication of each device |
| NIST SP 800-53 Rev. 5 | IA-5(2) Public Key-based Authentication, SC-12 | Certificate validation and key management for device credentials |
| NIST SP 800-53 Rev. 5 | CM-8 System Component Inventory, SI-7 | Fleet inventory; integrity of firmware that holds identity |
| NIST CSF 2.0 | PR.AA-01, PR.AA-03, ID.AM-01 | Credentials for hardware managed; hardware authenticated; hardware inventory |
| CIS Controls v8.1 | 1.1 Enterprise Asset Inventory, 4.7 Manage Default Accounts | Know every device; remove default credentials |
| ISO/IEC 27001:2022 | A.5.9 Inventory of information and other associated assets, A.5.17 Authentication information | Asset records and credential handling |
| MITRE ATT&CK | T1078.001 Default Accounts, T1552.004 Private Keys, T1072 Software Deployment Tools | Default credentials, extracted device keys, abuse of fleet management tools |
| MITRE D3FEND | D3-CBAN Certificate-based Authentication, D3-CERO Certificate Rotation | Per-device certificates rotated on schedule |
Common failure patterns
- Secrets baked into every unit: one extraction or code leak exposes the whole product line. When the Rabbit R1 hard-coded API keys leaked with the product's source code, rotating them caused brief device downtime, showing how hard-coded keys tie fleet availability to a single secret.
- Immortal claim certificates: a bootstrap credential valid for years, with registration rights, lets anyone who extracts it enrol counterfeit devices.
- No over-the-air renewal: certificates expire on a fixed date across a cohort and devices drop off the network together.
- Identity not removed at end of life: returned or resold devices keep a working cloud binding.
- Accepting development attestation in production: test PAAs or development certificates left trusted let uncertified devices join.
- Fleet console as a single point of failure: management platforms can issue bulk commands; in the Stryker attack a hijacked administrator account used Intune's remote wipe against tens of thousands of devices. Protect fleet and provisioning consoles as privileged access.
Practitioner checklist
- Require per-device key pairs generated in a secure element or TPM for every new product.
- Remove shared keys, default passwords and embedded API keys from firmware.
- Scope bootstrap and claim credentials to provisioning only, give each batch an expiry and an allowlist.
- Issue owner-controlled operational certificates from a private CA kept in an HSM.
- Test over-the-air renewal, offline recovery and trust store updates before launch.
- Revoke and deregister identities at decommissioning, return and resale.
- Alert on duplicate identities, revoked certificates still active and overly permissive device policies.
- Protect IoT consoles and provisioning templates with phishing-resistant MFA and approval for bulk actions.
- Check consumer products against PSTI and ETSI EN 303 645, and plan for CRA obligations.
Standards and references
- ETSI: EN 303 645 V3.1.3 Cyber Security for Consumer Internet of Things: Baseline Requirements
- UK legislation: The Product Security and Telecommunications Infrastructure (Security Requirements for Relevant Connectable Products) Regulations 2023, Schedule 1
- IETF: RFC 8995 Bootstrapping Remote Secure Key Infrastructure (BRSKI)
- NIST: IR 8259A IoT Device Cybersecurity Capability Core Baseline
- European Commission: Cyber Resilience Act
- Connectivity Standards Alliance: Matter Handbook, Device Attestation
- AWS: Provisioning devices that don't have device certificates using fleet provisioning
- Microsoft Learn: Azure IoT Hub Device Provisioning Service concepts
Related NHI Mgmt Group resources: Device and IoT Identity Guide · IoT Security Guide · Machine Identity, PKI and Certificate Lifecycle Guide · Medical Device Security Guide · UK PSTI Act Guide. This guide summarises the UK PSTI regulations and the EU Cyber Resilience Act and is not legal advice.