EU Cyber Resilience Act for Software Makers

The Cyber Resilience Act (CRA) turns software security into a product safety requirement in the European Union. Any product with digital elements, whether a desktop application, a mobile app, a router, a smart device or a software library sold commercially, must meet essential cybersecurity requirements before it can carry CE marking and be sold in the EU. Manufacturers must also handle vulnerabilities for years after release, deliver security updates and report actively exploited vulnerabilities to authorities.

The CRA has been in force since December 2024. Its reporting obligations began on 11 September 2026, and most other obligations apply from 11 December 2027. This guide explains who is a manufacturer, which products are covered and which are not (including the position of SaaS and open source), the essential requirements, conformity assessment, reporting, penalties, and the engineering work software companies should start now.

What is the Cyber Resilience Act?

The CRA is Regulation (EU) 2024/2847. It sets horizontal cybersecurity requirements for products with digital elements: software or hardware products and their remote data processing solutions, including software or hardware components placed on the market separately. It follows the EU's New Legislative Framework for product safety: essential requirements, conformity assessment, a declaration of conformity, CE marking and market surveillance.

Key roles:

Manufacturer: develops or manufactures a product, or has it designed or manufactured, and markets it under its own name or trademark. Most obligations fall here.
Importer and distributor: must check that manufacturers have met their obligations.
Open-source software steward: a legal person, other than a manufacturer, that systematically supports the development of free and open-source software intended for commercial activities, with a lighter set of duties.

History and why the CRA was introduced

EU product safety law historically focused on physical safety. Software vulnerabilities, unpatched devices and insecure defaults were causing widespread harm, from botnets of compromised devices to supply chain attacks through software updates, yet there was no general legal duty for manufacturers to secure their products or support them with updates. The Commission proposed the CRA in September 2022. It was adopted in October 2024, published in November 2024 and entered into force on 10 December 2024, with obligations phased in to give manufacturers time to adapt.

Its aims are to reduce vulnerabilities in products, ensure manufacturers take security seriously across the life cycle, and help users choose and use products securely.

Timeline

Date	What applies
10 December 2024	Entry into force
11 June 2026	Provisions on notification of conformity assessment bodies
11 September 2026	Manufacturers' reporting obligations for actively exploited vulnerabilities and severe incidents (Article 14), for all products on the EU market including those placed before December 2027
11 December 2027	All other obligations, including essential requirements, conformity assessment and CE marking

Which products are covered?

In scope

Products with digital elements whose intended or reasonably foreseeable use includes a direct or indirect logical or physical data connection to a device or network. That includes most commercial software (desktop, mobile, embedded, firmware, libraries sold commercially) and connected hardware.

Out of scope or covered by other law

Products covered by specific EU legislation with equivalent cybersecurity rules, such as medical devices, in vitro diagnostics, motor vehicles and civil aviation, and marine equipment.
Products developed exclusively for national security or defence.
Pure SaaS is generally not a product with digital elements; it falls under NIS2 where applicable. However, a remote data processing solution without which a product cannot perform one of its functions (for example the cloud backend of a smart device or a mobile app) is covered as part of that product.
Free and open-source software that is not supplied in the course of a commercial activity is excluded. Commercial activity can include monetising the software itself or associated services; the Commission's guidance helps draw the line.

Product categories

Default products (the large majority): manufacturers can self-assess conformity.
Important products, class I (Annex III), such as identity management systems, browsers, password managers, VPNs, network management systems, operating systems, routers and some smart home products: self-assessment is allowed if harmonised standards or certification schemes are fully applied; otherwise third-party assessment.
Important products, class II, such as hypervisors, firewalls and intrusion detection systems and tamper-resistant microprocessors: third-party conformity assessment.
Critical products (Annex IV), such as hardware devices with security boxes, smart meter gateways and smart cards: may require European cybersecurity certification.

Essential requirements (Annex I)

Part I: product properties

Products must be designed, developed and produced to ensure an appropriate level of cybersecurity based on risk. Among other things, they must:

Be made available without known exploitable vulnerabilities.
Have a secure-by-default configuration, with the ability to reset to the original state.
Ensure vulnerabilities can be addressed through security updates, including automatic updates by default where appropriate, with an opt-out.
Protect against unauthorised access through authentication, identity or access management, and report possible unauthorised access.
Protect the confidentiality of stored, transmitted or processed data, for example by encryption.
Protect the integrity of data, commands, programs and configuration.
Process only data that is adequate, relevant and limited to what is necessary (data minimisation).
Protect the availability of essential functions, including resilience against denial-of-service.
Minimise negative impact on other devices or networks, and limit attack surfaces.
Reduce the impact of incidents through exploitation mitigation mechanisms.
Record and monitor relevant internal activity, with an opt-out for users.
Allow users to securely and easily remove all data and settings.

Part II: vulnerability handling

Manufacturers must, for the support period:

Identify and document vulnerabilities and components, including by drawing up a software bill of materials in a commonly used, machine-readable format covering at least top-level dependencies.
Address and remediate vulnerabilities without delay, including by providing security updates, separately from functionality updates where technically feasible.
Apply effective and regular tests and reviews of security.
Publicly disclose information about fixed vulnerabilities once a security update is available.
Have and enforce a coordinated vulnerability disclosure policy, and a contact address for reporting vulnerabilities.
Share information about potential vulnerabilities in third-party components with the relevant maintainers.
Distribute updates securely, and disseminate them without delay and, for security updates, free of charge, with advisory messages.

Support period

Manufacturers must determine a support period reflecting how long the product is expected to be in use, at least five years unless the product's expected use time is shorter, and state it clearly at the time of purchase.

Reporting obligations (Article 14)

Since 11 September 2026, manufacturers must notify, through the Single Reporting Platform that ENISA launched on 11 September 2026, both the CSIRT designated as coordinator and ENISA of:

Actively exploited vulnerabilities in their products: an early warning within 24 hours of becoming aware, a vulnerability notification within 72 hours, and a final report within 14 days after a corrective or mitigating measure is available.
Severe incidents having an impact on the security of their products: an early warning within 24 hours, an incident notification within 72 hours, and a final report within one month after the incident notification.

Manufacturers must also inform affected users of the vulnerability or incident and of mitigation measures. These obligations apply to all products on the EU market, including those placed on the market before December 2027.

Conformity assessment and documentation

Before placing a product on the market (from December 2027), the manufacturer must carry out a cybersecurity risk assessment, draw up technical documentation (Annex VII), perform the applicable conformity assessment procedure, draw up an EU declaration of conformity and affix CE marking. Technical documentation and the declaration must be kept for at least ten years or the support period, whichever is longer. Products must come with information and instructions for users (Annex II), including the support period, the vulnerability contact point and how to install updates.

How to prepare, step by step

Inventory your products and decide which are products with digital elements on the EU market, and their category.
Set up vulnerability reporting now: a process to detect actively exploited vulnerabilities and severe incidents, an owner who can report within 24 hours, and access to the reporting platform.
Publish a coordinated vulnerability disclosure policy and a security contact.
Generate SBOMs for every release and monitor components for vulnerabilities.
Adopt a secure development life cycle, using frameworks such as the NIST SSDF and OWASP SAMM.
Review defaults: no default passwords, minimal open services, secure configuration out of the box.
Build secure update delivery: signed updates, automatic security updates where appropriate, separate security patches.
Define support periods and plan resources to honour them.
Prepare technical documentation and risk assessments; track harmonised standards as they are published.
Plan conformity assessment, including a notified body if your product is important class II or critical.

Penalties

Member states set penalties within maximums: up to 15 million euros or 2.5 percent of worldwide annual turnover, whichever is higher, for non-compliance with essential requirements and key manufacturer obligations; up to 10 million euros or 2 percent for other obligations; and up to 5 million euros or 1 percent for supplying incorrect, incomplete or misleading information. Market surveillance authorities can require corrective action or withdrawal and recall of products.

Timeline and cost considerations

Reporting obligations already apply, so the first priority is a working detection and reporting process. Full compliance by December 2027 requires changes to development, testing, documentation and support practices. Costs include SBOM and vulnerability management tooling, security testing, secure update infrastructure, documentation, longer support commitments, and notified body fees for some products.

Benefits and consequences

