Part: One
A quiet deadline is approaching. On 11 September 2026, the first major deadline under one of the most consequential pieces of software regulation in modern history arrives β and most companies that will be affected don’t know it yet.
The European Union’s Cyber Resilience Act (CRA) is a horizontal, binding legal framework that applies to essentially every hardware and software product with digital elements sold on the EU market. It’s not a niche directive for critical infrastructure. It covers the smart watch on your wrist, the app on your phone, the software inside your car, and the platform you build on.
It is also the clearest statement yet that “secure by design” is no longer a best practice β it’s becoming the law. The Act itself rolled out in stages: it entered into force in December 2024, its first obligations apply from September 2026, and its full requirements follow in December 2027. To be precise about what lands when, we’ve linked the authoritative sources straight into this article β because with a regulation this consequential, you should be able to check our work.
This article is the first of two. Here, we lay out what the CRA actually is, what it requires, and the two deadlines that matter. In the second, we’ll look at the strategic opportunity hiding inside it β and why the smartest builders are already ahead.
What the CRA is β and why it exists
Officially, the CRA is Regulation (EU) 2024/2847. Per the European Commission, it entered into force on 10 December 2024.
Its purpose is straightforward: for decades, digital products have been built to work first and hardened later. Vulnerabilities are patched reactively β after a breach, after an exploit, after the damage is done. The CRA flips that assumption.
Under the new rules, manufacturers must meet mandatory cybersecurity requirements at every stage of the value chain β planning, design, development, and ongoing maintenance. They must handle vulnerabilities across the entire lifecycle of their products. And for products of particular cybersecurity relevance, a third-party assessment by a notified body may be required before they can be sold in the EU.
Compliant products carry the CE marking, and national market-surveillance authorities will enforce the rules.
The CRA doesn’t stand alone. It builds on the EU’s 2020 Cybersecurity Strategy and, as the Commission notes, complements the NIS2 Directive β together forming a coherent European approach to cybersecurity.
The two deadlines that matter
The CRA is rolling out in two distinct waves, and they create two very different kinds of pressure.
Wave one β 11 September 2026: the reporting duty that never rests
The Commission’s reporting obligations page confirms that, from 11 September 2026, manufacturers must report actively exploited vulnerabilities and severe security incidents affecting their products.
The clock doesn’t start when you’re ready. It starts the moment you become aware, on these exact timeframes:
- An early warning must be filed within 24 hours.
- A full notification within 72 hours.
- A final report follows β within 14 days for a vulnerability, or within one month for a severe incident.
These figures are stated directly by the Commission in its official guidance on reporting obligations.
Two details catch people out.
First, this duty reaches your entire installed base. Even products placed on the market before the law applied are in scope for reporting. If a vulnerability in something you shipped years ago is actively exploited and you become aware of it on or after 11 September 2026, you report it β whether or not the product was ever modified.
Second, this is an always-on obligation, not a one-time checklist. It attaches to your whole team, around the clock, for as long as your products are out there.
Wave two β 11 December 2027: security becomes a design requirement
The larger wave arrives on 11 December 2027. From this date, the CRA’s full product requirements apply: security by design and by default, baked in across the entire lifecycle, with CE marking as proof of compliance. The Commission’s own guidance frames it plainly: principal obligations from 11 December 2027, with reporting obligations already applying from 11 September 2026.
This is the moment “vulnerability handling” stops being a nice-to-have and becomes a legal, auditable requirement of making and selling a product at all.
What counts as “a product with digital elements”
The scope is deliberately broad. It includes final products and components placed separately on the market. If it has a chip, a connection, or a line of code, and it reaches EU consumers, it’s likely in scope.
Two clarifications worth knowing, from the Commission’s practical guidance, published in July 2026:
- Remote data processing solutions and free and open-source software received explicit attention on scope.
- The guidance also clarifies what counts as a “substantial modification” (which can pull older products into the full requirements), how support periods should be understood, and how to meet reporting and risk-assessment obligations.
The guidance is deliberately SME-friendly β per the Commission, it includes 67 practical examples, use cases, flowcharts, and graphs, so smaller companies can find a proportionate path to compliance without unnecessary administrative burden.
The open-source angle most people miss
There’s a lesser-known clause worth flagging: the CRA reaches open-source software stewards too. If you maintain a widely used library or project that’s part of a product with digital elements, your obligations around actively exploited vulnerabilities are real.
This matters beyond any single project. It means the open-source ecosystem β the shared foundation most modern software is built on β is now part of the EU’s formal security framework. Strong vulnerability handling is no longer optional for major open-source projects; it’s becoming a structural expectation.
What to do now (if you ship to the EU)
Readiness is operational, not paperwork. The reporting obligation goes live in weeks, so the practical checklist is:
- Build a vulnerability-reporting runbook. Who detects, who drafts, who files, who covers the night shift.
- Name a primary and a backup representative. EU Login accounts can be created today.
- Know your CSIRT β the computer security incident response team that is your point of contact (based on your main establishment in the EU, or your authorised representative’s if you’re outside the EU).
- Keep an accurate software bill of materials (SBOM). You can’t report a vulnerability in a component you didn’t know you shipped.
- Monitor continuously. Match your components against known-vulnerability sources so an actively exploited flaw surfaces in hours, not weeks.
The reporting platform itself β ENISA’s Single Reporting Platform (SRP) β is scheduled to be operational by 11 September 2026. (Independent reporting on the SRP, such as this CRA walkthrough, notes that ENISA has indicated no application programming interface will be provided at this stage, making the human side of readiness β named people, backups, out-of-hours coverage β genuinely important.)
The bottom line
The CRA is a statement about the future: software security is becoming a floor you must stand on, not a feature you can skip.
For companies selling into Europe, the September deadline is real and imminent. For everyone else, the December 2027 wave is the structural shift that will reshape how digital products are designed, built, and maintained.
Either way, the direction is clear. And as we’ll explore in the second article, the builders who internalize this early aren’t just avoiding a burden β they’re building an advantage.
This article is informational and does not constitute legal advice. The CRA is evolving; timelines and guidance may be updated by the European Commission and ENISA. Information reflects the position as of August 2026.
Sources (primary)
- European Commission β Cyber Resilience Act policy page
- European Commission β CRA reporting obligations
- European Commission β practical guidance, July 2026
- European Commission β CRA implementation FAQ
- ENISA β Single Reporting Platform
- Regulation (EU) 2024/2847 (EUR-Lex)
- Independent reference (SRP reporting detail): cyberresilienceact.eu β reporting walkthrough