2025
The EU Cyber Resilience Act (CRA), entering into force in 2024 with key provisions applying from 2025-2027, fundamentally changed the security obligations for connected products sold in the European Union. Where previous cybersecurity regulation focused on how organizations protect their systems, the CRA imposed security requirements on the products themselves—mandating that hardware and software products with digital elements be designed, developed, and maintained securely throughout their lifecycle. For manufacturers, software vendors, and distributors touching the EU market, the CRA is a product compliance requirement that rivals GDPR in scope.
For product security officers, CTOs, and compliance teams at organizations selling connected products in Europe, understanding the CRA's requirements and implementation timeline is urgent. The phased applicability means some requirements are already in effect; full compliance requirements apply from 2027. Organizations that haven't begun CRA compliance programs are behind schedule.
The Connected Product Security Gap
The regulatory motivation for the CRA was clear and well-documented: connected products—IoT devices, industrial control equipment, consumer electronics, business software—had been reaching the market with inadequate security, creating systemic vulnerabilities that attackers exploited at scale. The Mirai botnet's 2016 exploitation of IoT devices, subsequent IoT-enabled DDoS attacks, and the proliferation of known-vulnerability software created by manufacturers that didn't patch their products provided the evidence base for regulatory action.
The market failure was structural: product security costs are borne by manufacturers, while the costs of insecure products are borne by users and society. Manufacturers had insufficient incentive to invest in security; users often lacked the information and capability to assess product security before purchase. The market was not self-correcting toward security—it was self-correcting toward cost and features.
Prior cybersecurity regulations in the EU addressed specific sectors—financial services, energy, healthcare, critical infrastructure—but did not establish horizontal security requirements for products. The result was variable security quality across the product landscape, with security-sensitive sectors requiring certifications that the broader market did not demand. The CRA addresses this gap by applying baseline security requirements to all connected products sold in the EU, regardless of sector.
CRA Core Requirements
The CRA organizes its requirements around four key categories. Security by design mandates: products must be designed and developed with security integrated throughout, not added as an afterthought. Specific technical requirements include no known exploitable vulnerabilities at delivery, secure default configurations, access control protections, minimizing attack surfaces, and protection of data in storage and transit.
Vulnerability management obligations require manufacturers to monitor for and address vulnerabilities in their products throughout the support lifecycle—typically five years for products not specified otherwise. Security updates must be free of charge and delivered separately from functionality updates. Manufacturers must establish vulnerability disclosure policies and handle reports through defined processes.
Transparency requirements include software bill of materials (SBOM) documentation, identifying the software components in products—a requirement that enables users and organizations to assess whether products contain components with known vulnerabilities. The SBOM requirement extends to embedded firmware and software dependencies that product users historically had no visibility into.
Market surveillance and conformity assessment requirements ensure that products meet CRA standards before EU market placement. The conformity assessment path depends on product risk classification: most products can self-declare conformity; critical products require third-party assessment. Notified bodies will evaluate products in the critical categories.
Immediate Impact: Product Development and Supply Chain Changes
CRA compliance requirements have driven significant product development changes:
- Secure development lifecycle (SDL) adoption accelerated: manufacturers building CRA compliance into development processes as a systematic requirement
- SBOM generation capability became a development infrastructure requirement, not an optional transparency measure
- Vulnerability management programs were established by manufacturers who previously shipped products without post-sale security support
- Component security evaluation intensified: manufacturers assessed the security status of third-party components and open-source dependencies in their products
- Product support lifecycle commitments became explicit: manufacturers that previously offered indefinite support without commitment now defined explicit security support periods
Lessons Learned: Security Debt Is a Product Liability
The CRA's most significant mindset change for product manufacturers is the reframing of security debt as product liability. Software with unpatched known vulnerabilities, hardware with default credentials, products lacking update mechanisms—these are no longer acceptable within EU market norms; they are CRA violations with enforcement consequences.
The SBOM requirement has particular implications for manufacturers using open-source components. Open-source software dependencies with known CVEs become CRA compliance issues when incorporated in EU-market products. Organizations that had accumulated large open-source dependency portfolios without systematic security review are finding CRA compliance a forcing function for open-source security management.
Evolution: CRA and Global Product Security Standards
The CRA is influencing product security requirements globally. The UK's Product Security and Telecommunications Infrastructure (PSTI) Act, the US IoT Cybersecurity Improvement Act, and similar legislation in other markets are creating a convergent regulatory environment where baseline product security is becoming a market access requirement in most major economies.
Manufacturers serving global markets face the choice of building CRA-compliant products globally (the most efficient approach) or maintaining different security standards for different markets (rapidly becoming operationally unsustainable). Most sophisticated manufacturers are taking the global approach.
The Outpace Approach: Cyber Resilience Act Compliance
Outpace Professional Services works with manufacturers and software vendors on CRA compliance programs that go beyond documentation to build genuine product security capability. Our assessments evaluate current product development practices against CRA requirements, identify gaps in vulnerability management programs, and design remediation roadmaps that achieve compliance efficiently.
For software products, we assess SBOM generation capability, vulnerability monitoring infrastructure, and update delivery mechanisms. For hardware products, we evaluate secure default configuration practices, firmware update capability, and supply chain security. The combination of cybersecurity expertise and compliance knowledge enables compliance programs that satisfy regulatory requirements rather than just creating compliance documentation.
The Compliance Window
CRA's critical compliance milestones are approaching: the vulnerability reporting obligations applied from September 2026, and full product security requirements apply from December 2027. Organizations that begin compliance programs now are building toward manageable milestones. Those that wait are compressing their remediation window and accepting higher compliance risk for products already in the EU market.
💡 Ready for a Cyber Resilience Act compliance assessment? Outpace Professional Services evaluates your product security practices against CRA requirements, identifies compliance gaps, and designs efficient remediation programs—building the product security capability that EU market access requires.
