EU Cyber Resilience Act (CRA, 2025–2027)

The EU Cyber Resilience Act (CRA, 2025–2027) represents a landmark legislative framework designed to establish mandatory cybersecurity requirements for digital products and software sold within the European Union. This regulation aims to protect consumers and businesses from inadequately secured products by requiring manufacturers to embed security throughout the entire product lifecycle. For DevSecOps leaders, security directors, and development teams at enterprise and mid-size organizations, the EU Cyber Resilience Act introduces binding obligations that will fundamentally change how software products are developed, deployed, and maintained.

The regulation creates a unified cybersecurity baseline for products with digital elements, addressing a critical gap in existing legislation. While previous directives covered specific sectors or product types, the CRA takes a horizontal approach, applying to virtually all hardware and software products unless explicitly exempted. This means organizations developing or distributing products in European markets—regardless of where they're headquartered—need to prepare for significant changes to their software development lifecycle and security practices.

What is the EU Cyber Resilience Act

The EU Cyber Resilience Act is a comprehensive regulatory framework that establishes cybersecurity requirements for manufacturers, importers, and distributors of products with digital elements. The regulation was formally proposed in September 2022 and is expected to enter into force between 2025 and 2027, with implementation timelines varying based on product classification and organizational readiness.

At its core, the CRA requires economic operators to design, develop, and produce products with security built in from the ground up. This "security by design" approach mandates that products are delivered without known exploitable vulnerabilities and that manufacturers maintain security throughout the expected product lifetime. The regulation applies to both hardware products with digital components and pure software products, including operating systems, browsers, password managers, security software, and even embedded firmware.

The scope is remarkably broad. Products covered include consumer electronics, smart home devices, network equipment, and virtually any software application distributed commercially. Open-source software receives special treatment under the CRA, with monetized or commercially supported versions falling under regulatory requirements while purely non-commercial projects receiving certain exemptions. This distinction has generated considerable discussion within the developer community about what constitutes commercial support.

Definition of Products with Digital Elements

The CRA introduces the concept of "products with digital elements" as its primary scope definition. This term encompasses any software or hardware product, including its remote data processing solutions, where the manufacturer intended the product to be placed on the market as a commercial item. The definition deliberately captures products regardless of whether they connect to networks or process data locally.

Products with digital elements include both directly purchased items and those provided as part of a service. This means software-as-a-service platforms, cloud-based applications, and embedded systems all potentially fall within scope. The regulatory text specifically addresses situations where software is distributed alongside hardware, treating the combined product as a single unit for compliance purposes.

Certain categories receive explicit exemptions from CRA requirements. Medical devices, automotive systems, and aviation components covered by existing sector-specific legislation remain outside the CRA's direct application. National security systems and products developed exclusively for internal use within an organization also fall outside the scope. These exemptions recognize that specialized regulatory frameworks already address security requirements in those domains.

Classification Framework for Products

The CRA establishes a risk-based classification system that determines the depth of compliance obligations. Products are divided into three main categories: default class, important products (Class I), and critical products (Class II). This tiered approach recognizes that not all digital products present equal risk to users or infrastructure.

Default class products represent the majority of consumer-facing digital items with limited criticality. These products must meet baseline security requirements but don't undergo third-party conformity assessment before market placement. Manufacturers can self-assess compliance for these products, though they remain liable for meeting all technical requirements and maintaining proper documentation.

Class I products include identity management systems, network management tools, browsers, password managers, and certain security software. These products perform functions considered important for security but aren't categorized as critical infrastructure components. Class I products may require more rigorous testing and documentation than default class items, though the specific requirements are still being finalized in the regulatory text.

Class II products represent the highest risk category and include operating systems, industrial firewalls, hardware security modules, smart meters, and microprocessors with security functions. These critical products must undergo third-party conformity assessment by notified bodies before they can be placed on the EU market. The conformity assessment process verifies that products meet all technical requirements and that manufacturers have implemented appropriate security processes throughout development.

Explanation of Essential Cybersecurity Requirements

The CRA establishes two sets of essential requirements: those relating to the properties of products with digital elements, and those relating to the vulnerability handling processes that manufacturers must implement. These requirements form the technical foundation of the regulation and directly impact how development teams structure their security practices.

