TPM 2.0, Secure Boot and Remote Attestation for IoT Fleets (2026)

Secure boot answers a question the device asks itself: “is the code I am about to run signed by someone I trust?” It cannot answer the question your operations team actually has at 3 a.m.: “which of my 40,000 gateways are running what I think they are running, right now, and can I prove it to an auditor?” A compromised device that passes its own signature check, or one whose boot policy was quietly loosened, looks identical to a healthy one from the network.

Remote attestation IoT closes that gap. The device uses a hardware root of trust, usually a TPM 2.0 chip or firmware TPM, to produce signed evidence of what it booted, and a verifier you control decides whether that evidence matches an approved state. With the EU Cyber Resilience Act reporting duties already live as of September 2026 and the main obligations arriving in December 2027, fleet-level integrity evidence has moved from a nice-to-have to something auditors will ask about.

This post is a reference architecture. You will leave with a precise mental model of the trust chain, the exact TPM objects involved (PCRs, event log, EK, AK, quotes), a working tpm2-tools flow, how Keylime, Linux IMA and DICE/DevID fit, and a catalogue of the ways attestation fails in real fleets.

What this covers: the root-of-trust chain, verified versus measured boot, TPM 2.0 internals, the IETF RATS model, fleet verifier design with Keylime, device identity and factory provisioning, SPIFFE/SPIRE bridging, CRA relevance, hardware choices, and failure modes.

Context and Background

Embedded security grew up around one idea: verified boot. An immutable first-stage loader in ROM checks a signature on the next stage, which checks the next, and so on until the kernel and root filesystem. U-Boot’s verified boot with FIT images, UEFI Secure Boot on x86 and many Arm servers, and vendor-specific high-assurance boot on i.MX or similar SoCs all follow this pattern. The result is enforcement: unsigned code does not run.

Enforcement is necessary but it is local and silent. The device does not tell anyone what it ran. If the signing key leaks, if a revoked-but-still-signed bootloader is rolled back, or if secure boot is disabled in firmware setup by someone with physical access, nothing leaves the device to say so. Measured boot is the complementary mechanism: each stage hashes the next stage and records the hash in a tamper-evident register before handing over control. Nothing is blocked, but everything is recorded, and the record can be signed and sent off the box.

The standards backbone for that record is the Trusted Computing Group’s TPM 2.0 Library Specification (the TCG publishes revisions and errata; revision 1.83 with errata is among the current published documents) plus the platform profiles layered on it, such as the PC Client Platform TPM Profile for x86 and the TPM 2.0 Mobile and Automotive-Thin profiles for other classes. On the protocol side, the IETF published RFC 9334, the Remote ATtestation procedureS (RATS) architecture, which gives the vocabulary we use below: Attester, Verifier, Relying Party, Endorser and Reference Value Provider. See the RFC 9334 text for the normative definitions.

Operationally, the open-source reference implementation for TPM-based fleet attestation is Keylime, which describes itself as “a TPM-based highly scalable remote boot attestation and runtime integrity measurement solution.” It is a CNCF project at the Sandbox maturity level (accepted September 22, 2020, per the CNCF project page at the time of writing). Sandbox status means early-stage; it is not a statement about code quality, but it does tell you to budget for your own hardening and upgrade testing.

If your fleet already has an OTA story, attestation is its audit counterpart: updates change the expected measurements, so the two systems must share a release pipeline. We covered the update side in SUIT RFC 9124 vs Uptane vs Mender, RAUC and SWUpdate, and we will return to how the two must be coordinated.

The Reference Architecture: Root of Trust to Verifier

Remote attestation works by chaining measurements: an immutable root of trust measures the first mutable stage, that stage measures the next, and each hash is extended into a TPM Platform Configuration Register (PCR). The TPM then signs those PCR values together with a verifier-supplied nonce using a restricted attestation key. A verifier compares the signed result with known-good reference values and issues a trust verdict.

Figure 1: Chain of trust and evidence flow. Each boot stage measures the next into TPM PCRs, the AK signs a quote bound to a verifier nonce, and the verifier appraises it against reference values.

