Device identity is a unique, cryptographically verifiable credential assigned to a physical device, usually during manufacturing, that lets the device prove it is genuinely itself to a backend system, an app, or another device. Not a username. Not a serial number printed on a sticker. A private key that never leaves the chip, paired with a certificate that says "this exact piece of hardware was made by this exact manufacturer, on this date, and hasn't been swapped or cloned since." Under the EU Cyber Resilience Act, it is the most direct way to satisfy the access control requirement in Annex I once you are shipping more than a handful of units.
I want to start with a number that still gets me every time I mention it in a conversation with other engineers: 62. That's how many default username/password pairs sat in the credential list of the original Mirai source code. That short list was enough to build the botnet that, on 21 October 2016, threw somewhere around 100,000 endpoints at the DNS provider Dyn and knocked Twitter, Netflix, and Reddit offline across three waves spanning most of a working day. A month later the same botnet peaked at roughly 600,000 infected devices. Not 62 vulnerabilities. Sixty-two default logins, reused across camera and router models from dozens of manufacturers. Every device with the same brain shared the same key to the front door.
That's the failure mode device identity exists to prevent, and a decade later, most connected products still ship exactly the way Mirai's victims did.
Device identity is not the same thing as authentication
I've had this conversation with product teams more times than I can count, so let me be precise about it here. User authentication is about a person proving who they are to log into an app. Device identity is about the physical hardware proving what it is, independent of any user, any app session, any password someone can forget or reuse.
A smart lock doesn't have a "user" in the way a web app does. But it absolutely needs to prove to your phone, and to the cloud service managing it, that it is the exact lock that was paired during setup, not a lookalike sitting on the same network pretending to be it. That proof is device identity. It typically comes down to a private key generated inside the device, ideally inside a secure element or a hardware root of trust, that never leaves the chip and never gets transmitted anywhere. The device uses that key to sign challenges, and anyone who wants to verify it just checks the signature against a public certificate issued at manufacturing time.
Why this actually matters, beyond the compliance checkbox
Here's the part that convinced me this deserves its own article instead of a paragraph inside a bigger compliance piece.
Cloning and counterfeiting. If your product is built through a contract manufacturer, and most hardware companies' products are, there's a specific and under-discussed risk: a CM that has your firmware and your provisioning process can, in theory, run an extra shift on the line and sell "your" devices through gray-market channels using the same cryptographic material as the real ones. Without per-device identity, there's no way to tell a genuine unit from an overrun one. With it, every device carries a certificate traceable to a specific manufacturing batch, and a cloned device without a valid private key simply can't authenticate, no matter how convincing the plastic housing looks.
Warranty and liability exposure. When a counterfeit or cloned device fails in the field, and it eventually will, customers come to you, not the counterfeiter. Proof of origin matters here in a very unglamorous, very real way: it's the difference between "this was never our device" and an expensive support ticket you can't actually resolve.
Supply chain compromise. SEC Consult's "House of Keys" research scanned firmware images covering more than 4,000 models of embedded device across 70+ vendors and found over 580 unique private keys (SSH host keys and the private keys behind HTTPS server certificates) shared across routers, modems, IP cameras, and VoIP phones. At least 230 of those keys were actively in use on more than 4 million internet-facing devices. Those weren't attacker-planted backdoors. They were inherited: vendors built firmware on top of chipset SDKs and reference images and shipped whatever keys were already in there, which is why the same key turns up not just across one product line but across products from companies that have nothing to do with each other. Every device sharing a key is a single point of failure for all of them, and once one unit gets reverse-engineered, the rest are compromised at the same moment.
That's the pattern behind almost every large-scale IoT compromise you've heard of. Not zero-days. Reused secrets.
What CRA actually requires here
The Cyber Resilience Act doesn't have a line item that says "thou shalt implement device identity." It's more indirect than that, and honestly a little frustrating to parse on a first read. The relevant text is Annex I, Part I, point 2(d), and it's worth quoting exactly rather than paraphrasing, because the paraphrases in circulation tend to be stronger than the regulation:
ensure protection from unauthorised access by appropriate control mechanisms, including but not limited to authentication, identity or access management systems, and report on possible unauthorised access
Two things to notice. The first is that trailing clause: you also have to be able to detect and report unauthorised access, which in practice means logging authentication failures somewhere your backend can see them. It gets dropped from most summaries. The second is the sentence that introduces the whole list, which conditions everything under it: these requirements apply "on the basis of the cybersecurity risk assessment referred to in Article 13(2) and where applicable." CRA is a risk-based regulation. It does not hand you a checklist of mandatory controls; it asks you to assess your product's risks and then justify what you did about them. Article 13(4) puts that in writing: the risk assessment goes into the technical documentation required under Article 31 and Annex VII, and where you decide a requirement isn't applicable to your product, you "shall include a clear justification to that effect in that technical documentation."
So the honest framing is not "CRA mandates device identity." It's that for a fleet of connected devices, per-device cryptographic identity is the most defensible answer to 2(d), and a shared password baked into a firmware image is very hard to defend as an "appropriate control mechanism" once you've written down that anyone who extracts it from one unit owns all of them. That's an argument you make in your risk assessment, not a box the regulation ticks for you.
Worth being precise about timing too: Annex I doesn't apply until 11 December 2027. What lands sooner is Article 14 vulnerability and incident reporting, on 11 September 2026, which is a separate obligation with nothing to do with device identity, and one that reaches products already on the market. If you're reading compliance content that describes Annex I as a present-tense legal requirement, that's a good signal to check its other claims.
One caveat cuts the other way, though, and most CRA-focused writing misses it. If your product has a radio, and most of the devices this article is about do, the Radio Equipment Directive got there first. RED Article 3(3)(d), switched on for internet-connected radio equipment by Delegated Regulation (EU) 2022/30, has been applicable since 1 August 2025. Read literally it is a network-protection requirement rather than an identity one: radio equipment must not "harm the network or its functioning nor misuse network resources, thereby causing an unacceptable degradation of service." The access control obligations arrive through the standard you use to demonstrate conformity with it. EN 18031-1 is the harmonised route to 3(3)(d), and default passwords sit squarely inside its scope: the Commission decision publishing it singles out clauses 6.2.5.1 and 6.2.5.2 as the ones that "deal with default passwords". RED is enforced through the CE machinery you already use. So "nothing bites until 2027" is true of the CRA and, quite possibly, false of your product.
On the technical side, IEEE 802.1AR is the reference most teams end up building against: an Initial Device Identifier, or IDevID, is an X.509 certificate provisioned into the device at manufacturing time, signed by the manufacturer's own certificate authority, meant to live for the device's entire lifecycle. On constrained microcontrollers it usually pairs with TCG DICE, which derives that identity from a secret fused into silicon so the credential is hardware-bound rather than a key written into ordinary flash. But it isn't the only route, and anyone telling you there's no alternative hasn't looked: EN 18031, cited in the Official Journal on 30 January 2025 and therefore already harmonised under the Radio Equipment Directive, covers access control mechanisms directly and leaves room for per-device unique passwords as an authenticator. What the Commission carved out of the presumption of conformity there is the option of letting a user set no password at all, not unique ones. (Both EN 18031 and 802.1AR are paywalled documents; that reading comes from Implementing Decision (EU) 2025/138, which is public, rather than from the standards themselves.) Matter has its own device attestation PKI. FIDO Device Onboard exists. Harmonised standards under CRA are still being finalised. Under the CEN/CENELEC/ETSI standardisation mandate (M/606), the two core horizontal standards are due by the end of August 2026, the product-specific vertical standards by the end of October 2026, and the remaining horizontal standards by the end of October 2027. So exactly which of these buys you presumption of conformity is genuinely not settled yet. What I'd say with confidence is narrower than the marketing version: IDevID-style provisioning is the approach that ages best, because it's the one that doesn't need revisiting when the vertical standard for your product category finally lands.
How this actually gets built, without the jargon
Strip away the acronyms and the process is closer to something you already understand intuitively: every device gets a passport the moment it's born.
During manufacturing, before the device ever leaves the factory floor, a unique cryptographic key pair gets generated. The best practice is generating it inside a secure element or the microcontroller's own hardware crypto and key storage, so the private half never exists anywhere outside that one chip, not in a database, not in a spreadsheet, not in the contract manufacturer's build logs. A certificate authority, controlled by you, signs a certificate that vouches for the public half. The certificate itself is just data and lives in flash next to the firmware. It's the private key, or the secret it's derived from, that has to live in storage the CPU can never read back, a locked key slot inside the secure element, or read-protected on-chip storage that only the crypto engine can touch.
From that point on, whenever the device talks to your backend, or to another device, it can sign a message with its private key. Anyone who wants to check that message is legitimate just verifies the signature against the certificate. No shared secret ever crosses the network. No password to leak. No single key that, once extracted from one unit, unlocks every unit you've ever shipped.
The trade-offs are real and worth naming honestly. Injecting keys during manufacturing is the cheapest approach in bill-of-materials terms but leans hard on how secure your provisioning process actually is, because for a moment the private key exists outside the chip. Using the key storage already built into a modern MCU costs nothing extra per unit and is a large improvement over that. A dedicated secure element adds real cost per unit and moves the trust anchor into a part designed to resist physical attack; a discrete TPM is a similar trade at similar or higher cost, and is more common in gateway-class hardware than in small devices. None of these is free, but all of them are cheaper than the alternative, which is retrofitting identity into a product that's already in ten thousand homes.
The mistake I see most often
One key, all devices. It's the single most common anti-pattern in embedded products, and it's rarely a decision anyone consciously made. It's what happens when a team is racing toward a launch date, generates one key pair to get the first prototype talking to the backend, and that "temporary" credential quietly becomes the production identity for the whole fleet because nobody circled back to fix it before the SKU shipped. (Worth separating from firmware signing, where a single key across all units is the normal and correct design; the point is that device identity has to go the other way.)
The second most common mistake is generating unique keys but storing them somewhere insecure, in a plaintext manufacturing database, in a CSV a contract manufacturer emails around, in firmware you can pull the key out of with a $30 programmer and an evening. Unique-but-exposed is barely better than shared-and-exposed. The point of device identity is that the private key is genuinely unextractable, not just technically different from unit to unit.
Retrofitting an existing product is possible, just harder
If your product is already shipping without per-device identity, the honest news is that this is one of the more painful CRA gaps to close after the fact, because it usually touches manufacturing, not just firmware. But it's not a full redesign. For units you haven't built yet, it mostly means adding a provisioning step at the contract manufacturer, sometimes a small secure element on the next board revision, and a certificate authority setup on your backend. The harder question is units already in the field: if they have usable hardware key storage sitting unprovisioned, you can sometimes provision them over the air, though with a weaker trust anchor than a factory would give you, and if they have no secure key storage at all, there's no firmware update that turns software-extractable keys into genuine hardware-backed identity. For products still in development, all of this is dramatically cheaper to build in from the start than to bolt on later, which is the whole argument for doing it now rather than in the run-up to December 2027.
Where to start
If you're not sure whether your product has real device identity or just a serial number that looks like one, ask one question: can two devices with identical firmware be told apart cryptographically, without relying on anything a customer or a cloner could copy? If the honest answer is no, this is worth fixing while it's still a design decision on your own timeline, rather than something you're defending in a risk assessment under deadline pressure.
Our free CRA Readiness Check walks through exactly this, alongside secure boot, update signing, and the rest of the Annex I baseline we cover in our guide to secure boot for IoT devices. If cloning and supply chain risk are part of your threat model already, that's also where device identity connects back to our broader IoT threat modeling approach. Identity is one of the concrete controls that comes out of that process, not a separate exercise.
FAQ
What is device identity in IoT? A unique, cryptographically verifiable credential, typically a private key and matching certificate, that lets a physical device prove it is genuinely itself to backend systems, apps, or other devices, without relying on a shared password or a copyable serial number.
Is device identity required by the CRA? Not by name, and not unconditionally. Annex I, Part I, point 2(d) requires products to "ensure protection from unauthorised access by appropriate control mechanisms, including but not limited to authentication, identity or access management systems, and report on possible unauthorised access", but that requirement, like the rest of the list, applies "on the basis of the cybersecurity risk assessment referred to in Article 13(2) and where applicable." So what CRA obliges you to do is assess the risk and justify your control. For a fleet of identical connected devices, per-device cryptographic identity is the answer that's easiest to justify and hardest to argue against. Note also that Annex I applies from 11 December 2027, not today. But if your product is internet-connected radio equipment, RED Article 3(3)(d) has been applicable since 1 August 2025, and EN 18031-1, the harmonised standard you would use to demonstrate it, does carry access control requirements. So "not today" may not apply to you.
What's the difference between device identity and device authentication? Device identity is the credential itself, the key and certificate that make a device recognizable. Authentication is the process of using that credential to prove legitimacy during a specific interaction. You need identity in order to authenticate.
Can I add device identity to a product that's already shipping? It depends on which devices you mean. For units you haven't built yet, yes: it usually means adding a provisioning step to manufacturing, and sometimes a secure element on the next board revision, so it's slower and more expensive than building it in from the start but entirely doable. For units already in the field, it's much harder. If they already have usable hardware key storage sitting unprovisioned, you can sometimes generate a key on-device and have your CA sign it over the air, though the trust anchor is weaker because provisioning happened outside a controlled factory. If the deployed hardware has no secure key storage at all, you can't retrofit genuine hardware-backed identity by firmware update alone, only software-based identity, which is extractable.
Do I need a dedicated secure element, or can I use software-based key storage? CRA doesn't mandate hardware-backed key storage. That's an engineering judgement you make and document in your risk assessment, not a line in the regulation. Our recommendation for anything shipping at scale is a dedicated secure element, or at minimum the key storage and crypto already built into a modern MCU. Software-based storage covers a wide range. A key sitting in plaintext flash comes out with a cheap programmer and an evening; readout protection or encryption-at-rest raises the bar to fault injection in a lab. But none of it is truly unextractable the way a secure element is, so "unique per device but extractable with enough physical access" is a weaker position than it sounds, and how weak depends on your threat model.
What is an IDevID? An Initial Device Identifier, defined by IEEE 802.1AR: an X.509 certificate provisioned into a device at manufacturing time, signed by the manufacturer's certificate authority, intended to remain valid for the device's full lifecycle as proof of authentic origin.
If you're working on a connected product and want a second opinion on your device identity and provisioning approach, our free CRA Readiness Check is a good place to start. Or reach out directly at info@platanor.com.