Products must be designed, developed, and produced in a manner that ensures appropriate levels of cybersecurity based on the risks they present. This includes being delivered without known exploitable vulnerabilities, employing a secure-by-default configuration, and protecting the confidentiality, integrity, and availability of data processed or transmitted. The requirements explicitly mandate that products minimize their attack surface and that security functions operate properly even when under attack.

Manufacturers must ensure products can be securely updated throughout their expected lifetime. This means implementing mechanisms for automatic security updates where appropriate, or at minimum, notifying users about available security patches and the risks of not applying them. The update mechanism itself must be secured against tampering or interception, and updates must be delivered in a timely manner following vulnerability disclosure.

Vulnerability Handling Requirements

The CRA requires manufacturers to establish documented vulnerability handling processes that cover the entire product lifecycle. These processes must include mechanisms for receiving reports of vulnerabilities from external researchers, security professionals, and users. Organizations need to establish clear channels for vulnerability disclosure and acknowledge receipt of reports within defined timeframes.

Once vulnerabilities are identified, manufacturers must assess their severity and take appropriate remedial action. For exploitable vulnerabilities, this typically means developing and distributing patches or workarounds within deadlines proportionate to the severity level. Critical vulnerabilities affecting Class II products demand particularly rapid response times to minimize exposure windows.

Manufacturers must maintain a software bill of materials (SBOM) for their products, documenting all components including third-party and open-source dependencies. This requirement addresses supply chain security concerns by creating transparency about what code is actually present in products. The SBOM enables both manufacturers and users to quickly identify whether products are affected by newly disclosed vulnerabilities in components.

Vulnerability information must be shared with relevant stakeholders according to coordinated disclosure practices. This includes notifying the European Union Agency for Cybersecurity (ENISA) and the designated national cybersecurity authorities about actively exploited vulnerabilities or severe security incidents. The reporting requirements align with broader European cybersecurity incident reporting frameworks.

Documentation and Transparency Obligations

The CRA mandates comprehensive technical documentation that demonstrates compliance with all essential requirements. This documentation must describe the product's security architecture, risk assessments performed during development, security testing results, and the vulnerability management process. For Class II products, this documentation forms the basis of third-party conformity assessment.

Manufacturers must provide users with clear, accessible information about the product's security properties and how to use it securely. This includes disclosing the expected support period during which security updates will be provided, instructions for secure configuration and deployment, and contact information for reporting vulnerabilities. The disclosure requirements aim to enable informed purchasing decisions based on security considerations.

The regulation requires that products bear CE marking indicating CRA compliance, accompanied by a simplified EU declaration of conformity. This marking represents the manufacturer's attestation that the product meets all applicable requirements. Affixing CE marking without genuine compliance constitutes a violation subject to enforcement action.

How to Prepare for CRA Compliance

Preparing for EU Cyber Resilience Act compliance requires systematic changes across the software development lifecycle. Organizations can't simply bolt security onto existing processes; the CRA demands security integration from initial design through end-of-life support. For teams accustomed to traditional development approaches, this represents a significant shift in methodology and resource allocation.

The starting point involves conducting a comprehensive product inventory to identify which products fall under CRA scope and their appropriate classification. This assessment should consider not just current products but also those in development pipelines. Understanding classification early determines the depth of compliance requirements and whether third-party conformity assessment will be necessary.

Development teams need to adopt security-by-design principles throughout their processes. This means performing threat modeling during the design phase, implementing secure coding practices, and conducting security testing as part of regular development workflows. The reactive approach of addressing security only when vulnerabilities are discovered doesn't satisfy CRA requirements, which demand proactive security integration.

Implementing Secure Development Practices

The CRA effectively mandates adoption of secure software development frameworks similar to those described in standards like NIST SSDF or ISO 27034. Development teams should implement security requirements gathering as part of initial planning, ensuring that security considerations inform architecture decisions rather than being addressed after the fact.

Code security practices need to become standard rather than exceptional. This includes regular code reviews with security focus, static and dynamic application security testing, and dependency scanning to identify vulnerable components. The DevSecOps approach of integrating security tools into CI/CD pipelines supports the continuous security verification that CRA compliance requires.

