Prioritise hardware-backed key storage when devices are physically exposed, widely distributed, or hard to retrieve after deployment. In those conditions, software-only key storage makes cloning and extraction much easier. Hardware-backed custody matters most when key theft would let an attacker impersonate the device or preserve trust after compromise.
When hardware-backed storage becomes the better IoT default
Hardware-backed key storage is the safer choice when an IoT device can be lost, stolen, opened, or cloned after deployment. Once keys live in general-purpose storage, an attacker with physical access or a software foothold has a much easier path to extraction and device impersonation. For fleets that operate outside controlled facilities, the custody model matters as much as the crypto algorithm.
The practical question is not whether the device uses encryption, but whether the key can be copied at scale. Hardware-backed custody raises the cost of extraction, makes offline cloning harder, and helps preserve trust boundaries when devices spend years in unattended or semi-trusted environments. That is why it is especially important for field devices, remote sensors, and anything that must keep authenticating long after provisioning.
Hardware-backed storage is also the right answer when key compromise would create durable downstream risk. If a stolen key can sign updates, join a private network, or impersonate a device to upstream systems, the incident is no longer limited to one unit. In that setting, the storage decision becomes a trust decision, not just a hardening choice. See Dropbox GitHub breach 2022 for an example of how exposed keys can cascade into broader access and rotation work.
What changes in practice when the device leaves your premises
The strongest trigger is physical exposure. A device mounted in a cabinet, shipped to customers, embedded in industrial equipment, or deployed in public space cannot be assumed to remain under trusted custody. At that point, software-only storage has to defend against both extraction and cloning, and it usually loses that contest once the attacker can image storage or tamper with the device.
Wide distribution is another decisive factor. The more units you ship, the more likely one will be recovered, tampered with, or reverse engineered. A single weak storage choice can scale into a fleet-wide identity problem, because every copied key extends the same trust relationship. That is why hardware-backed storage is most valuable when the fleet is large, the update path is long-lived, or the device identity gates access to sensitive services.
Retrievability matters too. If a device is hard to collect after compromise, you should assume remediation must happen remotely. Hardware-backed storage gives you a better chance of preserving the device’s identity while you rotate credentials, revoke trust, or quarantine the unit. Without that protection, compromise may require treating the whole device as replaceable rather than recoverable.
How to decide whether the extra protection is worth it
Not every IoT device needs a secure element or TPM-class design, but the burden of proof is on the software-only option. If the device authenticates to production systems, controls physical equipment, or carries a long-lived trust anchor, hardware-backed storage usually pays for itself in reduced blast radius. If the device is cheap, disposable, and low trust, software storage may be acceptable only when the key can be rotated quickly and the operational impact of cloning is small.
Hardware-backed storage is also most compelling when credential lifecycle is hard. Long-lived secrets, poor field access, and delayed replacement all increase the chance that a stolen key remains useful. In those cases, the storage mechanism should be evaluated alongside enrollment, rotation, revocation, and attestation, not as a standalone chip decision. For key lifecycle expectations, NIST SP 800-57 Key Management is the right reference point.
For devices that authenticate over APIs or brokered services, access design matters as much as storage design. A key that cannot be exported is still dangerous if it grants excessive privilege or can be replayed broadly. Teams should pair hardware-backed storage with narrow scopes, short cryptoperiods, and a clear revocation path. The storage tier reduces extraction risk, but it does not compensate for weak authorization.
Risk and Threat Considerations
Hardware-backed storage is a control against key extraction, but it is not a complete compromise barrier. Threats usually exploit the easiest path available, which may be physical tampering, firmware compromise, debug-port abuse, or simple overprivilege after the key is obtained. The key risk is not just theft, it is the ability to reuse that theft as durable device impersonation across a fleet or a backend trust chain.
Failure mechanism: Software-only storage leaves secrets readable by the OS, file system, or debug-capable attacker, so compromise of one device can become offline cloning, counterfeit enrollment, or persistent unauthorized access.
Impact: Attackers can impersonate devices, preserve access after cleanup, and force fleet-wide rotation or re-enrollment, which is often far more expensive than the original compromise.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-57, NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-57 | NIST-800-57 — Key Management | IoT key custody decisions depend on key lifecycle, rotation, and cryptoperiod planning. |
| Recommendation — Define cryptoperiods, rotation, and destruction requirements before trusting device-held keys. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | IoT device keys are authenticators whose storage and lifecycle affect compromise risk. |
| Recommendation — Manage device authenticators so keys are protected, rotated, and revoked on compromise. | ||
| CIS Controls v8 | CIS-5 — Account Management | IoT device credentials behave like managed accounts and need lifecycle control. |
| Recommendation — Inventory device credentials and remove or rotate them when devices are retired or compromised. | ||
| ISO/IEC 27001:2022 | A.8.24 — Use of cryptography | Hardware-backed storage is a cryptographic protection choice for secrets used by IoT devices. |
| Recommendation — Protect device keys with stronger cryptographic custody where exposure would be costly. | ||
Practitioner Guidance
What to prioritise: Prioritise hardware-backed storage first for devices that are physically exposed, long-lived, or able to reach production systems with meaningful privilege. The storage decision should follow the blast radius, not the unit cost.
What to verify: Confirm that the chosen hardware actually protects the key from export, that provisioning is controlled, and that you have a documented revocation path if the device is lost or cloned. If you cannot rotate or revoke the credential cleanly, the control is weaker than it looks.
Practitioner takeaway: The key question is not whether the device is “secure enough” in general, but whether stolen credentials would still be useful after physical compromise. If the answer is yes, hardware-backed custody should be the default.
Related resources from NHI Mgmt Group
- Should organisations prioritise hardware-backed key storage before shortening renewal cycles?
- Should organisations prioritise external exposure or internal credential governance first?
- Why is hardware-backed key storage not enough for code signing security?
- What is the difference between hardware-backed key storage and white-box cryptography?