The Cyber Resilience Act, explained for the teams who ship the product.
The CRA — Regulation (EU) 2024/2847 — is the EU's cybersecurity law for products, not for operators. If your product connects to a device or a network, it sets what the product must do, what you must keep doing about vulnerabilities, and what you must report when one is exploited. It applies in full from 11 December 2027, with the reporting duty live from 11 September 2026.
Who is in scope
One connectivity test, a short list of carve-outs, and a chain of economic operators.
Article 2(1) applies the Regulation to products with digital elements made available on the market whose intended purpose or reasonably foreseeable use includes a direct or indirect logical or physical data connection to a device or network. There is no sector list and no size threshold to fall under: the test is the product, and it catches hardware and software alike. Making a product available is itself defined — Article 3(22) means supply for distribution or use on the Union market in the course of a commercial activity, whether for payment or free of charge — so the commercial-supply element travels with the connectivity test.
The carve-outs are named, not general. The Regulation does not apply to products covered by the medical devices Regulations (EU) 2017/745 and 2017/746 or by motor-vehicle Regulation (EU) 2019/2144, to products certified under civil-aviation Regulation (EU) 2018/1139, to marine equipment under Directive 2014/90/EU, to identical spare parts manufactured to the same specifications as the components they replace (Article 2(6)), or to products developed or modified exclusively for national security or defence purposes or specifically designed to process classified information (Article 2(7)). Where other Union rules already address all or some of the same risks, Article 2(5) lets the Commission limit or exclude the CRA's application by delegated act — on two cumulative conditions: the limitation is consistent with the overall regulatory framework for those products, and the sectoral rules achieve the same or a higher level of protection.
Article 1 splits the duties into the two halves that shape everything below: essential requirements for the design, development and production of the product, and essential requirements for the vulnerability-handling processes you run while the product is expected to be in use. The duty-holders are economic operators, which Article 3(12) defines as the manufacturer, the authorised representative, the importer, the distributor, or any other person subject to obligations under the Regulation. Manufacturers carry both halves (Article 13). Importers must verify before placing a product on the market that it meets the Annex I Part I requirements, that the manufacturer ran the right conformity assessment and vulnerability-handling processes, and that the CE marking, documentation and instructions are there (Article 19). Distributors act with due care, and where a distributor considers or has reason to believe — on the basis of information in its possession — that the product or the manufacturer's processes fail the Annex I requirements, it must not make the product available until that is put right (Article 20).
What the product must be, and what you must keep doing
Annex I Part I is a property list. Part II is a process you run for the whole support period.
The product properties — Annex I, Part I
Products are designed, developed and produced to ensure an appropriate level of cybersecurity based on the risks. On the basis of the Article 13(2) risk assessment and where applicable, that means: no known exploitable vulnerabilities at the point of being made available; a secure-by-default configuration with the ability to reset to it, unless otherwise agreed with a business user for a tailor-made product; vulnerabilities addressable through security updates, automatic and default-on where applicable with an easy opt-out and the option to postpone; protection against unauthorised access with reporting of possible unauthorised access; confidentiality and integrity protection for stored, transmitted and processed data, with reporting of corruptions; data minimisation; availability of essential and basic functions including against denial-of-service; minimising the product's own negative impact on the availability of services other devices or networks provide; limited attack surfaces; exploitation-mitigation techniques; recording and monitoring of relevant internal activity, with a user opt-out; and secure, permanent erasure of all data and settings.
The vulnerability-handling process — Annex I, Part II
This is the half that outlives the release. Manufacturers identify and document the vulnerabilities and components in the product, including a software bill of materials in a commonly used, machine-readable format covering at least the top-level dependencies. They remediate without delay and, where technically feasible, ship security updates separately from functionality updates; test and review regularly; publicly disclose fixed vulnerabilities once the update is out, with the information users need to remediate — publication may be delayed in duly justified cases, where the security risk of publishing outweighs the benefit, until users can apply the patch; enforce a coordinated vulnerability disclosure policy; publish a contact address for vulnerability reports; distribute updates securely; and disseminate security updates without delay and free of charge, except where otherwise agreed with a business user for a tailor-made product.
The support period — Article 13(8)
Vulnerability handling runs for the support period, and the support period is at least five years — unless the product is expected to be in use for less, in which case it corresponds to that expected use time. You set it to reflect how long the product is expected to be in use, taking into account in particular reasonable user expectations, the nature of the product including its intended purpose, and Union law determining product lifetime. You may also take into account comparable products from other manufacturers, the availability of the operating environment, and the support periods of third-party components that provide core functions.
Telling the user — Annex II
The information and instructions supplied with the product are themselves regulated: the manufacturer's identity and contact point, the single point of contact for reporting vulnerabilities, where the coordinated vulnerability disclosure policy can be found, the product identification, the intended purpose and known or foreseeable circumstances leading to significant cybersecurity risks, where the EU declaration of conformity can be accessed, and the end date of the support period.
Two clocks, both running from the moment you know
Actively exploited vulnerabilities and severe incidents report on parallel tracks — and this duty starts more than a year before the rest of the Regulation.
Article 14 notifications go simultaneously to the CSIRT designated as coordinator and to ENISA, through the single reporting platform set up under Article 16. Every step below is due without undue delay and in any event within the stated period, counted from the moment you become aware — the outer deadline is a backstop, not a budget. Where necessary, the coordinating CSIRT may ask for an intermediate status report.
| Actively exploited vulnerability | Severe incident | |
|---|---|---|
| Early warning | Without undue delay and within 24 hours of becoming aware, naming where applicable the Member States where the product has been made available (Article 14(2)(a)). | Without undue delay and within 24 hours, including whether the incident is suspected of being caused by unlawful or malicious acts (Article 14(4)(a)). |
| Notification | Within 72 hours, unless already provided: the product concerned, the general nature of the exploit and the vulnerability as available, corrective or mitigating measures taken and what users can do (Article 14(2)(b)). | Within 72 hours, unless already provided: the nature of the incident where available, an initial assessment, measures taken and measures users can take (Article 14(4)(b)). |
| Final report | No later than 14 days after a corrective or mitigating measure is available — the vulnerability and its severity, information where available on any malicious actor exploiting it, and the remedy shipped (Article 14(2)(c)). | Within one month of the 72-hour notification — a detailed description, the likely threat or root cause, and applied and ongoing mitigations (Article 14(4)(c)). |
| Trigger | A vulnerability for which there is reliable evidence that a malicious actor has exploited it in a system without the system owner's permission (Article 3(42)), once you become aware of it (Article 14(1)). | An incident that affects — or can affect — the product's ability to protect the availability, authenticity, integrity or confidentiality of sensitive or important data or functions, or that has led or is capable of leading to the introduction or execution of malicious code in the product or in a user's network and information systems (Article 14(5)). |
Which list your product is on decides who assesses it
Article 32 offers four routes for an ordinary product. Two annexes narrow them, and open source keeps them.
| Product category | Assessment route |
|---|---|
| Default | Any of four routes: internal control (module A) — the manufacturer's own assessment against Annex I — EU-type examination (module B) followed by conformity to type (module C), full quality assurance (module H), or, where available and applicable, a European cybersecurity certification scheme (Article 32(1)). |
| Annex III class I | Identity and privileged access management, browsers, password managers, anti-malware, VPNs, network management, SIEM, boot managers, PKI and certificate issuance, network interfaces, operating systems, routers, modems and switches, security-related microprocessors, microcontrollers, ASICs and FPGAs, smart-home assistants and security products, internet-connected toys covered by the Toy Safety Directive 2009/48/EC with social interactive or location-tracking features, and wearables with a health-monitoring purpose or intended for children. Self-assessment survives only where harmonised standards, common specifications or a certification scheme at assurance level at least ‘substantial’ are applied in full; otherwise module B + C or module H (Article 32(2)). |
| Annex III class II | Hypervisors and container runtimes, firewalls, intrusion detection and prevention systems, tamper-resistant microprocessors and microcontrollers — module B + C, module H, or, where available and applicable, a certification scheme at assurance level at least ‘substantial’ (Article 32(3)). |
| Annex IV critical | Hardware devices with security boxes, smart meter gateways and other advanced-security devices, smartcards and similar devices including secure elements — a certification scheme under Article 8(1), or, where its conditions are not met, one of the class II routes (Article 32(4)). |
One carve-out cuts across both classes: under Article 32(5), free and open-source software falling under the Annex III categories may use any of the Article 32(1) routes, provided the Article 31 technical documentation is public at the time of placing on the market.
Whichever route applies, the paperwork is the same shape: an EU declaration of conformity stating that fulfilment of the applicable essential cybersecurity requirements in Annex I has been demonstrated, drawn up by the manufacturer (Article 28), and CE marking affixed visibly, legibly and indelibly before the product is placed on the market (Article 30). Enforcement then runs through the market surveillance authorities each Member State designates under Article 52. The money sits in Article 64: up to EUR 15 000 000 for the Annex I requirements and the Article 13 and 14 duties, EUR 10 000 000 for the obligations enumerated in Article 64(3), and EUR 5 000 000 for incorrect, incomplete or misleading information supplied in reply to a request — each becoming, where the offender is an undertaking, the higher of that figure and 2.5%, 2% or 1% of total worldwide annual turnover.
Product law, not entity law
The CRA regulates what you place on the market. NIS2 and DORA regulate how you operate.
Article 1 is explicit about the axis: the CRA lays down rules for the making available on the market of products with digital elements, essential requirements for their design and production, essential requirements for vulnerability handling, and market surveillance — plus obligations for economic operators in relation to both. Those operators are the manufacturer, the authorised representative, the importer, the distributor and anyone else the Regulation obliges (Article 3(12)), and what triggers the duties is making the product available on the market. Our NIS2 and DORA explainers cover the other axis — obligations an entity carries for how it runs its own systems — each cited to its own text.
If you carry duties under more than one of them, the overlap is worth mapping once rather than twice: the Annex I Part II vulnerability process, the coordinated disclosure policy and the 24-hour clock look a great deal like duties you may already carry as an operator, but they attach to a different subject and report to a different address. Where other Union rules already address all or some of the same risks for the same product, Article 2(5) is the mechanism for resolving it — by delegated act, and only where the limitation fits the overall regulatory framework and the sectoral rules are at least as protective.
The dates make sequencing possible. Article 71 applies the Regulation from 11 December 2027, but brings Article 14 reporting forward to 11 September 2026 — fifteen months earlier — and Chapter IV, the notification of conformity assessment bodies, to 11 June 2026. Reporting readiness is the first deadline that will actually bite.
From annex text to a cited gap analysis
Every answer grounded in the regulation, in the AI client your team already uses.
The fastest way to see where you stand: a CRA gap analysis is one of the workflow types on the Free tier — one run a month on a system you describe, reported as a watermarked document with every finding cited to the article or annex point it comes from. The sample gap analysis shows the deliverable shape end to end.
The CRA lands on engineering more than on policy, which is why the two halves that usually need evidence first are the secure-development story and the vulnerability process. Secure development with AI assistants covers the first; threat modeling that doubles as compliance evidence — mapping each threat to the measure it satisfies — is covered in this walkthrough.
Questions teams ask about the CRA
If your question is not here, email us — every message gets a human answer.
Does the CRA apply to my product?
The scope test in Article 2(1) is broad and mechanical: the Regulation applies to products with digital elements made available on the market whose intended purpose or reasonably foreseeable use includes a direct or indirect logical or physical data connection to a device or network. Hardware and software both count, and a product's remote data processing solutions come with it: Article 3(1) folds them into the product, and Article 3(2) defines them as data processing at a distance for which the software is designed and developed by the manufacturer, or under the manufacturer's responsibility, and whose absence would prevent the product from performing one of its functions. The named carve-outs are specific rather than general — products already covered by the medical devices Regulations (EU) 2017/745 and 2017/746, motor-vehicle Regulation (EU) 2019/2144, civil aviation certification under Regulation (EU) 2018/1139, and marine equipment under Directive 2014/90/EU, plus identical spare parts (Article 2(6)) and products developed or modified exclusively for national security or defence purposes, or specifically designed to process classified information (Article 2(7)). One element is easy to miss: being in scope turns on making the product available on the market, which Article 3(22) defines as supply for distribution or use on the Union market in the course of a commercial activity — whether for payment or free of charge.
When does the CRA start to apply?
Article 71 sets three dates, and they are not the same date. The Regulation applies in full from 11 December 2027. Article 14 — the manufacturer reporting duty for actively exploited vulnerabilities and severe incidents — applies earlier, from 11 September 2026. Chapter IV, Articles 35 to 51, covering the notification of conformity assessment bodies, applies from 11 June 2026 so that notified bodies exist before manufacturers need them. The regulation entered into force on the twentieth day after publication in the Official Journal.
What are the CRA's essential cybersecurity requirements?
Annex I has two parts and they ask for different things. Part I covers what the product must be: designed for an appropriate level of cybersecurity based on the risks, and — on the basis of the Article 13(2) risk assessment, where applicable — placed on the market without known exploitable vulnerabilities, with a secure-by-default configuration (unless otherwise agreed with a business user for a tailor-made product), able to receive security updates (automatic and default-on where applicable, with an easy opt-out), protected against unauthorised access with reporting of possible unauthorised access, protecting confidentiality and integrity of data with reporting of corruptions, minimising data processed, protecting availability of essential and basic functions including against denial of service, minimising the product's own negative impact on the availability of services provided by other devices or networks, limiting attack surfaces, using exploitation-mitigation techniques, recording and monitoring relevant internal activity with a user opt-out, and letting users securely and permanently erase all data and settings. Part II covers what the manufacturer must do over time — the vulnerability-handling process.
Does the CRA require a software bill of materials?
Yes. Annex I, Part II, point 1 requires manufacturers to identify and document the vulnerabilities and components contained in the product, including by drawing up a software bill of materials in a commonly used, machine-readable format covering at the very least the top-level dependencies. The rest of Part II is the process around it: remediate without delay and, where technically feasible, ship security updates separately from functionality updates; test and review regularly; publicly disclose fixed vulnerabilities once an update is available (publication may be delayed in duly justified cases until users can patch); enforce a coordinated vulnerability disclosure policy; publish a contact address for vulnerability reports; distribute updates securely and, where applicable, automatically; and disseminate security updates without delay and — unless otherwise agreed with a business user for a tailor-made product — free of charge.
What are the CRA reporting deadlines?
Article 14 runs two tracks, both notified simultaneously to the CSIRT designated as coordinator and to ENISA, through the single reporting platform of Article 16. Each notification is due without undue delay and in any event within the stated period. 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. For a severe incident affecting the security of the product: an early warning within 24 hours, an incident notification within 72 hours, and a final report within one month of that notification. The coordinating CSIRT may also request an intermediate status report. Article 14(5) defines severe: the incident negatively affects, or can affect, the product's ability to protect the availability, authenticity, integrity or confidentiality of sensitive or important data or functions, or it has led or is capable of leading to the introduction or execution of malicious code in the product or in a user's network and information systems.
How long do we have to support a product under the CRA?
Article 13(8) requires vulnerabilities to be handled effectively for the support period, and the support period is at least five years — unless the product is expected to be in use for less, in which case it corresponds to that expected use time. The manufacturer sets it to reflect how long the product is expected to be in use, taking into account in particular reasonable user expectations, the nature of the product including its intended purpose, and Union law determining product lifetime. It may also take into account comparable products from other manufacturers, the availability of the operating environment, the support periods of third-party components providing core functions, and guidance from the administrative cooperation group and the Commission.
Do we need a notified body, or can we self-assess?
It depends on which list your product is on. Article 32(1) offers four routes for an ordinary product, and one of them — internal control, module A — is the manufacturer's own assessment. For important products with digital elements in Annex III class I — among them identity and privileged access management, browsers, password managers, anti-malware, VPNs, network management, SIEM, boot managers, PKI software, operating systems, routers and switches, security-related microprocessors and microcontrollers, smart-home assistants and security products, internet-connected toys covered by the Toy Safety Directive 2009/48/EC that have social interactive or location-tracking features, and personal wearables with a health-monitoring purpose or intended for children — self-assessment survives only where harmonised standards, common specifications or a European cybersecurity certification scheme at assurance level at least 'substantial' have been applied in full; otherwise it is EU-type examination (module B) plus conformity to type (module C), or full quality assurance (module H). Class II — hypervisors and container runtimes, firewalls and intrusion detection and prevention systems, tamper-resistant microprocessors and microcontrollers — takes module B plus C, module H, or, where available and applicable, a certification scheme at assurance level at least 'substantial'. Annex IV critical products — hardware devices with security boxes, smart meter gateways and other advanced-security devices, smartcards and similar devices including secure elements — take a certification scheme under Article 8(1), or, where its conditions are not met, one of the class II routes (Article 32(4)). One carve-out cuts across both classes: under Article 32(5), free and open-source software falling under Annex III may use any Article 32(1) route provided the technical documentation is public at the time of placing on the market.
What are the CRA fines?
Article 64 sets three ceilings. Each is a euro figure, and where the offender is an undertaking it is instead the higher of that figure and a share of total worldwide annual turnover for the preceding financial year. Non-compliance with the Annex I essential requirements or the Article 13 and 14 manufacturer obligations: up to EUR 15 000 000 or 2.5%. Non-compliance with the obligations enumerated in Article 64(3) — Articles 18 to 23, the EU declaration of conformity, CE marking and conformity assessment duties among them: up to EUR 10 000 000 or 2%. Supplying incorrect, incomplete or misleading information to notified bodies or market surveillance authorities in reply to a request: up to EUR 5 000 000 or 1%. Member States set the penalty rules themselves. Article 64(10) then carves out, by way of derogation from paragraphs 3 to 9, microenterprises and small enterprises that miss the Article 14 early-warning deadlines, and open-source software stewards for any infringement.
See where you stand on the CRA
A free-tier run produces a cited CRA gap analysis of a product you describe — one row per requirement, each anchored to its article or annex point. Start there, then bring your own documents on a paid plan.