8.2 Device Security and Authentication

Author: Zhang Hongyuan · © 2016–2026 · All Rights Reserved · Copyright & License

8.2.1 Device Identity Management and Authentication

Device identity authentication is the first gate of device access security. If an identity is forged or bypassed, all the encryption, authorization, and audit that follow rest on a false foundation. IoT devices range from sensors that cost a few cents to edge gateways, with vast gaps in compute, storage, and power budget. An authentication scheme must trade off between "secure enough" and "fits on the device" — no universal solution exists.

The Unique Device Identifier: The Origin of Identity

Every device should be assigned a globally unique, hard-to-alter identity at the factory. Common approaches include:

• Hardware binding: use the chip's unique serial number (such as an MCU's UID) or a device ID burned into a secure element.
• MAC address: low cost, but a MAC can be changed in software and cannot serve alone as a root of trust.
• Thing-model identifier: the platform assigns each device a UUID or uses the certificate subject as its identifier.

In practice, the unique device identifier must be bound to cryptographic credentials (a certificate or a key); the identifier alone provides no authentication capability — it is only the carrier of the "who are you" claim. For production environments, the identifier should be fixed in a secure storage area (such as one-time programmable registers) and read by the bootloader during initialization, after which write access is locked down (the secure boot mechanism is developed in Section 8.2.2).

X.509 Certificates and Public Key Infrastructure: The Trust Chain of Strong Authentication

X.509 certificates are the most mature form of public key infrastructure (PKI). The device holds a private key and a certificate; the platform holds the CA root certificate. During a Transport Layer Security (TLS) handshake, the device presents its certificate and the platform verifies the certificate signature, while the device also verifies the platform's server certificate — achieving mutual authentication (mutual TLS, mTLS).

Advantages: compromising one device's private key does not affect other devices (asymmetric security); revocation is supported (CRL/OCSP); large-scale deployments are manageable.

Costs: certificate chain verification involves asymmetric operations, which can significantly increase the time cost on resource-constrained MCUs; certificate storage overhead is comparatively large; a CA and an issuance process must be deployed, at a high operational cost. X.509 is therefore better suited to gateways, edge servers, or smart devices with higher security requirements.

Pre-Shared Keys (PSK): Ultra-Lightweight

For sensors with severely constrained compute and storage (for example, an MCU with only tens of KB of RAM), a full certificate handshake is unaffordable. The pre-shared key (PSK) scheme authenticates the session directly with a symmetric key, eliminating certificate exchange and asymmetric operations. TLS-PSK and Datagram Transport Layer Security (DTLS)-PSK let the device store only one short key and markedly reduce handshake message volume. The cost is difficult key distribution: symmetric keys usually must be provisioned at the factory or distributed over a secure channel, and once a key leaks, every device using that PSK must be redeployed. In practice, PSK is mostly used in private networks where the device fleet is manageable and the security requirements are moderate (such as sensors in building automation).

The Standard Path of TLS/DTLS Mutual Authentication

With either certificates or PSK, TLS/DTLS provides a standardized secure channel for device-to-platform communication. TLS 1.3 optimizes the handshake, reduces the number of round trips, and removes insecure cipher suites. A typical mTLS flow is:

1. ClientHello: the device sends its supported cipher suites and a random number.
2. ServerHello + certificate: the platform replies with its random number, the selected cipher suite, and the server certificate.
3. After verifying the certificate, the device sends its client certificate (if mTLS is configured), the computed parameters, and the Finished message.
4. The platform verifies the device certificate, computes its own, and replies with Finished.
5. Both sides derive the session key; subsequent data is transmitted with symmetric encryption.

For UDP links (such as the Constrained Application Protocol, CoAP), TLS is unavailable and DTLS 1.2/1.3 is required — the principle is the same, but the message format is adapted to datagrams. The Lightweight Machine-to-Machine (LwM2M) specification defines its security scheme for CoAP precisely on the basis of DTLS 1.2.

A Lightweight Authentication Protocol: EDHOC

