The credential you put in a device at manufacture decides whether one stolen unit costs you one device or the whole fleet. Per-device X.509 certificates and pre-shared keys (PSKs) both authenticate IoT devices to a broker, gateway or cloud service, but they fail in very different ways once a fleet grows past a few hundred units. This guide compares the two as a design decision: the threat model behind each, how each works at fleet scale, what breaks, which controls fix it, and how to choose for a given product. It is written for device architects, IoT platform owners and security teams who review connected products. For the wider identity programme see the Device and IoT Identity Guide, and for fleet provisioning patterns see the Identity for IoT Fleets Guide.
Key takeaways
- The short answer: use a per-device certificate with the private key generated in a secure element or TPM for any fleet you cannot physically guard, and keep PSKs for constrained or legacy devices where each device gets its own high-entropy key.
- A shared PSK is a fleet-wide secret. IETF guidance in RFC 9257 warns that any party holding a group PSK can impersonate any other, and revoking one member means re-keying everyone.
- Certificates move the risk to the CA. A stolen device key exposes one device, but a stolen issuing CA key lets an attacker mint devices your platform will trust, so the CA needs production signing key protection.
- Expiry is the certificate failure mode, extraction is the PSK failure mode. Certificates brick devices when renewal is not designed in; PSKs leak when they are baked into firmware images.
- Both need a rotation and revocation path before shipping. EST re-enrolment for certificates and per-device key replacement for PSKs must exist on day one, because adding them to a deployed fleet is far harder.
The two models in plain terms
A pre-shared key is a symmetric secret that both the device and the service hold. The device proves its identity by showing it knows the key, typically through a TLS or DTLS PSK handshake (the PSK cipher suites first defined in RFC 4279 and the external PSK mode of TLS 1.3) or by signing a token with an HMAC. Because the service holds the same secret, anyone who reads the service's key store, or any device sharing that key, can act as the device.
A device certificate binds a public key to a device identity (serial number, device ID or registration ID) and is signed by a certificate authority the service trusts. The private key stays on the device and the service only stores the public certificate or the CA that issued it. Authentication normally happens through mutual TLS, for example MQTT over TLS on port 8883. AWS IoT documentation makes the point directly: keeping the private key on the device is a main benefit of X.509 over passwords or bearer tokens. IEEE 802.1AR formalises the idea as an IDevID, a manufacturer-installed identity that cannot be modified, and LDevIDs, locally significant identities an operator creates on top of it.
| Property | Pre-shared key | Per-device certificate |
|---|---|---|
| Secret held by the service | Yes, the same key (or the group key it was derived from) | No, only the public certificate or CA |
| Blast radius of one device extraction | Every device sharing the key; one device if keys are unique | One device |
| Blast radius of service-side breach | All keys in the store can be replayed | Low for the device store; total if the issuing CA key is stolen |
| Revoking one device | Delete its key; with a shared key, re-key the fleet | Deactivate or revoke the certificate |
| Expiry | None built in, which is why PSKs are rarely rotated | Built in; renewal must be designed or devices drop off |
| Device resources | Very low: HMAC and symmetric cipher | Asymmetric operations, certificate parsing, accurate time for validity checks |
| Infrastructure | Key generation, secure key store, injection process | PKI (root and issuing CAs), enrolment service, revocation, renewal |
| Identity privacy | PSK identity sent in clear in the ClientHello (RFC 9257) | TLS 1.3 encrypts the client certificate |
Threat model for pre-shared keys
RFC 9257 (Guidance for External PSK Usage in TLS, Informational, July 2022) is the clearest statement of what goes wrong with PSKs, and its findings map closely to IoT fleets.
- Group sharing: when more than two parties hold a PSK, any member can impersonate another, a non-member who can route traffic can rebind handshakes between honest members (the "Selfie" reflection attack is a case of this), and removing one member requires a new PSK for all the others. A fleet-wide key is the extreme version: one extraction from one unit compromises every unit.
- Low entropy: PSK-only modes are open to offline exhaustive search once an attacker captures a handshake. RFC 9257 recommends deriving PSKs from at least 128 bits of entropy and combining them with an ephemeral exchange (the TLS 1.3
psk_dhe_kemode) so that a later key leak does not expose recorded traffic. - Service-side theft: the server needs every device's key, or the master key it derives them from. A breach of that store, a debug export or a support tool with read access gives an attacker the ability to impersonate the whole fleet, which is a different and larger exposure than stealing a certificate database.
- Firmware extraction: a key compiled into a firmware image is recoverable by anyone who downloads the update file or dumps flash from a single unit. ETSI EN 303 645 provision 5.4-3 states that hard-coded critical security parameters in device software source code shall not be used, and provision 5.4-4 requires the relevant critical security parameters to be unique per device.
- Tracking: the PSK identity travels in clear in the ClientHello, so a passive observer can link connections from the same device, and an active one can target that device's traffic.
Derived keys reduce but do not remove the group problem. Azure IoT Hub Device Provisioning Service, for example, derives each device key as HMAC-SHA256 of the device registration ID keyed with an enrolment group key. Microsoft's documentation tells manufacturers to derive keys in the factory so the group key never ships on a device, because anyone who extracts the group key can derive the key for every device in the group. The same documentation positions symmetric keys as a starting point and for legacy devices with limited security features, and recommends TPM or X.509 attestation for stronger security.
Threat model for device certificates
- Device key extraction: if the private key is generated in software and stored in flash, a physical attacker can read it and clone that one device. The fix is to generate the key inside a secure element or TPM so it is never exportable; ETSI EN 303 645 provision 5.4-2 requires a hard-coded unique per-device identity to resist tampering by physical, electrical or software means. See IoT Device Identity with TPM and DICE Guide for the hardware options.
- Issuing CA compromise: the manufacturer or operator CA is the real crown jewel. Whoever holds its key can issue certificates for devices that do not exist, or for serial numbers that belong to genuine units. Treat it like a code signing key: offline root, issuing CA key in an HSM, signing ceremonies with dual control. The AnyDesk 2024 breach shows the cost when a signing key is exposed: the certificate was revoked, every release had to be re-signed and customers had to be told which versions to trust. A device CA compromise forces the same exercise across a fleet in the field.
- Enrolment abuse: the enrolment service is where a stolen bootstrap credential turns into a trusted identity. EST (RFC 7030) recommends TLS client certificate authentication for enrolment, with HTTP Basic or Digest only as a fallback inside TLS. A shared claim certificate in every unit recreates the group PSK problem one step earlier, so restrict what it can do and check serial numbers against a manufacturing allowlist.
- Validation gaps: services that accept any certificate chaining to a public root, skip revocation checks or ignore the subject identity let an attacker present any valid certificate. Pin the device CA and map the certificate subject to a registered device record.
How each works at fleet scale
Pre-shared keys done properly
- Generate per device: a unique random key of at least 128 bits for every unit, from a cryptographically secure generator on the provisioning station or derived from a master key held only in an HSM.
- Inject at the factory: write the key into protected storage (secure element, one-time programmable fuses or a locked flash region), never into the firmware image. ETSI EN 303 645 provision 5.4-1 requires sensitive security parameters in persistent storage to be stored securely.
- Register server-side: store each key in a dedicated secrets store with access logging, keyed by device ID, and keep the derivation master key out of application databases.
- Use forward secrecy: prefer TLS 1.3
psk_dhe_keor DTLS 1.3 so a later key leak does not decrypt recorded sessions. - Plan replacement: define how a device receives a new key over an authenticated channel and how the old one is deleted on both sides.
Certificates done properly
- Birth identity: generate the key pair inside the secure element on the production line and have the manufacturer CA sign a long-lived IDevID that names the device.
- Operational identity: at first connection the device uses its IDevID to enrol for a shorter-lived operational certificate (an LDevID) from the operator's CA, using EST
/simpleenrollunder/.well-known/est, a cloud provisioning service or a zero-touch protocol. See the IoT and Device Certificate Provisioning (EST, SCEP) Guide and the IoT Device Onboarding Guide. - Renewal: the device calls EST
/simplereenrollauthenticated with its current certificate well before expiry. RFC 7030 treats the same public key as renewal and a new key as rekey; prefer rekey. - Revocation: deactivate the certificate in the platform registry (AWS IoT requires a certificate to be
ACTIVEto connect) and publish CRL or OCSP status where gateways validate locally. See the Certificate Revocation Guide. - Algorithms: ECC P-256 keeps handshakes small on microcontrollers; AWS IoT accepts RSA of at least 2048 bits or ECC on P-256, P-384 or P-521.
Failure modes in the field
| Failure | Applies to | What it looks like | Control |
|---|---|---|---|
| Expired certificates brick devices | Certificates | Thousands of devices stop connecting on the same day; recovery needs a site visit | Renewal at 50 to 70 percent of lifetime, expiry monitoring, a recovery path using the IDevID |
| Expired CA or root | Certificates | Devices with a hard-coded trust anchor reject a renewed server or broker certificate | Updatable trust store, CA validity longer than device service life, cross-signing plan |
| Clock not set | Certificates | Constrained device without a real-time clock rejects valid certificates or accepts expired ones | Authenticated time source, tolerant first-boot logic that still checks chain and identity |
| PSK baked into firmware | PSKs | Key appears in every update image; researchers publish it | Per-device key in protected storage, never in the image |
| Fleet-wide PSK | PSKs | One teardown compromises every unit; rotation means a mass campaign | Unique key per device, or migrate to certificates |
| Server key store leak | PSKs | Attacker impersonates devices or the service at will | HSM-held master key, access logging, separation from application data |
| Shared claim credential | Certificates | Extracted bootstrap key used to enrol rogue devices | Narrow claim policy, serial allowlist, rate limits, revocable claim certificate |
Device service lives make expiry planning harder than it looks. AWS IoT documentation notes that certificates it generates expire at 31 December 2049, while certificates signed by your own CA expire on whatever date you set. Short lifetimes limit exposure but multiply renewal events; long lifetimes reduce renewal risk but make revocation more important. For broader outage lessons see the Certificate Expiry Outages and 47-Day TLS Certificates Guide.
Decision guidance
| Decision factor | Points to PSK (per device) | Points to certificates |
|---|---|---|
| Fleet size | Small, closed deployments (tens to low hundreds) with one operator | Thousands of units, multiple operators or resale |
| Microcontroller constraints | No room for asymmetric crypto or certificate parsing, no secure element | Secure element or TPM available; ECC hardware acceleration |
| Provisioning location | Trusted factory line injecting unique keys | Factory key generation in hardware, or field enrolment through EST or a claim flow |
| Revocation need | Low: devices rarely change hands | High: devices are resold, returned, transferred between tenants |
| Physical exposure | Devices in locked premises | Devices in public places, homes or customer sites |
| Third-party trust | Only your own service needs to verify the device | Gateways, partners or other clouds must verify identity without your secret |
| Regulation | Feasible if keys are unique and protected | Easier to show unique, tamper-resistant identity under ETSI EN 303 645 and the EU Cyber Resilience Act |
Small organisations with one product line usually do better buying a managed device PKI or using a cloud IoT service's provisioning than running their own CA; the cost of running a CA badly is higher than the cost of a PSK done well. Large manufacturers should run a manufacturer CA for IDevIDs with HSM protection and let operators or the cloud issue operational certificates. A hybrid is common and sound: a unique per-device symmetric key in a secure element as the factory credential, exchanged for a certificate at first connection.
Two worked scenarios
Scenario 1, 400 environmental sensors in one campus: battery-powered, a Cortex-M0 class microcontroller with no secure element, talking DTLS to an on-premises gateway the same organisation owns. A per-device 128-bit PSK injected at installation, stored in the gateway's secrets store and used with DTLS 1.3 PSK with ephemeral Diffie-Hellman is a defensible choice. The risks to manage are the gateway key store and the installer's process. The decision changes if the sensors are ever exposed to the public or connect to a third-party cloud.
Scenario 2, 250,000 consumer smart plugs: sold through retail, installed in homes, connected to the manufacturer's cloud, expected to work for ten years. Every unit is in an attacker's hands on day one. A fleet-wide PSK would be broken by the first teardown, and ETSI EN 303 645 rules out hard-coded credentials. The right design is a secure element generating the key on the line, an IDevID signed by an HSM-backed manufacturer CA, cloud enrolment for an operational certificate, renewal by re-enrolment and revocation on return or ownership transfer.
Migrating a fleet off shared keys
- Inventory: list every device model, firmware version and credential type. Find shared keys by checking whether the service validates many devices with one key.
- Stop the bleeding: change manufacturing for new units first, so no more devices ship with the shared key.
- Build the target: stand up the enrolment endpoint (EST or the cloud provisioning service) and test renewal and revocation on a lab fleet, including a forced expiry.
- Pilot ring: ship firmware to a small percentage of devices that generates a key, enrols over the existing authenticated channel and switches to the certificate. Keep the old credential accepted for those devices until telemetry confirms the switch.
- Expand in rings: 1 percent, 10 percent, then the rest, watching failed connection rates per ring.
- Retire the shared key: once migration reaches the target, remove the shared key from the service so extracted copies are useless. Devices that never migrated go into a quarantine policy with limited access.
- Rollback: keep the previous firmware signed and available and keep the old credential valid per device until success is confirmed, so a failed rollout reverts instead of bricking.
Firmware updates must themselves be authenticated, or the migration becomes an attack path. See the IoT Secure Firmware Update Guide (SUIT, signed OTA).
Detection and measurement
- Same identity, many places: alert when one device ID or certificate connects from two networks or two sessions at once, the clearest sign of a cloned credential.
- Enrolment anomalies: new enrolments for serial numbers not in the manufacturing record, bursts of enrolments from one source, or claim credential use outside expected windows.
- Expiry horizon: track certificates due to expire in 30, 60 and 90 days; AWS IoT Device Defender has a "Device certificate expiring" audit check for this purpose.
- Key store access: log every read of the PSK store or derivation master key and alert on bulk reads.
Metrics that show the design is working:
- Percentage of devices with a unique credential (target 100 percent).
- Percentage of device keys generated in, and non-exportable from, hardware.
- Renewal success rate per renewal window, and devices lost to expiry per quarter (target zero).
- Mean time to revoke a device after it is reported lost, returned or compromised.
- Number of shared or hard-coded credentials remaining in shipping firmware (target zero).
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev. 5 | IA-3 Device Identification and Authentication; IA-5 Authenticator Management; SC-12 Cryptographic Key Establishment and Management; SC-17 Public Key Infrastructure Certificates | Unique device authentication, key lifecycle and PKI operation |
| NIST CSF 2.0 | PR.AA-01, PR.AA-03, PR.DS-02 | Hardware identities managed and authenticated; data in transit protected |
| NIST IR 8259A | Device identification capability | Baseline expectation that a device can be uniquely identified |
| ETSI EN 303 645 | Provisions 5.1-1, 5.4-1 to 5.4-4, 5.5-1 | No universal default credentials, secure storage, no hard-coded parameters, per-device critical parameters |
| ISO/IEC 27001:2022 Annex A | 5.16 Identity management; 5.17 Authentication information; 8.24 Use of cryptography | Identity lifecycle, credential handling, key management |
| MITRE ATT&CK | T1552.004 Private Keys; T1588.004 Digital Certificates; ICS T1694 Insecure Credentials | Key theft, attacker-obtained certificates, hard-coded or weak device credentials |
| MITRE D3FEND | D3-CBAN Certificate-based Authentication; D3-MAN Message Authentication | Defensive techniques for device authentication |
Where identity fits
Every device credential is a non-human identity with an owner, a lifecycle and a blast radius. Register devices in the same inventory discipline as service accounts and workload identities, assign an owning team per product line, and apply the same rule as for secrets: no shared credentials, no credentials in code, rotation tested before it is needed. See the Machine Identity, PKI and Certificate Lifecycle Guide for the certificate side and Machine Identity Management vs Secrets Management for where PSK stores sit.
Practitioner checklist
- Confirm no credential is shared across devices, in the factory image or in the service configuration.
- Generate device keys in a secure element or TPM wherever the bill of materials allows.
- Keep the issuing CA key in an HSM with dual control, and the root offline.
- Use PSKs only with at least 128 bits of entropy, one key per device and an ephemeral key exchange.
- Design and test renewal and forced expiry before the first unit ships.
- Make the trust store updatable and keep CA validity beyond device service life.
- Restrict any bootstrap or claim credential to enrolment only and allowlist serial numbers.
- Alert on concurrent use of one device identity and on bulk reads of key stores.
- Document a revocation runbook for lost, returned and transferred devices.
Standards and references
- IETF: RFC 9257 Guidance for External Pre-Shared Key (PSK) Usage in TLS
- IETF: RFC 7030 Enrollment over Secure Transport
- ETSI: EN 303 645 Cyber Security for Consumer Internet of Things: Baseline Requirements
- IEEE: 802.1AR Secure Device Identity
- NIST: IR 8259A IoT Device Cybersecurity Capability Core Baseline
- NIST: SP 800-53 Rev. 5
- Microsoft: Symmetric key attestation with Azure IoT Hub Device Provisioning Service
- AWS: X.509 client certificates in AWS IoT Core
Related NHI Mgmt Group resources: Device and IoT Identity Guide, Identity for IoT Fleets Guide, PKI Basics Guide, HSM vs TPM vs Secure Enclave, IoT Security vs OT Security.