IoT security and device attestation
All AmbiSecure engineering content tagged IoT Security, newest first. Newer entries reflect current thinking; earlier entries come from the engineering archive.
IoT security is the discipline of giving connected devices a trustworthy identity and protecting them across a long, unattended lifecycle. Because IoT devices operate outside physical control and ship in large fleets, their security rests on a hardware root of trust: a secure element that provisions a unique device key, attests device state, and protects signed firmware updates.
This category covers connected-device security engineering — provisioning and attestation, mutually authenticated TLS, key rotation, secure updates, and how a co-resident secure element anchors all of it. The recurring theme is lifecycle: identity established at manufacture and defended through every update until decommissioning.
Frequently asked questions
Why do IoT devices need a hardware root of trust?
IoT devices are physically accessible and long-lived, so software-only keys can be extracted and cloned. A secure element holds a non-exportable device key and enables attestation and signed-update verification that survive host compromise.
What is device attestation?
Attestation lets a device cryptographically prove its identity and, often, its firmware/configuration state to a backend, so only genuine, untampered devices are trusted on the network.
How does the CRA affect IoT security?
The Cyber Resilience Act makes secure-by-design, security updates over a defined support period, and vulnerability handling mandatory for connected products in the EU — obligations that a hardware root of trust helps satisfy.
When should a device identity be provisioned?
At manufacture, on a controlled line under key custody. A device that leaves the factory without an identity has no trustworthy way to obtain one later, because there is nothing to authenticate the request.
How is a credential rotated on a device already in the field?
Over an authenticated channel whose session keys derive from the factory-provisioned root. The root stays fixed in hardware; the operational credentials above it rotate without a recall.