The CRA without a compliance department

Most of the products the EU Cyber Resilience Act covers are not made by companies with a compliance department. They are made by companies with an engineering team, a founder or two, a product manager if they are lucky, and a deadline. I have run product development in companies like that, for connected consumer hardware sold into several markets with different rules, and I have sat on the other side of the table reviewing technology for a bank before it lent. This is the CRA as I would explain it to a leadership team of that size: what you have to be able to show, when, and which of it takes longest.

It is not legal advice, and it is not a conformity assessment. It is the engineer's map of the territory, so that when you do talk to a lawyer or an assessor you know what you are asking.

What it is and who it catches

The Cyber Resilience Act is an EU regulation that applies to "products with digital elements" placed on the EU market: hardware or software that can connect, directly or indirectly, to a device or network. An e-bike controller, a smart thermostat, a sensor gateway, a battery management system with a Bluetooth app, the app itself, and the firmware inside all of them count. If you sell into the EU you are caught whether or not you are in it, so a UK manufacturer exporting to Germany has the same obligations as a German one. The UK's own regime for consumer connectable products, PSTI, has been in force since April 2024 and asks for a subset of the same things, so most of the work serves both.

Two dates matter. The reporting duties applied from 11 September 2026, so they are live now. The full set of obligations applies from 11 December 2027. Anything you place on the market after that date must comply; anything already in the field has obligations too, most obviously around updates and vulnerability handling.

The eight things, in the order that takes longest

The regulation is long. For a company of this size it boils down to eight things you must be able to show. I have put them in the order I would start them, which is the order in which they take time, not the order the regulation lists them.

1. A support period you can keep, and updates you can deliver

You must provide security updates for a support period that reflects the expected use of the product, and at least five years unless the product's life is plainly shorter. You must state that period to the buyer. Then you have to be able to deliver those updates, safely, to devices in the field for the whole of it. That is a product strategy decision and an engineering programme, and it is the item that takes longest, because it means an over-the-air update capability with signed images, staged rollout, rollback and an accurate picture of which version is on which device in which market. If you do not have that today, start here. Everything else on this list is easier once you can change what is in the field.

2. A vulnerability handling process, with someone running it

You must have a coordinated vulnerability disclosure policy, a single point of contact for reports, a way of tracking and fixing vulnerabilities, and a way of telling users what was fixed. That is a process and a named person, not a document. In a hundred-person company the person is usually the engineering lead, who already has a job, and this is the obligation that most often has no owner when I ask.

3. A 24-hour reporting process

From September 2026 you must report an actively exploited vulnerability, or a severe incident affecting the product's security, to ENISA's reporting platform and your national CSIRT: an early warning within 24 hours of becoming aware, a fuller notification within 72 hours, and a final report within 14 days. Twenty-four hours is a phone call on a Saturday. Decide now who makes it, how they find out, and what they need in front of them, and rehearse it once. This is the obligation that is already in force and the one almost nobody has practised.

4. A software bill of materials

You must produce a machine-readable list of the software components in the product, at least the top-level dependencies, and keep it current. Most small companies have never produced one. The first is a day's work with the right tooling; the harder part is what you find. Licences you did not know you had, components and services you did not know you depended on, and libraries three years out of date. The SBOM is also what the vulnerability process runs on, so items two and four are one job.

5. No known exploitable vulnerabilities at release, and secure by default

You must ship without known exploitable vulnerabilities, with a secure default configuration, with no universal default passwords (PSTI already requires this in the UK), with the attack surface minimised, and with protection for the data the product handles. For a small company the practical meaning is testing by someone who did not write the code: a penetration test on the device, the app and the cloud service before release, and again after major change. The attackers now use AI tools; assume they have already tried your product.

6. Knowing which class you are in, and therefore your conformity route

Most products are in the default class and can self-assess: you check your product against the requirements, write it down, and declare conformity. Products on the "important" lists (certain network equipment, identity and access products, some industrial control and smart-home security categories, among others) need either harmonised standards applied or a third-party assessment, and a small "critical" list needs certification. Establish your class early, because a third-party route adds months and money, and because it decides how much of the following two items you must produce.

7. Technical documentation and a risk assessment

You must write down the cybersecurity risk assessment for the product, the design and development decisions that follow from it, the testing, and how each requirement is met, and keep it for ten years. Engineers hate this item and it is the easiest, because you are documenting what a good team has already done. The trap is leaving it to the end; the documentation is what the assessor reads, and what your successor reads when the person who designed the thing has left.

8. The declaration, the CE mark and the user information

Finally the EU declaration of conformity, the CE marking with the CRA in scope, and the information the user gets: the support period, how to report a vulnerability, how updates arrive, and what to do at end of life. This is paperwork, and it comes last because it summarises the other seven.

The UK's PSTI regime, side by side

A UK company selling only in the UK is not caught by the CRA, but it is caught by PSTI, the product security regime under the Product Security and Telecommunications Infrastructure Act, in force since 29 April 2024 for consumer connectable products. In my experience most UK manufacturers of this size have not heard of it either; I have written it up separately in PSTI: the UK product security law that already applies to you. It asks for a subset of the same things, so the work overlaps almost entirely; the differences are scope (PSTI is consumer products only; the CRA covers industrial and business products too) and depth.

The practical reading: if you meet the CRA you meet PSTI; if you only meet PSTI you have done perhaps a third of the CRA, and none of the items that take longest.

What small teams find hardest

Having watched companies of this size approach this, the hard parts are not the ones people expect. The technical requirements are mostly good engineering that a competent team recognises. What is hard is the commitments: a support period of five years is a promise to fund engineering on a product that may have stopped selling, and the update capability behind it is an investment that produces no feature. The process obligations are hard because nobody owns them; the vulnerability contact and the 24-hour call fall to whoever is nearest. And the documentation is hard because it is the first time anyone has written down why the product is the way it is, and the answer is sometimes uncomfortable. Products already in the field make all three harder, because the decisions were made before anyone knew this was coming.

The companies that will find it easiest are the ones that already know what is in their products, can update them safely, and can find out quickly when something is wrong. That is not a compliance description. It is a description of a professionally run product, and the CRA has made it the law.

None of this is a reason to panic, and it is not a reason to buy a compliance platform. Fourteen months is enough for a company of this size to do all eight, provided it starts with the two that take longest and gives the process items an owner. Most of the work is engineering a good team would want to do anyway, and the paperwork follows from it. If you want to know where you stand before you commit anyone's time, the free CRA Readiness Check on this site asks about these eight and gives you the first step for every gap. If you want the map applied to your product by someone who has done it, that is what the connected-products audit is for, and I am happy to talk it through first.

Three things worth taking seriously

For leadership teams: the support period and the update capability are the long poles. Decide the support period you will state, cost the update capability, and start it this quarter; the rest fits behind it.

For engineering leads: produce the SBOM this month, even a rough one. What it shows you sets the priority for everything else, and it is the evidence every assessor asks for first.

For boards, investors and lenders: ask any connected-product company you are backing which class its products are in and what its stated support period is. If it cannot answer, the December 2027 date is now a line item in your risk.

I am an engineer, not a lawyer. This is a map for a leadership team, not legal advice; the classification of a particular product and the route to conformity need the regulation, the standards and, for the important classes, an assessor.

---

Which of the eight could your company show today, with evidence rather than assurance?

Check your readiness against the eight in ten minutes with the CRA Readiness Check, or talk it through with me first.