TL;DR

CRA (Cyber Resilience Act) makes security mandatory for anything “digital” sold in the EU—apps, firmware, IoT, software.

Requires security-by-design, patching, SBOMs, and vulnerability disclosure across a product’s lifecycle.

Starts December 2027. Miss the mark? Expect €15M+ fines or market bans.

EU Cyber Resilience Act (CRA) Scorecard Summary:

• Developer Effort: High (Requires embedding security throughout the entire product lifecycle: secure design, secure coding, rigorous testing, implementing vulnerability handling processes, providing secure updates, maintaining SBOMs).
• Tooling Cost: Moderate to High (Requires secure SDLC tools - SAST/SCA/DAST, SBOM generation tools, vulnerability management platforms, potentially secure update infrastructure - OTA platforms).
• Market Impact: Very High (Mandatory for almost all hardware/software products sold in the EU; sets a new global baseline for product cybersecurity expectations).
• Flexibility: Moderate (Defines essential requirements but allows different conformity assessment routes based on product risk classification).
• Audit Intensity: Moderate to High (Requires conformity assessments - self-assessment for standard products, third-party assessment for critical products; market surveillance authorities will enforce).

What is the EU Cyber Resilience Act (CRA)?

The EU Cyber Resilience Act (CRA) is a regulation establishing harmonized cybersecurity requirements for "products with digital elements" (PDEs) made available on the European Union market. It aims to tackle the widespread problem of insecure hardware and software products and the lack of timely security updates.

The CRA applies broadly to almost any software or hardware product that can connect directly or indirectly to another device or network, with some exceptions (e.g., medical devices, aviation, cars already covered by specific legislation, SaaS unless critical). This includes consumer IoT devices, network equipment, industrial control components, operating systems, mobile apps, desktop software, and more.

Key pillars of the CRA:

1. Essential Cybersecurity Requirements (Annex I): Manufacturers must ensure PDEs meet specific security objectives throughout their lifecycle. This covers:
   
   • Security by Design & Default: Products must be designed, developed, and produced to ensure an appropriate level of cybersecurity. They must be delivered with a secure default configuration.
   • Vulnerability Management: Manufacturers must have processes to identify and remediate vulnerabilities throughout the product's expected lifetime or a minimum of five years, including providing security updates "without delay" and free of charge.
   • Data Protection: Protection of confidentiality, integrity, and availability of data processed by the product.
   • Access Control: Prevention of unauthorized access.
   • Resilience: Ability to withstand and recover from incidents.
   • Minimizing Attack Surface: Limiting attack surfaces and mitigating the impact of incidents.
2. Obligations for Economic Operators:
   
   • Manufacturers: Bear the primary responsibility for ensuring CRA compliance – secure design, conformity assessment, technical documentation (including SBOM), vulnerability handling, incident/vulnerability reporting, providing updates and clear instructions. This applies even if based outside the EU.
   • Importers/Distributors: Have obligations to verify manufacturer compliance (e.g., CE marking, documentation) before placing products on the market.
3. Vulnerability Handling & Reporting: Manufacturers must establish processes to handle vulnerabilities effectively and report actively exploited vulnerabilities to ENISA (EU Agency for Cybersecurity) within 24 hours of awareness. They must also inform users about fixed vulnerabilities and available updates.
4. Conformity Assessment & CE Marking: PDEs must undergo a conformity assessment process (ranging from manufacturer self-assessment to third-party certification depending on product criticality) to demonstrate compliance before receiving a CE marking and being placed on the EU market.
5. Market Surveillance: Designates national market surveillance authorities to enforce the CRA, investigate non-compliance, and impose penalties or require product withdrawal/recall.

The CRA entered into force in late 2024, with most obligations becoming applicable 36 months later (around December 2027), while manufacturer reporting obligations apply earlier (around September 2026).

Why is it Important?

The CRA is a landmark piece of legislation with significant implications:

• Shifts Responsibility: Places the onus for product security squarely on the manufacturers, rather than leaving it primarily to end-users.
• Raises Baseline Security: Establishes mandatory minimum cybersecurity standards for a vast range of connected products sold in the EU.
• Software Supply Chain Security: Addresses vulnerabilities originating from third-party components through requirements like SBOMs and vulnerability management across the lifecycle.
• Protects Consumers & Businesses: Aims to reduce the number of insecure products exploited by attackers, protecting users from data breaches, financial loss, and safety risks.
• Harmonizes Requirements: Creates a single set of rules across the EU, replacing potentially fragmented national approaches to product cybersecurity.
• Global Impact: Given the size of the EU market, the CRA effectively sets a global standard, influencing manufacturers worldwide who wish to sell products in Europe.
• Complements Other Regulations: Works alongside NIS2 (securing critical services), GDPR (protecting personal data), and DORA (financial resilience) to create a more comprehensive EU cybersecurity landscape.