The figure shows two flows that people often conflate. The vertical flow on the device is the boot chain, where each component is both measured and the measurer of its successor. The horizontal flow is the attestation protocol, where the verifier challenges, the TPM answers, and a policy engine decides. Verified boot lives only in the first flow; measured boot feeds both.

Verified boot versus measured boot

Verified boot is a gate. Stage N holds a public key or hash (anchored in ROM, fuses or a signed database) and refuses to run stage N+1 on mismatch. Its security property is “only approved code executes”, and it depends entirely on the integrity of the key store and the revocation story. Measured boot is a ledger. Stage N computes a digest of stage N+1 and calls a TPM extend command, then runs it regardless. Its property is “whatever executed, you can find out afterwards, if the measuring stages were honest”.

You want both. Verified boot keeps casual tampering from executing; measured boot gives you proof of what executed, including the case where verification was weakened. On UEFI systems the Secure Boot policy itself (the PK, KEK, db and dbx state, and whether Secure Boot is on) is measured, conventionally into PCR 7, which is precisely why an attacker who turns Secure Boot off changes a value the verifier checks.

TPM 2.0 building blocks you actually need

A PCR is a hash-chain accumulator, not a store. The only way to change it is extend: PCR_new = H(PCR_old || digest). You cannot set it to a chosen value, and you cannot roll it back without a reset, which only happens on platform reset. Because extend is order-dependent, the final value commits to the whole sequence of measured events. A TPM 2.0 exposes multiple PCR banks, one per hash algorithm (commonly SHA-1 and SHA-256, sometimes SHA-384); modern fleets should attest the SHA-256 bank or better and ignore SHA-1 except where firmware forces it.

The conventional PC Client assignments are worth memorizing because embedded Linux images borrow them. PCR 0 holds firmware code, PCR 1 firmware configuration, PCR 2 and 3 option ROM code and data, PCR 4 the boot manager and loader code, PCR 5 the boot manager configuration and GPT, and PCR 7 the Secure Boot policy. The systemd ecosystem additionally uses PCR 11 for unified kernel image measurements (systemd-stub) and Linux IMA uses PCR 10 by default for its runtime measurement list. Non-UEFI embedded boards (U-Boot, bare-metal loaders) have no mandated mapping: you define your own, and you must document it, because the verifier policy depends on it.

Two keys matter. The Endorsement Key (EK) is a TPM-unique key derived from a seed burned in by the manufacturer, usually accompanied by an EK certificate in NV storage that chains to the TPM vendor CA; it proves “this is a genuine TPM of vendor X”. The Attestation Key (AK) is a restricted signing key created under the EK hierarchy that can only sign data the TPM itself generated (quotes), never arbitrary bytes. That restriction is the whole point: a compromised OS cannot ask the AK to sign a forged PCR blob. The EK is a decryption-class key and is used with credential activation (MakeCredential/ActivateCredential) to prove the AK lives in the same TPM as the EK.

The quote and the event log

A TPM2_Quote returns a signed TPMS_ATTEST structure containing the selected PCR digest, the qualifying data (your nonce), the TPM clock info, reset and restart counters, and firmware version. Replay protection comes from the nonce; “this boot, not a recorded one” comes from the reset counter. The quote carries only a digest of the PCRs, so on its own it says “something hashes to this”, not what the something was.

To make the digest explainable, the platform keeps an event log: a list of every extend with the event type, digest and metadata. On UEFI this is the TCG event log in the crypto-agile format; the verifier replays it by recomputing the extends and checks that the result equals the quoted PCR. The log itself is untrusted storage, but replay-and-compare makes it self-authenticating: if the replay matches the signed PCR, the log is exactly what was measured. Without the log, the verifier can only compare against a golden PCR value, which breaks the moment any benign component changes.

Mapping to the IETF RATS roles

RFC 9334 gives names to the pieces so that design reviews stop talking past each other. The Attester is your device. The Verifier appraises Evidence using Reference Values, Endorsements and an appraisal policy, and produces Attestation Results. The Relying Party is whatever acts on the result: a broker that admits a client, a certificate authority that issues a credential, an orchestrator that schedules a workload. The Endorser (typically the silicon or TPM maker) vouches for the Attester’s capabilities, which is what the EK certificate is. The Reference Value Provider (typically your build pipeline for your own images, the firmware vendor for theirs) supplies the “good” digests.

