The new EU law
The Cyber Resilience Act, in plain English
What the EU's Cyber Resilience Act asks of companies that sell products with software in them: who it covers, the two dates, and what you have to produce.
Updated 7 September 2026
On this page
The short version
The Cyber Resilience Act is the EU's new law on products that contain software. Regulation (EU) 2024/2847 of the European Parliament and of the Council on horizontal cybersecurity requirements for products with digital elements (the Cyber Resilience Act).[Title] The Cyber Resilience Act entered into force on 10 December 2024, the twentieth day after its publication in the Official Journal.[Art. 71(1)]
In one paragraph: if you sell a product with software in it in Europe, you have to build it securely, keep a folder of paperwork that shows how, tell your customers how long you will support it, fix security problems while you do, and tell the authorities quickly when someone is attacking one of your products. A product that does not meet the rules cannot be sold in the EU.
This page is written for the person who has to organise that work: a managing director, an operations or product manager, an engineering lead. It is our reading of the law as engineers, not legal advice. Where your own position turns on a detail, take advice. Every date and figure on this page comes from our published facts file, each with a link to its source.
Does it apply to your product?
You are very likely covered if all three of these are true.
It has software in it, and it can connect. A product with digital elements is a software or hardware product and its remote data processing solutions, including software or hardware components placed on the market separately.[Art. 3(1)] Machines, building systems, sensors, desktop programs, mobile apps, firmware, developer libraries and server software all count.
You sell it, or make money around it, in the EU. The Regulation applies to products with digital elements made available on the Union market in the course of a commercial activity, whatever the size or place of establishment of the manufacturer.[Art. 2(1); Art. 3] Selling, licensing and bundling with a paid service all count, wherever your company is based.
No other EU rulebook already covers it.
Products already covered by the medical device, in-vitro diagnostic, motor vehicle type-approval, civil aviation and marine equipment regimes, and products developed exclusively for national security or defence, are outside the scope of the Cyber Resilience Act.[Art. 2]Two points catch people out. The first is the cloud half of a product. Remote data processing means processing at a distance for which the software is designed by or for the manufacturer and without which the product could not perform one of its functions; a pure cloud service that is not part of a product in this sense is not itself covered.[Art. 3(2)] A pure web service with nothing to install is generally outside the law, but the server side of a device that cannot work without it is treated as part of the product.
The second is open source. Free and open-source software developed or supplied outside a commercial activity is not covered; the Regulation defines when making such software available counts as a commercial activity.[Art. 3; Recitals] Whether paid support or a dual licence around an open-source project counts as commercial is a question of fact. Our scope check walks you through both cases in two minutes.
Who has to do what
The law hands out duties by the part you play, not by the size of your company.
The maker. The manufacturer is the natural or legal person that develops or manufactures a product with digital elements, or has it developed or manufactured, and markets it under its own name or trademark.[Art. 3] This is the heavy role: build it securely, assess the risk, keep the paperwork, sign the declaration, put the CE mark on it, fix security problems and report attacks. If you write the software and sell it under your own name, this is you.
The importer. The EU company that brings in a product made outside the EU. It has to check that the maker did its job before the product is sold.
The distributor. Anyone else in the chain who passes the product on. Lighter duties, but real ones: check that the marks and the documents are there. Importers may place only compliant products on the market and must verify that the manufacturer has carried out conformity assessment, drawn up the technical documentation and affixed the CE marking; distributors must verify the CE marking, the declaration of conformity and that the manufacturer and importer have met their duties.[Arts. 19, 20]
Careful: an importer or a distributor can become the maker by accident. An importer or distributor that markets a product under its own name or trademark, or substantially modifies it, is treated as the manufacturer.[Art. 21] Sell a supplier's product under your own brand, or change it in a real way, and the heavy role is yours. Our page for importers and distributors covers this in more detail.
The EU representative. A company outside the EU may appoint an EU-based company to act for it. A manufacturer may appoint an authorised representative in the Union by written mandate; the Regulation does not oblige non-EU manufacturers to appoint one.[Art. 18] We are not one and do not act as one.
The open-source steward. A lighter role for foundations that support open-source projects without selling them. Open-source software stewards, legal persons that support the development of free and open-source software intended for commercial use, have a lighter regime than manufacturers.[Art. 24]
Which group is your product in?
Every covered product has to meet the same standard of security. What changes between groups is who checks that you have.
Default products may self-assess their conformity; important products (Annex III, class I and class II) and critical products (Annex IV) follow stricter conformity routes.[Arts. 7, 8, 32; Annexes III, IV]Ordinary products
Anything not on the special lists. Most machines, most business software, most apps. You check your own work, keep the paperwork and sign the declaration yourself. This is where we work, and where most of our customers sit.
Important, class I
Products whose failure has a wider effect. Annex III class I includes, among others, identity and access management software, browsers, password managers, anti-malware software, VPN products, network management systems, SIEM systems, boot managers, public-key infrastructure software, operating systems, routers and modems intended for internet connection, microprocessors and microcontrollers with security-related functions, smart home products with security functions such as locks, cameras and alarms, connected toys with social interaction or location tracking, and personal wearable health-monitoring products.[Annex III, Class I] You may still check your own work, but only if you follow the relevant European standards in full. Otherwise an outside body is involved.
Important, class II
A shorter list with a higher security role. Annex III class II includes hypervisors and container runtime systems, firewalls and intrusion detection or prevention systems, and tamper-resistant microprocessors and microcontrollers.[Annex III, Class II] An outside body checks these.
Critical
A small list that may need a formal European certificate.
Annex IV (critical products) covers hardware devices with security boxes, smart meter gateways, and smartcards or similar devices including secure elements.[Annex IV]
One thing worth knowing: the European standards that would make this simpler are not finished. Products that conform to harmonised standards published in the Official Journal are presumed to conform to the essential requirements those standards cover.[Art. 27] No harmonised standard for the Cyber Resilience Act has been published in the Official Journal yet, so no presumption of conformity is available and controls are versioned against the drafts.[Status at date of verification] Until they arrive, your paperwork has to explain your reasoning rather than point at a clause number.
We work on ordinary products, which is most of what small manufacturers make. If yours turns out to be important or critical, we say so early and tell you what that route involves. We do not run those checks, we are not a certification body, and we will not pretend the extra step away.
The two dates
11 September 2026
The first date brought the duty to report attacks.
Manufacturers' reporting obligations for actively exploited vulnerabilities and severe incidents apply from 11 September 2026.[Art. 71(2); Art. 14] The clocks start when you become aware, not when you finish investigating. Everything you need in order to meet them has to exist before the first incident, not after.
11 December 2027
The second date brings everything else.
The main obligations of the Cyber Resilience Act (essential requirements, technical documentation, conformity assessment, CE marking, importer and distributor duties) apply from 11 December 2027.[Art. 71(2)] From then on: how the product is built, the risk assessment, the paperwork, the declaration, the CE mark, the support period and the security updates. A product that does not meet the rules cannot be put on the EU market.
A simple way to plan. The first date needs a working process for handling security problems. The second needs a documented product. The process is most of the work, and the paperwork falls out of it if you set the process up to leave a trail.
The folder an inspector can ask for
The law calls it the technical documentation. The manufacturer draws up the technical documentation with the content set out in Annex VII before placing the product on the market and keeps it up to date during the support period.[Art. 31; Annex VII] Think of it as the folder you would hand over if someone official said "show me". Nobody stamps it and it is not a certificate. It has to exist before you sell the product and stay current. The manufacturer keeps the technical documentation and the EU declaration of conformity available to market surveillance authorities for at least ten years after the product is placed on the market or for the support period, whichever is longer.[Art. 13]
In ordinary words, it holds:
- What the product is — what it does, which versions, what it runs on, and the information you give the buyer.
- How you build and look after it — the design, how the pieces fit together, how you handle security problems, how updates reach people.
- What could go wrong — the risks you thought about, and how each requirement is met or why it does not apply. Manufacturers carry out and document a cybersecurity risk assessment of the product and include it in the technical documentation.[Art. 13; Annex VII]
- How long you will support it, and why you chose that length.
- Which standards you followed, and what you did where none fitted.
- Test results showing that the product does what you claim and that your process works.
- The signed declaration. The manufacturer draws up and signs the EU declaration of conformity, with the content set out in Annex V, and keeps it up to date; a simplified form is set out in Annex VI.[Art. 28; Annexes V, VI]
- The list of what is inside the product, if it is asked for.
The folder that survives a request is the one where every claim points at something real: a scan report, a change your engineers merged, a signed list of components, a note from a practice run. That is why we build the process first and let it produce the evidence.
The list of what is inside your product
Manufacturers must identify and document the components of the product, including a software bill of materials in a commonly used machine-readable format covering at least the top-level dependencies.[Annex I, Part II, point 1]In plain words: a machine-readable list of every software component in a release, with versions, so tools can read it. The trade calls it a software bill of materials, or SBOM. Three things follow.
It has to be produced by your build system, not typed. A hand-written list is wrong within a month and nobody updates it. Have your build produce it on every release, and sign it so a reader can tell it has not been altered.
It is what makes the reporting duty survivable. You cannot learn that a component you ship is being attacked unless you know that you ship it.
It is evidence. Keep each release's list with the paperwork, so you can answer "what was in version 3.2" a year later.
You do not have to publish the list. You have to have it, and produce it if an authority asks. ENISA's SME survey on the Cyber Resilience Act (June 2026; 194 organisations, 31 countries) found high awareness but low readiness, with a software bill of materials in use at about 35% of respondents.[Report] That gap is where most of the readiness work sits.
When someone is attacking your product
The duty is triggered by knowledge, not by suspicion.
A manufacturer must report an actively exploited vulnerability in its product, and any severe incident having an impact on the security of the product, simultaneously to the CSIRT designated as coordinator and to ENISA.[Art. 14(1), 14(3)] An actively exploited vulnerability is one for which there is reliable evidence that malicious code was executed by an actor on a system without the permission of the system owner; a severe incident is one that has an impact on the security of the product.[Art. 3 (definitions); Art. 14(3)]That is narrower than "somebody published a security bug in a library we use". A known weakness that nobody is exploiting goes into your normal queue. A weakness that credible reports say is being used against real systems, in a product of yours, starts the clocks.
For an actively exploited vulnerability: an early warning within 24 hours of becoming aware, a vulnerability notification within 72 hours, and a final report no later than 14 days after a corrective or mitigating measure is available.[Art. 14(2)]Three practical points:
24 hours
The first message is the hard one. It is short on purpose: what you know, that it is being exploited, which product. It goes out before your analysis is finished.
72 hours
The second message carries substance: what the weakness is, how bad it is, what you have done and what users should do.
14 days
The last one closes the case once you have a fix, with the cause and the correction.
An incident that hits the security of the product itself, rather than a weakness in it, follows the same shape with a longer final step.
For a severe incident: an early warning within 24 hours, an incident notification within 72 hours, and a final report within one month after the incident notification.[Art. 14(4)]The authorities are not your only audience. After becoming aware of an actively exploited vulnerability or a severe incident, the manufacturer must inform impacted users without undue delay, including corrective or mitigating measures they can take.[Art. 14(8)] Your plan needs a message for customers drafted next to the one for the authorities.
Reports go to one EU system. Notifications are submitted through a single reporting platform established and maintained by ENISA, with national electronic notification end-points operated by the CSIRTs designated as coordinators.[Art. 16] Which means somebody at your company needs an account, a written plan and pre-drafted messages before the first incident. One afternoon spent walking through a pretend incident with the people who would really be in the room is the cheapest way to find out whether the plan works.
How long you have to look after the product
The manufacturer determines the support period so that it reflects the expected time in use; it must be at least five years unless the product is expected to be used for a shorter time.[Art. 13(8)]You choose the length, you write down why, and you live with it: for the whole period you fix security problems and ship updates. Security updates must be distributed without delay and, by default, free of charge, through secure update mechanisms, and separately from functionality updates where technically feasible.[Annex I, Part II, points 7, 8] You also have to tell buyers when support ends. The end date of the support period must be stated clearly to users at the time of purchase and in the information accompanying the product.[Art. 13; Annex II]
Questions worth settling early: how an update reaches a machine already in the field, whether it can be checked and undone, what happens to a customer who never installs it, and which parts you depend on will stop being supported before your own period ends.
Does ISO 27001 cover this?
No, but it helps.
ISO 27001 certifies the way your organisation manages security. The Cyber Resilience Act regulates a product: what it does, how it was built and how it is looked after.
If you hold the certificate you already have governance, ownership, incident management and supplier checks, and an auditor who knows your processes. What it does not give you is a risk assessment for the product, a generated list of components, a published way for outsiders to report problems, a chosen support period, a reporting plan keyed to these clocks, or a paperwork folder per product.
We reduce the price of the sprint for certificate holders, because part of the groundwork is done. Do not expect the certificate on its own to be accepted as evidence for a product.
Selling into the EU from outside
The law follows the product into the EU market, wherever you are. The Regulation applies to products with digital elements made available on the Union market in the course of a commercial activity, whatever the size or place of establishment of the manufacturer.[Art. 2(1); Art. 3] A British, American or Asian maker carries the same duties as a French one.
A manufacturer may appoint an authorised representative in the Union by written mandate; the Regulation does not oblige non-EU manufacturers to appoint one.[Art. 18] The mandate says what the representative does; it does not move your responsibility for building a sound product. Expect your EU importers, who have duties of their own, to start asking you for the paperwork, the component list and your reporting arrangements well before the second date.
We are not an EU representative and do not act as one. We do the engineering work in English and can introduce an established provider.
Open source in your product
Open source used inside a product you sell is your responsibility like any other component. It goes in the component list, you check what you are pulling in, and you carry the same duties.
Manufacturers exercise due diligence when integrating third-party components, including free and open-source components, so that they do not compromise the security of the product.[Art. 13]The lighter steward role is for organisations that support open-source projects without selling them. Open-source software stewards, legal persons that support the development of free and open-source software intended for commercial use, have a lighter regime than manufacturers.[Art. 24]
Being sued, not only fined
The new Product Liability Directive applies to products placed on the market or put into service after 9 December 2026, the date by which Member States must transpose it.[Art. 2(1); Art. 22]The EU's revised product liability rules treat software as a product and make the maker liable for damage caused by a defect — including a security weakness that should have been fixed. The two laws work together: this one sets what a reasonably secure product looks like, the other is where failing to do it becomes a claim for money. Your paperwork, your decision log and your update history are the evidence in both cases.
Common questions
Does this apply to a small company?
Yes. Duties follow the role you play, not your headcount. The Regulation applies to products with digital elements made available on the Union market in the course of a commercial activity, whatever the size or place of establishment of the manufacturer.[Art. 2(1); Art. 3] There is help around the edges, but the duties themselves do not shrink. Member States must take measures to support microenterprises and SMEs, and the Commission may provide a simplified technical documentation form for them.[Art. 33]
Our product is software only. Are we covered?
Very likely, if you sell or license it and it can reach a network or a device. Desktop software, mobile apps, developer libraries and server software are all products with software in them.
We only sell a web service. Are we covered?
A pure web service with nothing to install is generally outside this law, though other rules may apply. If your service is the other half of something people install, that half is treated as part of the product.
Remote data processing means processing at a distance for which the software is designed by or for the manufacturer and without which the product could not perform one of its functions; a pure cloud service that is not part of a product in this sense is not itself covered.[Art. 3(2)]Does a product we already sell have to comply?
Products placed on the market before 11 December 2027 fall under the essential requirements only if they are substantially modified after that date, but the reporting obligations of Article 14 apply to them as well.[Art. 69] In practice: the duty to report attacks applies to what you support today, and a new version with real changes counts as a new product going on the market. A person who substantially modifies a product with digital elements and places it on the market takes on the obligations of the manufacturer for that product.[Art. 3; Art. 22] Get a scoping memorandum per product line rather than guessing.
Do we have to publish the list of what is inside our product?
No. You have to produce it, keep it with your paperwork and hand it over if an authority asks. Some customers will ask for it in a contract; that is a commercial decision, not a legal one.
Who decides whether an attack is really happening?
You do, as the maker of the product. Public lists and feeds give you signals; the judgement and the decision to report are yours. A monitoring tool set up in your own account puts the signal in front of your own people, and the runbook we write with you says what they check and what the first message says. The judgement, the decision and the sending stay with you: we are not sent your alerts and we never file anything with an authority.
Can you sign our declaration or certify our product?
No. We are engineers, not a certification body. We do not sign declarations, we do not put the CE mark on anything and we do not act as your EU representative. You remain the maker. We help you produce the evidence.
What should we do first?
Find out what you ship. Get your build system to produce the list of components for each supported product, match it against known weaknesses, name the person who owns reporting, and write down what they would do on day one. Everything else stands on that. The scope check tells you in two minutes whether the law applies to you.
Talk to an engineer
Still not sure how this reaches your product? Thirty minutes, and no slides — or write, and we answer within one working day.