For manufacturers of software and connected hardware, CRA compliance will become a fundamental requirement for market access in the EU.

What and How to Implement (Technical & Policy)

Implementing the CRA requires integrating its essential requirements (Annex I) throughout the product lifecycle:

1. Secure Design & Development (Security by Design):
   
   • Threat Modeling: Identify potential threats and design security controls from the outset.
   • Secure Coding Practices: Train developers and enforce secure coding standards (e.g., OWASP ASVS, CERT coding standards). Use SAST tools.
   • Minimize Attack Surface: Limit functionalities, open ports, and privileges to the minimum necessary.
   • Secure Defaults: Ensure products ship with secure configurations (e.g., no default passwords, unnecessary services disabled). Implement secure reset functionality.
   • Data Protection: Implement encryption for data at rest and in transit where appropriate. Protect data integrity.
   • Access Control: Implement robust authentication and authorization mechanisms.
2. Vulnerability Management:
   
   • Component Analysis (SBOM): Generate and maintain an accurate Software Bill of Materials (SBOM) identifying all components (including open-source libraries). Use SCA tools to find known vulnerabilities in dependencies.
   • Security Testing: Implement regular vulnerability scanning (SAST, DAST, SCA, IaC), fuzz testing, and penetration testing throughout development and post-release.
   • Vulnerability Handling Process: Establish clear procedures for receiving vulnerability reports (internal/external), analyzing them, developing patches, and distributing updates "without delay."
   • Patching/Updates: Provide security updates free of charge for the product's expected lifecycle (min. 5 years). Implement a secure update mechanism (e.g., secure OTA updates with integrity checks).
3. Transparency & Documentation:
   
   • Technical Documentation: Maintain detailed technical documentation demonstrating compliance with essential requirements. Include the SBOM.
   • User Information: Provide users with clear instructions on secure use, configuration, updates, and the product's support lifetime.
   • Vulnerability Disclosure: Establish a policy and contact point for receiving vulnerability reports; publicly disclose fixed vulnerabilities.
4. Conformity Assessment:
   
   • Risk Classification: Determine if the product falls into default, "important" (Class I), or "critical" (Class II) categories based on Annex III.
   • Assessment Procedure: Follow the required procedure (e.g., internal control/self-assessment for default, third-party assessment/certification for important/critical classes).
   • Declaration & CE Marking: Draw up an EU Declaration of Conformity and affix the CE marking once compliance is demonstrated.
5. Reporting Obligations:
   
   • Actively Exploited Vulnerabilities: Report to ENISA within 24 hours of awareness.
   • Significant Incidents: Report incidents impacting product security to ENISA.

Implementation demands embedding security into engineering culture, processes, and tooling from design through maintenance.

Common Mistakes to Avoid

Manufacturers preparing for the CRA should avoid these common mistakes:

1. Underestimating Scope: Believing the CRA only applies to complex IoT devices and not standard software or simpler hardware with digital elements. The scope is very broad.
2. Delaying Action: Waiting until closer to the 2027 deadline, underestimating the significant changes required in design, development, testing, vulnerability management, and update processes.
3. Treating Security as an Afterthought: Failing to integrate security from the design phase ("Security by Design") and trying to bolt it on later, which is less effective and more costly.
4. Inadequate Vulnerability Management: Lacking robust processes or tools (SCA, SAST, DAST) to identify vulnerabilities, or failing to provide timely and free security updates for the required lifecycle.
5. SBOM Inaccuracy/Neglect: Failing to generate a complete SBOM or keep it updated as components change, hindering vulnerability management.
6. Ignoring Secure Update Mechanisms: Not having a reliable and secure way (like a robust OTA platform) to deliver updates "without delay." Manual updates likely won't suffice.
7. Insufficient Documentation: Failing to maintain the required technical documentation, SBOM, and conformity assessment evidence needed for market surveillance.
8. Focusing Only on Development: Neglecting the ongoing post-market requirements for vulnerability handling and updates throughout the product lifecycle.

What Assessors/Authorities Might Ask (Developer Focus)

Conformity assessment bodies (for critical products) or market surveillance authorities might ask questions related to CRA requirements impacting development:

