--- title: "Cyber Resilience Act: CRA Scope, Deadlines, Obligations" description: "Cyber Resilience Act (Regulation 2024/2847) explained: scope, 2026-2027 deadlines, cybersecurity obligations, reporting, CE marking, and NIS 2 coordination." canonical: https://www.aegister.com/en/cms/insights/cyber-resilience-act-cra-obligations-manufacturers/ url: /en/cms/insights/cyber-resilience-act-cra-obligations-manufacturers/ lang: en --- ![](/static/images/header-contact.webp) # Cyber Resilience Act (CRA): Obligations for Software and Hardware Manufacturers --- ![Cyber Resilience Act (CRA): Obligations for Software and Hardware Manufacturers](/static/images/cms/cyber-resilience-act-cra-obligations-manufacturers.webp) ## Cyber Resilience Act (CRA): Obligations for Software and Hardware Manufacturers April 25, 2026 [CRA](/en/cms/keyword/cra/) [Cyber Resilience Act](/en/cms/keyword/cyber-resilience-act/) [EU cybersecurity](/en/cms/keyword/eu-cybersecurity/) [Regulation 2024/2847](/en/cms/keyword/regulation-20242847/) +6 The Cyber Resilience Act (CRA) is Regulation (EU) 2024/2847. It creates horizontal cybersecurity requirements for products with digital elements placed on the EU market. For software and hardware manufacturers, the CRA turns product security into a lifecycle compliance obligation. Sources: [Regulation (EU) 2024/2847](https://eur-lex.europa.eu/eli/reg/2024/2847/oj), [European Commission CRA summary](https://digital-strategy.ec.europa.eu/en/policies/cra-summary), [European Commission CRA page](https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act), [ENISA CRA materials](https://www.enisa.europa.eu/topics/cyber-resilience-act). ## Key takeaways - The CRA entered into force on 10 December 2024. - Main obligations apply from 11 December 2027. - Article 14 reporting obligations apply earlier, from 11 September 2026. - The CRA applies to hardware and software products with digital elements made available on the EU market, subject to defined exclusions. - Manufacturers must address security by design, vulnerability handling, conformity assessment, technical documentation, and CE marking. - Non-compliance with essential cybersecurity requirements and Articles 13 and 14 can lead to fines up to EUR 15 million or 2.5% of worldwide annual turnover. ## Scope of this article This article explains CRA obligations for manufacturers, importers, distributors, and software teams. It does not replace product-specific legal analysis or conformity-assessment planning. ## What is the Cyber Resilience Act? The CRA is a product-security regulation. It applies across sectors and targets products with digital elements, including software, hardware, and remote data processing solutions that are necessary for a product function. The Commission describes it as a horizontal framework for secure hardware and software in the EU market. ## Application timeline | Date | Milestone | Operational consequence | | --- | --- | --- | | 10 December 2024 | Entry into force | Preparation period starts. | | 11 June 2026 | Chapter IV applies | Conformity-assessment body notification rules apply. | | 11 September 2026 | Article 14 applies | Reporting obligations for actively exploited vulnerabilities and severe incidents start. | | 11 December 2027 | Main application date | Core CRA obligations apply to products with digital elements. | ## Who is in scope? The CRA covers economic operators such as manufacturers, authorised representatives, importers, and distributors. The most intensive obligations sit with manufacturers because they control design, development, documentation, vulnerability handling, and conformity assessment. Open-source software requires careful analysis. The regulation distinguishes non-commercial open-source activity from commercial activity and also introduces the role of open-source software steward. Do not assume every repository is out of scope. ## Product categories | Category | Practical reading | Compliance impact | | --- | --- | --- | | Standard products | Products with digital elements not listed as important or critical. | Manufacturer obligations and conformity assessment apply. | | Important class I | Products listed in Annex III with material cybersecurity relevance. | More structured conformity expectations. | | Important class II | Higher-risk products listed in Annex III. | Stronger conformity-assessment burden. | | Critical products | Products listed in Annex IV. | Potential certification relevance and higher assurance expectations. | ## Main manufacturer obligations - Design, develop, and produce products according to essential cybersecurity requirements. - Document cybersecurity risk assessment and technical controls. - Handle vulnerabilities during the support period. - Provide security information and instructions to users. - Run the appropriate conformity-assessment route. - Apply CE marking when requirements are met. ## Vulnerability and incident reporting Article 14 introduces reporting duties for actively exploited vulnerabilities and severe incidents affecting product security. The Commission summary states that these reporting obligations apply from 11 September 2026. Product teams should prepare intake, triage, evidence, and disclosure workflows before that date. ## Coordination with NIS 2 and other EU rules NIS 2 focuses on entities and their cybersecurity risk-management obligations. CRA focuses on products with digital elements. A software vendor can be affected by both: NIS 2 as an entity and CRA as a product manufacturer. Existing Aegister articles on [NIS 2](/en/cms/insights/nis-2-directive-impact/), [EU Cybersecurity Act revision](/en/cms/insights/eu-cybersecurity-act-revision-2026/), [Cyber Solidarity Act](/en/cms/insights/eu-cyber-solidarity-act-2025/), and [CRA readiness funding](/en/cms/insights/secure-first-open-call-cra-readiness-2026/) provide adjacent context. ## Operational checklist 1. Inventory products and digital components placed on the EU market. 2. Classify each product category and economic-operator role. 3. Map secure-by-design controls to the product lifecycle. 4. Define vulnerability intake, triage, remediation, and disclosure workflow. 5. Prepare technical documentation and evidence repository. 6. Assess conformity route and CE-marking plan. 7. Coordinate CRA reporting with NIS 2, DORA, or sector incident processes. ## Secure development lifecycle under the CRA Manufacturers should translate CRA obligations into the product lifecycle. The practical lifecycle includes product classification, threat modeling, secure design review, dependency control, vulnerability testing, release approval, security update process, and end-of-support communication. Each step should leave evidence. | Lifecycle step | Evidence to keep | | --- | --- | | Product classification | Scope analysis, category decision, role assessment. | | Secure design | Threat model, architecture review, security requirements. | | Build and dependency control | SBOM, dependency review, signing records. | | Testing | Security test results, vulnerability remediation notes. | | Release | Conformity evidence, user security instructions, CE documentation. | | Post-market | Vulnerability intake, patch records, notification evidence. | ## Importer and distributor checkpoints Importers and distributors should not treat CRA as only a manufacturer problem. They need evidence that products are properly identified, accompanied by required documentation, and handled in a way that does not undermine conformity. Procurement teams should therefore request product-security documentation before market placement or distribution. ## Vulnerability-handling workflow 1. Receive vulnerability reports through a monitored channel. 2. Triage exploitability, affected versions, and product-security impact. 3. Assign remediation owner and target date. 4. Prepare user communication and update guidance. 5. Assess whether Article 14 reporting duties are triggered. 6. Preserve decision logs and technical evidence. ## Penalty and governance implications The CRA fine ceiling for essential cybersecurity requirements and Articles 13 and 14 is high enough to make product security a board-level risk. Compliance should therefore be tracked in product governance, not left only to engineering teams. ## Support-period planning CRA vulnerability handling is not a one-time release task. Manufacturers must plan how long security updates, vulnerability intake, and user communications will be supported. Regulation text and official summaries should be checked for the product category, but the operational point is simple: the support period must be defined, communicated, and resourced. ## Technical documentation pack - Product description and intended use. - Cybersecurity risk assessment and design decisions. - Essential requirement mapping. - SBOM or component inventory where applicable. - Testing records and vulnerability remediation notes. - Conformity assessment evidence. - User security instructions and support-period information. ## Product team operating model CRA readiness requires product, engineering, security, legal, and support teams to work together. Engineering owns secure implementation. Security owns threat modeling and validation. Legal and compliance own conformity interpretation. Support owns user communication and vulnerability intake. Product management owns lifecycle decisions and support-period commitments. ## Legacy and substantial modification risk Products already on the market before the main application date still need analysis when they are substantially modified. Product teams should define what counts as a security-relevant change, who approves it, and when technical documentation must be refreshed. This should be part of release governance. Manufacturers building or refreshing the CRA program often benefit from external CISO support to bridge product engineering, cybersecurity, and legal. Aegister's [Virtual CISO service](https://aegister.com/en/solutions/virtual-ciso/) covers product-security governance, vulnerability handling design, conformity-assessment readiness, and coordination with NIS 2 obligations where both regimes apply. ## FAQ ### When does the CRA apply? The CRA entered into force on 10 December 2024. Article 14 reporting applies from 11 September 2026. The main obligations apply from 11 December 2027. ### Does the CRA apply to software? Yes, where software is a product with digital elements made available on the EU market, subject to the regulation’s scope and exclusions. ### Is CE marking enough? No. CE marking is the visible outcome of conformity. The underlying evidence, risk assessment, vulnerability handling, and documentation matter. ## Official sources - [Regulation (EU) 2024/2847](https://eur-lex.europa.eu/eli/reg/2024/2847/oj) - [European Commission CRA summary](https://digital-strategy.ec.europa.eu/en/policies/cra-summary) - [European Commission CRA page](https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act) - [ENISA CRA materials](https://www.enisa.europa.eu/topics/cyber-resilience-act) - [Directive (EU) 2022/2555](https://eur-lex.europa.eu/eli/dir/2022/2555/oj) Share this post ## Related News [![SECURE First Open Call 2026: What mSMEs Need to Submit Before 29 March 2026](/static/images/cms/secure-cra-open-call.webp)](/en/cms/insights/secure-first-open-call-cra-readiness-2026/) [SECURE First Open Call 2026: What mSMEs Need to Submit Before 29 March 2026](/en/cms/insights/secure-first-open-call-cra-readiness-2026/) [The SECURE First Open Call (28 Jan – 29 Mar 2026) offers up to EUR 30,000 per project at 50% co-financing to help mSMEs achieve Cyber Resilience Act readiness. Full breakdown of eligibility, evaluation, and operational checklist.](/en/cms/insights/secure-first-open-call-cra-readiness-2026/) [ACN](/en/cms/keyword/acn/) [SECURE](/en/cms/keyword/secure/) +8 [![EU AI Act: Cybersecurity Implications for Compliance Teams](/static/images/cms/eu-ai-act-cybersecurity-implications.webp)](/en/cms/insights/eu-ai-act-cybersecurity-implications/) [EU AI Act: Cybersecurity Implications for Compliance Teams](/en/cms/insights/eu-ai-act-cybersecurity-implications/) [Focused guide to the cybersecurity implications of the EU AI Act for compliance teams, including staged application dates, high-risk AI controls, and coordination with NIS 2 and CRA.](/en/cms/insights/eu-ai-act-cybersecurity-implications/) [Cyber Resilience Act](/en/cms/keyword/cyber-resilience-act/) [EU AI Act](/en/cms/keyword/eu-ai-act/) +8 [![Understanding NIS 2: A Comprehensive Guide to the New EU Cybersecurity Directive](/static/images/cms/nis-2-guide.webp)](/en/cms/insights/aegister-nis-2-guide/) [Understanding NIS 2: A Comprehensive Guide to the New EU Cybersecurity Directive](/en/cms/insights/aegister-nis-2-guide/) [Master the NIS 2 Directive with our comprehensive guide covering implementation strategies, compliance requirements, and practical steps for strengthening your organization's cybersecurity framework.](/en/cms/insights/aegister-nis-2-guide/) [cybersecurity compliance](/en/cms/keyword/cybersecurity-compliance/) [risk management](/en/cms/keyword/risk-management/) +13