The European Union identified significant gaps and inconsistencies in the approach to cybersecurity for digital products marketed across member states. While existing regulatory frameworks primarily addressed data protection (GDPR) or specific sectors (NIS2, medical devices, automotive, aviation), a comprehensive, horizontal legislative instrument governing the baseline cybersecurity of all products with digital elements was absent. The EU Cyber Resilience Act (CRA) is the first EU law to set mandatory cybersecurity standards for all hardware and software sold in the EU.
The primary objectives of the CRA are:
- To ensure a harmonised and elevated standard of cybersecurity throughout the single market.
- To mandate “security by design and by default,” thereby reducing inherent vulnerabilities from the initial stages of product development.
- To enhance transparency for both consumers and businesses regarding security features and the disclosure of vulnerabilities.
- To institute mandatory, clear procedures for the management of vulnerabilities and security incidents across a product’s entire lifecycle.
Scoping
General Scope
- The Cyber Resilience Act (CRA) applies to all digital products introduced into the EU market, including hardware and software with data connections, whether for consumers or businesses, that pose cybersecurity risks.
Key Product Types in Scope:
- Software: Applications (desktop/mobile/web), operating systems, firmware, embedded software, security software, cloud-based software (if it interacts with an EU-placed product), and remote data processing solutions.
- Hardware: Connected devices (IoT), smart appliances, routers/modems, wearables, smart TVs, network equipment, payment terminals, industrial control systems, etc.
- Combinations: Any product (hardware, software, or a combination) that can process or transmit data electronically and is sold or made available in the EU.
Economic Operators in Scope
The CRA clearly assigns responsibilities to manufacturers, importers, and other entities, reinforcing their vital role in ensuring cybersecurity and fostering confidence in compliance efforts.
- Manufacturers: Any entity that designs, develops, manufactures, or markets products containing digital elements under its own name or trademark.
- Importers: Any natural or legal person or company that introduces digital products from a third country into the European Union market.
- Distributors: Anyone or entity in the supply chain, other than the manufacturer or importer, that sells goods in the EU.
- Authorised Representatives: Entities established within the EU that are mandated to act on behalf of non-EU manufacturers.
- Open Source Stewards: Legal persons who systematically support the development and commercialisation of open-source software.
What Does “Placed on the Market” Mean?
- The act of placing a product on the EU market signifies the initial making available of that product within the European Union, whether for sale, distribution, or unrestricted use, and irrespective of the channels utilised, including online platforms.
- The regulation applies regardless of the manufacturer’s location, provided the product is made available to users within the European Union; in such cases, the Cyber Resilience Act (CRA) applies.
Special Categories Within Scope
- Critical Products with Digital Elements:
- Some products (see Annexe III of the Act) are classified as “critical” due to their function (e.g., operating systems, firewalls, VPNs, password managers, network management systems, security gateways).
- These require stricter conformity assessment (third-party audit).
- Products with Digital Elements (Default)
- Most other products, phones, smart devices, software apps, smart TVs, etc., fall under the general requirements and can self-assess conformity.
Exclusions (Out of Scope)
The CRA does NOT apply to:
- Products already subject to equivalent cybersecurity regulations under EU law, including:
- Medical devices (regulated by Medical Devices Regulation)
- Automotive products (EU vehicle regulations)
- Aviation equipment (EU aviation security)
- Some railway and maritime equipment
- Products developed exclusively for national security, military, or defence purposes
- Purely analogue devices (no digital elements)
- Open-source software provided outside of a commercial activity (i.e., not sold, supported, or commercialised; e.g., hobby projects, non-profit community releases)
Timeline
| Date | Milestone / Requirement |
|---|---|
| Sep 15, 2022 | The European Commission publishes the CRA draft proposal. |
| Dec 1, 2023 | A political agreement was reached in the EU Council and Parliament. |
| Mar 2024 | Formal adoption by the European Parliament. |
| Oct 10, 2024 | Formal adoption by the EU Council. |
| Nov 20, 2024 | Publication in the Official Journal of the EU. |
| Dec 10, 2024 | Entry into force: CRA becomes EU law (20 days after publication). |
| Dec 10, 2024 – Dec 10, 2027 | Transition period: Companies must prepare for compliance; authorities develop guidance, reporting platforms, and related measures. |
| Jun 11, 2026 | Start of reporting obligations for conformity assessment bodies (6 months after entry into force). |
| Sep 11, 2026 | Manufacturers’ obligation to report significant incidents and vulnerabilities begins (21 months after entry into force). |
| Dec 11, 2027 | Full application date: All core CRA requirements become enforceable (36 months after entry into force). |
Key Requirements
| CRA Requirement | Non-Conformity Risks | Mitigating Controls | Typical Owner |
|---|---|---|---|
| Security by Design & Default | Vulnerabilities in product architecture; insecure default settings; increased likelihood of exploitation | Secure SDLC, secure configuration baselines, design reviews, threat modelling, secure coding standards | Product/Dev/Engineering Lead |
| Risk Assessment | Undetected threats and vulnerabilities; inability to prioritise remediation | Regular risk assessments, use of risk registers, risk-based testing, periodic reviews | CISO, Risk Manager |
| Vulnerability Management | Undiscovered or unaddressed vulnerabilities, delayed patching, and exposure to attacks | Vulnerability scanning, patch management, coordinated disclosure policy, vulnerability response process | Security Ops, DevOps Lead |
| Incident Reporting | Regulatory fines for non-reporting; extended attack impact due to late or missed notification | Incident detection & response plan, reporting templates, clear escalation procedures, staff training | CISO, Security Ops |
| Technical Documentation | Inability to demonstrate compliance; delays in incident response or audits | Maintain up-to-date documentation (security features, risk assessments, logs), documentation reviews | Compliance Manager, Product Lead |
| Conformity Assessment & CE Marking | Non-compliant products on the market; risk of withdrawal or fines | Self-assessment checklist, third-party audit (for critical products), internal/external audit process, compliance file | Compliance, Quality Manager |
| Supply Chain Security | Compromise via third-party suppliers; inherited vulnerabilities | Supplier security assessment, contractual security clauses, third-party risk management, SBOM (software bill of materials) | Procurement, CISO |
| Post-Market Surveillance | Missed emerging threats; delayed response to new vulnerabilities | Continuous monitoring, threat intelligence, update mechanisms, incident & patch tracking | Security Ops, Product Manager |
| Staff Training & Awareness | Social engineering, phishing, insecure coding/operations due to a lack of awareness | Security training program, awareness campaigns, role-based training, regular refreshers | HR, CISO, Compliance |
| User Communication | User confusion, unsafe product usage, and reputational damage from poor communication | User security guides, security advisories, update notifications, and incident communication templates | Product, Support, Marketing |
| Record-Keeping & Auditability | Incomplete evidence for compliance; inability to demonstrate conformity under audit | Centralised compliance records, audit trails, regular internal reviews/audits | Compliance, Legal, IT |
Reporting Obligations
- What triggers a mandatory report?
- Actively Exploited Vulnerabilities:
- If a vulnerability in a product is being actively exploited “in the wild,” the manufacturer must report it.
- Significant Cybersecurity Incidents:
- If an incident substantially compromises the product’s security or the security of its users (e.g., a data breach or system compromise), it must be reported.
- Actively Exploited Vulnerabilities:
- Who must report?
- Manufacturers are the primary reporting party.
- Importers must report if they become aware of issues and the manufacturer does not act.
- What is the reporting process and timeline?
- Initial Report:
- Submit to ENISA (or the designated national authority) within 24 hours of becoming aware.
- Follow-up Report:
- Provide more detailed information within 72 hours.
- Final Report:
- Submit a root cause analysis and resolution within 2 weeks.
- Initial Report:
- What must the report include?
- Product identification and type.
- Nature of the vulnerability/incident
- Impact and risk assessment
- Actions already taken or planned.
- Contact details for follow-up.
- User Notification
- If the vulnerability or incident poses a significant risk to users, you must inform affected users without undue delay and provide mitigation instructions.
- Voluntary Reporting
- Manufacturers may voluntarily report vulnerabilities they discover, even if not (yet) exploited.
| What Must Be Reported | Who Must Report | To Whom | Deadline | CRA Article(s) | Additional Requirements |
|---|---|---|---|---|---|
| Actively exploited vulnerability | Manufacturer | ENISA or national authority | Within 24 hours | Art. 12, 14, 15 | Must also inform users of any significant risk. |
| Significant incident (cyber incident with major impact) | Manufacturer | ENISA or national authority | Within 24 hours | Art. 12, 14, 15 | Must provide a follow-up report within 72 hours; final report within 2 weeks. |
| Voluntary reporting of other vulnerabilities | Manufacturer (optional) | ENISA | As soon as possible | Art. 15 | Voluntary/extra reporting channel. |
| Vulnerabilities or incidents in imported products | Importer, if aware | ENISA or the authority | Without delay | Art. 19 | Must coordinate with the manufacturer. |
| Updates on remediation/corrective actions | Manufacturer | ENISA or the authority | As soon as available | Art. 12, 14, 15 | Keep authorities informed on progress. |
Consequences of Non-Compliance with the CRA
- Financial Penalties
- Severe fines:
- Up to €15 million or 2.5% of the company’s total worldwide annual turnover, whichever is higher.
- Fines vary based on the nature, gravity, duration, and intent of the violation.
- Lesser, but still substantial fines may apply for:
- Failure to report incidents/vulnerabilities on time.
- Providing incomplete or misleading information to authorities.
- Severe fines:
- Product Withdrawal or Recall
- Authorities can order your product to be withdrawn from the EU market.
- In urgent cases, products can be immediately recalled or prohibited from sale.
- Remediation Orders
- You may be required to fix vulnerabilities or bring your product into compliance within a specified timeframe.
- Failure to act may result in escalating enforcement or permanent removal.
- Audits and Investigations
- Market surveillance authorities can:
- Audit your compliance.
- Request technical documentation, risk assessments, and incident logs.
- Conduct on-site or remote inspections.
- Question or suspend your Declaration of Conformity or CE marking.
- Market surveillance authorities can:
- Legal & Civil Actions
- Users or consumer groups may initiate class actions or seek damages if they have suffered harm due to non-compliant products (see Article 65 on representative actions).
- Reputational Damage
- Public notification of non-compliance or a forced product recall can severely damage brand trust.
- Customers, partners, and investors may lose confidence in your organisation.
- Common Scenarios Leading to Non-Compliance
- Failing to report an exploited vulnerability or incident within 24 hours.
- Inadequate or missing technical documentation.
- Neglecting to perform risk or vulnerability assessments.
- Placing products on the market without proper CE marking or Declaration of Conformity.
- Inadequate post-market surveillance and patch management.
- Ignoring supply chain security obligations.
EU Cyber Resilience Act (CRA) Compliance Roadmap
Organisations that already have adequate security and compliance resources can confidently prepare for the EU Cyber Resilience Act by leveraging their own knowledge and using the numerous free tools and guides available. By starting early, these kinds of organisations can efficiently map requirements, change practices, and ensure compliance without hiring additional resources. Companies that don’t have their own infosec or compliance teams should hire skilled external consultants to ensure they fully understand the regulations, implement them correctly, and meet deadlines.Following are the guidelines which can be used:
- Understand the CRA Requirements
- Review the full text of the CRA, focusing on obligations for your organization’s role (manufacturer, importer, distributor, etc.).
- Identify relevant product categories and the specific security, reporting, and documentation requirements.
- Conduct a Gap Analysis
- Assess your current cybersecurity controls, risk management practices, and product development processes.
- Compare existing measures against CRA requirements, identifying gaps in:
- Security by design/default
- Vulnerability handling
- Secure update mechanisms
- Technical documentation
- Assign Internal Responsibility
- Designate a compliance lead or project team (consider a Virtual CISO or external consultant if needed).
- Ensure cross-functional collaboration between security, legal, product, and IT teams.
- Update Policies and Procedures
- Revise or create policies to address:
- Secure software/hardware development lifecycle
- Incident and vulnerability reporting
- Coordinated vulnerability disclosure
- Lifecycle management for digital products
- Revise or create policies to address:
- Technical and Organizational Measures
- Implement or enhance technical controls:
- Strong authentication and access controls
- Encryption and data protection
- Secure configuration and hardening
- Continuous vulnerability scanning and patch management
- Ensure organizational processes support ongoing compliance.
- Implement or enhance technical controls:
- Documentation and Recordkeeping
- Prepare and maintain technical documentation as required by the CRA:
- Product security features
- Risk assessments and mitigations
- Incident response processes
- Declaration of conformity and CE marking
- Prepare and maintain technical documentation as required by the CRA:
- Training and Awareness
- Train staff on CRA requirements and new/updated security practices.
- Foster a culture of cybersecurity and compliance.
- Testing and Validation
- Conduct security testing (e.g., penetration testing, code reviews) to validate controls.
- Document results and remediation activities.
- Conformity Assessment and CE Marking
- Perform or arrange for third-party conformity assessments if required (especially for critical or high-risk products).
- Prepare and affix CE marking to compliant products (If required).
- Ongoing Monitoring and Continuous Improvement
- Establish continuous monitoring for vulnerabilities, regulatory updates, and compliance status.
- Regularly review and improve controls, policies, and documentation.
- Incident and Vulnerability Reporting
- Set up clear processes for timely reporting to authorities (ENISA, national authorities) as per CRA timelines.
- Engage with vulnerability researchers and the public for coordinated disclosure.
- Re-audit and Review
- Schedule periodic internal/external audits to ensure ongoing compliance.
- Update the compliance program as regulations or business operations evolve.