Security used to be something a buyer asked about. In Europe it is becoming something the product itself has to carry. The Cyber Resilience Act is Regulation (EU) 2024/2847, adopted on 23 October 2024, and it sets cybersecurity requirements for products with digital elements sold in the EU. If your product is one of them, the text is worth reading before anyone summarises it for you.
This is not legal advice, and nothing here tells you whether your product meets the law. That judgement belongs to you and your advisers. What follows is what the text says, in plain terms, with the source linked so you can read it yourself.
It is a regulation, and parts of it already apply
Unlike a directive, a regulation applies directly in every Member State. Under Article 71, it entered into force on 10 December 2024 and applies in three steps:
- from 11 June 2026, the rules on notifying the bodies that assess conformity (Chapter IV);
- from 11 September 2026, the reporting obligations in Article 14;
- from 11 December 2027, everything else.
So on the day this essay is published, the first two steps already apply. The reporting obligations are live; the product requirements are not yet.
Article 69 adds a transition rule that matters for anything already on sale. A product placed on the market before 11 December 2027 falls under the requirements only if it is substantially modified from that date. The reporting obligations in Article 14 are different: they apply to products in scope that were placed on the market before that date too.
What counts as a product with digital elements
Not every piece of software is covered, and the line is worth getting exactly right.
Article 3 defines a product with digital elements as a software or hardware product and its remote data processing solutions, including components placed on the market separately. Article 2 narrows it to products whose intended purpose or reasonably foreseeable use includes a data connection to a device or network.
The cloud part is narrower than it sounds. Article 3 counts remote data processing only where the manufacturer designs it, or has it designed, and where the product could not perform one of its functions without it. Recital 12 spells out the consequence: websites that do not support the functionality of a product with digital elements, and cloud services designed outside a manufacturer’s responsibility, fall outside the Regulation. Where a service is the remote data processing behind an app or device you make, the answer can differ, so check each part on its own.
Article 2 also leaves out products already covered by their own sectoral rules, such as medical devices, motor vehicles and certain civil aviation products. Whether your product sits inside the line is the first question for your advisers.
What it asks of a product
It asks two things: that the product is secure by design, and that the manufacturer keeps it that way.
The first is Annex I, Part I, which Article 6 makes the condition for being on the market at all. A product has to be made available without known exploitable vulnerabilities and with a secure default configuration. It has to protect against unauthorised access, protect the confidentiality and integrity of the data it handles, process only the data it needs, and allow vulnerabilities to be addressed through security updates.
The second is Annex I, Part II, on handling vulnerabilities. It asks the manufacturer to identify and document the product’s components, including a software bill of materials covering at least the top-level dependencies. It asks for vulnerabilities to be addressed and remedied without delay, for security updates to be distributed securely, and for a policy on coordinated vulnerability disclosure with an address where vulnerabilities can be reported.
Article 13 turns this into the manufacturer’s duties. It asks for a cybersecurity risk assessment, kept with the technical documentation. It also sets a support period during which vulnerabilities are handled: at least five years, unless the product is expected to be in use for less, with its end date made clear to the user at the time of purchase.
What already applies: reporting
Article 14 asks a manufacturer to report any actively exploited vulnerability in its product, and any severe incident that affects the product’s security, through a single reporting platform. The Article sets out the steps: an early warning within 24 hours of becoming aware, a fuller notification within 72 hours, and a final report later. It also asks the manufacturer to inform the users affected.
These deadlines are measured in hours, which makes reporting a question of who knows what, and how quickly, more than a question of paperwork.
How a product shows it meets the requirements
The route depends on the product’s class. Under Article 32, a manufacturer of a product that is neither important nor critical may assess conformity itself through internal control. Products listed as important in Annex III, under Article 7, or as critical in Annex IV, under Article 8, face stricter routes, some of them through a third party.
Either way, the result is technical documentation (Article 31), an EU declaration of conformity (Article 28) and the CE marking (Article 30). Under Article 64, failing the essential requirements or the obligations in Articles 13 and 14 can bring fines of up to EUR 15 million or 2.5 % of total worldwide annual turnover, whichever is higher.
What this means for the roadmap
The text reads like a compliance project. For a product, it behaves more like a habit you either keep or lose with every release.
Know what is inside your product. A list of components and dependencies is the start of everything else. It is also the first thing you need when a new vulnerability is announced and someone asks whether you are affected.
Make the secure setting the default. Defaults decide what most users live with. A product that ships locked down and lets people open it up is a different product from one that ships open and hopes they close it.
Decide how long you will support each version. A support period is a product decision with a cost attached. Make it on purpose, write it down, and tell your users.
Settle who reports, and to whom. Reporting already applies to products in scope. Agree inside your company who decides that something must be reported, and who sends it.
Ask your advisers the legal questions early. Scope, product classes and the conformity route are theirs to answer. You will make better roadmap choices once you know their answer than while you are guessing it.
None of this needs to fill every meeting. Settle it, hold the course, and you can lift your eyes from the article numbers to the product your customers rely on.
Where we come in
We do not give legal advice, we never promise compliance, and we do not tell you when you will be ready. That judgement stays with you and your advisers.
What we can do is the security work on your product that you choose, described in Harden security before the questionnaire arrives. We work within the access you grant, and nothing more. The work lands in your own code repository. The code we build for you is yours. You decide what ships. Nothing reaches your users without your approval.
It starts with a conversation, with no obligation.