Organizations should implement comprehensive testing regimes that include penetration testing, vulnerability scanning, and security-focused quality assurance. Testing should cover not just the application layer but also infrastructure configurations, deployment processes, and update mechanisms. Documentation of testing activities and results forms part of the technical documentation required for compliance demonstration.

Establishing Vulnerability Management Processes

CRA compliance requires formal vulnerability management processes that operate throughout the product lifecycle. Organizations need to establish vulnerability disclosure programs that make it easy for researchers and users to report security issues. These programs should define clear communication channels, expected response timeframes, and coordination practices for public disclosure.

Internal processes must exist for triaging reported vulnerabilities, assessing their severity and exploitability, and prioritizing remediation efforts. The use of standardized vulnerability scoring systems like CVSS helps create consistency in severity assessment. Organizations should define service level objectives for patching based on severity levels, with critical vulnerabilities receiving expedited treatment.

Building and maintaining accurate SBOMs presents technical challenges for many organizations. Teams need tools and processes to automatically track all components used in products, including transitive dependencies that may be multiple levels removed from direct usage. The software supply chain security platform approach helps automate SBOM generation and maintenance as products evolve.

Vulnerability monitoring should extend beyond code that organizations write directly to encompass all dependencies and components. This requires continuous monitoring of security advisories for used libraries, frameworks, and infrastructure components. When vulnerabilities are disclosed in dependencies, organizations need processes to quickly assess impact and deploy updated versions.

Building Compliance Documentation

The documentation requirements under the CRA are substantial and require systematic capture throughout the development process. Attempting to create compliance documentation retroactively proves far more difficult than building it incrementally as products are developed. Teams should integrate documentation activities into their standard workflows rather than treating them as separate overhead.

Risk assessments performed during development should be documented with sufficient detail to demonstrate that security considerations informed design decisions. This includes identifying potential threats, evaluating their likelihood and impact, and documenting mitigation approaches. The risk assessment documentation shows that security was actively considered rather than assumed.

Security testing results need to be documented with evidence of testing scope, methodologies used, findings identified, and remediation actions taken. This documentation demonstrates due diligence in security verification and provides traceability between identified issues and their resolution. Organizations should retain this documentation for the period specified in the regulation, typically extending beyond the product's active support period.

Understanding Enforcement and Penalties

The CRA establishes significant penalties for non-compliance, following the enforcement model used in other major EU regulations like GDPR. Maximum fines can reach 15 million euros or 2.5% of worldwide annual turnover, whichever is higher, for the most serious violations. These penalties apply to manufacturers, authorized representatives, importers, and distributors who fail to meet their respective obligations.

Enforcement occurs primarily through market surveillance authorities in individual member states. These authorities have the power to require organizations to provide documentation demonstrating compliance, to test products for conformity with requirements, and to order recalls or market withdrawals for non-compliant products. The authorities can also restrict or prohibit products from being placed on the market if serious risks are identified.

The regulation establishes different penalty tiers based on violation severity. Supplying incorrect or misleading information to authorities, failing to cooperate with corrective measures, or breaching specific obligations draws penalties up to 10 million euros or 2% of turnover. The most severe penalties apply to placing non-compliant products on the market or failing to take corrective action when required.

Organizations should recognize that enforcement isn't limited to deliberate violations. Negligent failure to implement required processes or inadequate security measures that result from poor practices rather than intentional non-compliance can still trigger enforcement action. The burden falls on manufacturers to demonstrate they've taken appropriate measures to achieve compliance.

Market Surveillance and Cooperation

Market surveillance authorities across member states coordinate their activities through established cooperation frameworks. This means that enforcement action in one member state can have implications across the entire European market. Products found non-compliant in any member state may face restrictions throughout the EU unless compliance is demonstrated.

Authorities have the power to conduct inspections of manufacturer premises, review documentation and technical files, and test products to verify conformity. Organizations must retain technical documentation for at least ten years after the last unit of a product is placed on the market, ensuring authorities can review compliance long after initial product launch.