For lightweight scenarios that need more flexibility than PSK, EDHOC (Ephemeral Diffie-Hellman Over COSE) is a lightweight authentication protocol for constrained IoT devices. Built on the COSE (CBOR Object Signing and Encryption) format, it completes mutual authentication and session-key negotiation with only a few message exchanges:

• Message 1 (device → platform): sends the ephemeral public key, supported cipher suites, and the device identity.
• Message 2 (platform → device): sends the platform's ephemeral public key, a certificate or public-key credential, and the authentication signature.
• Message 3 (device → platform): sends the device's authentication signature and confirms the key.

EDHOC is the lightweight authenticated key exchange defined by RFC 9528 and can provide mutual authentication, forward secrecy, and identity protection. One of its primary uses is to establish an OSCORE security context, and it can be transported over CoAP; it is not another handshake layered on top of "CoAP + DTLS." EDHOC depends on device-side support for CBOR/COSE and the selected cipher suite. Whether it suits a particular MCU should be determined by measuring implementation code size, handshake latency, energy consumption, and hardware acceleration, rather than drawing a line based only on the processor core model.

Scheme Comparison and Selection Advice

Table 8-4 Comparison of device authentication schemes (X.509 certificate / PSK / EDHOC)

Feature	X.509 certificate + mTLS	PSK (pre-shared key)	EDHOC
Security strength	High (asymmetric, non-repudiation, revocation support)	Medium (symmetric, no forward secrecy)	High (asymmetric, forward secrecy, identity protection)
Device storage overhead	Relatively large (certificate + private key, usually several KB)	Very small (a symmetric key only)	Relatively small (public key + ephemeral key)
Handshake message exchange	1-2 round trips (including certificate transfer)	1 round trip	3 messages (about 1.5 round trips)
Handshake bandwidth usage	Relatively large	Very small	Relatively small
Key distribution difficulty	High (requires a CA and CRL maintenance)	High (per-device provisioning or a secure channel)	Medium (credentials can be issued offline)
Suitable device types	Gateways, edge servers, high-security endpoints	Extremely low-end sensors, fleets of identical devices	Better-resourced constrained devices, CoAP scenarios
Typical standard	TLS 1.3	TLS-PSK	The EDHOC protocol

Selection must take into account device compute, bandwidth budget, and security level (see the threat classification in Section 8.1.1). Large IoT platforms usually adopt a mixed strategy: X.509 certificates for critical gateways, EDHOC or PSK for end sensors, and, on the platform side, a unified identity-management service (such as access control lists and tenant isolation) that maps the different authentication schemes onto the same authorization model, avoiding a security weak link.

Figure 8-3 TLS 1.3 vs EDHOC Handshake

8.2.2 Firmware Security and Secure Boot

Firmware is the device's "operating-system-level" software — hardware initialization, protocol-stack execution, and business-logic execution all depend on it. Once the firmware is tampered with, the device becomes completely untrustworthy: a sensor can keep reporting normal-looking data while opening a network backdoor in the background, and a persistent backdoor implanted in firmware cannot be removed even by formatting the storage. The defensive idea is not complicated: make the device run only signed firmware, and ensure the signing private key is never read directly by anyone (including the device itself). This requires establishing the chain of trust at the moment of boot, and guaranteeing that every firmware update is strictly verified.

The Secure Boot Flow: The Start of the Chain of Trust

Secure Boot is not a single feature but a chain of trust verified level by level. A typical flow includes the following stages:

1. BootROM (read-only code hardened inside the chip) loads the first-stage bootloader (commonly called SBL or PBL) after power-on. BootROM performs no verification — it is the root of trust and is itself immutable.
2. The first-stage bootloader verifies the digital signature of the second-stage bootloader (such as U-Boot); it loads it only if the signature is valid, otherwise boot stops.
3. The second-stage bootloader verifies the signature of the operating-system kernel or firmware image, and only decompresses and executes it after verification passes.
4. Before mounting the root filesystem, the kernel verifies the integrity of the root filesystem (usually through dm-verity or a similar mechanism).