Compliance preserves access to the EU market, and the practices required (secure defaults, SBOMs, coordinated disclosure, timely patches) reduce incidents and support costs over time. Non-compliance risks fines, product withdrawal and reputational damage, and buyers are starting to ask suppliers about CRA readiness.

Common mistakes and challenges for IT companies

Assuming non-EU manufacturers are exempt. Placing products on the EU market brings them in scope.
Assuming everything cloud-based is out of scope. Remote data processing solutions integral to a product are covered.
Waiting for 2027. Reporting has applied since September 2026.
No SBOM or dependency monitoring.
Bundling security fixes with feature updates so users delay patches.
Short or undefined support periods.

Best practices, tools and technologies

Generate SBOMs in SPDX or CycloneDX in the build pipeline and store them per release; see our SBOM guide.
Monitor dependencies against vulnerability databases and known exploited vulnerability lists.
Sign releases and updates and protect build pipelines, following SLSA.
Test against the OWASP Top 10 and ASVS for web components.
Publish a security.txt file and a disclosure policy.
Keep a release register linking versions, SBOMs, vulnerabilities and fixes.

We build secure update pipelines, SBOM generation and hardened defaults into products through our custom software development work.

How the CRA relates to other frameworks

Framework	Relationship
NIS2	Covers entities and services (including SaaS providers in scope); the CRA covers products.
SBOM	The CRA makes an SBOM part of vulnerability handling and technical documentation.
NIST SSDF and OWASP SAMM	Secure development frameworks that help meet the essential requirements.
EU AI Act	High-risk AI systems that meet CRA requirements can be presumed to meet related AI Act cybersecurity requirements.
SLSA	Build integrity practices that support secure update requirements.

Real-world implementation examples

The European Commission published non-binding guidance on applying the CRA in July 2026, and national cybersecurity centres such as Ireland's published guidance ahead of the September 2026 reporting date. Open-source foundations have created steward programmes and documentation to help projects and commercial users understand their roles.

An illustrative case for a company selling a desktop and mobile app with a cloud backend in the EU: the app and its backend are a product with digital elements. The company sets up a 24-hour vulnerability reporting rota, publishes a disclosure policy, adds SBOM generation and dependency alerts to its pipeline, separates security patches from feature releases, commits to a five-year support period, and starts its technical documentation file ahead of December 2027.

Next steps

Confirm which of your products are in scope and their category.
Make sure 24-hour reporting works today.
Publish a vulnerability disclosure policy and security contact.
Generate SBOMs and monitor dependencies.
Plan secure-by-default changes, update delivery and documentation for December 2027.

Frequently asked questions

When does the Cyber Resilience Act apply?

It entered into force on 10 December 2024. Reporting obligations apply from 11 September 2026 and most other obligations from 11 December 2027.

Does the CRA apply to SaaS?

Pure SaaS is generally outside the CRA and may fall under NIS2. A remote data processing solution that a product needs to perform its functions is covered as part of that product.

Does the CRA apply to open-source software?

Free and open-source software not supplied in the course of a commercial activity is excluded. Commercial use and open-source software stewards have specific rules.

Does the CRA apply to companies outside the EU?

Yes. It applies to products placed on the EU market, wherever the manufacturer is based.

What must be reported under the CRA?

Actively exploited vulnerabilities and severe incidents affecting product security, with an early warning within 24 hours, a notification within 72 hours and a final report.

Does the CRA require an SBOM?

Yes. Manufacturers must draw up an SBOM in a commonly used machine-readable format covering at least top-level dependencies, as part of vulnerability handling and technical documentation.

How long must security updates be provided?

For a support period reflecting the expected use time of the product, at least five years unless the product is expected to be used for less.

Do all products need a notified body?

No. Most products can be self-assessed. Important class II products, and class I products where standards are not fully applied, need third-party assessment, and critical products may need certification.

What are the CRA fines?

Up to 15 million euros or 2.5 percent of worldwide turnover for essential requirement breaches, with lower maximums for other obligations.

Does the CRA require CE marking for software?

Yes, from December 2027, products with digital elements that conform must carry CE marking, which for software can be applied in accompanying documentation or on the website.