Cyber Resilience Act.
Develop secure products with digital elements, handle vulnerabilities and prepare the appropriate conformity evidence.
- Regulation (EU) 2024/2847
- By Derya Altinay
- As of: 10/22/2026
- Reading time: 8 min.
Short answer.
The Cyber Resilience Act is the EU cybersecurity regulation for products with digital elements in scope. Manufacturers are responsible for security throughout development, supply and support. Manufacturer reporting duties have applied since 11 September 2026; general product duties apply from 11 December 2027. The basis is Regulation (EU) 2024/2847.
The Cyber Resilience Act and CRA deadlines.
The Cyber Resilience Act, or CRA, governs product cybersecurity. Regulation (EU) 2024/2847 connects design requirements with duties throughout the product lifecycle. Its subject is the specific product, including relevant components and associated remote data processing. An organisation-wide security programme can support this work but does not answer product-specific questions on its own.
CRA deadlines are phased. Under Article 71(2) CRA, general requirements begin on 11 December 2027; manufacturer reporting under Article 14 has applied since 11 September 2026. Chapter IV on notification of conformity assessment bodies has applied since 11 June 2026. This institutional date is not an earlier general CE deadline for all software products.
Older products are not categorically exempt from manufacturer reporting. Article 69(2) and (3) CRA distinguishes transitional product conformity rules from reporting. Commission guidelines C(2026) 5252, section 9.1, explain this distinction also for products placed on the market before December 2027. The guidelines are a non-binding interpretative aid; the regulation remains authoritative.
Which products and companies the CRA affects.
The CRA concerns hardware and software products in scope that are made available on the EU market and provide a direct or indirect data connection to a device or network. Articles 2 and 3 CRA define scope and terms. This can include separately marketed components. Examine actual functionality and statutory exceptions before classifying the whole portfolio alike.
A company's role determines its obligations. Manufacturers, importers and distributors have different tasks; the manufacturer role can also be relevant when marketing under one's own brand. For open-source software, commercial supply, individual contributions and the special role of the open-source software steward must be distinguished. A free licence does not categorically exempt a commercial product's manufacturer from responsibility.
A SaaS service does not fall within or outside the CRA simply because of its sales label. Product boundaries and associated remote data processing are decisive. Commission guidelines, sections 2 and 8, distinguish software products from remotely provided services. Record the reasoning for the specific architecture; a general statement about all cloud offerings would be too broad.
The main areas of CRA requirements.
CRA requirements connect risk-based product security with ongoing responsibility. Article 13 and Annex I CRA form the basis of product duties; Article 14 governs manufacturer reporting that applies earlier. The following areas provide orientation without replacing the individual statutory requirements.
Understand the product and its risks.
A cybersecurity risk assessment supports security decisions throughout the lifecycle. Manufacturers consider intended and reasonably foreseeable use. Describe in practical terms the product's functions, interfaces and dependencies and the consequences a security issue could have for its users.
Build security into the product.
Secure design and secure defaults belong together. Annex I CRA covers product characteristics such as access protection, data protection and limiting attack surfaces. A policy written afterwards cannot replace technical characteristics; development decisions and their verification must align with the risk assessment.
Integrate components responsibly.
Integrated components remain part of the product assessment. Manufacturers need traceable information about what they ship and how vulnerabilities in dependencies affect their product. The Commission explicitly describes due diligence for third-party components; simply passing on a supplier statement does not answer every product question.
Handle vulnerabilities and updates.
Vulnerability handling is an ongoing task during the relevant support period. This includes accessible reporting channels, assessment, remediation and secure delivery of security updates. Separate technical handling of a finding from the legal assessment of whether an actively exploited vulnerability or severe incident is reportable.
Define support and user information.
The support period follows the criteria in Article 13(8) CRA and expected use. In principle, at least five years is required; where expected use is shorter, that duration applies, while longer expected use may require a longer period. Commission guidelines, section 5, explicitly explain that five years is not a general maximum.
Enable manufacturer reporting.
Article 14 CRA distinguishes actively exploited vulnerabilities from severe security incidents. Manufacturers face staged reporting: an early warning without undue delay and within 24 hours at the latest, and further information within 72 hours of awareness. Final deadlines differ by trigger. A scanner finding alone is therefore neither automatically reportable nor sufficient reason to close the event.
Prepare conformity assessment and documentation.
Technical documentation and conformity assessment must explain the offered product. Article 32 CRA and the product category determine the permitted procedure. Record the chosen assessment basis alongside the product version; a general document collection without a traceable link to the assessed configuration is not a sufficient practical evidence strategy.
CRA implementation as a product process.
Define the portfolio and roles.
As a practical starting point, record the products offered, their relevant functions, the responsible legal entity and its role in each distribution channel.
Distinguish application phases.
Separate readiness for the manufacturer reporting duties already in force from preparation for general product conformity, and examine transitions for existing products.
Translate risks into product decisions.
Connect the risk assessment with design, component selection and verifiable security criteria for development and release.
Test reporting channels.
Name responsible people and deputies, and practise assessment, escalation and submission with incomplete information within the applicable deadlines.
Define support and the evidence route.
Plan maintenance of supported product versions and establish from the category which conformity assessment and technical documentation will be required.
CE marking for software and product evidence.
CRA evidence is a product-specific conformity assessment. In its explanation of Article 32 CRA, the Commission notes that internal assessment is possible for the default category. Certain important or critical products face stricter procedures involving a notified body or other permitted evidence routes. Actual product functionality determines the category; a promotional product name is insufficient.
The EU declaration of conformity and CE marking follow the applicable procedure. They are not a general certificate for the whole company or a promise that a product will never have vulnerabilities. A uniform certificate term therefore does not aptly describe the CRA: documentation, vulnerability handling and applicable duties must be considered throughout the relevant lifecycle.
Other frameworks and independent duties.
ISO 27001 organises an information security management system; the corresponding certificate alone does not confirm a product's CRA conformity. NIS2 considers entities in scope and their security organisation. The GDPR protects personal data, so a product event can raise additional data protection questions. Related workflows can be coordinated, while legal triggers and evidence still require separate examination.
In Secani.
Secani includes an editorial CRA work catalogue with sources, assessment questions and evidence examples. The company profile records roles and the assessment date, among other details; unresolved prerequisites remain visible as matters requiring examination. The aid supports organisation of the assessment but confirms neither legal classification nor product conformity.
Start with a defined product.
Choose a specific product and first clarify its boundaries, the responsible legal entity and the people responsible for security reporting. Then examine which current and future duties affect the product. This keeps preparation manageable and prevents a general compliance project from obscuring the reporting readiness already required.
Sources.
- Regulation (EU) 2024/2847 – Cyber Resilience Act
- European Commission: Cyber Resilience Act and application dates
- European Commission: summary of the legal act
- European Commission: manufacturer obligations
- European Commission: conformity assessment
- European Commission: CRA and open source
- European Commission: guidelines C(2026) 5252 with annex
Frequently asked questions.
Yes. For manufacturers in scope, reporting under Article 14 CRA has applied since 11 September 2026. General product duties begin on 11 December 2027; special roles and transitions require separate examination.
No. The SaaS label does not determine scope. Examine the software product, its functions and associated remote data processing based on the specific architecture.
No. Special treatment of upstream open-source contributions does not categorically exempt a commercial product manufacturer from its duties. The manufacturer role and possible steward role must be distinguished.
No. An ISO 27001 certificate concerns a defined management system. The CRA requires separate consideration of the product and the applicable conformity evidence.
Organise product security with a clear audit trail.
Use Secani to structure work on CRA requirements and their assessment.
This page explains the Cyber Resilience Act in general terms and does not replace legal examination of an individual product. Applicable legal acts take precedence.