Each level verifies the next level's signature, forming a "chain of trust." The strength of the chain is determined by its innermost root — the root key (Root of Trust, RoT) hardened inside the chip and immune to tampering. As long as the root key has not been physically read out or replaced, the whole chain is trustworthy.

A hypothetical example: an industrial edge gateway built on an ARM Cortex-A-series SoC configures secure boot so that BootROM verifies the second-stage bootloader with an asymmetric signature (such as ECDSA, Elliptic Curve Digital Signature Algorithm), which in turn loads the Linux kernel and filesystem image the same way. How the public key itself is protected against tampering is developed below in "Firmware Signing and Verification."

Firmware Signing and Verification: Who Authorized This Code

The secure boot chain of trust relies on digital signatures. The development team signs the firmware image with a private key; the device verifies the signature with the public key. The key points are:

• The private key must be strictly protected, typically stored in a hardware security module (HSM) or an isolated signing service, with no direct export of any kind. A leaked private key compromises the entire product line.
• The public key can be public, but its integrity must be guaranteed on the device — once the public key on the device can be tampered with externally, an attacker can sign arbitrary firmware with their own private key.

In practice, the fingerprint (hash) of the public key is written into the chip's OTP or eFuse region and can be written only once. At boot, BootROM reads the hash from OTP and checks it against the stored public key. Any tampering with the public key makes the device refuse to boot.

The firmware signing process typically runs: compile the binary image → sign it with the private key (the signature is appended to the end of the image) → package it (with version number, target device identifier, timestamp) → distribute it to the device. The verification flow on the device is:

Bootloader reads the firmware image and its signature → reads the public key/fingerprint from OTP → verifies the signature with the public key → boots on success, otherwise halts or enters recovery mode.

On verification failure, the device must never execute unsigned code in any way. A common extension is fail-safe recovery: if the primary firmware fails to boot, the device falls back to a protected recovery mode and receives signed repair firmware through a secure interface.

The Root of Trust (RoT): The Anchor of the Whole Chain

The Root of Trust (RoT) is the non-compromisable base point of the device security model. It usually consists of two parts: immutable boot code (BootROM, hardened in silicon) and tamper-proof key storage (key material burned into OTP or a physically unclonable function region).

The industry implements the RoT with several hardware approaches. On the ARM Cortex-A architecture, for example, Trusted Firmware-A runs at exception level EL3 and is responsible for secure boot and runtime security monitoring. Intel's SGX (Software Guard Extensions), though aimed mainly at trusted execution environments, provides hardware isolation that can also protect the root of trust and keys, and some implementations combine it with firmware verification. On lightweight MCUs, many vendors' TrustZone-M schemes isolate critical operations in a secure world; secure boot and key management are typical use cases.

Choosing an RoT approach depends mainly on cost versus protection level:

• Pure software: store the public-key hash in ordinary flash and rely on the boot-code logic not being bypassed. The benefit is limited — flash can be physically tampered with or read out over a debug interface.
• Dedicated SE/TEE chips: offer an independent processor and secure storage, with keys that are physically unreadable. Suitable for critical devices (edge gateways, medical equipment, payment terminals).
• SoC integration: many modern MCUs integrate secure-boot hardware support internally, providing a one-time programmable region and a root of trust, with cost and protection level in between.

These trade-offs are very real: chips with SE/TEE cost more, and the OTA channel needs additional signing and staged-rollout mechanisms. Extremely resource-constrained devices often settle for "signature-verified updates + software-level key protection," reserving the stronger hardware root of trust for critical nodes.

Secure Update Mechanisms: Do Not Let Upgrades Become Vulnerabilities

OTA (Over-the-Air) updates open a new door for attackers. If the update mechanism itself is insecure — for example firmware transmitted in plaintext, signatures skipped, rollback allowed — a single malicious OTA update can compromise an entire fleet of devices in bulk.

Engineering practice for secure updates should include:

