The CRA without a compliance department

Many 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 (Regulation (EU) 2024/2847) 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. A product already on the market before then becomes subject to the wider requirements only if it is substantially modified afterwards: a change that affects its compliance with the essential cybersecurity requirements, or changes the intended purpose it was assessed for. The size of an update is not the test, and a security update that only reduces risk without changing the intended purpose is generally not a substantial modification. The reporting duties apply regardless.

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.

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, once, through the CRA Single Reporting Platform, which routes it to the relevant national CSIRTs and ENISA: an early warning within 24 hours of becoming aware, a fuller notification within 72 hours, and a final report within 14 days of a fix or mitigation being available for an actively exploited vulnerability, or within one month of the 72-hour notification for a severe incident. 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 few small companies have practised it.

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. For a simple product the first can be 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. Attackers now use AI tools too; assume your product will be probed with them.

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) come in two classes. Class I products may self-assess only if you apply a harmonised standard, a common specification or a qualifying European cybersecurity certification; otherwise they need a third-party assessment. Class II products need a third-party assessment or an eligible certification scheme. A small "critical" list needs European cybersecurity certification where the Commission requires it, and otherwise follows the class II route. 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 or for the support period, whichever is longer. Engineers tend to put this item off, and it is the easiest, because you are documenting what a good team has already done. The trap is treating it as an end-of-project task: the risk assessment should shape the design from the start, and the documentation should be written as the work is done, because 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 outside the CRA unless it also places products on the EU market. It may, however, fall within PSTI, the product security regime under the Product Security and Telecommunications Infrastructure Act, in force since 29 April 2024, where its product is a relevant consumer connectable product and no exemption applies. The exemptions matter for readers of this book: some vehicle categories have been excluded since February 2025. Many 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 much of the work overlaps, but meeting the CRA does not by itself show PSTI compliance: PSTI has its own scope, its own duties for importers and distributors, and its own statement of compliance. The main differences are scope (PSTI covers relevant consumer connectable products, subject to exclusions; the CRA covers industrial and business products too) and depth.

The practical reading: CRA work covers much of what PSTI asks, but it does not establish PSTI compliance, which needs its own check of scope, supply-chain duties and the statement of compliance. If you only meet PSTI you have done a small part of the CRA, and none of the items that take longest.

What small teams find hardest

For companies of this size, 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 turns much of that discipline into explicit legal obligations.

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 assessors will expect to see it.

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. If it can, it is probably ahead of most of its competitors.

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 obligations are in Chapter II and Annex I, the important and critical classes in Annexes III and IV, the reporting duties in Article 14), the standards, the Commission's CRA pages for the harmonised standards as they are published 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.