26.2: EU Cyber Resilience Act (CRA)¶

Legal Disclaimer: This chapter provides general educational information about the European Union's Cyber Resilience Act for informational purposes. It does not constitute legal advice and should not be relied upon as a substitute for consultation with qualified legal counsel familiar with EU law, your specific business activities, and applicable jurisdictional requirements. The CRA is a complex regulation with evolving interpretations and implementing acts. Organizations subject to the CRA should consult with attorneys experienced in EU product safety law and cybersecurity regulation.

The European Union's Cyber Resilience Act represents the most sweeping regulatory intervention into software security ever enacted. Formally adopted in October 2024 and entering into force on December 10, 2024,¹ the CRA establishes mandatory cybersecurity requirements for virtually all products containing software sold in the European market. For software vendors and open source communities worldwide, the regulation creates obligations that extend far beyond the EU's borders—any organization placing software products on the European market must comply, regardless of where they are headquartered.

The CRA emerged from the EU's broader cybersecurity strategy, responding to the same supply chain security concerns that prompted U.S. Executive Order 14028. However, the European approach differs fundamentally in its mechanism: rather than procurement requirements, the CRA uses product safety regulation, treating insecure software as analogous to unsafe physical products that cannot legally be sold. This approach—backed by significant penalties of up to €15 million or 2.5% of global annual turnover—ensures uniform application across the entire European market.

Scope: Products with Digital Elements¶

The CRA applies to products with digital elements, defined broadly as "any software or hardware product and its remote data processing solutions, including software or hardware components to be placed on the market separately." This definition encompasses an extraordinary range of products:

• Standalone software applications
• Operating systems and firmware
• Hardware devices with embedded software
• Internet of Things (IoT) devices
• Industrial control systems
• Software libraries and components sold commercially
• Cloud-connected products (with certain limitations)

The regulation explicitly covers both consumer and business-to-business products. A smartphone app, an enterprise database system, a network router, and an industrial sensor all fall within scope if they are placed on the EU market.

Several categories of products are excluded from CRA requirements:

• Products already regulated under sector-specific EU cybersecurity legislation (medical devices, automotive, aviation, marine)
• Software as a Service (SaaS) offerings, which fall under the NIS2 Directive instead
• Products developed exclusively for national security, military, or defense purposes
• Open source software developed or supplied outside the course of commercial activity

This final exclusion—non-commercial open source software—proved the most contentious aspect of the CRA's development and merits detailed examination later in this section.

Essential Cybersecurity Requirements¶

The CRA establishes essential cybersecurity requirements that all covered products must satisfy. These requirements, detailed in Annex I of the regulation, mandate that products be designed, developed, and produced to ensure appropriate cybersecurity based on identified risks. Specific requirements include:

Security by design and by default: - Products must be delivered with secure default configurations - Attack surfaces must be minimized - Exploitation impact must be limited through appropriate mechanisms (least privilege, compartmentalization) - No known exploitable vulnerabilities may exist at time of placing on market

Data protection requirements: - Confidentiality must be protected (including encryption of data at rest and in transit where appropriate) - Integrity of stored, transmitted, and processed data must be ensured - Only data necessary for product operation may be processed - Users must be able to delete their data

Access control and authentication: - Products must protect against unauthorized access - Authentication mechanisms must be appropriate to the risk level - Identity and access management must be implemented where relevant

Resilience and availability: - Products must be resilient against denial of service attacks - Availability and essential functions must be maintained during incidents - Negative impact on other devices and networks must be minimized

Update capability: - Security updates must be possible and practically implementable - Updates must be provided free of charge during the support period - Users must be informed when updates are available

Secure supply chain: - Manufacturers must identify and document components including open source - Vulnerabilities in components must be addressed and security-relevant dependencies identified

The CRA's requirements are technology-neutral and risk-based—the specific implementation depends on product category and risk assessment. A simple temperature sensor faces different expectations than an enterprise network security appliance.

Vulnerability Handling Obligations¶

Among the CRA's most significant provisions are mandatory vulnerability handling requirements that establish strict timelines for manufacturer response and disclosure. These obligations substantially exceed typical industry practice:

