Best practices for IoT device identity and lifecycle management

Why identity is the foundation of IoT security

The basic elements of security protection for IoT devices are familiar to most developers:

• A device must be safe from the risk of tampering, side-channel attacks, and other forms of physical attack
• A device must run authentic firmware which is protected against unauthorized changes
• The data on the device must be protected from unauthorized access, both at rest and in transit
• The device’s firmware must be capable of being updated remotely to maintain its protection against emerging cyber threats

For a deeper dive into the fundamentals of securing connected devices, check out our guide on IoT security.

All of these forms of protection are necessary. But they are not sufficient to provide for device security, since they all depend on one foundation: a secure identity, unique to each production unit. Establishing a device’s identity securely requires the use of a unique identifier, and a secret key— known only to the device manufacturer—for the device to encrypt its identifier.

Provisioning is the process of loading this unique identity into a device. Provisioning is one of the essential steps in the production of security-protected IoT devices: this article provides advice on best practices for provisioning and other aspects of establishing an IoT device’s secure identity.

But it is important to note that the developer’s objective should not be to implement secure provisioning: the objective is to secure the IoT device. Provisioning is simply one of the means to the end of implementing appropriate security protection.

By following device identity best practices, IoT device manufacturers will be able to rely on device identity as one of the building blocks of their fleet’s resistance to cyber-attack.

What is IoT device identity and why it matters

Device identity is a unique, cryptographically protected identifier which distinguishes any one IoT device from all others: it is the digital equivalent of a human fingerprint.

A secure device identity consists of encrypted keys, certificates, and hardware-based security elements which are embedded in the device during production – in the process called provisioning – and which cannot be easily cloned or modified.

Device identity is crucial for IoT security because it enables several vital security functions:

Authentication and authorization: networks can verify that devices connecting to it are legitimate and authorized. This prevents compromised or rogue devices from gaining unauthorized access.

Secure communication: a secure identity underpins encrypted communication between devices and cloud services, protecting data in transit from eavesdropping and tampering.

Trust establishment: a secure identity is the basis for trusted relationships with other devices, servers, and users, creating a foundation for secure IoT ecosystems.

Attack mitigation: strong device identity makes it extremely difficult for attackers to impersonate legitimate devices, to execute man-in-the-middle attacks, or to inject malicious devices into networks.

Lifecycle management: the security of over-the-air (OTA) updates, remote management, and device lifecycle tracking is reliant on the existence of a unique identifier for every device in a fleet.

Learn more about managing large fleets of connected devices in our article on IoT device management.

Without robust device identity, IoT devices become vulnerable to impersonation attacks, data breaches, and network infiltration. As IoT deployments grow in scale, device identity becomes ever more important to the maintenance of security across distributed, heterogeneous device populations.

Common challenges in managing identity across the device lifecycle

The practical implications of building a secure identity into a fleet of IoT devices numbering thousands or millions of units are different from the process of provisioning a handful of prototypes in the design laboratory. Development teams will need to find solutions to the following challenges affecting the process of establishing and maintaining IoT device identity.

Provisioning at scale

Embedded device OEMs will need to address the following challenges when provisioning a large fleet of IoT devices during the production process.

• Supply chain security ‐ assembling IoT devices can involve the orchestration of multiple suppliers and factories in a complex, often geographically distributed network. This exposes devices to numerous attack vectors. The device manufacturer has to put measures in place to maintain the confidentiality of keys across multiple sites and suppliers.
• Manufacturing infrastructure ‐ fitting production lines with secure provisioning equipment often requires substantial process design and investment.
• Key management ‐ the device manufacturer has to establish secure key generation, storage, and tracking systems that can handle millions of unique identities without compromising security or creating operational bottlenecks.
• Quality assurance ‐ each device needs to receive a valid, unique credential while preventing duplicates, errors, or gaps from arising in the provisioning process across multiple production facilities.
• Revocation planning ‐ the system must be able to handle compromised keys or to recall devices across a large fleet of deployed devices without disrupting legitimate devices.

Root of trust

The root of trust in an IoT device is an immutable, hardware-based component which serves as the ultimate source of trust for all security operations on the device. The root of trust contains cryptographic keys, certificates, or other security credentials which are established during manufacturing and which cannot be altered by software or external attacks.

