Table of Contents
- 1.What the Cyber Resilience Act regulates — and why it hits pure software too
- 2.The timeline: which deadline bites when
- 3.The 24/72/14 cascade: what exactly must be reported
- 4.What must go into the SDLC now: six concrete building blocks
- 5.CRA alongside NIS2, DORA and the AI Act: the regulatory matrix
- 6.Penalties and the next 90 days
What the Cyber Resilience Act regulates — and why it hits pure software too
The Cyber Resilience Act (Regulation (EU) 2024/2847) is the first EU-wide law to impose binding cybersecurity requirements on "products with digital elements" across their entire lifecycle. Unlike NIS2, which regulates operators of essential and important entities, the CRA targets manufacturers themselves: anyone who places hardware or software with a direct or indirect data connection on the EU market must in future demonstrate that the product was developed "secure by design", is supplied with security updates, and is maintained over a defined support period. The regulation entered into force on 10 December 2024 (see https://eur-lex.europa.eu/eli/reg/2024/2847/oj).
The crucial point for delivery organisations is the broad scope: the CRA explicitly covers pure software too — operating systems, libraries, applications, firmware. The European Commission makes clear that any product with digital elements made commercially available on the market falls within scope, unless it is already covered by sector-specific rules (medical devices, motor vehicles, aviation) (see https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act). Pure software-as-a-service offerings are in principle excluded — but the software artefacts that are shipped or embedded are not.
The CRA thereby shifts a basic assumption of product development: cybersecurity is no longer a downstream quality attribute but a regulatory market-entry condition with CE marking. For engineering leads this means that security requirements, vulnerability handling and update capability become mandatory parts of the Definition of Done — verifiable, documented and auditable.
The CRA turns cybersecurity into a CE-marked product property. For software manufacturers that means security-by-design, vulnerability handling and a defined support period are no longer optional — they are a condition of market access.
The timeline: which deadline bites when
The CRA becomes applicable in stages, and that staggering is the most common planning trap. Three dates matter for delivery roadmaps: from 11 June 2026 the rules on notification of conformity assessment bodies apply. From 11 September 2026 the reporting obligations for actively exploited vulnerabilities and severe incidents bite. And from 11 December 2027 the CRA applies in full — including all essential requirements and the CE-marking obligation (see https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act).
The order is counterintuitive: the operationally most demanding duty — the time-bound reporting of incidents to the authorities — applies fifteen months before full applicability. Anyone who waits until December 2027 to engage with the CRA will already have been in breach of the reporting duty for over a year. Organisations already know this pattern — a brought-forward reporting duty ahead of substantive full application — from NIS2 and DORA; the CRA repeats it.
For planning this implies a clear priority: the reporting process must be in place before 11 September 2026, regardless of whether the full conformity documentation is finished. The essential technical requirements from Annex I have more runway with December 2027, but must not be left until then, because security-by-design properties cannot be retrofitted into products that have already shipped.
| Date | Obligation | What delivery teams need by then |
|---|---|---|
| 11 June 2026 | Notification of conformity assessment bodies | Clarify whether the product is "important" (Annex III) or "critical" (Annex IV) and which conformity route applies |
| 11 September 2026 | Reporting duties (Art. 14): 24h / 72h / 14 days | A working incident- and vulnerability-reporting process to CSIRT + ENISA, including roles, escalation and templates |
| 11 December 2027 | Full applicability, CE marking | Annex I requirements met, technical documentation, SBOM, update mechanism, documented support period |
The 24/72/14 cascade: what exactly must be reported
The core of the duty applicable from September 2026 is a three-stage reporting cascade under Article 14 of the regulation. It triggers on two events: an actively exploited vulnerability in the product and a severe security incident affecting the product's security. In both cases the same deadline logic applies (see https://eur-lex.europa.eu/eli/reg/2024/2847/oj).
Stage one is the early warning: within 24 hours of the manufacturer becoming aware, a first notification must be made — brief, but without delay. Stage two is the actual notification within 72 hours, with the available details on nature, impact and corrective measures taken. Stage three is the final report: for vulnerabilities within 14 days of a corrective or mitigating measure becoming available, for severe incidents within one month of the 72-hour notification.
The addressee is not a single authority but the CSIRT designated as coordinator of the member state together with the EU Agency for Cybersecurity ENISA, handled technically via a single reporting platform that ENISA provides (see https://www.hoganlovells.com/en/publications/eu-cyber-resilience-act-getting-ready-for-cra-compliance-in-2026). For delivery organisations the 24-hour early warning is the sharpest lever: it is only achievable if detection, the "is this reportable?" decision and the notification itself are defined and rehearsed in advance as a process. A ticket workflow improvised only when it matters will fail this deadline.
The three reporting stages at a glance
Early warning (24 hours from awareness): first notification of the actively exploited vulnerability or severe incident. Incident notification (72 hours): substantive report with assessment, impact and initial countermeasures. Final report (14 days for vulnerabilities once a fix is available / 1 month for incidents): root-cause analysis, measures taken, lessons learned.
In practice this means: the organisation needs clear ownership (who decides on the notification?), a 24/7-reachable escalation chain and prepared reporting templates. The clock starts at awareness — not at internal confirmation, not at the fix.
What must go into the SDLC now: six concrete building blocks
The CRA cannot be discharged through a one-off compliance project, because its requirements run across the entire lifecycle. Six building blocks belong in the delivery pipeline, not in a separate compliance folder.
First, a Software Bill of Materials (SBOM): the CRA requires manufacturers to know and document the components contained in their products. A machine-readable SBOM (CycloneDX or SPDX) produced from the build is the basis for answering, within hours of a newly disclosed vulnerability, whether your own product is affected. Second, a coordinated vulnerability-disclosure process with a public point of contact and a security policy. Third, an update mechanism that delivers security updates promptly and ideally automatically.
Fourth, the technical documentation and conformity evidence needed for CE marking from December 2027 — these artefacts are cheapest to produce continuously, not in a final sprint. Fifth, the defined support period: the CRA expects manufacturers to set and communicate a period during which they provide security updates; the European Commission cites five years as guidance, unless the expected use is shorter (see https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act). Sixth, the rehearsed reporting process for the 24/72/14 cascade as part of the incident runbook.
The common denominator of these six blocks: they are all automatable and belong in the CI/CD pipeline. An organisation that treats SBOM generation, dependency scanning and update delivery as pipeline stages satisfies the CRA substance as a by-product of good engineering practice — rather than carrying it as a regulatory special burden.
CRA alongside NIS2, DORA and the AI Act: the regulatory matrix
The most common mistake in practice is to view the CRA in isolation. In fact it overlaps with the other major EU frameworks at precisely the points where delivery governance already operates. NIS2 regulates the operators of important and critical entities and their reporting duties to the BSI; the CRA regulates the products those operators use. An organisation that both manufactures software and operates critical services falls under both — with two parallel but distinct reporting routes (BSI for NIS2 incidents, CSIRT/ENISA for CRA product incidents).
DORA in turn requires financial entities to manage their ICT third-party providers strictly, including a register of information — and CRA-conformant products become a verifiable quality attribute in exactly that third-party management. The AI Act finally applies where the product with digital elements is an AI system; for high-risk AI the cybersecurity requirements of the AI Act point to the CRA level. The BSI situates the CRA within this overall context of European cybersecurity legislation (see https://www.bsi.bund.de/dok/cyber-resilience-act).
For governance practice this implies a more efficient strategy than four separate compliance silos: a shared vulnerability- and incident-management process that treats the different deadlines and addressees as variants of the same workflow covers CRA, NIS2 and DORA with one mechanism. Building a separate runbook for each regulation, by contrast, produces friction and gaps at the interfaces — and it is precisely those interfaces where the 24-hour deadline tears in a real emergency.
CRA, NIS2, DORA and the AI Act are not four projects but four views of the same core: know your vulnerabilities, detect incidents, report on time, act demonstrably. Building that as one process saves effort and closes the dangerous interface gaps.
Penalties and the next 90 days
The CRA comes with tangible penalties: breaches of the essential cybersecurity requirements can attract fines of up to 15 million euro or 2.5 percent of worldwide annual turnover, whichever is higher (see https://eur-lex.europa.eu/eli/reg/2024/2847/oj). That raises the CRA to an enforcement level comparable to the GDPR and makes it a board-level topic, not merely an engineering task.
For the next 90 days a sober three-step approach is advisable. First: take stock — which of your products fall under the CRA at all, and are any of them "important" or "critical" per Annex III and IV? Second: build and rehearse the reporting process for the 24/72/14 cascade first, because its deadline bites first, in September 2026. Third: introduce SBOM generation and dependency scanning as pipeline stages, so the question "are we affected?" can be answered in minutes rather than days at the next critical vulnerability.
The CRA rewards organisations that already run their security work as a continuous pipeline component, and penalises those that treat security as a downstream audit. It is therefore less a new burden than a regulatory occasion to catch up on engineering discipline that was overdue anyway.
Key Takeaways
- The Cyber Resilience Act (Regulation (EU) 2024/2847) regulates manufacturers of products with digital elements — including pure software — and makes cybersecurity a CE-marked product property.
- The reporting duties bite as early as 11 September 2026, fifteen months before full applicability on 11 December 2027 — anyone waiting until 2027 will have been in breach of the reporting duty for over a year.
- The Article 14 reporting cascade has three stages: 24-hour early warning, 72-hour notification, 14-day final report — to the coordinating CSIRT and ENISA via a single platform.
- Six building blocks belong in the SDLC: SBOM, coordinated vulnerability disclosure, update mechanism, technical documentation, a defined support period and a rehearsed reporting process.
- CRA, NIS2, DORA and the AI Act overlap — a shared vulnerability- and incident-management process covers all four with one mechanism instead of four separate compliance silos.
- Fines of up to 15 million euro or 2.5% of worldwide annual turnover make the CRA a board-level topic.
Related Assessment Templates
Frequently Asked Questions
Yes. The CRA covers "products with digital elements", and the European Commission makes clear that this explicitly includes pure software — operating systems, libraries, applications and firmware — provided they are made commercially available on the EU market. Excluded are, among others, pure software-as-a-service offerings as well as products already covered by sector-specific legislation (medical devices, motor vehicles, aviation). Non-commercial open-source software is in principle out of scope, whereas commercially distributed open-source products are in scope.
The reporting duties for actively exploited vulnerabilities and severe security incidents under Article 14 apply from 11 September 2026. That is significantly earlier than the full applicability of the regulation on 11 December 2027. A third date, 11 June 2026, concerns the notification of conformity assessment bodies. The staggered applicability is the most common planning trap: the operationally most demanding duty — time-bound reporting — applies first.
It describes the three-stage reporting cascade: within 24 hours of becoming aware an early warning must be submitted, within 72 hours the actual incident or vulnerability notification with the available details, and a final report follows for vulnerabilities within 14 days of a remedy becoming available, or for severe incidents within one month. The deadlines start at the moment of becoming aware, not at internal confirmation or the fix — which is why the process must be defined and rehearsed in advance.
Not primarily the BSI. CRA notifications go to the CSIRT designated as coordinator of the relevant member state together with the EU Agency for Cybersecurity ENISA, technically via a single reporting platform that ENISA provides. That is a different route from NIS2, where incidents in Germany go to the BSI. Organisations that both manufacture products and operate critical services must therefore serve both routes in parallel — a key reason to build incident management as one process with several output variants.
NIS2 regulates the operators of important and critical entities, the CRA the products those operators use. DORA requires financial entities to manage ICT third-party providers strictly, where CRA conformity becomes a verifiable quality attribute. The AI Act applies where the product is an AI system and points to the CRA security level for high-risk AI. The frameworks overlap at the points where delivery governance already operates: know your vulnerabilities, detect incidents, report on time. A shared mechanism is more efficient and safer than four separate silos.
For breaches of the essential cybersecurity requirements the CRA provides for fines of up to 15 million euro or 2.5 percent of worldwide annual turnover, whichever is higher. Other breaches carry lower but still substantial caps. This level of sanction is comparable to the GDPR and makes the CRA a topic for executive management, not just engineering. The market surveillance authorities of the member states enforce the regulation.