RFC 9334 describes two conveyance topologies. In the passport model (Section 5.1) the Attester sends Evidence to the Verifier, receives a signed Attestation Result and carries it to Relying Parties, like a passport issued by a trusted authority. In the background-check model (Section 5.2) the Attester hands Evidence to the Relying Party, which forwards it unparsed to the Verifier and then evaluates the returned result. For IoT the choice is practical: passport suits devices that talk to many services and have intermittent connectivity, because the result can be cached; background-check suits constrained nodes and brownfield services, because the Relying Party never parses complex Evidence.

Freshness is where most home-grown designs go wrong. RFC 9334 Section 10 lists three approaches: synchronized clocks with signed timestamps, nonce-based challenge/response, and epoch IDs distributed by a third party. A TPM has a clock but you should not trust its absolute value; it is a monotonic tick counter plus a reset counter. The nonce approach costs the verifier state per outstanding challenge, while epoch IDs keep verifier state independent of fleet size. For a fleet of tens of thousands that “state per attester” cost is real, and we return to it in the capacity section.

Fleet Attestation with Keylime

Keylime is the practical answer to “I have the TPM, now I need a verifier that scales and a policy language”. Its documentation (build 7.14.3 at the time of writing) names four components: the agent on the device, the verifier that polls and appraises, the registrar that stores identity and key material, and the tenant, an operator CLI used to enroll agents and attach policy. Documented features include measured boot policy, IMA-based runtime integrity monitoring, secure payload delivery, agent revocation, user-selected PCR monitoring, IDevID/IAK handling and a push-model attestation mode. I did not verify per-feature maturity beyond the documentation index, so treat the list as capability claims to test in your lab.

Figure 2: Enrollment and continuous attestation. The registrar binds AK to EK via credential activation; the verifier then challenges with nonces and applies the policy on each quote.

Enrollment: proving the AK belongs to a real TPM

On first start the agent creates an AK and registers with the registrar, presenting the EK public key (and the EK certificate where one exists), the AK public area and its name. The registrar runs credential activation: it encrypts a secret to the EK in such a way that only the TPM holding both that EK and an AK with the matching name can recover it. The agent decrypts via the TPM and returns the proof. This is the step that transforms “some key someone claims is an AK” into “an AK resident in a genuine TPM of known provenance”.

The operator, via the tenant, then registers the agent with the verifier along with a policy: the PCRs to check, the allowed measured-boot reference state, and the runtime-integrity allowlist. Whether to additionally validate the EK certificate against vendor CA roots is a policy decision, and it is the one that most determines whether a software TPM emulator on an attacker’s laptop can pass as a fleet member. Do it.

Continuous attestation: pull versus push

In the classic pull model the verifier connects to each agent, sends a nonce, receives a quote and the incremental IMA list and event log, and evaluates. This keeps the device simple but requires the verifier to reach the device, which is awkward behind carrier NAT or in cellular fleets. The documentation index lists a push-model attestation mode, in which the agent initiates; for IoT networks that block inbound connections this is the natural fit, and you should read its current limitations in the docs before committing.

Capacity planning is arithmetic you can do yourself. Suppose a quote verification costs a few milliseconds of verifier CPU (an illustrative figure, measure your own) and you attest every 60 seconds. At 50,000 devices that is about 833 verifications per second, which a few cores handle comfortably; the real cost is the per-device state (last nonce, IMA offset, PCR snapshot) and the policy evaluation over a growing IMA list. Choose the interval from your detection-time requirement, not from what the verifier can handle: the interval is your worst-case window in which a compromised device still looks healthy.

What happens on failure

When a quote fails policy the verifier marks the agent as failed and can trigger revocation actions so that peers stop trusting it. What you do with that signal is a design decision: quarantine VLAN, certificate revocation, workload eviction, or just an alert. A common anti-pattern is wiring attestation failure straight to automatic device bricking; transient failures (clock jump, benign firmware update, flaky storage) will then take down healthy devices in bulk. Prefer a graded response: alert, restrict, then revoke, with human confirmation for irreversible steps.

Walk-through: A Hands-On Quote with tpm2-tools

