EU regulation
Rules for cybersecurity of software and connected products sold in the EU.
The CRA sets cybersecurity requirements for each placed on the EU market. Manufacturers must design securely, handle vulnerabilities, document conformity, and support products after release.
In one sentence
Design securely, fix vulnerabilities, report specified events, and prove conformity throughout the product lifecycle.Filter the full timeline by event type, inspect milestones, zoom in, or download the data.
For each product version and supply channel, record the product functions, data connections, EU supply facts and any applicable exclusion. The linked checks explain which facts decide each branch. Keep an in-scope, excluded or unresolved conclusion with the evidence behind it; then assess operator role, product class and application dates separately.
Scroll horizontally to compare
| Product or situation | Starting check | Why |
|---|---|---|
| Connected products | Run the product applicability test | Confirm EU-market supply and an intended or reasonably foreseeable direct or indirect data connection. |
| Standalone software | Test software supply and connections | Downloadable apps, desktop or mobile software, and firmware can qualify when the market-and-connection test is met; standalone SaaS does not qualify by itself. |
| Separately marketed components | Assess the separately supplied component | Software or hardware components can qualify when placed on the market separately and the other scope conditions are met. |
| Manufacturer-responsible remote processing | Apply the three remote-processing criteria | Remote data processing solutions (RDPS) belong to the product when processing takes place at a distance, the product needs it for a function, and the software was designed and developed by or under the manufacturer's responsibility. Record the dependent function, software boundary and development responsibility. |
| Medical and in vitro diagnostic products | Verify medical or diagnostic-device coverage | Excluded only when Regulation (EU) 2017/745 or Regulation (EU) 2017/746 applies to the product. Retain the product classification and the evidence establishing which regulation applies; healthcare use alone does not establish the exclusion. |
| Civil aviation products | Verify the aviation certification | Excluded only when the product is certified under Regulation (EU) 2018/1139. Record the certificate and the exact product it covers; aviation use alone does not establish the exclusion. |
| Motor and L-category vehicles | Check the vehicle regime and pedal exception | Excluded where Regulation (EU) 2019/2144 applies; Regulation (EU) No 168/2013 products are also excluded, except L1e category vehicles designed to pedal. Record the type-approval scope and vehicle category before concluding that the exclusion applies. |
| Marine equipment | Verify marine-equipment coverage | Excluded only when it falls within Directive 2014/90/EU. Record the equipment's regulated status and supporting conformity evidence; assess a separately supplied component on its own facts. |
| National-security, defence, and classified-information products | Document the exclusive purpose or classified design | Excluded if developed or modified exclusively for national-security or defence purposes, or specifically designed to process classified information. Record the intended purpose and design or modification facts; civilian and defence use together does not establish an exclusive-purpose exclusion. |
| Free and open-source software | Assess commercial supply and steward status | Open-source status alone is not decisive: commercial supply can trigger the full product regime, while qualifying open-source software stewards have separate duties. Record the licence, publication and monetisation facts for each edition and the publisher's role. |
Classify the product's own core functionality against Annex III and Annex IV before choosing its conformity route. The examples below are category examples, not a substitute for the binding technical descriptions. An integrated listed component does not by itself determine the finished product's class.
For Class I, the Commission guidance permits when all applicable requirements of a cited harmonised standard are applied and its scope covers all risks associated with core functionality. Assess the whole product and document additional measures for risks outside that standard. Otherwise apply the Article 32(2) third-party routes for the corresponding requirements.
Annex III free and open-source software
Article 32(5) permits the general Article 32(1) routes, including , for qualifying free and open-source software in Annex III when the technical documentation is made public at market placement. This exception covers Class I and Class II, not Annex IV critical products.Scroll horizontally to compare
| Products that do not match an Annex III or Annex IV core-function category | Password managers, operating systems, routers and smart security cameras | Hypervisors, container runtimes, firewalls and tamper-resistant microprocessors | Hardware devices with security boxes, smart-meter gateways and smartcards or secure elements |
| internal control is available under Article 32(1). | depends on applying the relevant Article 32(2) conformity basis; otherwise or is required for the corresponding requirements. | , , or available and applicable Article 27(9) certification at assurance level at least substantial. | Mandatory Article 8(1) certification when specified; otherwise the Class II route set. |
Map every legal entity and supply channel to its actual activities. One organisation can hold more than one CRA role, and own-branding or a can change the role.
Responsibilities
Own the product boundary, cybersecurity risk assessment, Annex I compliance, technical file, conformity route, , , and post-market handling.
Responsibilities
Verify that the manufacturer completed conformity work, documentation and labelling before placing the product on the EU market.
Responsibilities
Check , required information and obvious non-conformity, and cooperate on corrective action and traceability.
Responsibilities
Follow the CRA's duties for open-source stewards. Supporting open-source development alone does not make the steward a manufacturer.
List software, hardware, separately sold components and necessary remote processing.
Check the default, , and critical categories.
Record intended purpose, foreseeable use, threats and security assumptions.
Map Annex I requirements to controls, tests and release decisions.
Maintain the technical file, SBOM record, instructions and support-period rationale.
Confirm whether internal control, a or certification is required.
Connect the released product version to the declaration and evidence.
Handle vulnerabilities, security updates, incidents and user communication.
Start here for scope, classification, duties, evidence, reporting and transition rules. Use the detailed guides for procedures, templates and edge cases.
Answer all five questions and record the facts behind each answer.
Include standalone software, firmware, embedded systems, hardware, separately marketed components, and qualifying remote processing.
Its intended or reasonably foreseeable use must include a direct or indirect logical or physical connection to a device or network.
Check whether it is supplied for distribution or use in the EU in the course of commercial activity, whether paid or free of charge.
Include integrated components and manufacturer-responsible remote processing that the product needs to perform a function.
Confirm the sector law and every condition of the exclusion. Labels such as "medical" or "open source" do not settle the question.
Remote processing
Include it when it operates at a distance, was designed by or under the manufacturer's responsibility, and the product needs it to perform a function. Ordinary websites, analytics and unrelated third-party SaaS remain outside the product boundary.Scroll horizontally to compare
| Product or case | What must be checked |
|---|---|
| Medical and IVD products | Excluded when covered by the MDR or IVDR. Document the exact regulated product status. |
| Civil aviation products | Excluded when certified under Regulation (EU) 2018/1139; aviation use alone is not the test. |
| Motor vehicles | Verify vehicle coverage and the L1e pedal exception Check Regulation (EU) 2019/2144 and Delegated Regulation (EU) 2025/1535 against the product and vehicle category. |
| Marine equipment | Excluded when it falls within Directive 2014/90/EU. |
| National security or defence | Excluded when developed or modified exclusively for national security or defence, or specifically designed to process classified information. |
| Identical spare parts | Check that the replacement is identical and made to the same specifications as the component it replaces. |
| Free and open-source software | Outside the manufacturer regime only when developed or supplied outside commercial activity; integration into a commercial product still creates manufacturer work. |
Compare the product's main technical capabilities with Annex III, Annex IV and the binding technical descriptions. Marketing labels or deployment in a sensitive environment do not decide the class. Classify the finished product by its core functionality, even when it contains an important component.
For Class I, the Commission guidance permits when all applicable requirements of a cited harmonised standard are applied and its scope covers all risks associated with core functionality. Assess the whole product and document additional measures for risks outside that standard. Otherwise apply the Article 32(2) third-party routes for the corresponding requirements.
Annex III free and open-source software
Article 32(5) permits the general Article 32(1) routes, including , for qualifying free and open-source software in Annex III when the technical documentation is made public at market placement. This exception covers Class I and Class II, not Annex IV critical products.Scroll horizontally to compare
| Class | How to identify it | Examples | Assessment consequence |
|---|---|---|---|
| No Annex III or Annex IV core-function category match | Products outside the listed important and critical categories | internal control is available under Article 32(1). | |
| Annex III, Class I | Password managers, operating systems, routers and smart security cameras | depends on applying the relevant Article 32(2) conformity basis; otherwise or is required for the corresponding requirements. | |
| Annex III, Class II | Hypervisors, container runtimes, firewalls and tamper-resistant microprocessors | , , or available and applicable Article 27(9) certification at assurance level at least substantial. | |
| Annex IV | Hardware devices with security boxes, smart-meter gateways and smartcards or secure elements | Mandatory Article 8(1) certification when specified; otherwise the Class II route set. |
Own the product boundary, cybersecurity risk assessment, Annex I compliance, technical file, conformity route, , , and post-market handling.
Verify that the manufacturer completed conformity work, documentation and labelling before placing the product on the EU market.
Check , required information and obvious non-conformity, and cooperate on corrective action and traceability.
Follow the CRA's duties for open-source stewards. Supporting open-source development alone does not make the steward a manufacturer.
An importer or distributor can become the manufacturer when it places the product on the market under its own name or trademark or carries out a . One organisation can hold more than one CRA role.
Use the product's cybersecurity risk assessment to decide which Annex I requirements apply. Record how you implemented and tested each one, and explain any requirement you marked as not applicable.
Finish the technical documentation before placing the product on the market. Keep it updated during the when the product or evidence changes. 'Audit file' is an internal label; Annex VII sets the required contents.
Models, intended purpose, foreseeable use, interfaces, integrated components, remote processing and affected versions.
Risks, applicable Annex I requirements, justified non-applicability, controls, tests, residual risk and release decision.
Component relationships, data flows, trust boundaries, security controls and production or validation processes.
Supplier or project checks, vulnerability history, support assumptions and machine-readable dependency record.
Disclosure policy, reporting address, triage, remediation, advisories, secure update distribution and records.
Expected use and user expectations, product nature, operating environment and component-support assumptions.
Secure setup and use, risks, update instructions, vulnerability contact, support end date and decommissioning guidance.
Standards or specifications used, test reports, notified-body or certification records, and the selected Article 32 route.
EU declaration of conformity, product or software marking location, release version and approval date.
Reassessment triggers, substantial-modification decisions, updated files and records retained for the required period.
Select the route using the product class and the evidence that makes that route available. For qualifying free and open-source software in Annex III, Article 32(5) permits the general Article 32(1) procedures when the technical documentation is public at market placement; it does not extend to Annex IV critical products.
Scroll horizontally to compare
| Product class | Permitted route | Practical meaning |
|---|---|---|
| internal control is available. | The manufacturer assesses conformity and retains the evidence. | |
| when the Article 32(2) conditions are met; otherwise or for the corresponding requirements. | Apply all applicable requirements of a cited harmonised standard covering core-functionality risks and document other measures for additional risks, as the Commission guidance explains. | |
| , , or an applicable Article 27(9) certification scheme at assurance level substantial or higher. | Ordinary self-assessment is not available. | |
| Use a mandatory Article 8 certification scheme when specified; otherwise the Class II route set applies. | Check current delegated acts before choosing the route. |
Complete the selected conformity assessment.
Finish and approve the technical documentation.
Draw up the EU declaration of conformity.
Affix before market placement and retain the evidence.
The clock starts when the manufacturer becomes aware of a reportable condition. An unpatched vulnerability or zero-day is not automatically reportable. The track requires reliable evidence of malicious exploitation.
From 11 September 2026, manufacturers submit notifications through the ENISA Single Reporting Platform. They must also give affected users, and where appropriate all users, available mitigation or corrective-action information.
Scroll horizontally to compare
| Track | Trigger | Reporting stages |
|---|---|---|
| Reliable evidence of malicious exploitation without the system owner's permission. | 24-hour early warning; 72-hour notification; final report within 14 days after a corrective or mitigating measure is available. | |
| Severe security incident | An incident meeting the CRA severity conditions and affecting product security. | 24-hour early warning; 72-hour incident notification; final report within one month after the incident notification. |
At least five years unless expected product use is shorter. Record the rationale and tell users the end date.
Products placed on the market before 11 December 2027 generally enter the remaining CRA requirements only after a from that date.
reporting starts on 11 September 2026 for in-scope products, including products already placed on the market.
A post-market change can trigger manufacturer responsibility when it affects Annex I conformity or changes intended purpose under the CRA test.
An importer or distributor can become the manufacturer by marketing under its own name or trademark or by substantially modifying the product.
A steward must maintain a security policy, handle vulnerabilities, support voluntary reporting and cooperate with authorities. A steward does not take on CE-marking duties solely because of that role.
Fine figures are maximum ceilings. Member State law, the facts and proportionality determine the actual procedure and amount. Market-surveillance measures can matter before or alongside a fine.
Authorities can request technical documentation and the SBOM where justified, require corrective action, restrict or prohibit market availability, and order withdrawal or recall. Open-source software stewards sit outside the Article 64 administrative-fine regime but must still meet their applicable duties and cooperate with market surveillance.
Annex I, manufacturer obligations under Article 13, and reporting.
Specified economic-operator, conformity, documentation, notified-body and authority-cooperation obligations.
Incorrect, incomplete or misleading information supplied in response to an official request.
New to the CRA? Start with scope. If the product is already scoped, jump to requirements, evidence and market access, vulnerability operations and deadlines, or a focused comparison or question.
Decide whether the CRA applies to the product, market activity and software or service boundary before assigning controls.
Translate Annex I and economic-operator duties into a product-level compliance program.
Build the release file, select the conformity route, and connect technical evidence to the declaration and .
Run support-period vulnerability handling, triage events, track staged application dates, and understand enforcement exposure.
Separate the CRA from adjacent EU and UK product-security regimes, or go directly to a focused implementation answer.
"A product with digital elements also includes its remote data processing solutions."
"The CRA introduces mandatory cybersecurity requirements for manufacturers"
"The guidance will help manufacturers, developers, and other stakeholders understand their obligations"
"focuses on remote data processing solutions and free and open-source software"
"Products with digital elements shall be designed, developed and produced in such a way that they ensure an appropriate level of cybersecurity"
Next steps
This hub is the shared entry point for CRA product classification, vulnerability-handling design, reporting readiness, technical documentation, conformity assessment, , and importer or distributor checks.
Turn CRA scope, security requirements, vulnerability handling, reporting, conformity and CE evidence into owned tasks and review checkpoints.
Answer CRA scope, role, timing, reporting and interpretation questions with cited outputs from official sources.
Align staged application dates with product, engineering, legal, support, importer and distributor work.
Review your current product file, vulnerability-handling process, reporting readiness and conformity evidence model.