A connected device that has to prove who it is, or verify that its own firmware has not been altered, needs a secret it can keep. A secret sitting in an ordinary microcontroller's flash is not one it can keep, since anyone with a debugger, a flash reader, or a path to dump memory can lift it, and a connected product is exactly the kind of device an attacker can often get into their hands.

A hardware root of trust is the part that holds that secret in a place the rest of the system cannot read, and does the cryptographic work with it so the key itself never has to leave. It is a small and cheap addition for what it buys, and it has moved over a few years from a feature of high-security products to a baseline that a connected device is increasingly expected to carry, often because a customer or a platform now asks for it by name. Regulations are pushing the same way, since rules on connected-device security in several markets now expect a device to protect its credentials and prove its identity, which turns a once-optional part into one a product needs to ship at all.

Why a secret in flash is not a secret

The problem with keeping a key in the main MCU is that the MCU was never built to hide it. Readout protection can be turned off, bypassed, or defeated with effort, a firmware image pulled from a returned unit can be searched for the key, and a device that an attacker owns gives them all the time they want to try. Once one key is out, every device that shares it is compromised, which is the failure that turns a single cracked unit into a cloned product line. The same exposure applies to a symmetric key shared across a fleet for convenience, which looks fine until one unit is opened and that shared secret unlocks every other unit at once, so a real root of trust gives each device its own key rather than a common one baked into the image.

A secure element answers this by making the key something that cannot be read, even in principle, by the host or by anyone holding the board. The key pair is generated inside the chip and the private half never crosses the boundary; when the device has to sign a message or run a key exchange, it hands the data to the secure element, which does the math internally and returns only the result, so the secret does the work without ever appearing on a bus where it could be captured. The chip is built to resist physical attack as well, with shielding and sensors that wipe the secret if someone tries to open it or glitch it, so prying the package apart yields nothing useful. On top of that one guarantee a whole set of jobs becomes possible, and the central one is why a connected device needs a hardware root of trust rather than a software secret: secure boot, where the device checks each stage of its firmware against a key it trusts before running it; authenticated updates, where it accepts new firmware only if a signature proves the source; and a device identity that a server can verify, so a network can tell a genuine unit from a counterfeit or a spoof. The secure element also gives each device its own unique key from the factory, provisioned in a way the manufacturer never has to handle in the clear, which means a break of one device stays one device rather than spreading. None of this is about encryption speed, since the host MCU can do bulk crypto faster; it is about where the key lives and who can reach it, and the answer the root of trust gives is nobody, not even the device's own processor. The provisioning is part of the guarantee too, since the key can be injected at the chip vendor's secure facility and certified there, so the device maker never handles the secret in the clear on its own line and a compromised factory cannot leak what it never sees. That chain, from a key born inside the silicon to an identity a remote server can check, is the whole of what a root of trust delivers, and it is the reason a serious connected design treats it as a foundation rather than a feature bolted on at the end.

What it enables is concrete. A device can refuse to run firmware that is not signed by its maker, which closes the door on a whole class of tampering and malware. It can hold a certificate that lets a cloud service trust it on first contact without a shared password baked into every unit. And it can authenticate an accessory or a consumable, so a printer, a medical device, or a battery pack can tell an original part from a clone, which is as much a business protection as a safety one.

The low cost authentication ICs

For many connected products the right part is a small, inexpensive authentication chip that adds a root of trust for a few cents and a couple of pins, doing the one security job the design needs without turning into a security subsystem of its own. The ATECC608B provides low cost device identity and keys, a crypto authentication IC that stores keys, runs the ECC operations for signing and key agreement on its own, and talks to the host over I2C, which is why it shows up across IoT designs that need a real identity and secure boot support without the cost or complexity of a full secure element. It pairs cleanly with the common cloud onboarding flows, which is half of why it became a default.

An older and simpler part covers the plainest case. The ATSHA204A-SSHDA-T does low cost device authentication with symmetric-key challenge and response rather than the full public-key suite, which is enough to prove a device or an accessory is genuine at the lowest cost, in a tiny package and with a simple single-wire or I2C interface. It suits the job that is only authentication, where the richer key handling of the newer part is more than the design needs.

Accessory and consumable authentication is a category of its own, and one part is built squarely for it. The DS28E30X+T fits secure accessory and consumable authentication, an ECC-based part with a strong identity and a tamper history that lets a host verify a cartridge, a cable, or a replacement module is an approved one before it trusts or enables it. It is the chip behind a lot of the quiet authentication that keeps clones and unsafe parts out of a system that depends on its consumables.

Where the need is protected storage rather than identity, the parts shift again. The ATAES132A provides encrypted secure storage, combining hardware AES with a block of memory so a device can keep data encrypted and access-controlled in a part separate from the main MCU, which suits holding sensitive configuration, calibration, or usage data that should survive and stay private even if the host is compromised. It blurs the line between a secure element and a secure memory, and it is chosen when the asset to protect is data more than a signing key. A logger that records tamper-evident measurements, or a part that stores a license or an entitlement, fits it well, since the value there is in keeping the stored bytes both secret and honest against a host that an attacker may have already reached.

When the assurance has to be higher

Above the low cost tier sit the certified secure elements, for products where the threat demands more than an authentication chip can promise.

The high assurance secure elements, and stocking them

A high assurance secure element is a chip designed and independently certified to resist serious, funded attack, the kind of part that carries a Common Criteria evaluation and the hardened design that backs it. The SE050 is a high assurance secure element with a broad set of cryptographic functions, certified protection, and the credential storage a payment, identity, or industrial-control product needs, which is why it appears where a plain authentication IC would not pass the security bar the application is held to. It costs more and asks more of the integration, and it earns both where a breach is expensive enough to justify them. It also supports the standard interfaces and applets a security stack expects, so it fits into an established trust architecture rather than forcing a custom one, which counts when the product answers to an auditor as much as to a customer.

Some teams want that security without building the integration themselves, and the turnkey parts answer that. The OPTIGA Trust M offers turnkey device security, a secure element that ships preprovisioned with a certificate and a host library so a design can add a root of trust without becoming security engineers, trading some flexibility for a path that gets a credentialed device working quickly. It suits a team that needs the assurance and the certificate but wants the security part to be a block they buy rather than a system they design. The tradeoff is less control over the exact configuration, which a team set on owning its security stack would refuse, but for many products that is a price gladly paid to ship a credentialed device sooner.

These parts share a trait that has to be planned around: they are usually sole-sourced. A secure element or an authentication chip is rarely second-sourced the way a logic part is, because its security, its provisioning, and its host software are specific to the vendor, so a design that builds one in takes on a single point of supply for a part that is hard to swap late.

That makes the supply question its own piece of the design rather than an afterthought, and stocking a sole source authentication chip means treating it like the long-lead, single-vendor part it is: watching its lifecycle, holding buffer stock against a shortage, and confirming the provisioning and certificate service behind it will last as long as the product. A security part that becomes unavailable cannot be replaced with a similar one on short notice, because the keys, the provisioning, and the trust were all built around that exact chip and its vendor's service behind it.

The choice across all of them runs from a few-cent authenticator to a certified secure element, set by how much an attacker could gain and what the product is held to, with the supply of the part weighed alongside its security from the start. Getting both right is the difference between a device that can prove itself for its whole life and one that is secure until the day its single irreplaceable chip runs out of stock.