Before trusting any framework, run the primitive by hand once. The flow below uses tpm2-tools and follows the option names in the project’s man pages (tpm2_createak, tpm2_quote, tpm2_checkquote). Handle numbers and file names are examples; check tpm2_quote --help on your installed version, because option details have changed across major releases.

# 1. Create the endorsement key and a restricted attestation key under it
tpm2_createek -c ek.handle -G rsa -u ek.pub
tpm2_createak -C ek.handle -c ak.ctx -u ak.pub -n ak.name
tpm2_evictcontrol -C o -c ak.ctx 0x81010002     # persist the AK

# 2. Verifier side: generate a fresh nonce
NONCE=$(openssl rand -hex 16)

# 3. Device side: quote PCRs 0-7 in the SHA-256 bank bound to the nonce
tpm2_quote -c 0x81010002 -l sha256:0,1,2,3,4,5,6,7 \
           -q $NONCE -m quote.msg -s quote.sig -o quote.pcrs -g sha256

# 4. Ship quote.msg, quote.sig, quote.pcrs and the event log to the verifier
cp /sys/kernel/security/tpm0/binary_bios_measurements eventlog.bin   # UEFI systems

# 5. Verifier side: check signature, nonce and PCR digest
tpm2_checkquote -u ak.pub.pem -m quote.msg -s quote.sig \
                -f quote.pcrs -g sha256 -q $NONCE

# 6. Explain the PCRs by decoding the event log
tpm2_eventlog eventlog.bin | less

Step 5 proves three things only: the signature came from the AK, the nonce matches your challenge, and the PCR digest in the signed structure equals the digest of the PCR values supplied. It does not prove the AK is in a genuine TPM (that is credential activation), and it does not tell you the PCR values are good (that is policy). Teams that stop at step 5 have built a signature checker, not an attestation system.

Reading the event log like a verifier

Decode the log and look for the event types. EV_EFI_VARIABLE_DRIVER_CONFIG entries record Secure Boot state and the db/dbx contents measured into PCR 7. EV_EFI_BOOT_SERVICES_APPLICATION entries record the loaded bootloader image in PCR 4. EV_SEPARATOR events close each PCR’s pre-OS phase. A verifier that replays the log recomputes each PCR, compares to the quote, then applies rules such as “the loader digest must be in the approved set” or “PCR 7 must correspond to Secure Boot enabled with our db and the vendor dbx revision”.

Pay attention to the rule’s shape. Matching a full PCR value is brittle because PCR 4 changes whenever the bootloader does. Matching individual log events is robust because you can allow-list a set of acceptable bootloader digests. Keylime’s measured boot policy works on this principle, evaluating log entries rather than only comparing raw PCRs; consult its “Use Measured Boot” guide for the policy schema, which I have not reproduced here because it changes between releases.

Runtime integrity with Linux IMA

Boot-time measurements say nothing about what happens after init. The Linux Integrity Measurement Architecture (IMA) extends the chain into runtime: the kernel hashes files as they are executed, mmapped executable, or read by root according to an IMA policy, appends an entry to an in-kernel measurement list, and extends the aggregate into a PCR (PCR 10 by default). The kernel documentation describes templates for the list; the default ima-ng carries a digest (d-ng) and a path (n-ng), and ima-sig adds a file signature field. A verifier replays the list to the quoted PCR 10 exactly as it replays the boot log, then checks each file digest against an allowlist or each signature against trusted keys.

IMA has costs that bite in practice. The list grows with every new distinct file measured, so a long-running device accumulates thousands of entries and the verifier must track an offset per device to avoid re-reading it all. Writable data files and scripts pollute the allowlist unless the policy confines measurement to executables and libraries. Container runtimes multiply the paths. And IMA measures files at access time; it does not see in-memory modification of an already-loaded binary. For a locked-down appliance image with a read-only dm-verity rootfs, IMA is cheap and highly informative. For a general-purpose Linux gateway running arbitrary containers, expect substantial policy work.

Coupling attestation to the update pipeline

