IoT and the EU CRA: A Secure by Design Guide for Manufacturers

A plain-English guide to the EU Cyber Resilience Act's secure-by-design rules for IoT manufacturers, and how to prove you meet them.

TL;DR: Under the EU Cyber Resilience Act (CRA), every connected device sold in the EU must be secure by design and by default, get security updates across a declared support period, and ship with documented compliance evidence. Secure by design means engineering protection in from the first architecture decision. Secure by default means the device arrives with its strongest practical protections already switched on. The hard part isn't claiming this in a design document. It's proving it in the software that actually ships.

The EU Cyber Resilience Act is one of the most far-reaching product cybersecurity laws in the world. It sets one clear expectation for IoT manufacturers: security is not an optional feature you add at the end, it's a built-in part of every device. Because the EU market is so large, the CRA is already shaping what global buyers and private companies demand from their suppliers, so its reach goes well beyond Europe.

This post is the first in a six-part series walking IoT manufacturers through the CRA in detail. We start with the idea at the core of the whole regulation: secure by design and by default. For the wider picture, see our overview of the EU Cyber Resilience Act.

What does the EU Cyber Resilience Act require for IoT devices?

The CRA requires connected devices in the EU to be secure by design and default, updated across their support period, and backed by compliance evidence.

The CRA, formally Regulation (EU) 2024/2847, applies to any product with digital elements that connects directly or indirectly to a device or network. That covers most IoT: smart-home cameras, medical devices, industrial controllers, connected vehicles, routers, and the firmware inside them. Unlike many rules, it has no carve-out for small companies. If you build, import, or distribute the product in the EU, the essential cybersecurity requirements in Annex I apply to you.

The law entered into force in December 2024, with two dates to plan around. Vulnerability and incident reporting obligations begin September 11, 2026 [verify before publishing], and the full set of requirements applies from December 11, 2027 [verify before publishing]. You can confirm scope and timing on the European Commission's Cyber Resilience Act overview. Three years sounds far off, but a typical hardware development cycle eats most of it, so the products you design now are the ones that have to comply.

What does "secure by design" mean under the CRA?

Secure by design means building security into a device from the first architecture decision, so protection is engineered in rather than bolted on later.

This is the same principle Deloitte and others describe as including security design principles, technology, and governance at every stage of the IoT journey. The CRA turns that principle into a legal duty. In practice it means three things happen up front, not after a product is built: you identify security requirements, you perform threat modeling to map likely attack paths, and you design in features that close those paths. Done well, it shrinks the attack surface before a single line of code ships, instead of leaving teams to patch their way out of trouble after launch.

What does "secure by default" mean under the CRA?

Secure by default means a device ships with its strongest practical protections already on, so users get a secure setup without configuring anything themselves.

The CRA recognizes a simple truth: most users won't, or can't, configure advanced security on their own. So the protection has to be on out of the box. That means no shared default passwords, automatic security updates enabled, and encrypted communication channels by default. The balance to strike is usability. If the secure setup is painful, people disable it, and you've lost the protection. Clear documentation and an intuitive first-run experience keep customers from trading away their own safety for convenience.

Secure by design vs secure by default at a glance

What security features are required to be CRA-compliant?

The CRA expects secure boot, a hardware root of trust, access controls, encryption, and signed secure updates, plus an SBOM and lifecycle vulnerability handling.

The regulation describes outcomes in Annex I rather than dictating exact technologies, but the features below are how IoT teams meet those outcomes in practice. National guidance such as Germany's BSI technical guidance for the CRA spells out the technical expectations, including SBOM content and secure update handling, in more detail.

These features reduce the attack surface and shut down the common initial-access techniques attackers reach for first. They also map directly to the evidence you'll need to produce later.

Why is secure by design so critical for IoT specifically?

IoT devices sit in homes, hospitals, and factories and make attractive entry points, so weak design choices can expose a whole network, not one device.