Actively exploited vulnerabilities must be reported to the European Union Agency for Cybersecurity (ENISA) within 24 hours of the manufacturer becoming aware that a vulnerability is being actively exploited. This initial notification must include: - Product identification - General information about the vulnerability - Information about exploitation (where known) - Whether other manufacturers may be affected

A more detailed report must follow within 72 hours, and a final report within 14 days of making a corrective measure available.

Severe incidents affecting product security must also be notified to ENISA within 24 hours, with follow-up reporting on similar timelines.

The 24-hour notification window proves particularly challenging. Many organizations currently take days or weeks to confirm exploitation status and perform initial analysis. The CRA's timeline demands rapid internal escalation procedures, pre-established ENISA communication channels, and potentially 24/7 security operations capability.

Coordinated vulnerability disclosure processes become mandatory. Manufacturers must: - Establish and publicize a vulnerability disclosure policy - Provide a contact address for security researchers - Process reported vulnerabilities promptly - Ensure researchers who report in good faith are not subject to legal action

Beyond ENISA notification, manufacturers must inform affected users about security vulnerabilities and provide remediation guidance without undue delay.

SBOM and Documentation Requirements¶

The CRA mandates that manufacturers prepare and maintain technical documentation demonstrating conformity with essential requirements. This documentation must include a Software Bill of Materials (SBOM) covering at least the top-level dependencies incorporated in the product.

The CRA's SBOM requirements align broadly with established formats and practices. Documentation must:

• Identify all components included in the product
• Document component dependencies (at minimum, top-level)
• Be kept current as products and components evolve
• Be made available to market surveillance authorities upon request

The regulation does not mandate public SBOM disclosure—manufacturers must provide SBOMs to authorities, not necessarily to customers. However, customers may contractually require SBOM provision, and practical market pressure increasingly favors transparency.

Technical documentation must be maintained for ten years after the product is placed on the market, or throughout the support period, whichever is longer. For products with ongoing updates, this creates substantial documentation management obligations.

The Commission is empowered to adopt delegated acts specifying SBOM format and elements. This creates potential for future harmonization with U.S. NTIA minimum elements and international standards like SPDX and CycloneDX.

Treatment of Open Source Software¶

The CRA's treatment of open source software evolved significantly during legislative development. Early drafts created alarm throughout the open source community, with major foundations warning that requirements could effectively prohibit volunteer-driven open source development. The final text addresses these concerns through careful distinctions between commercial activity and non-commercial open source development.

The fundamental principle: The CRA applies based on commercial activity, not on whether software is open source. Open source software developed and distributed as part of commercial activity falls within scope; purely non-commercial open source development does not.

The regulation recognizes that open source development typically involves:

"Free and open-source software is developed, maintained, and distributed openly, including via online platforms. In relation to the economic operators that fall within the scope of this Regulation, only free and open-source software made available on the market, and therefore supplied for distribution or use in the course of a commercial activity, should fall within the scope of this Regulation."

Non-commercial exclusion: Open source software falls outside CRA scope when: - It is not monetized directly - It is developed by volunteers not acting in a commercial capacity - Monetary contributions only cover development costs - It is provided without warranty and without expectation of commercial gain

This exclusion protects hobbyist developers and traditional community-driven open source projects from regulation. An individual maintaining a utility library on GitHub without commercial involvement faces no CRA obligations.

Commercial inclusion: Open source software falls within CRA scope when: - It is developed, maintained, or distributed as part of commercial activity - The manufacturer generates revenue from the software (directly or through related services) - Commercial entities provide the software as part of their product offerings

A company that develops open source software as part of its business—even if the software itself is free—must comply with CRA requirements as a manufacturer.

Open Source Steward Concept¶

The CRA introduces a novel concept: the open source steward, defined as "a legal person, other than a manufacturer, which has the purpose or objective to systematically provide support on a sustained basis for the development of specific products with digital elements qualifying as free and open-source software that are intended for commercial activities, and ensures the viability of those products."

This definition encompasses open source foundations like the Apache Software Foundation, Eclipse Foundation, Linux Foundation, and similar organizations that: - Provide sustained infrastructure support for projects - Ensure project governance and continuity - Support software intended for commercial use (even though the foundation itself is non-commercial)

