The Cyber Resilience Act, in plain English

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 a weakness in one of your products is being exploited or something goes seriously wrong with its security. 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.

The connection is the first question, and it is broader than a network port. The Regulation applies to a product with digital elements whose intended purpose or reasonably foreseeable use includes a direct or indirect data connection — logical or physical — to a device or network. This is the first scoping question, and it is the only test Article 2(1) sets: nothing in it turns on how big the company is or where it is based.[Art. 2(1)] It also counts when the product only reaches a network through something it is part of. A connection counts as indirect when the product does not reach a device or network by itself, but does so as part of a larger system that is directly connectable. That test settles how a product is connected, not who owes what. A component is a product in its own right when it is placed on the market separately; a part a manufacturer builds into its own product and never supplies on its own is covered through the product around it instead. And building in a component that belongs to one of the important or critical categories does not by itself put the surrounding product into that category.[Art. 3(10); Art. 3(1); Art. 7(1)] A sensor board that talks to a gateway, and the gateway talks to the internet, is in.

You sell it, or make money around it, in the EU. Making a product available on the market means supplying it for distribution or use on the Union market in the course of a commercial activity, whether it is paid for or free, and placing on the market is the first such supply. Because the test is supply onto the Union market, a seller established outside the EU is caught in the same way as one inside it, and the size of the company makes no difference. The Regulation does not define "commercial activity" itself; the examples usually quoted for it come from the recitals, which guide interpretation rather than bind.[Art. 3(21), Art. 3(22); recitals for the commercial-activity examples] Selling, licensing and bundling with a paid service all count, wherever your company is based.

A narrow sector carve-out does not already take it out. The sector carve-outs are a short, closed list. Products to which the medical device, the in-vitro diagnostic or the motor vehicle type-approval Regulations apply are outside the Cyber Resilience Act, and so is equipment within the scope of the marine equipment Directive. Civil aviation works differently and more narrowly: what is outside is a product that has actually been certified under the EU civil aviation Regulation, not aviation equipment as a class, so an uncertified product sold into that sector is fully in scope. Outside as well are products developed or modified exclusively for national security or defence purposes — "exclusively" is the whole of that gate, and it asks what the product was developed or modified for rather than who buys it, so neither a product also sold commercially nor a general-market product whose customers today are all defence ones is carved out — and, on a different test, products specifically designed to process classified information. Any wider limitation or exclusion for products covered by other Union rules needs a Commission delegated act; no other rulebook displaces this one by itself. One such act has now been adopted and it takes out a whole sector — the L-category vehicles of Regulation (EU) No 168/2013 — so the closed list above is no longer the whole of the answer, and that sector exclusion has to be read with it.[Art. 2(2), 2(3), 2(4), 2(5), 2(7)] That list is short and closed, and widening it takes a decision by the Commission. Every other EU rulebook — machinery, radio equipment, the AI rules, the network security rules, general product safety — applies alongside this law rather than instead of it. Radio equipment is the clearest example. The Cyber Resilience Act contains no provision that treats meeting its essential requirements as meeting the Radio Equipment Directive's cybersecurity requirements. Recital 30 says only that the Act's requirements include all the elements of the radio-equipment ones, that the Commission may later repeal or amend Delegated Regulation (EU) 2022/30, and that in the meantime it should give guidance to manufacturers caught by both. A recital guides interpretation and does not create a shortcut, so a manufacturer of connected radio equipment has to satisfy both sets of rules today.[Recital 30; recital 100 (a body notified under Delegated Regulation (EU) 2022/30 must be assessed and notified afresh under this Regulation). The Act has 130 recitals; there is no recital 219. There is no enacting article on radio equipment anywhere in the Act. Contrast Art. 12, which is the deeming provision for high-risk AI systems under Regulation (EU) 2024/1689 and has nothing to do with radio equipment] If your product sits on that boundary it needs a review, not an assumption.

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 and developed by the manufacturer, or under the manufacturer's responsibility, 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 — that carve-out is stated in the recitals rather than in the definition, and it turns on the responsibility limb: a cloud service designed and developed outside a product manufacturer's responsibility is outside the Regulation.[Art. 3(2); recital 12 for the cloud carve-out] 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 does not define "commercial activity"; the examples usually quoted for it — charging for support, monetising the software, a dual licence — come from the recitals, which guide interpretation rather than bind, so whether a given project crosses the line is a question of fact.[Art. 2(1); Art. 3(22); Art. 3(48); recitals for the commercial-activity examples] 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 person or company that develops or makes a product with digital elements, or has it designed, developed or made by someone else, and sells it under its own name or trademark — whether for payment, for monetisation or free of charge. Outsourcing the build does not move you out of the definition, and neither does giving the product away.[Art. 3(13)] 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 a weakness under attack or a serious incident. 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 and distributors check different things, and the distributor's list is the shorter of the two. Before placing a product on the market an importer must make sure the manufacturer carried out the right conformity assessment and drew up the technical documentation, that the product bears the CE marking and comes with the declaration of conformity and the user information, and that the manufacturer has put its identification and contact details on it and stated the end date of the support period. Before making a product available a distributor checks that it bears the CE marking, that the manufacturer and the importer have met their identification, contact-detail, user-information, support-period-end-date and declaration-of-conformity duties, and that all the necessary documents have been handed over. Neither may go ahead where it believes the product is not compliant.[Art. 19(1), 19(2), 19(3); Art. 20(1), 20(2), 20(3)]

