EU Cyber Resilience Act: Secure Software Development Is No Longer Optional
The security community has known for years what good software development should look like: security is built in from the start, not patched on at the end. Dependencies must be tracked and updated. Vulnerabilities need to be disclosed and fixed promptly. Products should ship with secure defaults, not configurations that "make things easier" by leaving them open.
The problem has always been time and money. Security got pushed back. The EU Cyber Resilience Act changes that. From October 2027, these principles become a legal obligation for manufacturers of a large portion of software and hardware products sold in the EU.
What Is the Cyber Resilience Act
The Cyber Resilience Act (CRA) is EU Regulation 2024/2847. It sets binding cybersecurity requirements for products with digital elements placed on the EU market — covering both hardware and software.
The regulation entered into force on 10 October 2024. It is built on a straightforward premise: manufacturers bear responsibility for the security of their products throughout their supported lifetime, not only at the point of sale. And they cannot transfer that responsibility to customers through license agreement exclusions (EULAs).
CRA is not a revolution without precedent. Most of what it requires, the security community has been telling the industry for years. The law simply makes it enforceable.
Who Does the CRA Apply To
Here is the thing that catches companies off guard: CRA is not limited to IoT device manufacturers or industrial hardware makers. It applies to any product with digital elements that meets two conditions. First, it is placed on the EU market as part of a commercial transaction, whether paid or provided free as part of another commercial offering. Second, it includes software or firmware capable of communicating with a network or other device.
In practice this covers mobile applications distributed as part of a product, desktop software, IoT firmware, industrial control systems, network equipment (routers, switches, firewalls), connected medical devices, and smart home systems, among others.
Pure SaaS models are excluded from CRA scope, because they are services rather than products. If your SaaS offering includes client software installed on a user's device — an agent, a desktop app, an SDK, a plugin — that client software is typically within scope.
Open source software developed in a non-commercial context is exempt from CRA. Commercial distribution or commercial support of an open source project is generally in scope.
CRA categorises products by risk level. The default category covers most products and allows the manufacturer to conduct a self-assessment of conformity. The important product categories (Class I and Class II) cover products with higher inherent risk: VPNs, firewalls, identity management systems, network equipment, and operating systems. These face stricter requirements, including third-party assessment or conformance with harmonised standards.
What the CRA Actually Requires
Security by Design and Secure Default Configuration
Products must be designed to minimise their attack surface and operate on the principle of least privilege. Security features must be enabled in the default configuration, not offered as an optional add-on. Cryptographic mechanisms must reflect the current state of the art.
In practice, this means that security questions must be answered in the design phase, not during a security review scheduled two weeks before release.
Software Bill of Materials (SBOM)
The CRA requires manufacturers to maintain and be able to provide a complete inventory of their software product's components — a Software Bill of Materials. The SBOM is a machine-readable document capturing all dependencies, libraries, and their versions that make up the product.
An SBOM is not a paper exercise for auditors. It enables rapid identification of whether your product contains a newly-discovered vulnerable component, and how quickly you can remediate it. The Log4Shell incident in 2021 affected countless organisations in part because they simply did not know where they were using that library. An SBOM solves that problem systematically.
The regulation does not require public disclosure of the SBOM. It requires that it exists, is kept current, and is available to market surveillance authorities on request.
Vulnerability Management Throughout the Product Lifecycle
Manufacturers must have a defined and operational process for receiving and handling reported vulnerabilities. Security patches must be issued free of charge and without undue delay throughout the supported lifetime of the product. Manufacturers define their own support period, but must actually honour it and communicate it transparently to users.
In practice this means: a public vulnerability disclosure policy (VDP), an internal triage process, an SLA for issuing patches, and continuous monitoring of vulnerabilities in used components.
Incident and Vulnerability Reporting
From July 2026, strict reporting timelines apply. A manufacturer must notify the relevant national CSIRT and ENISA of any actively exploited vulnerability in their product, or of any severe security incident affecting product security.
Phase | Deadline | Content |
|---|---|---|
Early warning | 24 hours from awareness | Notification that the incident or vulnerability exists |
Notification | 72 hours from awareness | More detail including severity and impact |
Final report | 14 days from awareness | Complete analysis and actions taken |
These timelines are very short. Without pre-established processes and a clearly defined internal escalation chain, meeting them is nearly impossible.
Why CRA Effectively Mandates DevSecOps
The requirements above are not isolated checkboxes. Together, they describe exactly what the security community has been calling DevSecOps: integrating security throughout the development lifecycle rather than running a one-time test at the end of the project.
Secure defaults and secure-by-design require threat modelling in the early design phase. SBOM requires continuous dependency management and automation (Software Composition Analysis). Vulnerability management requires a functional CI/CD pipeline with security controls, ongoing testing, and an operational VDP. The 24-hour reporting obligation requires well-configured monitoring, alerting, and escalation processes.
Companies that have been implementing DevSecOps practices because they make sense now have a strong business case to present to leadership: the investment doubles as CRA compliance. Companies that have been ignoring these practices must start. The alternative is fines and a ban from the EU market.
Deadlines You Cannot Miss
Date | What Happens |
|---|---|
10 Oct 2024 | CRA enters into force |
11 Jul 2026 | Vulnerability and incident reporting obligations apply (Articles 14 and 15) |
11 Oct 2026 | Obligations for notified conformity assessment bodies apply |
11 Oct 2027 | Full CRA compliance required — all other provisions |
October 2027 may appear distant. It is not. Restructuring development processes, establishing SBOM generation, setting up VDPs, and preparing for regulatory reporting takes months, not weeks.
Penalties for Non-Compliance
Violations of the CRA carry:
Fines of up to €15 million or 2.5% of global annual turnover (whichever is higher) for the most serious violations, such as placing non-compliant products on the market.
Fines of up to €10 million or 2% of turnover for less severe violations.
Fines of up to €5 million or 1% of turnover for providing incorrect or incomplete information to authorities.
Beyond financial penalties, a supervisory authority can order the withdrawal or prohibition of a product from the EU market. For companies whose primary market is the EU, that is an existential threat.
What to Do Now: A Practical Starting Point
Determine whether CRA applies to you. It is not enough to ask whether you sell software. The right question is: do you place on the EU market a product (not a purely SaaS service with no client component) that communicates with a network or other device? If yes, CRA most likely applies to you.
Inventory your dependencies. Start building or formalising SBOMs for your products. Tools like Syft, cdxgen, and formats like SPDX and CycloneDX are industry standard, and many CI/CD platforms can generate them automatically as part of the pipeline.
Set up or review your vulnerability disclosure process. Do you have a channel through which researchers and customers can report vulnerabilities? Is there an internal triage process? Do you know who is specifically responsible for notifying the relevant CSIRT within 24 hours of discovering an incident?
Audit your SDLC through a CRA lens. Where in your development process do security controls occur? If the answer is a one-time penetration test before release, that is not sufficient. CRA assumes continuous security attention throughout the entire product lifecycle.
Identify which category your product falls into. Different categories carry different conformity assessment requirements. Products such as VPNs, firewalls, identity management systems, and operating systems fall into categories with stricter third-party assessment requirements.
Start now, not in 2027. October 2027 looks far off, but implementing processes, training teams, auditing code, standing up tooling, and obtaining potential certification takes time. Companies that begin in 2025 or 2026 will make the transition comfortably. Companies that begin in September 2027 will not.
CRA and NIS2: How They Relate
CRA is an EU regulation and applies directly across all member states without transposition into national law. It sits alongside the NIS2 Directive and the national cybersecurity laws that implement it, such as Germany's BSIG or Czechia's ZKB (Zákon o kybernetické bezpečnosti). These regulations target different groups: CRA applies to product manufacturers, NIS2 applies to operators of essential and important services.
If your organisation falls under both regulations, there is a practical upside: investment in security architecture, SBOM processes, and vulnerability management counts toward both. You do not have to build those capabilities twice.
CRA is the law that acknowledges what the security community has known for years: secure software does not happen by accident. It is built deliberately, from the start, with the right tools, processes, and discipline. Now that principle is legally enforceable.
If you are unsure whether CRA applies to your organisation, or want to understand what specifically needs to change in your development process, we are happy to help.
We help companies assess their CRA scope, implement secure SDLC practices, build DevSecOps capabilities, and prepare vulnerability management and reporting processes. The initial consultation is free. We respond within 24 hours.
Last updated: 16 June 2026.
Sources: EU Regulation 2024/2847 (Cyber Resilience Act) · ENISA — Cyber Resilience Act · European Commission — Cyber Resilience