IoT is where the digital and physical worlds meet, which is exactly what makes it a target. A device is both smart and connected, often running for years with little oversight, processing personal and operational data the whole time. The World Economic Forum has made the stakes plain: hacking a car's location data is a privacy problem, but hacking its control system is a threat to life. Attackers know a single weak device can be the bridge into an entire network, from a smart home to an energy grid. That's why the CRA makes secure by design the starting point for compliance, not an afterthought.

How do SBOM and supply chain requirements fit into secure by design?

The CRA makes you responsible for every component you ship, so secure by design extends to third-party and open-source code, tracked through an SBOM.

You can't secure what you can't see. Modern IoT firmware is mostly assembled from open-source libraries and third-party components, and any one of them can carry a known vulnerability like Log4Shell or Ripple20. The CRA pushes secure-by-design practices down through your supply chain, which means knowing exactly what's inside every build and keeping that inventory current. A software bill of materials is how you get that ground truth. For the documentation side of this, see our guide to the CRA's SBOM and technical documentation requirements.

What does the CRA require after a device ships?

After launch, the CRA requires ongoing vulnerability handling, security updates across a declared support period, and timely reporting of exploited vulnerabilities and severe incidents.

Compliance doesn't end at launch. The CRA treats security as continuous across the product's whole life, which lines up with the prevent, detect, and respond model security teams already use. In practice that means: deliver regular updates and patches, run continuous monitoring so you can detect known and unknown issues, and have an incident response plan ready. You also have to report actively exploited vulnerabilities and severe incidents to authorities, a duty that runs through the EU Agency for Cybersecurity, ENISA. Finally, you need an end-of-life policy that says how long a device gets updates, so legacy devices still in the field don't quietly become the weak point.

{{cta('182378906501')}}

How do IoT manufacturers prove secure by design to regulators?

Prove it with evidence grounded in what actually ships: test the final binary, document requirements and results, and keep an audit-ready trail.

This is where most teams get caught out. Secure by design on the CRA isn't a claim you make in a slide deck, it's something you have to demonstrate to a market surveillance authority on request. And the thing they care about is the product that actually shipped, not the source code you intended to ship. Compilers, build flags, and third-party binaries can all introduce risk that source-only testing never sees. So the proof has to come from the real artifact.

Three practices turn good intentions into defensible evidence:

• Test what ships, not just the source. Analyze the final firmware and binaries so your findings reflect the device a customer actually receives. This is also where binary-level penetration testing earns its place, by confirming whether a vulnerability is genuinely exploitable rather than theoretical.
• Tie requirements to results. Document the security requirements you set at design time, then show the tests and findings that verify each one. That design-to-build traceability is what an audit actually asks for.
• Automate the evidence. Instead of assembling a compliance package by hand the week before an audit, generate it continuously from real scan and test data. That's the idea behind automated, evidence-backed compliance.

Get this right and compliance stops being a last-minute scramble. It becomes a byproduct of how you build.

What are the main CRA challenges for IoT manufacturers, and how do you solve them?

The main challenges are balancing security with usability, limited resources, and a shifting regulation. You solve them by automating checks and proving compliance from shipped software.

Every IoT team hits the same three walls. Here's how to get past each one.

The bottom line for IoT manufacturers

The EU Cyber Resilience Act changes how IoT devices get designed, built, and maintained. Embed security from the first architecture decision, keep it current across the product's life, and you don't just satisfy a regulator. You ship genuinely more resilient devices into an increasingly hostile environment.

The teams who'll struggle are the ones treating secure by design as paperwork. The ones who'll move fast are the ones who can prove it from the software that actually ships. That's the gap we close. From ground-truth analysis of your firmware to continuous monitoring and audit-ready compliance reporting, Finite State helps IoT manufacturers turn secure-by-design requirements into defensible proof.

Ready to make CRA compliance something you can demonstrate instead of just claim? Book a demo to see how Finite State helps you meet EU CRA requirements and stay ahead of emerging threats.