This root of trust is typically implemented in a dedicated security hardware chip: a discrete Trusted Platform Module (TPM) or Hardware Security Module (HSM), or a secure enclave embedded in the main processor or microcontroller.

Challenges in establishing a root of trust across a fleet of production units include:

• Immutable foundation ‐ ensuring the root of trust cannot be modified or compromised requires careful hardware design and secure boot processes which make the development process more complex.
• Early establishment ‐ devices are most vulnerable to supply chain attacks and insider threats when they are in production. To defend against this threat, the root of trust needs to be implemented early in the production process.
• Performance trade-offs – the cryptographic operations underlying the verification of a root of trust can place high demands on the resource-constrained processors in IoT devices, affecting both their performance and battery life.
• Lifecycle management ‐ maintaining trust across device updates, key rotations, and potential hardware failures while preventing downgrade attacks requires sophisticated security procedures and resources.

Certificate renewal

The certificates which underpin device identity have defined lifespans ‐ when they expire, devices lose the ability to authenticate and communicate securely, potentially causing service outages or complete device disconnection. Certificates can also be compromised, or require updating to newer cryptographic standards.

To maintain a secure device identity across the life of a device, manufacturers need to master certificate renewal. This means addressing these challenges:

• Scale management – co-ordinating certificate renewals across millions of deployed devices requires robust infrastructure and automated systems to prevent service disruptions.
• Connectivity breakdown – IoT devices might operate in remote locations or in areas with little network bandwidth, making it difficult to deliver new certificates in a timely fashion, or to transmit renewal requests.
• Resource constraints – the limited processing power, memory, and data storage capacity in IoT devices can mean that the operations for certificate validation and renewal place a considerable overhead on system resources.
• Downtime risks ‐ certificate expiration can render devices inoperable. This is a particular risk for mission- or safety-critical systems.
• Legacy device support – across a large fleet, older devices may lack the ability to perform over-the-air certificate updates, requiring costly field replacement or manual intervention.

Tamper detection

Many IoT devices operate in unsecured environments to which attackers can gain access. This allows attacks to be carried out through direct interference with the hardware. Effective methods of tamper detection are required to enable the OEM to implement protection against the following types of attack:

• Key extraction attacks ‐ physical access allows sophisticated attackers to use techniques such as side-channel analysis, fault injection, or chip decapping to extract cryptographic keys and certificates which protect the device's identity.
• Hardware modification ‐ attackers can install malicious components, modify circuits, or replace security chips to bypass authentication mechanisms or to create counterfeit devices with stolen identities.
• Supply chain integrity ‐ tampering detection helps identify whether devices were compromised during manufacturing, shipping, or installation before being deployed in production networks.
• Identity theft ‐ without tamper detection, a compromised device's stolen identity credentials can be used to impersonate legitimate devices, potentially infiltrating entire networks.
• Compliance and trust ‐ many security frameworks require tamper-evident or tamper-resistant hardware to maintain certification and customer trust.

Detection of tampering should trigger responses such as key zeroization, device lockdown, or alert generation, ensuring that compromised identities cannot be exploited to breach an IoT network or the wider IoT infrastructure.

Secure remote management

IoT device manufacturers need to remain responsible for the security status of their products after they have left the factory and are in use in the field. The ability to remotely manage a millions-strong fleet of IoT devices is a crucial enabler for lifetime security.

For instance, remote management enables the OEM to deliver and install updates to certificates, keys or credentials, to patch devices to protect against emergent vulnerabilities which threaten devices’ identity, to recover devices which have already been compromised, or to monitor the health and security of a fleet of devices.

A system for secure remote management enables these functions to be performed efficiently at scale for a large fleet of IoT devices.

Best practices: what engineering teams should do

A unique identity, maintained and secured for the lifetime of an IoT device, is a foundation for securing the device, the code that it runs, and the data stored on and transmitted by it.

The main challenges faced by developers in establishing and maintaining a secure identity have been described above.

The best practices to implement in IoT device identity and lifecycle management are well established – and they start with the use of secure hardware.

Use secure hardware

An IoT device identity is established with cryptographically encoded certificates and keys. In theory, these certificates and keys can be stored, decoded and used by any microcontroller, application processor or other device that has sufficient cryptographic compute power – typically provided by an on-chip cryptographic hardware accelerator.

