The Cyber Resilience Act (CRA) is a new EU regulation designed to strengthen security standards for European products with digital elements. With mandatory requirements for design, development, maintenance, and lifecycle management, the CRA aims to make secure products easier to identify.
Although the regulation entered into force in December 2024, it won’t be fully applicable until 11 December 2027. So what should organizations be preparing for? Andrea Barisani, Principal Consultant and head of Reversec’s Hardware Security team, breaks down the implications.
Why the Cyber Resilience Act matters
The Cyber Resilience Act is a significant development in the EU’s cybersecurity regulation. It brings into scope any product with digital elements that can directly or indirectly connect to other devices or networks, reinforcing the idea that anything digital must be secure.
Like any regulation, some parts of the CRA leave room for interpretation and may be implemented with varying levels of quality. Other parts are more specific, such as the requirement to support vulnerability handling for at least five years.
The CRA should be approached in the same way as security standards or regulations like NIS2 or PCI DSS. It forces organizations to document their processes, take action, and align those actions with a broader standard.
The CRA provides helpful structure, but structure alone doesn’t guarantee security. A device can meet every compliance requirement and still have blind spots. Likewise, something that falls short on paper could still be well protected. This is why technical expertise and compliance knowledge should go hand in hand.
What it demands
At the heart of the Cyber Resilience Act is an obligation to release products without known exploitable vulnerabilities that might impact security. This requirement is supported by assessing cybersecurity risks and applying suitable harmonized standards, common specifications, or recognized standards.
The CRA’s requirements for regular updates, vulnerability fixes, a clear reporting policy and public disclosure are essential for transparency and accountability. If a vulnerability is discovered, there must be a public framework for reporting it.
“These are all things that I would expect companies to have even without the regulation,” Andrea Barisani says. “The regulation captures fairly well what we expect a manufacturer to have and to provide for their clients.”
Covered and excluded products
The CRA applies to any product with digital elements (PDEs). That includes any product that can interface with a network or other software, with a few exceptions such as medical devices, cars and aviation, which are already covered by existing rules. Open-source software is also exempt, but only in a narrow sense. If a developer integrates an open-source library into a product, they are still responsible for its security.
CE marking as a signal of compliance
Many products in the European Economic Area carry the CE marking to signal high health, safety and environmental standards. Manufacturers, importers and distributors follow CE requirements to enable unrestricted trade in the EEA and provide a consistent level of protection for consumers. Under the CRA, the CE marking will also indicate cybersecurity compliance. This extension will add new weight to an already pervasive label.
Implementation
The CRA requires manufacturers to address cybersecurity throughout the entire product lifecycle — from planning and production to maintenance. Risks must be documented and any exploited vulnerabilities or incidents reported. Manufacturers are also expected to provide clear and understandable instructions for their products.
“My washing machine is digitally connected. But companies making washing machines don’t necessarily have a strong background in pushing updates.”
Vulnerability handling
Companies must effectively support vulnerability handling for no less than five years, unless the lifetime of the product is less than five years, in which case the support period should cover that lifetime. If the product is reasonably expected to be in use for longer than five years, manufacturers should ensure longer support periods. This is a major change that places more responsibility on the manufacturers of digitally enabled products.
Security by design
Many of the CRA’s requirements can be effectively met through security by design, not by adding them later. The regulation explicitly mentions that products must be designed and developed in accordance with the requirements of the CRA. Andrea predicts that all manufacturers will eventually realize that implementing protections early is the most cost-effective approach.
Third-party accountability
Understanding what goes into a product has always been a challenge, but the CRA makes it an obligation. This is a welcome change, as security gaps often stem from a lack of visibility. Companies may include hardware, software, or firmware that isn’t directly under their control, overlooking its security implications.
Most products include code that isn’t owned by the developer. Even internal ecosystems are complex, with many teams and moving parts. The CRA forces orchestration of all these elements and holds manufacturers accountable for the final product’s security, regardless of its components.
Many suppliers will also be subject to the CRA, creating a waterfall effect that improves security outcomes for sub-components of end-user products. These suppliers will have a responsibility to manage their own security and communicate vulnerabilities, which will increase accountability throughout the supply chain.
Update requirements
Some products are better suited for remote updates than others. The ability to update a product exposes it to a larger attack surface, meaning that a poorly added mechanism can create new vulnerabilities. Updates are essential for security, but they must be handled with great care. The task requires significant effort and infrastructure, which makes this one of the most challenging aspects of CRA implementation.
“My washing machine has Wi-Fi — it’s digitally connected. That means this product is probably going to fall under regulation. But companies making washing machines don’t necessarily have a strong background in pushing updates.”
For effective implementation, the mechanism should be engineered into the product from day one. Good security consulting can offer valuable input during testing and early design, so that updating can be integrated more organically and at a lower cost.
“I don’t think that from January 1st, 2028, we’ll suddenly have everyone caught up and the ones who didn’t will be fined immediately.”
Industry readiness
The CRA will come into full effect in December 2027, but Andrea expects a slow start to EU-wide compliance. “I don’t think that from January 1st, 2028, we’ll suddenly have everyone caught up and the ones who didn’t will be fined immediately.”
Security isn’t binary, so meeting the requirements won’t necessarily guarantee strong protection. Features like update mechanisms or user authentication can be implemented in many ways, with varying levels of robustness. The industry should gradually move from checkbox compliance to meaningful adoption.
Given the complexity of today’s product ecosystems, it’s hard to say whether manufacturers are ahead or behind on CRA compliance. Some are well-positioned because they’ve been applying security principles for years. The landscape resembles what we’ve seen with NIS2: highly fragmented.
Andrea has worked with some clients for over two decades. For them, CRA compliance is largely a matter of making sure existing practices are documented in a way that aligns with the regulation’s structure. Other clients will need pinpointed advice to close specific gaps.
For companies starting from scratch, reaching CRA compliance within a few years can feel daunting, but it makes financial sense. The cost of overlooking the requirements will only increase from here.
Commercial impact as a driver of security
Regardless of the regulation’s specifics, the underlying challenges remain the same. The hope is that stronger incentives will drive better practices, raise awareness and improve outcomes, lifting the overall maturity level of the products we rely on.
Security also carries commercial weight. If a product is successful and widely used, companies become more sensitive to security risks, knowing that any failure could have business consequences. Successful products tend to mature in security, setting a market expectation.
Consumers are more informed now than they were two decades ago, and security can influence buying decisions. This logic applies to purely digital products as well. However, newer players often overlook these aspects while focusing on getting their product to market.
Strategic implications
The CRA can be seen as a catalyst for improving supply chain security. Many of its requirements directly affect how supply chains are managed, calling for intermediate checks and tighter oversight to maintain integrity. Over time, companies may find better ways to reuse components rather than reinventing the wheel. Supply chain security principles could even inspire cross-company collaboration or funding and sponsoring of open-source projects that become critical to the security of the final product.
Will it spur innovation?
Whether the CRA stifles or stimulates innovation is a matter of perspective. There’s plenty of room for innovation in how CRA requirements are fulfilled, especially when aiming to do it effectively, reliably and in a way that can be repeated. At the same time, regulations can cause stagnation, as some companies may hesitate to develop products if they’re unsure how to meet the requirements. But the CRA itself doesn’t inherently pose a risk to innovation.
Impact on open source
Non-commercial open-source software is exempt from the CRA, simply because it’s not feasible to impose requirements on it. Regardless of this, the CRA requirements still apply to products containing exempted code. This could lead to more investment in securing crucial open-source software.
Manufacturers who choose to incorporate third-party code are responsible for ensuring that the final product adheres to their own standards. Trusting an open-source product doesn’t shift that responsibility.
Small vs. big teams
The CRA has been criticized for potentially favoring larger companies, as smaller businesses and solo developers may struggle to comply when redistributing open-source software. However, size doesn’t always mean better security.
Smaller companies struggle with security, and larger ones often do too. Their scale can make them less agile, which creates additional challenges for security. A well-engineered product can be very secure regardless of the size of the team responsible for it. What matters is having a team that fits the product’s context and understands good engineering practices.
Impact on security testing
Some of our long-time clients are already heavily aligned with the CRA, having worked with us to implement security frameworks like ISO/IEC 62443. Others are engaging with Reversec for the first time, prompted by the CRA and its new requirements. These organizations are facing a complex journey, but they’re motivated to improve security regardless of regulations. That mindset makes a difference.
The new regulation brings a difference in testing scope. In earlier projects, Andrea’s team might have tested a narrow subcomponent, such as an individual chip essential for maintaining security. The CRA advises companies to build security into every process that touches a product before it’s on the market.
Alignment with security standards
While the CRA does not point to any specific standards, many of the requirements closely align with well-known standards like IEC 62443. This alignment will help to push many manufacturers and developers into established security best practices, and also ease the journey towards future certification, if desired.
Early implementation pays off
Secure design and development make compliance with the CRA easier. The earlier security is integrated into the design process, the more effective and less expensive it becomes. In development calls with clients, a simple suggestion at the early stage has prevented months of complex fixes, future problems, and saved hundreds of thousands of euros. Sometimes that’s all it takes: one design choice at the beginning.
Start preparing for the Cyber Resilience Act now
Companies with a solid security posture will find CRA compliance relatively straightforward. Those struggling to meet the requirements may benefit from following established frameworks like IEC 62443. The best path forward is to start improving organically. Whether that happens internally or with support from third parties like Reversec depends on the situation.
Our consulting services are designed to help your organization meet CRA requirements and build real security into your products. We can support you in getting ahead of the regulatory implementation date, making sure you’re integrating resilience in your system and meeting compliance requirements.
