Cyber Resilience Act

The Cyber Resilience Act (CRA) is about to change the way digital products are designed, built, and maintained across Europe. For the first time, the European Union is legally requiring that any product with a digital component must meet strict cybersecurity standards throughout its entire lifecycle.

This isn’t just another regulation. It marks a fundamental shift in responsibility, moving cybersecurity from the user to the manufacturer, and turning “secure-by-design” from a best practice into a legal obligation. Suppose your company develops, distributes, or integrates digital products for the EU market. In that case, the Cyber Resilience Act will directly impact your development processes, vendor selections, open-source usage, and risk exposure over the coming years.

What Is the Cyber Resilience Act?

The Cyber Resilience Act is an EU regulation designed to ensure that all “products with digital elements” placed on the EU market meet baseline cybersecurity requirements throughout their lifecycle.

In plain language, it forces manufacturers and software vendors to:

Build products securely from the start
Maintain them securely with updates and patches
Be transparent about vulnerabilities and components
Take responsibility when things go wrong

Key goals of the CRA

The Cyber Resilience Act aims to:

Reduce the number of insecure consumer and industrial devices on the market
Make vendors more accountable for vulnerabilities and poor design
Improve transparency around software components and supply chains
Protect consumers, businesses, and critical infrastructure from cyberattacks

It is not just about “compliance paperwork.” It’s about shifting cybersecurity responsibilities upstream, from end users to the manufacturers and providers who design and ship the products.

When Does the Cyber Resilience Act Apply?

The CRA is already in force as an EU regulation, but its main obligations apply after a transition period to give organisations time to adapt.

Typical timeline (high-level):

Now-2026: Awareness, preparation, and alignment with secure-by-design practices
2026-2027: Implementation of vulnerability handling, SBOM, and documentation processes
From late 2027: Most obligations become fully applicable; non-compliance can trigger enforcement and fines

Which Products Fall Under the Cyber Resilience Act?

The CRA applies to “products with digital elements” placed on the EU market. That includes:

Hardware devices with embedded software, such as:
- IoT devices and smart home products
- Industrial sensors and controllers
- Consumer electronics and appliances
Standalone software products, such as:
- Desktop or mobile applications
- Security software
- Networking software
Software that connects to a network, directly or indirectly, as an expected use case
Products that rely on cloud or remote services as part of normal operation

Who Has Obligations Under the CRA?

The CRA doesn’t just target one actor. It spreads responsibility across the product supply chain:

Manufacturers – The primary obligated party. They design, develop, and place the product on the market.
Importers – Companies introducing products from third countries into the EU market.
Distributors – Resellers and retailers who make products available to EU customers.
Software publishers – Vendors of software products with digital elements, whether standalone or embedded.

Each role has specific duties, but the manufacturer (or product owner) generally carries the heaviest burden: ensuring the product meets cybersecurity requirements, maintaining it securely, and providing the necessary technical documentation.

If you’re a non-EU company selling into the EU, you’re still in scope. The CRA focuses on where the product is placed on the market, not where your headquarters are.

Core Requirements of the Cyber Resilience Act

To understand what the Cyber Resilience Act actually demands, it’s useful to group the obligations into a few main areas.

1. Security by Design and by Default

Products must be designed and developed with cybersecurity in mind. That means:

Performing cybersecurity risk assessments during design
Minimising attack surface (removing unnecessary services and features)
Using secure default configurations (no default passwords, no open debug ports, etc.)
Applying secure coding practices and regular testing

Security must be present by default. Users should not have to be security experts to configure the product safely.

2. Secure Lifecycle and Updates

The CRA requires that manufacturers:

Support products with security updates for their expected lifespan
Clearly define how long updates will be provided
Deliver patches in a timely manner, especially for critical vulnerabilities
Provide update mechanisms that are reliable and, where appropriate, automatic or highly user-friendly

Feature updates and security updates should be clearly distinguished. Users should not have to accept risky new features just to get a critical security patch.

3. Vulnerability Management and Incident Reporting

Manufacturers must establish a vulnerability handling process, including:

A clear channel for receiving vulnerability reports from researchers, customers, and partners
Internal processes for triaging, prioritising, and remediating vulnerabilities
Coordinated disclosure practices, including communication with customers
Reporting actively exploited vulnerabilities and serious incidents to the relevant authorities within defined timeframes

This pushes organisations to move from “ad-hoc patching” to a structured vulnerability management programme.

4. Transparency and Software Bill of Materials (SBOM)

To improve supply-chain security, the CRA emphasises transparency about product components:

Manufacturers should understand and document which software and libraries are included in their products, including open-source components.
A Software Bill of Materials (SBOM) is expected to become a standard deliverable, listing dependencies and versions.
Customers and authorities may require access to SBOMs to assess risk and exposure when vulnerabilities are discovered.

Without this visibility, it’s almost impossible to react quickly when a widely used library is found to be vulnerable.

5. Technical Documentation and CE Marking

To place a product on the EU market, manufacturers must:

Prepare and maintain technical documentation, including:
- Cybersecurity risk assessment and mitigation measures
- Architecture and security controls
- Update and support policies
- Vulnerability management procedures
- Component and dependency information
Conduct a conformity assessment (sometimes involving an external body, especially for critical products)
Affix the CE mark, indicating that the product meets CRA cybersecurity requirements

This documentation must be maintained and provided to authorities on request.

6. Penalties for Non-Compliance

The Cyber Resilience Act introduces significant enforcement powers, including:

Fines proportional to the organisation’s global turnover (up to a capped percentage)
Orders to bring products into compliance
Product recalls or withdrawals from the EU market
Public notices that can damage brand trust

The message is clear: ignoring CRA obligations can become expensive, both financially and reputationally.

Turning CRA Compliance into a Strategic Advantage

The Cyber Resilience Act changes the rules of the game for digital products in Europe. It pushes security from an afterthought to a core design and business requirement, and it forces organisations to confront the reality of their software supply chains, especially their reliance on open-source components.

For manufacturers, software vendors, and platform providers, this is both a challenge and an opportunity:

A challenge, because compliance requires investment in processes, tooling, and culture.
An opportunity, because companies that embrace secure-by-design principles will ship better products, build more trust, and reduce the long-term cost of cyber incidents and emergency patching.