What CRA compliance actually takes for a small hardware team

After I wrote about the reporting duty that started in September, the question I got most often was a simple one. Fine, we can report, so what else is there? Most of the answers floating around are either a two-line summary that says "secure by design" and stops there, or a hundred-page consulting deck. I wanted something in between, so I sat down with the regulation, the annexes and the Commission guidance from July and wrote down every obligation a manufacturer of a connected product actually has. The result became a readiness checklist on this site. This post is the reasoning behind it.

Two dates, and the unit that matters

The CRA has two dates a hardware company needs to care about. The reporting obligation in Article 14 has applied since 11 September 2026, to every product on the EU market, including units you sold years ago. Everything else applies from 11 December 2027.

The detail that changes planning is what "placed on the market" means. The Commission guidance is explicit that it applies to each individual unit. A sensor model you have been selling since 2023 does not get a pass in December 2027. The units already sold stay outside the design requirements, but every unit that leaves your warehouse from 11 December 2027 has to meet all of them. If your product line will still be shipping then, the work below applies to it, and with hardware lead times that work starts now.

The risk assessment everything hangs on

Article 13 asks for a documented cybersecurity risk assessment, based on the intended purpose, the reasonably foreseeable use, the environment the product works in and how long it will be in use. It sounds like paperwork, and in a way it is, but it is also the document the rest of the regulation is built on. For each of the thirteen security properties in Annex I, the assessment has to say how you meet it or why it does not apply. A requirement you simply skip is the easiest thing for a market surveillance authority to find.

The backend belongs in that assessment too. The CRA counts remote data processing that the device needs for its functions as part of the product, so the API, the MQTT broker configuration and the provisioning service are in scope along with the firmware.

The thirteen properties

When I first read Annex I Part I, I was relieved. Most of it describes what a careful IoT team already does. Ship without known exploitable vulnerabilities. Be secure by default, with a way to reset the device to its original state. Protect against unauthorised access, which in practice means per-device credentials and authenticated local interfaces. I wrote about one way to get unique device identities through a production line a few days ago. Protect the confidentiality and integrity of data, commands, firmware and configuration, which is TLS, secure boot and signed images. Limit the attack surface, which on a device means the JTAG and UART ports are locked in production and the test endpoints are gone.

A few of the thirteen are less obvious and deserve a careful read. Security updates have to be possible, and where applicable they should install automatically by default within an appropriate timeframe, with a clear opt-out, a notification that an update is available and an option to postpone it. That is a product decision as much as a firmware one, and it is worth settling now, because changing update behaviour on a fleet later is painful. I covered the mechanics of updating a large fleet safely in an earlier post. The product also has to record and monitor relevant internal activity, such as access to or changes of data and functions, and give the user a way to opt out of that. It has to let users remove all their data and settings permanently. And it has to minimise its negative effect on other devices and networks, which for a fleet mostly means reconnecting with backoff and jitter so ten thousand devices do not hammer a service at the same second after an outage.

Handling vulnerabilities for years

Annex I Part II is about processes. You need an SBOM for every release in a common machine-readable format, covering at least the top-level dependencies. You fix vulnerabilities without delay and, where technically feasible, ship security fixes separately from new features. You test the security of the product regularly. Once a fix is out, you publish what the vulnerability was, which products it affects, how severe it is and what users should do. You run a coordinated vulnerability disclosure policy and publish a contact where people can report problems, including problems in third-party components you integrate. Updates have to be distributed securely, and security updates go out free of charge with a message telling users what to do.

Two numbers from Article 13 are easy to miss. The support period must be at least five years, longer if the product is expected to be used longer, and its end date, at least month and year, has to be visible at the time of purchase. Every security update you publish must then stay available for at least ten years or the rest of the support period, whichever is longer. If your update server and signing keys are not planned for that horizon, they should be.

Paperwork, conformity and the CE mark

Annex II lists what the user information has to contain, from the vulnerability contact and the support end date to instructions for secure setup, updating and decommissioning. Annex VII lists the technical documentation, which pulls together the product description, the architecture, the vulnerability handling processes, the risk assessment, the reasoning behind the support period, test reports and the declaration of conformity. Both have to be kept for ten years, or for the support period if that is longer.

How you prove conformity depends on the category. For a default product, which covers most sensors, trackers and controllers, you can assess it yourself under internal control. Important products in class I can only do that when they apply harmonised standards, common specifications or a certification scheme in full. Harmonised standards for the CRA are still being finalised, so in practice many class I manufacturers should plan for a notified body. Class II always needs one, and critical products such as smart meter gateways may need a European certificate. The rules for notified bodies have applied since June 2026, and I expect their calendars to fill up well before December 2027. After that comes the EU declaration of conformity and the CE marking, which for most of us will sit alongside the Radio Equipment Directive in a single declaration.

The fines are worth knowing even if nobody plans to pay them. Breaching the essential requirements or the obligations in Articles 13 and 14 can cost up to fifteen million euros or two and a half percent of worldwide turnover, whichever is higher.

What I would do first

If I were running engineering at a small hardware company today, I would start with reporting, because it already applies and it is mostly about people and accounts. Register on ENISA's platform, decide who makes the call at two in the morning, know which firmware versions run in which countries, and set up a daily check of your SBOMs against lists of actively exploited vulnerabilities.

Next I would go after everything that needs a firmware or hardware change, because those take product cycles. Secure boot, signed updates with rollback protection, per-device credentials, locked debug ports and an SBOM generated by the build. If a board revision is needed to fit a secure element or lock down a debug interface, finding that out in 2026 is a lot cheaper than finding it out in late 2027.

The documentation comes last, and it goes much faster when the engineering already exists. A risk assessment written after the design decisions are made mostly records reasons you already had. A technical file assembled from a build pipeline that produces SBOMs and test reports on every release is mostly links.

The checklist

I put all of this into a readiness checklist. Three questions about your product adjust it to your situation, then each item can be marked done, in progress, to do or not applicable, with a reference to the article or annex it comes from. It runs in your browser, keeps your answers on your device and gives you a Markdown gap report to take to your team. If you are not yet sure the CRA covers your product at all, the scope check is the place to start.

None of this is legal advice, and the harmonised standards will refine how individual requirements are met once they are published. The structure of the obligations is in the regulation itself, though, and it is not going to change. If your team is looking at that list and wondering where to begin, I am happy to help.