The Cyber Resilience Act applies to products with digital elements placed on the EU market. That is deliberately broad: if your product contains software and connects to anything, it is in scope, whether you think of yourself as a software company or as a firm that makes sensors.
The reporting obligations took effect on 11 September 2026. The wider requirements — essential cybersecurity requirements, conformity assessment and CE marking against them — follow in December 2027. Most of the companies I speak to have filed the whole thing under the later date and missed that the reporting duty is already running.
The clock
When you become aware of an actively exploited vulnerability in your product, or a severe incident affecting its security, you have 24 hours to file an early warning, 72 hours for a full notification, and a final report within 14 days of a corrective measure being available. Reports go through ENISA's Single Reporting Platform to the CSIRT of your main establishment.
Twenty-four hours is shorter than most escalation paths. It is shorter than a weekend. The hard questions are not technical: who decides that something is "actively exploited" rather than theoretically exploitable, and who has authority to file at two in the morning without waiting for a board meeting?
What you need in place
A current software bill of materials. You cannot assess whether a disclosed vulnerability affects your product if you do not know what is inside it — including the vendor SDK, the RTOS, the TLS library and the bootloader. Generate the SBOM as part of the build, not by hand once a year, or it will be wrong within a month.
A way to ship an update. The CRA expects vulnerabilities to be handled and remediated for the support period you declare. A product with no update path is a product you cannot fix, and declaring a long support period on hardware with no OTA mechanism is a promise you cannot keep.
A coordinated disclosure route. A published contact address and a documented process for handling what comes in. Researchers will find your device before you find the bug.
A named person and an out-of-hours route. Not a team — a name and a deputy, with a phone that gets answered.
Where this bites hardest for small manufacturers
The support period is the clause that catches people. You declare it, and you are then obliged to handle vulnerabilities across it. Declare five years on a product whose MCU vendor drops SDK support in two, and you have taken on the maintenance yourself. That decision belongs at the design stage, when the silicon is chosen, not in the marketing copy afterwards.
The second is third-party components. Your obligation covers the whole product, including a module you bought in. If the module vendor will not tell you what is in their firmware, that is a procurement problem with a compliance consequence, and it is far easier to solve before you design them in.
What to do first
Three things, in order. Produce an SBOM for your current shipping product, even a rough one — it will tell you how exposed you are. Decide and write down who files a report and how they are reached. Then check that you could actually ship an update to a device already in the field, and time it. Most firms discover more in that exercise than in any amount of policy writing.
The penalties reach €15 million or 2.5% of global turnover, but that is not really the argument. The argument is that procurement teams at large buyers are already asking suppliers for this evidence, and being able to produce it is becoming a condition of selling.