An OTA update changes the expected measurements, so the Reference Value Provider must publish new reference values before the fleet reboots into them. The failure pattern is familiar: operations ships a signed image, the fleet reboots, PCR 4 and 11 change, and the verifier flags 100 percent of devices as untrusted. The fix is procedural and mechanical. The build pipeline should emit the expected digests (bootloader, UKI, kernel command line, IMA allowlist delta) as signed reference-value artifacts. The verifier should accept both old and new values for a bounded rollout window, and drop the old value once the rollout completes, which also yields rollback detection: a device reporting the superseded state after the window closes is either stuck or has been downgraded.

This is the intersection with SBOM and vulnerability workflows. Reference values are effectively a hash-level inventory; mapping them to component versions lets you answer “which attested devices run the vulnerable library” without trusting a self-reported package list. The triage side of that story is in VEX, CSAF and OpenVEX for vulnerability exploitability triage, and attestation supplies the ground truth that VEX statements are usually missing.

Device Identity: EK, DevID and DICE

Attestation answers “what is running”. Identity answers “who is this device”. The two must be bound, otherwise a verifier happily validates a healthy stranger. IoT has three overlapping identity mechanisms, and fleets usually need more than one.

TPM identity: EK, AK and the cert chain

The EK certificate is issued by the TPM manufacturer and typically stored in TPM non-volatile memory; the TCG publishes an EK Credential Profile describing its format. It identifies the chip, not your product. Your fleet identity should therefore be an AK (or a DevID key, below) enrolled in your registrar after you have checked that the EK chains to an accepted vendor root. Privacy note: the EK is a stable unique identifier, so exposing it to third parties allows device tracking. That is acceptable inside your own fleet and a problem if you expose it to customers or the public internet.

IEEE 802.1AR DevID

IEEE 802.1AR (2018 revision) defines the Secure Device Identifier. An IDevID is a manufacturer-installed, long-lived identity credential bound to a key that never leaves secure storage; an LDevID is an operator-installed credential, issued after the owner authenticates the device with its IDevID, and is the one you rotate and revoke. The pattern is “birth certificate, then local ID card”: the IDevID bootstraps trust once, and the LDevID carries daily operation. This is the model behind zero-touch onboarding in industrial networks and is the reason the Keylime documentation lists IDevID and IAK (Initial Attestation Key) handling.

The TCG’s TPM 2.0 Keys for Device Identity and Attestation specification defines how to build DevID and attestation keys inside a TPM and how the certificates relate to the EK, so a verifier can establish that the DevID key and the AK are co-resident. I am describing that document’s purpose from memory of its title and scope; confirm the current version and exact key templates against the TCG site before implementing.

DICE: identity for devices without a TPM

Many constrained devices (microcontrollers, small SoCs) cannot afford a TPM. The Device Identifier Composition Engine (DICE) provides measured-boot identity with minimal hardware: a small immutable block of logic holds a Unique Device Secret (UDS) and, at each boot layer, derives a Compound Device Identifier (CDI) by hashing the UDS (or the previous CDI) together with the measurement of the next layer. Change any layer’s code and the derived CDI changes, so the keys derived from it change too.

Figure 3: DICE layering. Each layer derives the next CDI from the previous CDI plus the measurement of the next-layer code, then emits a certificate for the key it derives.

Elegantly, the identity is conditional: a device running modified firmware literally derives a different key and cannot sign as the original. The cost is that the “device identity” is really a sequence of per-layer certificates, and the verifier must handle certificates whose subject keys change legitimately on every firmware update. That is what the TCG DICE Attestation Architecture specification addresses with X.509 certificate extensions for conveying attestation Evidence and Endorsements. The TCG page lists version 1.2 (published April 24, 2025) with an errata release dated January 29, 2026, and a v1.3 release candidate dated July 2026 is publicly posted as a draft; treat v1.3 as unfinished. The open-source Open DICE project documents an Arm-oriented profile used in Android-class designs; it is a separate effort, not the TCG text.

Factory provisioning: where trust really starts

All of these chains inherit the integrity of the manufacturing step. A realistic provisioning flow reads the EK public key and certificate from each TPM on the line, records them in a database keyed by serial number, optionally creates and certifies the DevID key inside the TPM, and writes the initial secure-boot keys and fuses. That database becomes your allowlist of genuine devices, so protect it like a CA.