Open source stewards face reduced obligations compared to manufacturers:

• They must establish a cybersecurity policy addressing vulnerability handling
• They must cooperate with market surveillance authorities
• They must facilitate vulnerability reporting to them
• They must document vulnerabilities they become aware of

Critically, open source stewards are not subject to: - Essential cybersecurity requirements - Conformity assessment procedures - CE marking obligations - The full range of manufacturer liability

"The open-source software steward should not be considered as a manufacturer even if they provide active support in the development of products with digital elements."

This distinction allows foundations to continue their governance and support roles without assuming manufacturer liability for every project they host. The obligation falls instead on commercial entities that take foundation-stewarded software and incorporate it into products they place on the market.

Manufacturer vs. Steward Responsibilities¶

The responsibility allocation between manufacturers, open source stewards, and volunteer developers operates as follows:

The commercial manufacturer bears responsibility for ensuring the complete product—including all incorporated open source components—meets essential requirements. This creates practical challenges: a manufacturer cannot compel volunteer open source maintainers to produce SBOMs or fix vulnerabilities on CRA timelines.

Manufacturers must therefore: - Perform due diligence on incorporated components - Create SBOMs covering open source dependencies - Monitor components for vulnerabilities - Develop or commission patches when upstream maintainers cannot or will not address issues - Potentially contribute security improvements back upstream

This responsibility allocation incentivizes commercial entities to invest in the security of open source software they depend on—a policy outcome deliberately designed into the regulation.

Conformity Assessment and CE Marking¶

Products within CRA scope must undergo conformity assessment before being placed on the EU market. The assessment procedure depends on product classification:

Default products (the majority) may use self-assessment, where the manufacturer evaluates their own conformity. This procedure requires: - Conducting risk assessment - Ensuring essential requirements are met - Preparing technical documentation including SBOM - Issuing an EU declaration of conformity - Affixing the CE marking to the product

Important products (Class I) include operating systems, identity management systems, browsers, password managers, VPNs, network management systems, security information and event management (SIEM) tools, boot managers, and others listed in Annex III. These may use self-assessment if conforming to harmonized standards covering all essential requirements; otherwise, third-party assessment is required.

Important products (Class II) include hypervisors, container runtimes, public key infrastructure components, firewalls, intrusion detection systems, and tamper-resistant microprocessors and microcontrollers. These require either: - EU-type examination followed by conformity to type, or - Conformity based on full quality assurance

Critical products (smart cards, secure elements, hardware security modules) require third-party certification under the EU Cybersecurity Act framework.

The CE marking indicates conformity with all applicable EU requirements and is mandatory for lawfully placing products on the market. Products lacking required CE marking may be withdrawn from the market by surveillance authorities.

Implementation Timeline¶

Note on Regulatory Currency: Regulatory implementation timelines evolve, and dates listed below may have passed by the time you read this. Readers should verify current regulatory status through official sources: the Official Journal of the European Union, ENISA, and the European Commission's Digital Strategy portal. This section describes the timeline as established at entry into force.

The CRA entered into force on December 10, 2024, with phased compliance deadlines:

The staggered timeline provides industry with transition periods, but the vulnerability reporting deadline arrives relatively quickly. Organizations must establish ENISA notification capabilities and internal escalation procedures within 21 months.

The December 2027 deadline for full compliance means products placed on the EU market after that date must satisfy all essential requirements, bear CE marking, and be supported by complete technical documentation. Products already on the market before this deadline may continue to be made available until the end of their support period, but new versions or substantially modified products must comply.

Impact on Non-EU Companies¶

The CRA applies based on where products are placed on the market, not where manufacturers are located. A U.S., Chinese, or Indian software company selling products to EU customers must comply fully with CRA requirements.

For manufacturers outside the EU, additional requirements apply: - Products must have an authorized representative established in the EU - Importers and distributors have verification obligations - Non-compliant products may be blocked at EU borders

Practically, this means: - Global software vendors must incorporate CRA compliance into development practices - Products may require EU-specific versions or compliance documentation - Smaller companies may face market access barriers if unable to meet requirements - Cloud providers must carefully structure offerings to distinguish SaaS (NIS2) from products with digital elements (CRA)