The regulation also establishes whistleblower protections and encourages reporting of suspected non-compliance. This means competitors, security researchers, or even employees could trigger investigations into an organization's compliance. Maintaining genuine compliance rather than superficial conformity becomes crucial given these multiple potential sources of scrutiny.

Impact on Software Supply Chains

The CRA's requirements extend beyond individual products to affect entire software supply chains. When manufacturers incorporate third-party components into their products, they remain responsible for overall product compliance even if issues originate in components they didn't develop. This creates downstream pressure on component suppliers and open-source projects to meet security expectations.

Organizations sourcing software components need to evaluate suppliers' security practices and verify that components meet requirements comparable to those imposed by the CRA. This means conducting vendor security assessments, reviewing vulnerability handling processes, and potentially requiring contractual commitments regarding security practices. The days of incorporating dependencies without security due diligence are ending for CRA-regulated products.

Open-source components present particular challenges under the CRA framework. While non-commercial open-source projects receive exemptions, determining what constitutes "commercial" support remains somewhat ambiguous. Organizations using open-source components can't simply assume they're exempt; they need to evaluate whether their usage model creates obligations and how they'll address security requirements for incorporated components.

SBOM Requirements and Transparency

The software bill of materials requirement creates unprecedented transparency into product composition. Organizations must track not just direct dependencies but also transitive dependencies that their direct dependencies rely upon. This multi-level visibility presents technical challenges for complex products built from numerous components.

SBOM maintenance requires automation given the dynamic nature of modern software development. Manual tracking proves impractical when dependencies are updated frequently and new components are added regularly. Organizations should implement tools that integrate with their build processes to automatically generate and update SBOMs as products evolve.

The SBOM serves multiple purposes beyond initial compliance documentation. When vulnerabilities are disclosed in widely-used components, an accurate SBOM enables rapid impact assessment across an organization's product portfolio. This capability becomes increasingly valuable as the volume of disclosed vulnerabilities continues growing year over year.

SBOM format standardization remains an evolving area, with formats like SPDX and CycloneDX gaining traction. Organizations should adopt standardized formats that facilitate automated processing and exchange with partners, customers, and authorities. The ability to programmatically analyze SBOMs for known vulnerabilities depends on using machine-readable, standardized formats.

Managing Third-Party Risk

The CRA amplifies the importance of third-party risk management for software supply chains. Organizations need formal processes for evaluating the security posture of component suppliers and open-source projects before incorporating their code. This evaluation should consider the component's security track record, the maintainer's vulnerability response practices, and the availability of security support.

Contractual relationships with commercial suppliers should address CRA-related obligations explicitly. This includes commitments to timely vulnerability disclosure, provision of security updates during the product support period, and cooperation with incident response when vulnerabilities are discovered. Without these contractual provisions, organizations may struggle to meet their own CRA obligations when problems arise in third-party components.

Continuous monitoring of component security becomes mandatory rather than optional. Organizations need processes to track security advisories for all components used in their products and to assess impact when vulnerabilities are disclosed. The continuous security monitoring approach helps automate this surveillance across large component inventories.

Timeline and Implementation Phases

The CRA follows a phased implementation timeline that gives organizations time to adapt their practices before enforcement begins. The regulation enters into force twenty days after publication in the Official Journal of the European Union, but most substantive obligations don't apply immediately. This transition period recognizes the significant changes required for compliance.

Manufacturers have approximately 36 months from the regulation entering into force to achieve full compliance for new products. Products already on the market before the compliance deadline benefit from certain transitional provisions, though ongoing support obligations still apply. Organizations should not wait until the deadline approaches to begin preparation; the scope of required changes demands early action.

The establishment of notified bodies capable of performing conformity assessments for Class II products occurs during the transition period. Organizations developing critical products should engage early with these bodies to understand assessment requirements and timelines. Waiting until just before the compliance deadline may result in assessment capacity constraints as many organizations seek certification simultaneously.

Market surveillance authorities will be ramping up their capabilities during the transition period. This includes developing inspection procedures, testing methodologies, and cross-border cooperation mechanisms. Organizations can expect increasing scrutiny of product security claims even before full enforcement begins, as authorities establish their surveillance programs.

Preparing Before the Deadline