• Mandatory signature verification: the device must verify the digital signature before writing new firmware; firmware with an invalid signature must never be written (not even by a manual user operation).
• Rollback protection: the device should support rolling back to a known-good version, but must prevent attackers from exploiting a "downgrade to a vulnerable old version." Rollback protection is usually implemented with a security version number (SVN): the device accepts updates only to higher versions and rejects any firmware whose SVN is lower than the recorded one; the SVN is stored in secure storage (such as OTP or an SE) and only ever increases.
• Atomic writes: if power or communication fails during an update, the device should recover to the previous stable firmware instead of becoming a "brick." The common practice is a dual-image layout (A/B partitions): firmware is written to the inactive partition; once writing completes, the device boots from it and marks it as the active partition after verification succeeds. If verification fails or boot misbehaves, the device falls back to the original partition.

The intent of rollback protection is blunt: when an attacker tries to restore firmware to an old version with known vulnerabilities, the device must be able to recognize and refuse it. Beyond the security version number, a complementary practice is key-version verification: each firmware update is signed with a new key pair, and old keys retire with their versions — even if an attacker obtains an old private key, it can no longer produce a valid image for a retired version.

A hypothetical example: a smart-lock manufacturer fixes a Bluetooth protocol vulnerability, releases new firmware, and raises the security version number to 3. An attacker who obtains the old private key then tries to downgrade the device to version 2: the bootloader finds that the image's SVN (2) is lower than the recorded SVN (3), refuses to write and boot it, and marks the image unusable.

The Trade-offs in Summary

Listing the above as a practice checklist:

• Must do: firmware signing and verification (even if only at the software layer), OTA updates that write only after mandatory verification, and rollback protection (version number or key version).
• Should do: support A/B partitions (lowering the risk of bricking) and use a hardware root of trust (OTP/PUF/SE).
• Optional / cost-dependent: TEE isolation, physical tamper detection, and real-time firmware integrity monitoring.

Secure boot in production is not a one-time investment — it requires supporting key-management processes, a signing service, staged-release mechanisms, and anomaly-detection capability. Without these supports, even the strongest chain of trust cannot hold the defensive line on its own.

Figure 8-4 Secure Boot Chain of Trust

8.2.3 Physical Security and Tamper-Resistant Design

Network-level attacks are invisible and intangible, but IoT devices are often deployed unattended outdoors, on factory floors, or even inside a competitor's plant. A temperature sensor mounted on a pipe can simply be unscrewed and taken apart; a smart meter can be pried open so the data on its chips can be read. Physical security answers the question "once the device falls into the attacker's hands, can it still keep its secrets?" Logical security often collapses in the face of physical access — if an attacker can read the private key straight out of flash, even the strongest TLS encryption is effectively worthless.

The engineering goal of physical security is not "completely blocking all physical attacks" — that is unaffordable — but raising the attack threshold so that the cost of breaking a device exceeds the attacker's gain. Tamper-resistant enclosures, secure elements (Secure Element, SE), physically unclonable functions (Physically Unclonable Function, PUF), and side-channel protection form four lines of defense: the first two are standard equipment on the vast majority of devices, while the latter two depend on security level and cost budget.

Tamper-Resistant Enclosures: The First Physical Barrier

The simplest physical protection makes it hard for an attacker to disassemble a device without damage. Tamper-resistant enclosures typically include the following designs:

• Sealed potting: the circuit board is completely encapsulated in epoxy resin or similar material; disassembly requires destroying the enclosure and the board, which is hard to restore. This method is low-cost and widely used in low- and mid-range devices.
• Special screws + fragile seals: special screw heads such as triangular-recess or pin-in (security) Torx require dedicated tools; a fragile seal, once peeled, leaves an obvious trace — well suited to warranty service and field inspections for judging whether a device has been opened.
• Triggered self-destruct circuitry: micro switches or capacitive sensing electrodes are placed inside the enclosure, and when the enclosure is opened or the board is pulled out, they trigger key erasure or chip self-destruction. This design is fairly common in high-end access-control card readers and financial POS terminals, at a higher cost.