Careful: an importer or a distributor can become the maker by accident. An importer or a distributor that places a product on the market under its own name or trademark, or that substantially modifies a product already on the market — a change that affects whether it still meets the product security requirements, or that changes what the product was assessed to be for — is treated as the manufacturer and takes on the manufacturer's product obligations and reporting obligations in full. That deeming rule applies from 11 December 2027 with the rest of the Regulation: Article 71(2) brings forward only Article 14 and Chapter IV, and Article 21 is in neither. A reseller that markets a product under its own name or trademark does not need that rule to be reporting today: the definition of manufacturer covers having a product designed, developed or manufactured and marketing it under one's own name, and Recital 78 says that an entity selling its own branded products qualifies as a manufacturer — so the reporting duty reaches every own-name reseller from 11 September 2026, whether it had the product made for it or buys it in finished. What waits for 11 December 2027 is the substantial-modification limb, for an importer or distributor whose name is not on the product.[Art. 21; Art. 3(13); Art. 3(30); Art. 71(2); Recital 78] Sell a supplier's product under your own brand and the heavy role is yours, reporting included, from the first date rather than the second. Change a product after it is on the market — in a way that affects how secure it is, or that changes what it is for compared with what it was assessed for — and then supply it on, and the maker's duties are yours in full. The narrower version of that rule, the one that stops at the part you changed, is written for someone who is neither the maker, the importer nor the distributor — not for you. 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. An open-source software steward is a legal person, other than a manufacturer, whose purpose is to provide support systematically and on a sustained basis for the development of specific free and open-source products intended for commercial activities, and that keeps those products viable. Its regime is lighter than a manufacturer's, but it is not empty. A steward must put in place and document a cybersecurity policy, must cooperate with market surveillance authorities on request, and carries part of the reporting duty: notifying an actively exploited vulnerability where the steward is involved in developing the product, and notifying a severe incident and informing users where the incident affects the systems the steward provides for that development. Article 24 is not among the provisions brought forward to 11 September 2026, so on the face of the text those duties start on 11 December 2027 with the rest of the Regulation. No administrative fine may be imposed on a steward for any infringement of the Regulation — but that is true only of the corrected text: as first published, Article 64(10) started at paragraph 3 and left a steward exposed to the top band.[Art. 3(14); Art. 24(1), 24(2), 24(3); Art. 14(1), 14(3), 14(8); Art. 71(2)] Lighter, not empty. A steward keeps a written security policy, works with the authorities, and carries part of the reporting duty itself: for a weakness under attack in a project it helps build, and for a serious incident hitting the systems it provides for that work. Whether that reaches a steward from the first date or only from the second turns on a point the law does not settle cleanly, so if you run a foundation, have it looked at rather than assumed.

One thing worth knowing: the European standards that would make this simpler were not finished when we last checked.

As at 10 September 2026, no harmonised standard for the Cyber Resilience Act had had its reference published in the Official Journal, so the presumption of conformity that comes with a harmonised standard was not available and our controls are versioned against the drafts. This is a point-in-time check: it must be re-read and re-dated before it is quoted anywhere, because the day a reference is published the sentence stops being true.[Regulation (EU) 2024/2847 Art. 27(1) — the presumption attaches on publication of the reference in the Official Journal by the Commission, not on adoption by CEN-CENELEC, so the page in source_url cannot evidence an absence from the Official Journal and is the wrong source for this row. The value is the date we last checked, not a figure from the provision.] 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 longer version of this section, worked through step by step, is Ordinary, important or critical: which group is your product in?.

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.