Manufacturing risks are mundane and severe. Contract manufacturers who photograph TPM serials into spreadsheets, shared line-station credentials, test images left with debug unlocked, and fuses blown late or not at all each break the chain silently. Require line-side evidence: signed provisioning logs, per-lot audit samples and a way to detect cloned or re-labelled parts. For high volumes, put the issuance of IDevID certificates behind an HSM and make the line station request them rather than hold the key.

Choosing the Hardware Root of Trust

The word “TPM” covers four quite different assurance levels, and the choice decides which attacks you can ignore.

Option	Where it runs	Strengths	Weaknesses	Typical fit
Discrete TPM 2.0 (SPI/I2C chip)	Separate certified chip	Own tamper-resistant silicon, vendor EK cert, certification options	Bus is sniffable and resettable by a physical attacker, adds BOM cost	Gateways, industrial PCs, edge servers
Firmware TPM (fTPM, e.g. in a TEE)	Secure world of the SoC	No extra part, faster, no external bus	Shares silicon and side-channel surface with the host, depends on the TEE implementation	Cost-sensitive Arm and x86 designs
Secure element (e.g. NXP EdgeLock SE050 class)	Separate I2C chip, vendor API	Strong key storage, device-unique credentials, low power	Typically not a TPM 2.0 command set, so tpm2-tools and Keylime do not work unchanged	Sensors, constrained nodes needing identity more than PCRs
DICE in ROM/MCU	Boot ROM logic	Near-zero cost, identity tied to firmware	No PCR/event-log semantics, ecosystem tooling younger	Microcontroller-class devices

Be honest about each tier’s known weak points. Discrete TPMs on an unprotected bus have been attacked by interposers that capture secrets in transit and by reset attacks that replay a forged measurement sequence on platforms where the reset line is exposed. Firmware TPMs inherit the vulnerabilities of the secure world they run in; TPM-Fail (2019) showed timing leakage in ECDSA on both a discrete part and Intel’s firmware TPM, and CVE-2023-1017 and CVE-2023-1018 were out-of-bounds bugs in the TPM 2.0 reference library’s command parsing, so patching a TPM firmware is part of fleet operations. Secure elements like the SE050 are widely used for identity, but check the vendor datasheet and middleware for the exact command set before assuming TPM compatibility; my statement that such parts are not TPM 2.0 is the general case, not a claim about every SKU.

Certification matters for regulated sales. TCG has its own TPM certification program, and Common Criteria protection profiles exist for TPM 2.0 implementations. If your customer base includes critical infrastructure, ask whether your target TPM carries an evaluated certificate and at what assurance level; this is far cheaper to settle at design time than after tooling is chosen.

From Attestation Verdict to Workload Identity: SPIFFE/SPIRE Bridging

Attestation produces a verdict; services need a credential. The bridge between them is the part most teams leave undesigned. SPIFFE defines workload identities (SPIFFE IDs) carried in short-lived X.509 or JWT SVIDs, and SPIRE is its reference implementation. SPIRE separates node attestation (proving the machine is legitimate) from workload attestation (proving a process on that machine matches a selector). Node attestation is pluggable, and a TPM-backed attestor is the natural way to make the node-level proof hardware-rooted rather than based on a join token or cloud metadata.

Figure 4: Attestation as the gate for identity. A passing verdict lets the issuer mint short-lived SVIDs; a failing verdict stops renewals, so trust decays within one credential lifetime.

The design principle is that credential lifetime sets your revocation latency. If an attested device receives a certificate valid for a year, a later attestation failure changes nothing for 364 days unless you also run revocation. If the SVID lasts an hour and renewal requires a fresh passing verdict, a compromised device loses access within the hour with no revocation infrastructure at all. For fleets, pick lifetimes that your connectivity can sustain: a cellular device offline for six hours needs either a longer lifetime or graceful degradation, and that is a business decision about acceptable exposure.

Note what the bridge does not do. SPIRE’s TPM-style node attestors prove the node, and per-workload identity then depends on selectors (Unix user, container image, path). IMA can tighten this by letting the verifier know that the binary behind the selector matches an approved digest, but the coupling is custom work. We explored the certificate-management side of this in Kubernetes pod certificates vs SPIFFE/SPIRE vs cert-manager, and the same trade-offs apply when the “pod” is a protocol gateway at a factory edge.