Organizations should begin CRA preparation well before mandatory compliance dates. Starting early allows incremental process improvements rather than disruptive last-minute changes. The transformation to security-by-design development requires cultural shifts that take time to fully embed within engineering organizations.

Early preparation also enables organizations to influence industry standards and best practices as they develop. The CRA references harmonized standards that provide presumption of conformity with essential requirements. Getting involved in standards development efforts allows organizations to shape practical implementation approaches that balance security with development efficiency.

Conducting gap assessments against CRA requirements helps organizations understand their current posture and prioritize improvement efforts. These assessments should evaluate both technical security capabilities and process maturity. Identifying gaps early provides time to address them systematically rather than rushing to achieve superficial compliance.

Strategic Implications for US Organizations

Despite being European legislation, the EU Cyber Resilience Act has significant implications for US-based organizations. Any company that sells products into European markets—directly or through distributors—must comply with CRA requirements for those products. The extraterritorial reach mirrors other EU regulations like GDPR, where jurisdiction extends to foreign organizations serving European customers.

Organizations can't simply partition their product lines into Europe-compliant and non-compliant versions for other markets. The technical and process changes required for CRA compliance typically need to be applied globally rather than maintained as separate tracks. Building and maintaining parallel development processes for different regulatory regimes proves inefficient and error-prone.

The CRA may drive cybersecurity baseline improvements beyond Europe as organizations extend their CRA-compliant practices globally. Just as GDPR influenced privacy practices worldwide, the CRA could elevate security expectations in markets without equivalent regulations. Organizations competing on security may highlight CRA compliance as a differentiator even in non-regulated markets.

US organizations should monitor potential domestic legislative responses to the CRA. While no direct equivalent exists in federal US law currently, the CRA demonstrates a comprehensive approach to product security that may influence future US regulation. Preparing for CRA compliance positions organizations well for whatever domestic requirements may emerge.

Competitive Dynamics and Market Access

CRA compliance creates barrier to entry for European markets, favoring organizations with mature security practices and resources to invest in compliance. Smaller organizations and startups may struggle with the compliance burden relative to larger competitors with established security programs. This dynamic could affect competitive positioning in European markets.

Organizations that achieve compliance early gain timing advantages over slower competitors. Being able to market CRA-compliant products while competitors are still preparing positions early movers favorably. This advantage extends beyond Europe if customers in other markets begin valuing CRA compliance as a security indicator.

The regulation may also affect acquisition strategies and due diligence. Organizations acquiring companies with European market presence need to assess CRA compliance status as part of their evaluation. Products that don't meet CRA requirements may require significant post-acquisition investment or even withdrawal from European markets.

Are you evaluating how the EU Cyber Resilience Act will impact your organization's development practices and market access? Kusari provides comprehensive solutions for software supply chain security, SBOM management, and compliance automation that align with CRA requirements. Schedule a demo to explore how our platform can help your team prepare for the evolving regulatory environment while strengthening your overall security posture.

What Are the Main Requirements of the EU Cyber Resilience Act

The main requirements of the EU Cyber Resilience Act center on security-by-design development, vulnerability management, and transparency obligations for manufacturers of products with digital elements. The EU Cyber Resilience Act requires that products are designed and developed to minimize vulnerabilities, delivered in secure configurations, and supported with security updates throughout their expected lifetime. Manufacturers must establish documented processes for handling vulnerabilities, including mechanisms for receiving reports, assessing severity, and deploying patches within appropriate timeframes. The regulation also mandates maintaining software bills of materials that document all product components, enabling rapid response when vulnerabilities are discovered in dependencies. Products must bear CE marking indicating compliance, supported by technical documentation that demonstrates conformity with all essential requirements. For critical products classified as Class II, third-party conformity assessment by notified bodies is required before market placement, adding an independent verification layer to the compliance process.

How Does the CRA Affect Software Development Organizations