One narrow piece of relief, if you are a small company: a correction to the law took the fine off the very first deadline for the smallest manufacturers. As the Act was corrected in July 2025, no administrative fine applies to a manufacturer that counts as a microenterprise or a small enterprise for missing the 24-hour deadline on an early warning — either about a weakness under attack or about a serious incident. Because the correction moved the carve-out to start at paragraph 2, it reaches the largest band, 15 million euro or 2.5% of worldwide turnover, which is where a reporting failure sits; before the correction it did not. Read the limits with it: the two 24-hour early warnings only, not a failure to report at all and not the 72-hour notification or the final report; microenterprises and small enterprises only, not medium-sized ones; and it removes the fine, not the duty, so an authority can still order corrective or restrictive measures and a customer or importer will still ask. A second limb of the same paragraph covers open-source software stewards, and it is wider: no administrative fine at all, for any breach of the Act.[Art. 64(10) as corrected by OJ L, 2025/90555, 2.7.2025 ("paragraphs 2 to 9"); Art. 64(10)(a) with Art. 14(2)(a) and Art. 14(4)(a); Art. 64(10)(b) for stewards; Art. 64(2) for the band now reached; Art. 64(9) for fines sitting alongside corrective and restrictive measures] Read it as what it is. The duty to report has not moved, the later deadlines still carry a fine, an authority can still order you to do things, and a customer or an importer will not care that the fine did not apply.

A serious incident affecting the product itself, rather than a weakness in it, is the other half of the duty — and it does not have to be an attack. A bad update that takes out something essential, a misconfiguration that lets one customer see another's data, a failed key rotation: each of them can qualify. It has its own two tests. The first says what kind of incident is covered at all. An incident has an impact on the security of a product when it harms, or is capable of harming, the product's ability to protect the availability, authenticity, integrity or confidentiality of data or functions. This is the gate for what kind of incident the reporting duty is about; whether an incident is severe enough to report is a separate and narrower test.[Art. 3(44)] The second decides whether it is severe enough to report, and it is the test that starts the clock.

Read that second one carefully before deciding you have nothing to send. It is not the same test as the one for a weakness under attack, and it does not wait for harm that has already happened.

The filings then follow the same shape as for a weakness, with a longer last step. For a severe incident the first two filings carry the same two-part standard: an early warning without undue delay and in any event within 24 hours of becoming aware, and an incident notification without undue delay and in any event within 72 hours. The final report is due within one month after the incident notification is submitted — the month runs from the filing, not from the 72-hour deadline.[Art. 14(4)] The authority that receives your report can also ask for an update in between.

The authorities are not your only audience. After becoming aware of an actively exploited vulnerability or a severe incident, the manufacturer must tell the users it affects — and where appropriate all users — about it, and where needed about the steps they can take to limit the damage, in a machine-readable form where that is appropriate. There is no fixed deadline: the standard is that it is done in a timely manner, and if the manufacturer does not, the CSIRT may tell users itself.[Art. 14(8)] Your plan needs a message for customers drafted next to the one for the authorities.

Notifications are submitted through a single reporting platform established by ENISA and run day to day by it, using electronic notification end-points that Member States and ENISA put in place. Two things a manufacturer should know: the reporting duty in Article 14 applies from 11 September 2026, but Article 16, which sets the platform up, is not among the provisions brought forward, so on the face of the text it applies from 11 December 2027; and we have not established whether the platform and the national end-points are operating today. The duty and its deadlines start regardless — where to file in practice is a question for the manufacturer's national CSIRT coordinator.[Art. 16(1); Art. 71(2)] So the practical step this month is to ask your national coordinator how they want to receive a report, and to write the answer down. A notification goes to the CSIRT designated as coordinator in the Member State of the manufacturer's main establishment in the Union, and reaches ENISA at the same time. Main establishment means where the decisions about the cybersecurity of the products are mostly taken — not where the company is registered; if that cannot be worked out, it is where the manufacturer has most of its Union employees. A manufacturer with no main establishment in the Union follows a set order: the Member State of its authorised representative, then of its importer, then of its distributor, then where most of its users are.[Art. 14(7)]

What does not depend on any of that: a named person, a written plan and pre-drafted messages, ready 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.

What to put in place first, one step at a time: six things to do in a week.