A pragmatic hybrid is common. The TPM-backed attestation service registers each device once and issues an LDevID-like operational certificate. Your message broker (MQTT, for instance) authenticates devices by mutual TLS with that certificate. Periodic attestation then gates renewal. The broker never needs to understand TPM structures, which is the background-check logic of RFC 9334 in everyday clothes.

Regulatory Relevance: The EU Cyber Resilience Act

The Cyber Resilience Act, Regulation (EU) 2024/2847, applies to products with digital elements placed on the EU market. Per the dates reported by industry sources I checked, its vulnerability and incident reporting obligations (Article 14) began applying on 11 September 2026, and the full set of essential requirements, conformity assessment and CE marking applies from 11 December 2027. Confirm both against the Official Journal text before building a compliance plan.

Attestation is not named as a mandatory technique, and anyone claiming “the CRA requires a TPM” is overreaching. What the Regulation does require are properties that attestation helps evidence. Annex I, Part I, point (2)(b) requires that products be made available with a secure by default configuration; point (2)(d) requires protection from unauthorised access through appropriate control mechanisms; and point (2)(f) requires protecting the integrity of stored, transmitted or otherwise processed data, commands, programs and configuration against unauthorised manipulation, and reporting corruption. A device that measures its boot chain and reports signed evidence gives you a concrete, auditable mechanism for the integrity and configuration claims, and fleet attestation logs are the kind of artefact you can show a market-surveillance authority.

The reporting obligation links to attestation in a more operational way. When you must notify of an actively exploited vulnerability in a short time window, you need to know which shipped devices run the affected component. Reference-value inventories tied to attested state answer that faster and more truthfully than self-reported package lists. For the wider mapping across the CRA, NIS2 and IEC 62443, see EU CRA vs NIS2 vs IEC 62443 compliance mapping for IoT and OT vendors. This is engineering analysis rather than legal advice.

Trade-offs, Gotchas, and What Goes Wrong

Attestation is easy to oversell. These are the limits and failure modes that matter in production.

Time-of-check to time-of-use. A quote proves the state at the moment it was taken. Malware that arrives after the quote and leaves before the next one is invisible, and your detection window equals the attestation interval. Measured boot also cannot see a runtime memory-only exploit of a measured, approved binary; the code is exactly as expected and still compromised. Attestation proves provenance and configuration, not behaviour.

No runtime integrity by default. Without IMA or an equivalent, everything after the kernel handoff is unmeasured. With IMA, you inherit the allowlist-maintenance burden described above. If the device runs interpreted code, a measured interpreter executing an unmeasured script is a classic gap.

Brittle policy and false positives. Raw PCR matching breaks on every benign firmware update, boot-order change or kernel command-line tweak. Mature deployments match on event-log entries, maintain bounded sets of allowed values, and test policies in a shadow mode that alerts without acting before enforcement.

Emulated and relayed TPMs. If the verifier does not validate the EK certificate chain, an attacker can run a software TPM and present arbitrary PCRs. If it does, a determined attacker can still relay quotes from a real TPM held elsewhere, unless identity binds the AK to a key used in the same TLS session. Bind the attestation channel to the transport.

Weak freshness. Reusing nonces, using timestamps from an unauthenticated clock, or caching verdicts indefinitely lets recorded good quotes substitute for a bad current state. Use unpredictable single-use nonces and treat the TPM reset and restart counters as part of the evidence.

Physical attacks. Anyone with hands on the board can probe a discrete TPM’s bus or abuse reset lines. If your threat model includes field tampering, pick parts and board designs accordingly (integrated or fTPM, bus encryption features where offered), and recognize the residual risk instead of papering over it.

Verifier as single point of failure. If the verifier is down, do devices fail open or fail closed? The answer must be explicit and tested. A fleet that quarantines itself during a verifier outage turns an infrastructure incident into an availability disaster; one that fails open silently has no security at all. Cache bounded-lifetime passport results and alert loudly on verifier unavailability.

Privacy and data governance. Event logs reveal firmware versions and configuration, and EKs are stable identifiers. Treat attestation data as sensitive telemetry with retention limits and access control.