The limitation of tamper-resistant enclosures is that once an attacker has professional disassembly means (such as a heat gun softening the potting compound or chemical solvents dissolving the epoxy), the board can still be extracted, if slowly. The real keys must therefore be stored in deeper hardware.

The Secure Element: The Safe for Keys

A secure element (SE) is an independent, tamper-resistant hardware chip dedicated to storing keys securely and performing cryptographic operations. It has its own processor, memory, and anti-attack circuitry, and protects keys from being read by the host chip through physical isolation and bus encryption. Typical secure elements follow the Common Criteria (CC) certification standard, with security levels ranging from EAL4+ (entry level) to EAL6+ (high security). High-grade chips are designed to withstand common physical probing means.

Typical uses of secure elements in IoT include:

• Storing the device private key and root certificate for mutual TLS/DTLS authentication with the platform. When the host chip initiates a connection request, the signing operation completes inside the secure element; the private key never leaves the chip.
• Performing verification of OTA firmware signatures, avoiding the leakage of the signing private key that could occur if the host chip verified alone.
• Generating one-time random numbers (nonces) for anti-replay defense, because secure elements usually have a built-in hardware true random number generator.

In enterprise IoT platform architectures, critical nodes with high security requirements (such as gateways and edge servers) are advised to integrate a secure element, using its hardware isolation to make keys "usable but unreadable." On extremely resource-constrained endpoints (such as a temperature sensor built on a single MCU), the fallback is often to protect keys inside the SoC with a Trusted Execution Environment (TEE) or software obfuscation — an engineering trade-off between cost and security.

Physically Unclonable Functions: The Chip's "Fingerprint"

A physically unclonable function (PUF) does not "store" a key; it exploits the random physical differences of the chip itself produced during manufacturing to generate a unique, unclonable "fingerprint." On each power-up, the PUF circuit outputs a stable, device-unique identifier or key.

The core advantage of the PUF is that the key never needs to be explicitly stored in non-volatile memory, so an attacker cannot extract it by reading the flash or using probes. Even two neighboring chips on the same wafer produce completely different PUF outputs. In addition, the PUF resists physical cloning — even if an attacker obtains the chip's layout, they cannot fabricate a clone chip with the same output. This property is valuable in anti-counterfeit device authentication and one-time key generation.

PUFs also have weak points. The output may fluctuate with temperature, voltage, and chip aging, so error-correction circuitry and helper data are needed to stabilize it. Most commercial SRAM PUF and ring-oscillator PUF schemes today are still not secure enough to resist professional side-channel attacks, but their low cost (no extra security chip) has driven their gradual adoption in smart door locks and consumer IoT devices.

Side-Channel Attack Protection: The Invisible "Ears"

Side-channel attacks do not destroy hardware directly; they infer the key by observing the "byproducts" of the running device: variations in supply current (power analysis), electromagnetic radiation (electromagnetic analysis), operation timing (timing analysis), or cache hit rates (cache side channels). During AES encryption, for example, the operations of different rounds draw different currents; an attacker who collects many power traces can recover the key with statistical analysis.

Protecting against side-channel attacks requires coordinated design at both the hardware and firmware levels:

• Power balancing: use constant-power circuits or noise-injection techniques so that the power trace of every operation converges toward the same shape.
• Random delay insertion: insert dummy loops of random length into cryptographic operations to scramble the timing pattern.
• Masking: blend sensitive data with random numbers before it enters the operation, so that what the attacker extracts from the power trace is unrelated to the real key.
• Isolating sensitive operations: for critical operations (such as private-key signing), complete them inside the secure element whenever possible, so that the host chip exposes no side-channel signals. The secure element's own circuitry usually already has side-channel resistance.

Example: Tamper-Resistant Design of an Outdoor Gas Meter

Suppose a device manufacturer needs to design an outdoor gas meter that prevents attackers from stealing gas through physical tampering. The design approach is:

1. The circuit board is potted in epoxy as a whole, and a fragile seal is embedded at the enclosure seam. Once the enclosure is forced open, the seal breaks and leaves an unrecoverable trace.
2. A high-security-level secure element is integrated on the board and stores the device private key inside. Each time a TLS connection is established with the platform, the secure element completes the certificate signing — the host chip only initiates the request and never touches the private key itself.
3. Inside the secure element, an SRAM PUF serves as the key-derivation root: on each power-up, the PUF outputs a device-unique 128-bit identifier which, combined with the non-volatile counter inside the secure element, generates the subsequent key material. If the chip is removed and transplanted into another metering module, the PUF output differs and the keys become invalid with it.
4. On the SPI lines between the secure element and the host chip, resistors and capacitors are inserted in series to suppress electromagnetic radiation. During cryptographic operations, the host chip enables random delay insertion to prevent attackers from obtaining the communication key between the secure element and the host through power analysis.

Figure 8-5 Defense in Depth for Tamper Resistance

Practical Boundaries: Physical Security Is No Silver Bullet

Stronger tamper resistance is not automatically better; before deployment, at least two practical constraints should be assessed.

Cost boundary. The material cost of a high-security-level secure element can be several times that of an ordinary MCU; adding potting, special screws, and self-destruct circuitry can push the physical security cost per device up significantly. On a consumer IoT product shipping in the tens of millions, this cost is enough to change product pricing and margins. The security level should therefore match device value and attack risk: a low-value smart bulb does not deserve a high-level secure element, while adding an appropriate budget for physical protection to an industrial gateway controlling several production lines is a reasonable engineering decision.

Failure mode. Physical protection introduces a side effect that cannot be ignored: the device becomes nearly unrepairable. Once the enclosure is potted or the secure element's self-destruct circuitry is triggered, the device is basically beyond repair. Across large outdoor deployments, this means a higher device replacement frequency and increased operations cost. During design, make the trade-off between repairability and tamper resistance explicit, and communicate it clearly to the operations team.

Physical security is the starting point of defense in depth, but not the end — a device must carry this security through its entire lifecycle of manufacturing, deployment, updating, and retirement. That is exactly the device lifecycle, SBOM, and secure supply chain discussed in the next section.

8.2.4 Device Lifecycle, SBOM, and Supply Chain Security

The preceding parts of Section 8.2 have addressed "how a single device authenticates, boots, and resists tampering," but the security responsibility of an IoT system does not stop at the moment the device powers on. From factory manufacturing, onboarding, deployment, and updates, through incident handling, to final retirement, a device lives through several years; meanwhile, the firmware it runs and the cloud software are both built from layers of third-party components. Once lifecycle governance and the software supply chain are missing, a vulnerability in an individual device is amplified across the whole fleet through OTA or library updates. NIST's public material on IoT emphasizes that manufacturers should carry out defined security activities at every stage of design, development, production, support, and retirement (NIST Cybersecurity for IoT Program).

The Six Stages of the Lifecycle: First Separate Who Owns What

Table 8-5 Responsibilities across the six device lifecycle stages

Stage	Main activities	Owner	Key evidence
Manufacturing	Generate unique identity, inject root keys, burn the signed boot chain, production testing	Hardware vendor and security engineering	Factory identity manifest, root-key custody records
Onboarding	First registration, tenant binding, delivery of initial configuration and least privilege	Platform operations and integrators	Registration audit, configuration versions
Operation	Telemetry, commands, key rotation, status monitoring	Operations and security operations	Heartbeats, audits, anomaly events
Update	Signed release and staged rollout of firmware/drivers/models/rules	Release owner	Release manifest, rollback target version
Suspicious events	Key leakage, abnormal heartbeats, recalls, incident response	Security incident owner	Incident tickets, isolation and revocation records
Retirement	Key invalidation, certificate revocation, data erasure, spare-part recovery	Platform operations and compliance	Retirement audit, data-disposal evidence

The stages must be mutually verifiable: the factory identity can be traced to the device's current state, runtime events can be traced to the most recent update and its approver, and retirement actions can be checked for key revocation and data disposal. Without closed loops across stages, keys may be left in limbo indefinitely, retired devices may be reactivated, and recall responses may cover only part of a batch.