• (Annex I) Secure Design: "How was security considered during the design phase? Can you show threat models or security architecture documents?"
• (Annex I) Vulnerability Management: "What tools and processes are used to identify vulnerabilities in first-party code and third-party components (SAST, SCA) during development?"
• (Annex I) Secure Coding: "What secure coding standards are followed? How is compliance enforced (e.g., linters, code reviews, training)?"
• (Annex I) Security Testing: "Show evidence of security testing (e.g., penetration testing, fuzz testing) performed before release."
• (Annex I) Secure Updates: "Describe the mechanism for delivering security updates. How is the integrity and authenticity of updates ensured?"
• (Art. 10) SBOM: "Provide the Software Bill of Materials (SBOM) for this product version."
• (Art. 10) Vulnerability Handling: "Describe the process for handling a reported vulnerability, from intake to patch release."
• (Annex I) Secure Default Config: "How does the product ensure a secure configuration out-of-the-box?"

They will require evidence from the design, development, testing, and maintenance phases, including documentation, tool reports, process descriptions, and potentially code review access.

Quick Wins for Development Teams

While full CRA compliance takes time, dev teams can start laying the groundwork:

1. Implement SBOM Generation: Integrate tools to automatically generate an SBOM as part of the build process.
2. Integrate SCA & SAST: Ensure Software Composition Analysis and Static Application Security Testing are running reliably in the CI/CD pipeline.
3. Adopt Basic Threat Modeling: Start discussing potential threats during design meetings for new features or products.
4. Review Default Configurations: Actively assess and harden the default settings for products before shipping. Remove default credentials.
5. Document Update Process: Clearly document the current process for building and releasing software updates, even if it's manual initially.
6. Establish Vulnerability Intake: Create a simple, documented way for internal teams or external researchers to report potential vulnerabilities (e.g., a dedicated email address or form).

Ignore This And... (Consequences of Non-Compliance)

Non-compliance with the CRA can lead to severe consequences enforced by national market surveillance authorities:

• Heavy Fines: Administrative fines can reach up to €15 million or 2.5% of the manufacturer's total worldwide annual turnover for the preceding financial year, whichever is higher, for non-compliance with essential requirements. Lesser infringements carry fines up to €10M/2% or €5M/1%.
• Market Withdrawal/Recall: Authorities can require non-compliant products to be withdrawn from the EU market or recalled from end-users.
• Sales Prohibition/Restriction: Placing non-compliant products on the market can be prohibited or restricted.
• Reputational Damage: Public disclosure of non-compliance, recalls, or significant vulnerabilities damages brand trust and market perception.
• Loss of Market Access: Failure to meet CRA requirements effectively blocks access to the entire EU single market for covered products.

FAQ

What products are covered by the CRA?

"Products with digital elements" (PDEs) whose intended or reasonably foreseeable use includes a direct or indirect logical or physical data connection to a device or network. This includes most software (standalone, mobile, embedded) and hardware with connectivity (IoT devices, routers, smart appliances, industrial components, etc.). There are specific exclusions (e.g., medical devices, cars, aviation, certain SaaS).

When do CRA requirements become mandatory?

Most obligations, including conformity assessments and essential requirements, apply 36 months after the CRA enters into force (around December 2027). However, the manufacturer's reporting obligation for actively exploited vulnerabilities and incidents applies earlier, 21 months after entry into force (around September 2026).

Does the CRA apply to free and open-source software (FOSS)?

Standalone FOSS developed or supplied outside a commercial activity is generally excluded. However, FOSS integrated into a commercial product is covered, and the manufacturer of the final product is responsible. FOSS projects with formal structures (e.g., foundations) that monetize support or versions might fall under some CRA obligations as well (specifics are still debated).

What is the CE marking in the context of the CRA?

Similar to other EU product regulations, manufacturers must affix the CE marking to compliant PDEs to indicate they meet the CRA's essential requirements before placing them on the EU market. This requires a successful conformity assessment.

What is an SBOM and why is it required?

A Software Bill of Materials (SBOM) is a formal record containing the details and supply chain relationships of various components used in building software. The CRA requires manufacturers to generate and maintain an SBOM for their products to improve transparency and facilitate vulnerability management throughout the supply chain.

How long must manufacturers provide security updates under the CRA?

Manufacturers must provide security updates for the product's expected lifetime or for a minimum period of five years from placing the product on the market, whichever is shorter. The expected lifetime needs consideration during design. Updates must be free and timely ("without delay").

How does the CRA relate to NIS2 or GDPR?

• NIS2: Focuses on the security of networks and systems used by essential/important service providers. CRA focuses on the security of the products themselves that might be used by those providers or consumers.

GDPR: Focuses on protecting personal data. CRA focuses on product cybersecurity. A secure product under CRA helps protect the personal data processed by it (supporting GDPR), but CRA's scope is broader than just personal data. They are complementary parts of the EU's digital security strategy.