Practical Recommendations

Start from the verifier and the policy, not the chip. A fleet with a mediocre TPM and a disciplined reference-value pipeline is safer than one with a certified part and no one maintaining golden values. Build in this order: identity, boot evidence, update coupling, runtime evidence, response automation.

Run the tpm2-tools flow by hand on a development board, then move to Keylime in a lab with a few devices and a shadow-mode policy. Decide your passport versus background-check topology early, because it determines where Evidence is parsed. Keep SHA-256 or stronger as the attested bank, validate EK certificates against vendor roots, and make credential lifetime your revocation mechanism.

• Define a PCR (or DICE layer) map for every board family and version it in the repository next to the image build.
• Emit signed reference values from CI for every release: bootloader, kernel or UKI, command line and IMA allowlist delta.
• Validate the EK certificate chain at enrollment and store provisioning records from the factory.
• Use single-use nonces and bind the attestation session to the TLS channel.
• Prefer event-log policy over raw PCR equality, and run new policies in shadow mode first.
• Accept old and new reference values only for a bounded rollout window to detect rollbacks.
• Gate short-lived credential renewal on a passing verdict; avoid year-long certificates for attested devices.
• Specify and test verifier-outage behaviour (fail open, fail closed, or bounded cache).
• Patch TPM firmware as part of fleet maintenance, and watch TCG and vendor advisories.
• Keep attestation logs with retention rules, since they double as compliance evidence.

Frequently Asked Questions

What is remote attestation in IoT?

Remote attestation is a protocol in which a device proves to a remote verifier what hardware and software state it booted. A TPM signs the current PCR values together with a verifier-supplied nonce, the device sends the signed quote and event log, and the verifier appraises them against approved reference values. A passing verdict then gates access, credentials or workloads.

What is the difference between secure boot and measured boot?

Secure (verified) boot blocks code whose signature does not verify, so it enforces which code may run. Measured boot lets code run but records a hash of every stage into TPM PCRs, so a verifier can later learn exactly what ran. Secure boot prevents; measured boot provides evidence. Production fleets should use both, because a weakened secure boot policy is only detectable through measurements.

Do I need a TPM for device attestation?

No, but you need some hardware root of trust. Discrete and firmware TPM 2.0 give you PCRs, event logs and standard tooling. Microcontroller-class devices can use DICE, where firmware measurements change the derived keys, or a secure element for identity. You lose the PCR and event-log model with those, so verifier tooling such as Keylime may not apply unchanged.

Is Keylime production ready and who maintains it?

Keylime is a CNCF project at the Sandbox level (accepted September 22, 2020, as shown on the CNCF project page when I checked), with agent, verifier, registrar and tenant components and active documentation. Sandbox is the earliest CNCF stage, so run your own scale tests, security review and upgrade rehearsals before relying on it for safety-critical fleets.

What is the difference between DICE and IEEE 802.1AR DevID?

IEEE 802.1AR defines the credential model: a manufacturer-installed IDevID and an operator-installed LDevID. DICE defines a hardware-light mechanism for deriving device keys from firmware measurements and a UDS. They compose: a DICE-derived key can back a DevID credential, and TCG’s DICE Attestation Architecture defines certificate extensions that carry the attestation evidence.

What does remote attestation not protect against?

It does not stop attacks between two quotes, runtime memory exploitation of approved software, or bugs in code that measured correctly. A relayed quote from another genuine TPM defeats naive designs, and physical bus attacks can undermine discrete TPMs. Treat attestation as strong evidence of provenance and configuration, combined with runtime monitoring and short credential lifetimes.

Further Reading

• SUIT RFC 9124 vs Uptane vs Mender, RAUC and SWUpdate: how updates change the reference values attestation compares against.
• VEX, CSAF and OpenVEX vulnerability triage automation: turning attested inventory into exploitability decisions.
• EU CRA vs NIS2 vs IEC 62443 compliance mapping: where integrity evidence fits in regulatory duties.
• Kubernetes pod certificates vs SPIFFE/SPIRE vs cert-manager: credential issuance after a passing verdict.
• External: RFC 9334, RATS Architecture; Keylime documentation; tpm2-tools manual pages.

By Riju — about