The extraterritorial effect creates what some term the "Brussels effect"—EU regulation effectively sets global standards because compliance for the EU market is simpler than maintaining separate practices for different markets.

Foundation and Project Preparation¶

Open source foundations have actively prepared for CRA implementation. The Eclipse Foundation, Apache Software Foundation, Linux Foundation, and others have developed guidance for their communities, including through the Open Regulatory Compliance Working Group.

For foundations and open source stewards: 1. Document your steward status clearly in governance documents 2. Establish or enhance cybersecurity policies for vulnerability handling 3. Create or formalize vulnerability reporting channels (security@, SECURITY.md) 4. Implement vulnerability tracking and disclosure processes 5. Prepare to cooperate with market surveillance authorities 6. Educate project maintainers about their (limited) role under the CRA

For individual maintainers of non-commercial projects: 1. Understand that the CRA likely does not apply to your volunteer activities 2. Document the non-commercial nature of your project 3. Consider joining a foundation that serves as an open source steward 4. Maintain clear contribution agreements to prevent confusion about commercial status 5. Be prepared for increased requests from commercial users regarding SBOM data and vulnerability information

For commercial entities using open source: 1. Inventory all open source components in your products 2. Implement SBOM generation for comprehensive dependency tracking 3. Establish vulnerability monitoring for all incorporated components 4. Develop capability to patch or replace components when upstream support is unavailable 5. Budget for security contributions to critical dependencies 6. Consider contributing to foundation stewardship programs 7. Prepare conformity assessment documentation and procedures 8. Establish ENISA notification capabilities before September 2026

The CRA represents a fundamental shift in how the EU regulates software security. Organizations that begin preparation now will be positioned for compliance; those that delay risk market access disruption as deadlines approach.

Related EU Regulation: Digital Operational Resilience Act (DORA)¶

Organizations in the financial services sector should note that the Digital Operational Resilience Act (DORA), Regulation (EU) 2022/2554, became applicable on January 17, 2025. While the CRA addresses products with digital elements broadly, DORA establishes ICT risk management requirements specifically for financial entities operating in the EU—and has significant supply chain security implications.

DORA's Supply Chain Requirements:

DORA's Chapter V establishes comprehensive requirements for managing ICT third-party risk:

• Third-party risk management framework: Financial entities must adopt and regularly review a strategy on ICT third-party risk, including policies on use of ICT services, risk assessment processes, and exit strategies

• Contractual requirements: Contracts with ICT service providers must include specific provisions covering security measures, audit rights, data location, business continuity, and termination assistance

• Register of ICT third-party providers: Financial entities must maintain and regularly update a register of all contractual arrangements with ICT third-party service providers

• Pre-engagement due diligence: Prior to entering arrangements, entities must identify and assess all relevant risks, including concentration risk

Concentration Risk—Unique to DORA:

DORA explicitly addresses concentration risk in ICT third-party services—the danger of overreliance on any single provider or small group of providers. Article 29 requires financial entities to:

• Take into account the degree of substitutability of ICT third-party service providers
• Assess the number of arrangements with the same provider or related providers
• Consider whether critical functions are appropriately distributed across providers

This concentration risk requirement extends supply chain thinking beyond individual vendor assessment to portfolio-level dependency analysis.

Critical ICT Third-Party Providers:

The European Supervisory Authorities (ESAs) may designate certain ICT third-party service providers as "critical" based on their systemic importance to the financial sector. Designated critical providers face:

• Direct oversight by a Lead Overseer (one of the ESAs)
• Mandatory compliance with technical standards
• Powers of inspection and enforcement by EU authorities
• Requirements to demonstrate adequate security controls

Major cloud providers, financial software vendors, and core infrastructure providers may receive critical designation, creating direct EU regulatory obligations for these organizations.

DORA and CRA Interaction:

For software products used by financial entities, both regulations may apply:

• The CRA governs the product's cybersecurity requirements when placed on the EU market
• DORA governs how the financial entity manages risk from that product as an ICT third-party service

Organizations selling to EU financial sector customers should prepare for both sets of requirements, recognizing that DORA may impose additional contractual and audit obligations beyond CRA compliance.