SBOM: Making the Firmware's "Ingredient List" Readable

Lifecycle governance answers only "who is responsible," but supply chain attacks usually come from third-party components in device firmware and cloud services. A Software Bill of Materials (SBOM) records, in machine-readable form, which components, versions, and vendors a piece of software contains, so that vulnerability intelligence (such as CVEs) can be mapped to specific device batches within milliseconds. SBOMs have become the minimum consensus explicitly required by policy in multiple countries; for concrete practice, refer to NIST's software supply chain security guidance (NIST Software Supply Chain Security).

Engineering practice recommends:

• SBOMs are generated automatically by the build pipeline (either SPDX or CycloneDX), not patched together by hand after release;
• SBOMs should cover firmware, drivers, edge agents, and cloud services, including embedded operating systems, libraries, fonts, and model weights;
• SBOM storage is bound to the same version as the release artifact: one SBOM per version, traceable to batches through the device inventory;
• An SBOM alone does not solve vulnerabilities; it must be paired with vulnerability-intelligence subscriptions, VEX (Vulnerability Exploitability eXchange), and response processes;
• High-risk components (such as TLS libraries, bootloaders, AI inference runtimes) should be listed as sensitive dependencies and put under mandatory approval and fallback drills.

Secure Updates: Signing, Anti-Rollback, and Failure Recovery

The most easily exploited window in the device lifecycle is the update path. Forged update packages, rolling devices back to vulnerable versions, and getting stuck in a half-executed state after a failed update are common risks. Engineering should cover:

• Signing and chain of trust: update packages are signed by the release server with production keys, and the device verifies the signature and binds it to the trust anchor; compromised keys must be revocable through a CA/trust-anchor update.
• Version anti-rollback: the device records the lowest version that has booted successfully and refuses any downgrade below it; emergency downgrades must carry an independent signature and an explicit policy.
• Staged rollout and batches: releases are batched by device batch, region, and tenant, while runtime metrics and heartbeat error codes are observed; on anomalies, pause or roll back instead of expanding the rollout.
• Failure recovery: a failed update should automatically return to the last known-safe version and report an error code to the platform; the device must not be allowed to stay in a "half-updated" state for long.
• Models and rules treated as artifacts: AI models, rule packs, and tool schemas are all handled as "artifact + signature + version + staged rollout," consistent with firmware.

The Lifecycle of Keys, Certificates, and Identity

A device identity should not be "injected once and used for a lifetime." Key rotation, certificate renewal, and revocation must be linked to the device lifecycle:

• Every device holds at least one non-exportable device identity key, plus several short-term credentials;
• Key/certificate rotation is completed while the device is running normally, avoiding dependence on device reinstallation;
• A key leak must be able to trigger revocation in the lifecycle system, invalidating heartbeat sessions across the entire fleet;
• A retired device's keys are invalidated immediately, preventing "old devices coming back to life";
• Every identity state change enters the audit trail and can be traced back to the person, the action, and the evidence.

Putting this section back into the chapter's context: Section 8.1.4 answered "why to do it" at the governance layer, and this section lands that answer in the operation, updating, and retirement of the device layer; the authentication, boot-chain, and physical-protection mechanisms given in Sections 8.2.1 through 8.2.3 thereby gain a time dimension — they are not one-time configurations made at deployment but objects of continuous operations throughout the lifecycle. The identity and update evidence continuously produced here is a direct input to the agent security decisions of Section 8.5.4 and the incident response of Section 8.6; the thing model and runtime reused by device identity and the OTA channel are developed in Chapters 3 and 6 respectively, and this section does not repeat them.

Lifecycle governance is ongoing work, not a document produced before release. Any device allowed to connect to an AIoT platform should be able to answer: who signed its factory identity, which firmware and model versions it is currently running, when its last key rotation happened, and how its data will be disposed of after retirement.

← 8.1 An Overview of IoT Security8.3 Communication Security →