But standard microcontrollers and processors do not provide securely partitioned hardware which provides safe space for the storage of secret keys and certificates, and trusted memory space for the execution of cryptography and other security-critical functions.

Instead, secure hardware should be used for the storage of security secrets and for executing security-critical cryptographic and other functions. This hardware should be either:

• A Trusted Platform Module (TPM)
• A Hardware Security Module (HSM)
• A secure enclave ‐ a trusted, partitioned hardware block inside a microcontroller or application processor

Implement PKI early

A public key infrastructure (PKI) is a set of roles, policies, hardware, software and procedures governing the use of digital certificates and public key encryption.

By establishing the PKI early in the development process, IoT product manufacturers can embed the requirements for creating, managing, distributing, using, storing and revoking digital certificates and for managing public keys into the host device’s hardware and software.

The security, compute and memory implications of the PKI can be profound: failure to take account of these when developing the host product’s architecture can lead to severe shortfalls in compute, memory or interface provision. Putting the design right can involve substantial, costly and time-consuming rework late in the development cycle. In some cases, this can serve as a disincentive to the manufacturer to properly implementing a secure identity.

Rotate credentials

The establishment of a secure IoT device identity is just the start of its security protection. Manufacturers should also implement practices which maintain the security of an IoT device’s identity throughout its life.

Credential rotation is an important such practice. Its benefits include:

• Limits the impact of successful cyber-attacks ‐ regular rotation ensures that, if credentials are compromised, attackers have only a limited window of time in which to exploit them before new credentials replace the compromised ones.
• Prevents long-term attacks ‐ sophisticated attackers often conduct prolonged reconnaissance before exploitation. Frequent rotation disrupts these extended attack campaigns, invalidating the intelligence that they have gained about a device’s credentials.
• Cryptographic hygiene ‐ rotation enables migration to stronger cryptographic algorithms and longer key lengths as security standards evolve, ensuring device identities remain resilient against strengthened attack capabilities.
• Supporting compliance efforts ‐ many security frameworks mandate regular credential rotation to maintain certification and meet regulatory obligations for critical infrastructure deployments.
• Opportunities to detect compromises ‐ the rotation process provides regular checkpoints at which the manufacturer can verify a device’s integrity, and detect potential compromises that might otherwise go unnoticed.
• Reduces cryptographic wear ‐ some cryptographic implementations can weaken over time through repeated use. Rotation prevents potential vulnerabilities from arising through extended key usage.
• Mitigates supply chain risks ‐ regular rotation helps mitigate risks from compromised manufacturing processes or insider threats by regularly refreshing the foundation of a device’s security.

Encrypt communications

Data communications entering or leaving an IoT device are an obvious vector for cyber-attacks. Communications can expose a device to attack either directly – when an attacker snoops on data which has some inherent value or sensitivity – or indirectly, when the attacker uses the data as a way to uncover secrets which enable them to infiltrate either the device or the network itself.

Protection is achieved by encrypting all data shared over the IoT network.

Bind audit trails to identity

Secure provisioning provides a strong foundation for IoT device security, but no security measures can guarantee that a device will not be compromised. Auditing device and network behavior is an important method for monitoring the security of a fleet, and for detecting and responding to compromises.

Such auditing should be bound to device identity for several reasons:

• Accountability ‐ links all device actions to a specific, authenticated identity, enabling precise tracking of which device performed which operations, and when.
• Detection of compromised devices ‐ unusual patterns of activity tied to a device identity can reveal potential security breaches, unauthorized access, or attempts at impersonating a device.
• Forensic analysis ‐ when security incidents occur, identity-bound logs provide crucial evidence for understanding attack vectors, the scope of the compromise, and affected systems.
• Compliance ‐ many regulations require traceability of actions to specific devices for audit purposes and regulatory compliance.
• Non-repudiation ‐ cryptographically signed audit trails prevent devices from denying their actions, ensuring reliable evidence of a device’s behavior.
• Network security ‐ helps identify compromised devices that might be participating in botnet activities or lateral movement attacks within IoT networks.

Automate provisioning and revocation of identity

This article has described processes and techniques which enable an IoT device manufacturer to scale the provisioning of a secure identity up to a fleet of thousands or millions of units.

