Introduction
The EU Cyber Resilience Act (CRA) is a binding European Union regulation that establishes mandatory cybersecurity requirements for hardware and software products sold in the EU market. It applies to manufacturers, importers, and distributors of products with digital elements, regardless of where those organizations are headquartered. The CRA governs the full product lifecycle, covering security by design, vulnerability reporting, patching obligations, and conformity assessment from development through end of support.
Key Takeaways
- The EU Cyber Resilience Act (CRA) introduces cybersecurity requirements that must be mandatorily applied for digital products, products with digital elements, and digital goods, across their entire lifecycle, from design to end-of-support.
- It applies to manufacturers, importers, and distributors placing hardware or software products on the EU market, regardless of where the organization is headquartered.
- The regulation classifies products into different risk tiers, with higher-risk categories subject to stricter conformity assessments and oversight.
- Core obligations include embedding security into product design, managing vulnerabilities throughout the product lifecycle, maintaining technical documentation, and ensuring compliance through CE marking.
- A key early requirement is the obligation to report actively exploited vulnerabilities within strict timelines, making operational readiness a near-term priority.
- Preparing for compliance requires a structured approach, including identifying in-scope products, conducting risk assessments, embedding secure development practices, and establishing reporting and documentation processes.
- Organizations may face challenges such as remediating legacy products, managing risks from third-party components, and ensuring compliance across complex global supply chains.
- GRC platforms help operationalize CRA compliance by enabling control mapping across frameworks, automating vulnerability tracking and reporting workflows, and providing visibility to leadership.
What Is the EU Cyber Resilience Act (CRA)?
The EU Cyber Resilience Act (CRA), formally published as Regulation (EU) 2024/2847 in the Official Journal of the European Union, is the first horizontal EU regulation to impose binding cybersecurity requirements on products with A digital element/ component, across their entire lifecycle. Unlike earlier EU cybersecurity frameworks that focused on organizational practices or sector-specific obligations, the CRA is product-centric: it governs what gets built and how, from initial design through decommissioning.
The regulation was proposed by the European Commission in September 2022, driven by concern over the fragmented and inadequate state of product security across the EU market. The Commission found that cybersecurity was too often treated as an afterthought in product development, leaving consumers and enterprises exposed to preventable vulnerabilities. The Council adopted the CRA on 10 October 2024, and it entered into force on 10 December 2024. As a regulation rather than a directive, it is directly applicable across all EU Member States without requiring national transposition.
The scale of the CRA's reach reflects the seriousness of the problem it addresses. The regulation covers any hardware or software product that can connect directly or indirectly to another device or network, a definition broad enough to encompass consumer electronics, industrial control systems, operating systems, and enterprise software components. Organizations that manufacture, import, or distribute such products and place them on the EU market will face mandatory compliance obligations regardless of where they are based.
Who Does the Cyber Resilience Act Apply To?
The CRA places obligations on three categories of economic operators: manufacturers, importers, and distributors. Manufacturers carry the most extensive obligations, including security by design, vulnerability handling, technical documentation, and conformity assessment. Importers must verify that the manufacturers of the products they place on the market have met CRA requirements. Distributors carry lighter due-diligence obligations but are not exempt from liability if they knowingly supply non-compliant products.
The regulation applies to any organization placing products with digital elements on the EU market, irrespective of the organization's location. A US-headquartered software vendor selling a product into the EU is subject to the same obligations as a manufacturer based in Germany.
In terms of product scope, the CRA classifies products across three tiers:
- Default products are subject to self-assessment conformity procedures and represent the majority of in-scope products.
- Important products (Class I and Class II), listed in Annex III, carry elevated risk profiles and require third-party conformity assessment by a Notified Body. Examples include browsers, password managers, VPNs, network management software, and smart home devices with security functions.
- Critical products, listed in Annex IV, include items such as operating systems, industrial firewalls, and hardware security modules, and face the most stringent conformity requirements.
Several product categories are explicitly out of scope. Products already governed by sector-specific EU regulations with equivalent cybersecurity requirements are excluded. These include medical devices regulated under the MDR and IVDR, aeronautical equipment under EASA rules, and motor vehicles under the type-approval framework. Pure SaaS and cloud services with no downloadable client component are also outside the CRA's scope; NIS2 governs those entities instead.
SMEs and microenterprises are subject to the same technical obligations as larger organizations but benefit from some procedural accommodations. Microenterprises and small enterprises are, for instance, not subject to fines for failure to meet the 24-hour vulnerability reporting deadline under the regulation's penalty provisions, as confirmed in the European Commission's summary of Regulation (EU) 2024/2847.
Key Requirements Under the Cyber Resilience Act
The CRA's substantive obligations are set out primarily in Annex I and in Articles 13 and 14. They fall into four main areas:
Security by Design
Manufacturers must integrate cybersecurity into the product development process from the earliest design stage. Products must be delivered in a secure default configuration, protect against unauthorized access, ensure the confidentiality and integrity of stored and transmitted data, and minimize their attack surface. Manufacturers are required to conduct risk assessments during the design and development phases and document how those assessments informed the product's architecture and controls. Security cannot be retrofitted post-launch to meet the CRA's standard; it must be embedded in the development lifecycle.
Vulnerability Handling
Manufacturers must establish and maintain processes for identifying, documenting, and remediating vulnerabilities throughout the product's supported life. This includes a policy for coordinated vulnerability disclosure, mechanisms for delivering security patches separately from functional updates, and a defined support period of at least five years (or the expected product lifetime, whichever is shorter). Manufacturers must notify users when a support period is ending, ensuring that buyers can make informed decisions about continued use.
Reporting Obligations for Actively Exploited Vulnerabilities
From 11 September 2026, manufacturers must report any actively exploited vulnerability to the relevant national Computer Security Incident Response Team (CSIRT) and to ENISA within 24 hours of becoming aware of it, followed by a more detailed notification within 72 hours. The CRA mandates the creation of a Single Reporting Platform to coordinate this process across Member States. This early-application deadline makes vulnerability reporting the most immediate compliance priority for organizations already placing products on the EU market.
Technical Documentation and Conformity Assessment
Manufacturers must prepare and maintain technical documentation demonstrating how their product meets the essential cybersecurity requirements in Annex I. This documentation must be available to market surveillance authorities on request. Products must carry CE marking to signal conformity before being placed on the market. The conformity assessment route depends on the product's classification: default products may self-certify, while Important and Critical products require assessment by an accredited Notified Body.
CRA Compliance Timeline and Key Dates
| Date | Milestone | What Organizations Must Do |
|---|---|---|
| 10 December 2024 | CRA enters into force | Begin scoping exercise: identify in-scope products, assign compliance ownership |
| 11 June 2026 | Notification framework for conformity assessment bodies applies | Confirm which Notified Bodies are accredited for your product category; initiate third-party assessment engagements if required |
| 11 September 2026 | Vulnerability and incident reporting obligations apply | Reporting processes and ENISA notification workflows must be operational; 24-hour reporting SLAs go live |
| 11 December 2027 | Full CRA application | All essential cybersecurity requirements, technical documentation, CE marking, and conformity assessment obligations must be met for all products placed on the EU market |
CRA vs. NIS2: Key Differences for Compliance Teams
Both the CRA and the NIS2 Directive are central to the EU's cybersecurity regulatory framework, but they operate on different dimensions and should not be conflated. The table below sets out the primary distinctions relevant to compliance planning.
| Dimension | EU Cyber Resilience Act (CRA) | NIS2 Directive |
|---|---|---|
| Legal instrument | Regulation - directly applicable in all Member States | Directive - requires national transposition; rules may vary by Member State |
| Primary focus | Product security across the lifecycle | Organizational cybersecurity and operational resilience |
| Who it targets | Manufacturers, importers, and distributors of products with digital elements | Essential and important entities in critical sectors (energy, health, transport, finance, digital infrastructure, and others) |
| Scope trigger | Placing a product with digital elements on the EU market | Operating as an essential or important entity (generally 50+ employees or €10M+ turnover in covered sectors) |
| Core obligations | Security by design, vulnerability handling, reporting, CE marking, technical documentation | Risk management measures, incident reporting, business continuity, supply chain security, governance |
| SaaS and cloud | Largely out of scope (no downloadable component) | In scope if the provider qualifies as an essential or important digital service provider |
| Max penalties | €15M or 2.5% of global annual turnover (whichever is higher) | Up to €10M or 2% of global annual turnover for essential entities. However, this guideline has undergone multiple changes, and the most recent applicable guideline must be analyzed. |
| Overlap risk | An organization that manufactures a digital product and operates as an essential entity may be subject to both frameworks simultaneously | |
How to Prepare for CRA Compliance
Here is a step-by-step breakdown of the CRA compliance process:
Step 1: Identify In-Scope Products
Conduct a complete inventory of all hardware and software products your organization places on the EU market. Assess whether each qualifies as a product with digital elements, meaning it can connect to a device or network. Confirm whether any products fall under exempt categories governed by sector-specific regulations.
Step 2: Conduct a Security Risk Assessment
Perform a structured cybersecurity risk assessment across the product lifecycle, covering design, development, production, and maintenance. Identify key threat vectors, evaluate potential impact, and document the controls implemented. Ensure the findings inform product architecture and are retained as part of technical documentation.
Step 3: Implement Secure Development Lifecycle Practices
Translate risk assessment findings into your development processes by embedding security into product specifications. Introduce security testing at each stage, along with code reviews and vulnerability scanning before release. Align your practices with established frameworks to ensure consistency and defensibility.
Step 4: Establish Vulnerability Disclosure and Patching Processes
Define and document a coordinated vulnerability disclosure policy that outlines how issues are received, assessed, and resolved. Set clear SLAs for remediation and ensure security patches can be deployed independently of functional updates. Build the operational capability to meet strict reporting timelines, including the 24-hour requirement.
Step 5: Prepare Technical Documentation
Assemble documentation that demonstrates compliance with cybersecurity requirements, including risk assessments, architecture details, and test results. Include key elements such as a Software Bill of Materials and the EU Declaration of Conformity. Keep this documentation updated throughout the product’s lifecycle and ready for regulatory review.
Step 6: Plan Your Conformity Assessment Route
Determine the appropriate conformity assessment route for each product based on its classification. Default products may follow self-assessment, while higher-risk categories require third-party evaluation. Complete the required assessment before applying CE marking and placing the product on the market.
Step 7: Assign Ongoing Compliance Ownership
Assign clear ownership for monitoring vulnerabilities, updating documentation, and managing reporting obligations. Define responsibilities across teams, including escalation and regulatory communication workflows. Treat compliance as an ongoing function that evolves with the product and regulatory landscape.
Managing CRA alongside NIS2 and DORA creates overlapping obligations that require a coordinated compliance approach.
MetricStream's Cyber GRC platform enables organizations to map EU cyber regulatory requirements to a unified control framework, track obligations across frameworks in a single environment, and maintain audit-ready evidence for multiple regulators simultaneously. Request a Demo
CRA Compliance Challenges and How to Address Them
Below are some of the challenges companies may face while dealing with the CRA compliance process, along with ways to address them:
Legacy Product Remediation
Organizations with large product portfolios must manage the compliance of products already in circulation alongside new ones. Products that remain on the EU market after December 2027 must meet CRA requirements, even if they were launched earlier. For products not built with security by design, this may require significant re-engineering rather than surface-level fixes. Organizations should prioritize high-risk legacy products early and factor remediation into product roadmap planning.
Third-Party Component Risk
Modern digital products rely heavily on third-party libraries, open-source components, and external modules. The CRA holds manufacturers accountable for the security of the entire product, including components they did not develop. This creates a need to track component-level vulnerabilities and maintain visibility into product composition. Building and maintaining an accurate Software Bill of Materials (SBOM) is critical, though it requires investment in tooling and processes.
Cross-Border Supply Chain Complexity
Organizations operating across multi-tier global supply chains face challenges in verifying upstream compliance. Importers must ensure that manufacturers meet CRA requirements before placing products on the EU market. Obtaining and validating this evidence, especially from non-EU suppliers, requires stronger due diligence processes. Embedding CRA requirements into supplier contracts and procurement workflows early can help manage this complexity.
How GRC Tools Support CRA Compliance
Meeting CRA obligations across product lines, frameworks, and reporting timelines creates operational complexity that manual processes cannot reliably handle, which is where GRC tools support the process in the following ways:
Control Mapping Across Frameworks
One of the practical challenges CRA compliance presents to security and compliance teams is managing its requirements alongside those of NIS2, DORA, ISO 27001, and other applicable frameworks. GRC platforms address this by maintaining a unified control library in which each control can be mapped to multiple regulatory requirements simultaneously. When a team implements a control to satisfy a CRA vulnerability handling obligation, the platform can automatically reflect that control's status against any mapped NIS2 or DORA requirements as well, eliminating the duplication of effort that typically arises when teams manage each framework in isolation.
Automated Evidence Collection and Vulnerability Tracking
The CRA's reporting obligations, particularly the 24-hour notification requirement for actively exploited vulnerabilities, demand that organizations have real-time visibility into their vulnerability landscape and pre-built workflows for escalation and reporting. GRC platforms support this by integrating with vulnerability scanning and asset management tools to ingest findings automatically, routing them to the appropriate owners, and tracking remediation status against defined SLAs. The same workflow infrastructure can generate the evidence needed for technical documentation and conformity assessment, reducing the manual effort involved in demonstrating compliance to market surveillance authorities or Notified Bodies.
Executive and Board-Level Reporting
CRA compliance has board-level implications: non-compliance can result in market withdrawal and penalties that materially affect revenue. GRC platforms translate operational compliance data into executive dashboards and structured reports that give senior leadership and audit committees visibility into the organization's CRA readiness posture, outstanding obligations by product line, and progress against the compliance timeline. This reporting function supports informed decision-making at the governance level and provides a documented record of oversight that is increasingly expected by regulators and insurers alike.
Ready to map your CRA obligations to your existing control framework? Our experts can walk you through how MetricStream supports EU cyber regulatory compliance across your product portfolio. Talk to an Expert
How MetricStream Cyber GRC Can Help
Meeting the CRA's requirements demands more than a compliance checklist. Manufacturers and importers need a sustained operational capability to track product-level risks, manage vulnerability workflows, maintain technical documentation, and report to regulators within tight timeframes. MetricStream's Cyber GRC platform provides the infrastructure to operationalize these obligations at scale, connecting IT risk management, compliance tracking, and policy management functions in a single environment.
MetricStream's IT and Cyber Risk Management capabilities enable organizations to conduct structured risk assessments at the product level, document findings against defined cybersecurity frameworks, and maintain an up-to-date view of control effectiveness across their product portfolio. Vulnerability tracking workflows can be configured to reflect the CRA's 24-hour and 72-hour reporting timelines, with automated escalation paths and evidence capture built into the process. This reduces the operational burden of meeting the September 2026 reporting deadline while creating a documented trail for audit and regulatory review.
For compliance teams managing CRA alongside NIS2, DORA, or ISO 27001, MetricStream's cross-framework control mapping eliminates the need to manage each regulation in a separate tool. Obligations are mapped to a unified control library, and compliance status is tracked and reported in a consistent format across all applicable frameworks. This integrated approach gives CISOs, IT risk managers, and compliance leads a reliable basis for reporting CRA readiness to the board and for engaging with market surveillance authorities or Notified Bodies with confidence.
The EU Cyber Resilience Act (CRA) is a binding European Union regulation that establishes mandatory cybersecurity requirements for hardware and software products sold in the EU market. It applies to manufacturers, importers, and distributors of products with digital elements, regardless of where those organizations are headquartered. The CRA governs the full product lifecycle, covering security by design, vulnerability reporting, patching obligations, and conformity assessment from development through end of support.
- The EU Cyber Resilience Act (CRA) introduces cybersecurity requirements that must be mandatorily applied for digital products, products with digital elements, and digital goods, across their entire lifecycle, from design to end-of-support.
- It applies to manufacturers, importers, and distributors placing hardware or software products on the EU market, regardless of where the organization is headquartered.
- The regulation classifies products into different risk tiers, with higher-risk categories subject to stricter conformity assessments and oversight.
- Core obligations include embedding security into product design, managing vulnerabilities throughout the product lifecycle, maintaining technical documentation, and ensuring compliance through CE marking.
- A key early requirement is the obligation to report actively exploited vulnerabilities within strict timelines, making operational readiness a near-term priority.
- Preparing for compliance requires a structured approach, including identifying in-scope products, conducting risk assessments, embedding secure development practices, and establishing reporting and documentation processes.
- Organizations may face challenges such as remediating legacy products, managing risks from third-party components, and ensuring compliance across complex global supply chains.
- GRC platforms help operationalize CRA compliance by enabling control mapping across frameworks, automating vulnerability tracking and reporting workflows, and providing visibility to leadership.
The EU Cyber Resilience Act (CRA), formally published as Regulation (EU) 2024/2847 in the Official Journal of the European Union, is the first horizontal EU regulation to impose binding cybersecurity requirements on products with A digital element/ component, across their entire lifecycle. Unlike earlier EU cybersecurity frameworks that focused on organizational practices or sector-specific obligations, the CRA is product-centric: it governs what gets built and how, from initial design through decommissioning.
The regulation was proposed by the European Commission in September 2022, driven by concern over the fragmented and inadequate state of product security across the EU market. The Commission found that cybersecurity was too often treated as an afterthought in product development, leaving consumers and enterprises exposed to preventable vulnerabilities. The Council adopted the CRA on 10 October 2024, and it entered into force on 10 December 2024. As a regulation rather than a directive, it is directly applicable across all EU Member States without requiring national transposition.
The scale of the CRA's reach reflects the seriousness of the problem it addresses. The regulation covers any hardware or software product that can connect directly or indirectly to another device or network, a definition broad enough to encompass consumer electronics, industrial control systems, operating systems, and enterprise software components. Organizations that manufacture, import, or distribute such products and place them on the EU market will face mandatory compliance obligations regardless of where they are based.
The CRA places obligations on three categories of economic operators: manufacturers, importers, and distributors. Manufacturers carry the most extensive obligations, including security by design, vulnerability handling, technical documentation, and conformity assessment. Importers must verify that the manufacturers of the products they place on the market have met CRA requirements. Distributors carry lighter due-diligence obligations but are not exempt from liability if they knowingly supply non-compliant products.
The regulation applies to any organization placing products with digital elements on the EU market, irrespective of the organization's location. A US-headquartered software vendor selling a product into the EU is subject to the same obligations as a manufacturer based in Germany.
In terms of product scope, the CRA classifies products across three tiers:
- Default products are subject to self-assessment conformity procedures and represent the majority of in-scope products.
- Important products (Class I and Class II), listed in Annex III, carry elevated risk profiles and require third-party conformity assessment by a Notified Body. Examples include browsers, password managers, VPNs, network management software, and smart home devices with security functions.
- Critical products, listed in Annex IV, include items such as operating systems, industrial firewalls, and hardware security modules, and face the most stringent conformity requirements.
Several product categories are explicitly out of scope. Products already governed by sector-specific EU regulations with equivalent cybersecurity requirements are excluded. These include medical devices regulated under the MDR and IVDR, aeronautical equipment under EASA rules, and motor vehicles under the type-approval framework. Pure SaaS and cloud services with no downloadable client component are also outside the CRA's scope; NIS2 governs those entities instead.
SMEs and microenterprises are subject to the same technical obligations as larger organizations but benefit from some procedural accommodations. Microenterprises and small enterprises are, for instance, not subject to fines for failure to meet the 24-hour vulnerability reporting deadline under the regulation's penalty provisions, as confirmed in the European Commission's summary of Regulation (EU) 2024/2847.
The CRA's substantive obligations are set out primarily in Annex I and in Articles 13 and 14. They fall into four main areas:
Security by Design
Manufacturers must integrate cybersecurity into the product development process from the earliest design stage. Products must be delivered in a secure default configuration, protect against unauthorized access, ensure the confidentiality and integrity of stored and transmitted data, and minimize their attack surface. Manufacturers are required to conduct risk assessments during the design and development phases and document how those assessments informed the product's architecture and controls. Security cannot be retrofitted post-launch to meet the CRA's standard; it must be embedded in the development lifecycle.
Vulnerability Handling
Manufacturers must establish and maintain processes for identifying, documenting, and remediating vulnerabilities throughout the product's supported life. This includes a policy for coordinated vulnerability disclosure, mechanisms for delivering security patches separately from functional updates, and a defined support period of at least five years (or the expected product lifetime, whichever is shorter). Manufacturers must notify users when a support period is ending, ensuring that buyers can make informed decisions about continued use.
Reporting Obligations for Actively Exploited Vulnerabilities
From 11 September 2026, manufacturers must report any actively exploited vulnerability to the relevant national Computer Security Incident Response Team (CSIRT) and to ENISA within 24 hours of becoming aware of it, followed by a more detailed notification within 72 hours. The CRA mandates the creation of a Single Reporting Platform to coordinate this process across Member States. This early-application deadline makes vulnerability reporting the most immediate compliance priority for organizations already placing products on the EU market.
Technical Documentation and Conformity Assessment
Manufacturers must prepare and maintain technical documentation demonstrating how their product meets the essential cybersecurity requirements in Annex I. This documentation must be available to market surveillance authorities on request. Products must carry CE marking to signal conformity before being placed on the market. The conformity assessment route depends on the product's classification: default products may self-certify, while Important and Critical products require assessment by an accredited Notified Body.
| Date | Milestone | What Organizations Must Do |
|---|---|---|
| 10 December 2024 | CRA enters into force | Begin scoping exercise: identify in-scope products, assign compliance ownership |
| 11 June 2026 | Notification framework for conformity assessment bodies applies | Confirm which Notified Bodies are accredited for your product category; initiate third-party assessment engagements if required |
| 11 September 2026 | Vulnerability and incident reporting obligations apply | Reporting processes and ENISA notification workflows must be operational; 24-hour reporting SLAs go live |
| 11 December 2027 | Full CRA application | All essential cybersecurity requirements, technical documentation, CE marking, and conformity assessment obligations must be met for all products placed on the EU market |
Both the CRA and the NIS2 Directive are central to the EU's cybersecurity regulatory framework, but they operate on different dimensions and should not be conflated. The table below sets out the primary distinctions relevant to compliance planning.
| Dimension | EU Cyber Resilience Act (CRA) | NIS2 Directive |
|---|---|---|
| Legal instrument | Regulation - directly applicable in all Member States | Directive - requires national transposition; rules may vary by Member State |
| Primary focus | Product security across the lifecycle | Organizational cybersecurity and operational resilience |
| Who it targets | Manufacturers, importers, and distributors of products with digital elements | Essential and important entities in critical sectors (energy, health, transport, finance, digital infrastructure, and others) |
| Scope trigger | Placing a product with digital elements on the EU market | Operating as an essential or important entity (generally 50+ employees or €10M+ turnover in covered sectors) |
| Core obligations | Security by design, vulnerability handling, reporting, CE marking, technical documentation | Risk management measures, incident reporting, business continuity, supply chain security, governance |
| SaaS and cloud | Largely out of scope (no downloadable component) | In scope if the provider qualifies as an essential or important digital service provider |
| Max penalties | €15M or 2.5% of global annual turnover (whichever is higher) | Up to €10M or 2% of global annual turnover for essential entities. However, this guideline has undergone multiple changes, and the most recent applicable guideline must be analyzed. |
| Overlap risk | An organization that manufactures a digital product and operates as an essential entity may be subject to both frameworks simultaneously | |
Here is a step-by-step breakdown of the CRA compliance process:
Step 1: Identify In-Scope Products
Conduct a complete inventory of all hardware and software products your organization places on the EU market. Assess whether each qualifies as a product with digital elements, meaning it can connect to a device or network. Confirm whether any products fall under exempt categories governed by sector-specific regulations.
Step 2: Conduct a Security Risk Assessment
Perform a structured cybersecurity risk assessment across the product lifecycle, covering design, development, production, and maintenance. Identify key threat vectors, evaluate potential impact, and document the controls implemented. Ensure the findings inform product architecture and are retained as part of technical documentation.
Step 3: Implement Secure Development Lifecycle Practices
Translate risk assessment findings into your development processes by embedding security into product specifications. Introduce security testing at each stage, along with code reviews and vulnerability scanning before release. Align your practices with established frameworks to ensure consistency and defensibility.
Step 4: Establish Vulnerability Disclosure and Patching Processes
Define and document a coordinated vulnerability disclosure policy that outlines how issues are received, assessed, and resolved. Set clear SLAs for remediation and ensure security patches can be deployed independently of functional updates. Build the operational capability to meet strict reporting timelines, including the 24-hour requirement.
Step 5: Prepare Technical Documentation
Assemble documentation that demonstrates compliance with cybersecurity requirements, including risk assessments, architecture details, and test results. Include key elements such as a Software Bill of Materials and the EU Declaration of Conformity. Keep this documentation updated throughout the product’s lifecycle and ready for regulatory review.
Step 6: Plan Your Conformity Assessment Route
Determine the appropriate conformity assessment route for each product based on its classification. Default products may follow self-assessment, while higher-risk categories require third-party evaluation. Complete the required assessment before applying CE marking and placing the product on the market.
Step 7: Assign Ongoing Compliance Ownership
Assign clear ownership for monitoring vulnerabilities, updating documentation, and managing reporting obligations. Define responsibilities across teams, including escalation and regulatory communication workflows. Treat compliance as an ongoing function that evolves with the product and regulatory landscape.
Managing CRA alongside NIS2 and DORA creates overlapping obligations that require a coordinated compliance approach.
MetricStream's Cyber GRC platform enables organizations to map EU cyber regulatory requirements to a unified control framework, track obligations across frameworks in a single environment, and maintain audit-ready evidence for multiple regulators simultaneously. Request a Demo
Below are some of the challenges companies may face while dealing with the CRA compliance process, along with ways to address them:
Legacy Product Remediation
Organizations with large product portfolios must manage the compliance of products already in circulation alongside new ones. Products that remain on the EU market after December 2027 must meet CRA requirements, even if they were launched earlier. For products not built with security by design, this may require significant re-engineering rather than surface-level fixes. Organizations should prioritize high-risk legacy products early and factor remediation into product roadmap planning.
Third-Party Component Risk
Modern digital products rely heavily on third-party libraries, open-source components, and external modules. The CRA holds manufacturers accountable for the security of the entire product, including components they did not develop. This creates a need to track component-level vulnerabilities and maintain visibility into product composition. Building and maintaining an accurate Software Bill of Materials (SBOM) is critical, though it requires investment in tooling and processes.
Cross-Border Supply Chain Complexity
Organizations operating across multi-tier global supply chains face challenges in verifying upstream compliance. Importers must ensure that manufacturers meet CRA requirements before placing products on the EU market. Obtaining and validating this evidence, especially from non-EU suppliers, requires stronger due diligence processes. Embedding CRA requirements into supplier contracts and procurement workflows early can help manage this complexity.
Meeting CRA obligations across product lines, frameworks, and reporting timelines creates operational complexity that manual processes cannot reliably handle, which is where GRC tools support the process in the following ways:
Control Mapping Across Frameworks
One of the practical challenges CRA compliance presents to security and compliance teams is managing its requirements alongside those of NIS2, DORA, ISO 27001, and other applicable frameworks. GRC platforms address this by maintaining a unified control library in which each control can be mapped to multiple regulatory requirements simultaneously. When a team implements a control to satisfy a CRA vulnerability handling obligation, the platform can automatically reflect that control's status against any mapped NIS2 or DORA requirements as well, eliminating the duplication of effort that typically arises when teams manage each framework in isolation.
Automated Evidence Collection and Vulnerability Tracking
The CRA's reporting obligations, particularly the 24-hour notification requirement for actively exploited vulnerabilities, demand that organizations have real-time visibility into their vulnerability landscape and pre-built workflows for escalation and reporting. GRC platforms support this by integrating with vulnerability scanning and asset management tools to ingest findings automatically, routing them to the appropriate owners, and tracking remediation status against defined SLAs. The same workflow infrastructure can generate the evidence needed for technical documentation and conformity assessment, reducing the manual effort involved in demonstrating compliance to market surveillance authorities or Notified Bodies.
Executive and Board-Level Reporting
CRA compliance has board-level implications: non-compliance can result in market withdrawal and penalties that materially affect revenue. GRC platforms translate operational compliance data into executive dashboards and structured reports that give senior leadership and audit committees visibility into the organization's CRA readiness posture, outstanding obligations by product line, and progress against the compliance timeline. This reporting function supports informed decision-making at the governance level and provides a documented record of oversight that is increasingly expected by regulators and insurers alike.
Ready to map your CRA obligations to your existing control framework? Our experts can walk you through how MetricStream supports EU cyber regulatory compliance across your product portfolio. Talk to an Expert
Meeting the CRA's requirements demands more than a compliance checklist. Manufacturers and importers need a sustained operational capability to track product-level risks, manage vulnerability workflows, maintain technical documentation, and report to regulators within tight timeframes. MetricStream's Cyber GRC platform provides the infrastructure to operationalize these obligations at scale, connecting IT risk management, compliance tracking, and policy management functions in a single environment.
MetricStream's IT and Cyber Risk Management capabilities enable organizations to conduct structured risk assessments at the product level, document findings against defined cybersecurity frameworks, and maintain an up-to-date view of control effectiveness across their product portfolio. Vulnerability tracking workflows can be configured to reflect the CRA's 24-hour and 72-hour reporting timelines, with automated escalation paths and evidence capture built into the process. This reduces the operational burden of meeting the September 2026 reporting deadline while creating a documented trail for audit and regulatory review.
For compliance teams managing CRA alongside NIS2, DORA, or ISO 27001, MetricStream's cross-framework control mapping eliminates the need to manage each regulation in a separate tool. Obligations are mapped to a unified control library, and compliance status is tracked and reported in a consistent format across all applicable frameworks. This integrated approach gives CISOs, IT risk managers, and compliance leads a reliable basis for reporting CRA readiness to the board and for engaging with market surveillance authorities or Notified Bodies with confidence.
Frequently Asked Questions
The EU Cyber Resilience Act (Regulation EU 2024/2847) is a binding EU regulation that requires manufacturers, importers, and distributors of hardware and software products to meet mandatory cybersecurity standards before placing those products on the EU market. It covers the full product lifecycle, from design through end of support, and includes obligations for vulnerability reporting, security patching, and conformity assessment.
The CRA entered into force on 10 December 2024. Vulnerability and incident reporting obligations apply from 11 September 2026. Full application of all requirements, including security by design, technical documentation, and CE marking, takes effect on 11 December 2027. Organizations placing products on the EU market should treat the September 2026 reporting deadline as the first hard compliance milestone.
Pure SaaS and cloud services with no downloadable client component are outside the CRA's scope, as clarified in Recital 12 of the regulation. However, if a SaaS product includes a companion desktop or mobile application that users download, that application is a product with digital elements and is in scope. Organizations providing both a cloud service and a downloadable component may be subject to both the CRA and NIS2 simultaneously.
Under Article 64 of Regulation (EU) 2024/2847, non-compliance with essential cybersecurity requirements can result in fines of up to €15 million or 2.5% of global annual turnover, whichever is higher. Failure to meet other manufacturer and distributor obligations carries fines of up to €10 million or 2% of turnover. Providing incorrect or misleading information to regulators can result in fines of up to €5 million. Products may also be subject to market withdrawal or recall.
The CRA regulates the security of digital products, placing obligations on manufacturers, importers, and distributors. NIS2 regulates the cybersecurity practices of organizations that operate essential services. The CRA is a regulation directly applicable across all Member States; NIS2 is a directive requiring national transposition, meaning specific rules may vary by country.
Products governed by existing EU sector-specific regulations with equivalent cybersecurity requirements are excluded from the CRA's scope. Exempted categories include medical devices regulated under the MDR and IVDR, aeronautical equipment under EASA rules, motor vehicles under EU type-approval legislation, and certain defence and national security products. Pure SaaS services without a downloadable component are also out of scope.
The CRA assigns primary responsibility to the legal entity placing the product on the EU market. For manufacturers, this is the organization that designs and markets the product, while for importers, it is the entity bringing it into the EU. Internally, responsibility is typically shared across product security, legal, and compliance teams, with technical accountability often sitting with the CISO or IT risk lead.
Commercial software vendors distributing products with digital elements in the EU are fully in scope. Non-commercial open-source software may fall outside the CRA, but open-source components within commercial products remain the manufacturer’s responsibility. Organizations must assess all third-party components against CRA requirements.
conformity assessment is the process of demonstrating that a product meets the CRA’s cybersecurity requirements before CE marking and market placement. Default products may use self-assessment, while higher-risk products require third-party evaluation by a Notified Body. Critical products face the most stringent assessment requirements.
Organizations should begin with a regulatory mapping exercise to identify overlaps across frameworks. The September 2026 vulnerability reporting deadline should be treated as the most immediate priority. Where controls apply across multiple frameworks, designing them to meet the strictest requirement can reduce overall compliance effort.
