The CRA applies to products with digital elements made available on the EU market whose intended or reasonably foreseeable use includes a direct or indirect data connection. If your product contains software or firmware and reaches the EU market, it is very likely in scope. Art. 2 The quickest way to check is the self-assessment.
Frequently asked questions
Concise answers to the questions stakeholders ask most often about the Cyber Resilience Act, with references back to the text.
Questions and Answers
Classification follows the product's core functionality, not every feature it includes. If the core function matches a category named in Annex III the product is 'important' (Class I or II); if it matches Annex IV it is 'critical'; otherwise it is 'default'. A capability such as identity management or a VPN, included only as a feature, does not make the product 'important' unless that is its core purpose. Where more than one category could apply, the stricter class applies. Art. 7
Non-commercial open-source software developed outside a commercial activity is largely outside the scope. Open-source software stewards have a lighter, tailored set of obligations. Open-source components supplied in the course of a commercial activity can fall within scope.
Standalone services are generally outside the CRA. However, remote data-processing solutions that are necessary for a product to perform its functions are treated as part of that product and are in scope. Art. 3(2)
Yes. The CRA applies to products placed on the EU market regardless of where the manufacturer is established. Manufacturers outside the EU must ensure an economic operator established in the Union is responsible for the relevant obligations.
They fall into two parts of Annex I: security properties the product must have (secure by default, confidentiality, integrity, availability, minimised attack surface, security updates) and vulnerability-handling processes the manufacturer must operate (SBOM, remediation, coordinated disclosure). Annex I
Yes. Manufacturers must identify and document the components contained in the product, including by drawing up a software bill of materials in a commonly used, machine-readable format. Annex I · II(1)
The support period is the time during which a manufacturer must provide security updates. It must reflect the period the product is reasonably expected to be in use; Commission guidance indicates this should generally be at least five years unless the expected use is shorter. Art. 13(8)
Actively exploited vulnerabilities and severe incidents affecting the security of the product must be notified to ENISA and the relevant CSIRT. An early warning is due within 24 hours of becoming aware, followed by a fuller notification and a final report. Art. 14
The Act entered into force on 10 December 2024. Reporting obligations apply from September 2026 (21 months later) and the bulk of the obligations apply from December 2027 (36 months later). Art. 71
Breaches of the essential requirements or manufacturer obligations can attract fines of up to €15 million or 2.5% of total worldwide annual turnover, whichever is higher. Lower ceilings apply to other infringements and to supplying incorrect information.
Not yet, as of mid-2026. ENISA is building the single reporting platform under Article 16 and is publishing registration and dry-run material in the run-up; it is intended to be operational by 11 September 2026, with a testing period before then. Note too that the exact reporting format and procedure may still be specified by Commission implementing acts, and the harmonised standards underpinning vulnerability handling are expected around 30 August 2026; so build your internal process now rather than waiting for the final mechanics. See the reporting guide. Art. 14 · 16
The Commission's standardisation request M/606 was accepted by CEN, CENELEC and ETSI in 2025, covering around 41 standards (horizontal and product-specific). The two core horizontal standards (secure development and vulnerability handling) are expected by 30 August 2026, the vertical product standards by 30 October 2026, and the remaining horizontal standards by 30 October 2027, ahead of full application in December 2027. Following a cited harmonised standard gives a presumption of conformity. Annex I
Carry out the conformity assessment route for your product class, compile the technical documentation, draw up and sign the EU declaration of conformity, and then affix the CE marking. Default products may self-assess; important and critical products require stricter routes. Art. 28 · 32
Begin with the CRA Fast Check to confirm scope and class, follow the guide written for your role, and use the compliance matrix to track the essential requirements to done.
The Article 14 reporting obligations become enforceable. From that date manufacturers must notify actively exploited vulnerabilities and severe incidents to ENISA and the relevant CSIRT through the single reporting platform. It is the earliest of the CRA's major obligations to take effect, well ahead of full application on 11 December 2027. See the reporting guide. Art. 14 · 71
No. Only actively exploited vulnerabilities and severe incidents affecting the security of your product are reportable under Article 14. Vulnerabilities you find and fix before they are exploited are handled through your ordinary vulnerability-handling process, not the reporting channel. The reporting guide sets out the test and the deadlines. Art. 14
Through ENISA's single reporting platform, which routes your notification to ENISA and the relevant national CSIRT. You send an early warning within 24 hours of becoming aware, a fuller notification within 72 hours, and a final report within 14 days of a corrective measure being available. See the step-by-step reporting guide. Art. 14 · 16
Didn't find your answer?
Confirm your product's position with the free self-assessment, or read the plain-language explainer.