Automation of the provisioning process, and the process for revoking a device’s identity if it is known to have been compromised, are important techniques for securing identity at scale, since manual processes cannot handle millions of devices efficiently, creating security gaps and operational bottlenecks which compromise fleet-wide security.

Automated systems can also instantly revoke compromised identities and provision replacements, minimizing the window during which a compromised device or network is exposed.

In addition, manual processes are prone to mistakes, such as the provision of duplicate credentials, missed revocations, or configuration errors that create security vulnerabilities. Automation ensures uniform security policies and procedures are implemented across all devices, eliminating the creation of weak links in the chain of security.

Automated provisioning and revocation also enable an immediate response to threats without waiting for human intervention during critical security events.

How the FoundriesFactory platform helps create and maintain a more security-focussed IoT device identity

The FoundriesFactory™ service enables IoT device manufacturers to build, deploy and maintain security-focussed, connected products more rapidly, incorporating their own technology and applications, helping to reduce both time to market and engineering costs.

A modern framework for supporting development for secure identity and lifecycle management

The FoundriesFactory platform provides a ready-made infrastructure to help IoT product manufacturers to develop, test, validate, produce, maintain and decommission an entire fleet of devices.

The security-focussed features embedded in the FoundriesFactory platform allow manufacturers to implement the best practices described above as an integral part of the device development, production and maintenance workflow. The FoundriesFactory service focusses on security by design ‐ from device boot software to the cloud.

Secure boot and root of trust

The Foundries.io secure boot architecture includes support for the Arm® Platform Security Architecture (PSA) and Intel Platform Trust Technology (PTT) through the entire software stack, through to The Update Framework (TUF)-compliant secure product updates.

Secure boot implemented through the FoundriesFactory service is designed to facilitate an IoT device to boot the correct, trusted software.

The FoundriesFactory software also provides integral support for root of trust hardware, including via:

• The OP-TEE trusted execution environment (TEE) for Arm TrustZone-based systems-on-chip.
• Optionally, third-party hardware security element (HSE) features including key generation, secure key, credential and data storage, and cryptographic accelerators from vendors such as Rambus or NXP Semiconductors.
• The FoundriesFactory service can also be used to authenticate IoT devices for access to public cloud services including Microsoft Azure, Google Cloud and Amazon Web Services.

Key injection and provisioning

The FoundriesFactory platform includes a utility for the installation of keys on the production line, or on deployment using the SoC manufacturer’s tools.

Key revocation and rotation options in the platform are TUF-compatible.

Identity-bound OTA updates

TUF-compliant incremental OTA updates implemented through the FoundriesFactory platform use OSTree and Aktualizr-lite for firmware, blobs, the kernel, user space, and containers. All updates are encrypted and secured with per-device and/or per-fleet public keys.

OSTree and Aktualizr-lite provide incremental updates for the Linux® file system and optional containers, minimizing the operating system payload. Updates secured using the TUF specification are power-safe, and containers can be updated without a product restart.

Automatic roll-back takes place if an update fails for any reason.

The FoundriesFactory service also provides configurable access to remote devices using a Linux WireGuard secure VPN tunnel. Remote attestation allows for logging and auditing of software when it is running.

Conclusion

The reader can find above a collection of best practices for establishing and securing a unique identity for IoT devices. Techniques for IoT lifecycle management and secure device provisioning are also described.

It is essential to implement these practices and techniques: a secure device identity is the foundation of IoT security, ensuring that only the correct software can run on a properly authenticated device. A secure identity helps to repel many types of cyber-attack that are commonly launched at IoT devices, including impersonation, spoofing, and man-in-the-middle attacks.

But the practices described here should not be regarded as a simple checklist, or a set of boxes to be ticked: rather, device identity is a component of a complete security system, which should be designed to provide robust protection from end to end of the IoT network, from the SoC through the device’s communications interfaces, the network connecting the device to the internet, right up to the cloud.

Best practices are important indicators of the necessary steps to take, but security should be based on a secure architecture, and its effectiveness continually verified by reference to stringent security testing and continual monitoring of devices in the field: security is not a list of boxes to be ticked.

The FoundriesFactory service provides a strong basis for implementing essential processes such as secure boot and OTA updating, which enable a device manufacturer to simplify IoT device security and lifecycle management.

To find out more about the FoundriesFactory service and to view an in-depth demonstration of the service in action, go to foundries.io/contact/.