The CRA affects software development organizations by requiring fundamental changes to development methodologies, security practices, and lifecycle management approaches. Software development organizations must integrate security considerations throughout the entire development process rather than treating security as a separate activity performed after functional development. This means conducting threat modeling during design phases, implementing secure coding practices as standard procedure, and performing security testing as part of regular quality assurance. Development teams need to adopt tools and processes for tracking all software components used in products, maintaining accurate SBOMs that document dependencies at all levels. Organizations must establish formal vulnerability management programs that include disclosure mechanisms, severity assessment processes, and patch development workflows with defined response timeframes. The CRA also requires maintaining comprehensive documentation of security activities, risk assessments, and testing results throughout the product lifecycle. For organizations accustomed to rapid release cycles, the documentation and verification requirements may require adjustments to development velocity and resource allocation to ensure compliance without compromising market responsiveness.

When Does the EU Cyber Resilience Act Take Effect

The EU Cyber Resilience Act takes effect through a phased timeline beginning when the regulation is published in the Official Journal of the European Union. The regulation enters into force twenty days after publication, though substantive compliance obligations for manufacturers begin approximately 36 months later. This transition period provides organizations time to adapt their development practices, implement required processes, and bring existing products into compliance. Products placed on the market after the compliance deadline must meet all CRA requirements at the time of market placement. Products already in circulation before the deadline benefit from certain grandfathering provisions, though manufacturers remain obligated to provide security support and handle vulnerabilities for those products during their support period. The establishment of notified bodies capable of performing conformity assessments for critical products occurs during the transition period, with these bodies becoming operational before the general compliance deadline. Market surveillance authorities will be developing their enforcement capabilities throughout the transition, though organizations should expect increasing scrutiny of security practices even before full enforcement begins. Organizations should not wait until the compliance deadline approaches to begin preparation, as the scope of required changes demands substantial lead time for proper implementation.

What Products Are Covered Under the Cyber Resilience Act

Products covered under the Cyber Resilience Act include virtually all hardware and software items with digital elements that are placed on the EU market, unless they fall under specific exemptions. The Cyber Resilience Act applies to consumer electronics, network equipment, security software, operating systems, browsers, password managers, smart home devices, and embedded systems that contain digital components. Both standalone software products and hardware devices with embedded software fall within scope when they're intended for commercial distribution. Software-as-a-service offerings and cloud-based applications are covered when provided commercially, extending the regulation beyond traditional packaged software. Open-source software receives nuanced treatment, with commercially supported or monetized distributions falling under requirements while purely non-commercial projects receiving exemptions. Medical devices, automotive components, and aviation systems covered by existing sector-specific regulations are explicitly excluded from CRA scope to avoid regulatory duplication. Products developed exclusively for internal use within an organization don't fall under CRA requirements, nor do national security systems. The broad scope reflects the regulation's horizontal approach to product security, establishing baseline requirements across diverse product categories rather than limiting applicability to specific sectors or technologies.

Navigating the New Regulatory Reality

The regulatory framework established by the EU Cyber Resilience Act (CRA, 2025–2027) represents a fundamental shift in how organizations approach product security. Rather than voluntary security practices that organizations can adopt or ignore based on their own risk tolerance, the CRA creates mandatory baseline requirements backed by significant enforcement mechanisms. For development teams, security directors, and organizational leaders, this transition demands strategic thinking about how security integrates into development processes, product roadmaps, and business strategies.

Organizations that view CRA compliance purely as a regulatory burden miss the opportunity to build competitive advantages through genuine security improvements. The practices required for compliance—security-by-design development, comprehensive vulnerability management, supply chain transparency—align with what sophisticated customers increasingly demand. Investing in these capabilities positions organizations well beyond mere regulatory compliance, building trust with security-conscious customers and reducing the business risks associated with security incidents.

The timeline for CRA implementation is approaching, and organizations should be treating preparation as a strategic priority rather than deferring action until enforcement deadlines loom. The changes required touch every aspect of the software development lifecycle, from initial architecture decisions through end-of-life support. Attempting to achieve compliance through last-minute efforts will prove far more disruptive and costly than systematic preparation beginning now.

For US-based organizations selling into European markets, the EU Cyber Resilience Act joins a growing set of regulations that demand attention despite being enacted outside domestic jurisdictions. The interconnected nature of modern software markets means that regulatory developments in major markets affect organizations globally. Building compliance capabilities that can adapt to evolving requirements across jurisdictions becomes a strategic necessity for organizations operating internationally.

‍