EU Cyber Resilience Act: What Developers Must Report in 2026

Key Takeaway

• 🛡️ The reporting clock is running: since 11 September 2026, manufacturers of products with digital elements must report actively exploited vulnerabilities and severe security incidents affecting those products under the EU Cyber Resilience Act.
• ⏱️ Three deadlines, once: an early warning within 24 hours of becoming aware, a full notification within 72 hours, and a final report 14 days after a corrective or mitigating measure becomes available for an exploited vulnerability, or one month after the 72-hour notification for an incident — all submitted once, through ENISA’s Single Reporting Platform.
• 🏭 Who owes the duty is specific: the manufacturer placing the covered product on the EU market carries the statutory obligation — developers and contractors usually support that duty rather than hold it themselves.
• 📦 Not every vulnerability is reportable: the Act’s thresholds matter. A vulnerability that is not actively being exploited and does not rise to a severe incident is handled under the product’s normal vulnerability-management process, not the 24-hour notification.
• 📅 The bigger obligations arrive 11 December 2027, when the Act’s main cybersecurity requirements, CE marking, and open-source steward duties take effect.

The European Union’s Cyber Resilience Act entered into law on 10 December 2024, and its vulnerability and incident reporting requirements took effect on September 11, 2026 — one of the regulation’s most consequential phases for anyone selling software into Europe. According to the European Commission’s official reporting-obligations page, manufacturers are now legally required to report actively exploited vulnerabilities and severe security incidents affecting products with digital elements — connected hardware and software sold in the EU, from apps to appliances. This article explains what changed on 11 September 2026, who the obligations actually bind, how the notification deadlines work, and what software businesses should evaluate now before the wider requirements apply on 11 December 2027.

What changed in September 2026

Two developments took effect that day. First, the EU Cyber Resilience Act’s reporting obligations took effect for products already on the market: under Regulation (EU) 2024/2847, manufacturers must notify actively exploited vulnerabilities and severe incidents that have an impact on the security of their products with digital elements. Second, ENISA — the EU agency for cybersecurity — launched the Single Reporting Platform (SRP), the online system those notifications go through, on 11 September 2026. The agency’s launch notice describes the platform’s core promise plainly: a manufacturer reports once, and the information reaches the right authorities across the Member States.

The deadlines are fixed in the Act and restated by the Commission’s reporting page. An early warning goes to the platform within 24 hours of the manufacturer becoming aware that a vulnerability is being actively exploited, or that a severe incident is having an impact on the product’s security. A full notification follows within 72 hours, with the technical detail the early warning does not carry. The final report comes later, and its start point depends on the trigger: for an actively exploited vulnerability, no later than 14 days after a corrective or mitigating measure becomes available; for a severe incident, within one month after the submission of the 72-hour notification. Each deadline starts from a specific event: awareness for the early warning and the notification, the availability of a corrective or mitigating measure for the vulnerability final report, and the 72-hour submission for the incident final report. None is a calendar date, which is why the thresholds and the documentation around each case matter.

The mechanics are coordinated rather than duplicated. The notification is addressed to the computer security incident response team (CSIRT) in the Member State where the manufacturer has its main establishment, made available simultaneously to ENISA, and shared by that CSIRT with the other Member States where the product is sold. A manufacturer with customers in eight EU countries does not file eight EU Cyber Resilience Act reports; the sharing between CSIRTs does that work.

For companies without an establishment in the Union — the situation of most Philippine software companies serving EU customers — Article 14(7) of the EU Cyber Resilience Act sets a fallback order for where that filing goes. The CSIRT of the Member State where the manufacturer has its main establishment handles the default case, with the main establishment meaning the Member State where the decisions related to the cybersecurity of the products are predominantly taken; if that cannot be determined, it is the establishment with the highest number of employees in the Union. Without any Union establishment, the notification goes through the CSIRT of the Member State where the manufacturer’s authorised representative is established, or — in that order — where its importer, its distributor, or the largest group of its users sits. A Philippine company with no EU office therefore files through whichever of those anchors applies to it, and subsequent notifications for the same product may go to the same CSIRT that first received a filing. A delegated act adopted on 11 December 2025 sets out the exceptional grounds on which a CSIRT can delay that sharing — for example, where dissemination itself would help an attacker.

Who actually has the reporting duty

The EU Cyber Resilience Act places the statutory obligation on the manufacturer: the entity that develops or manufactures a covered product, or has it designed and manufactured, and markets it under its own name or trademark. It binds the company whose name is on the product and whose EU market placement carries the legal responsibility. Importers and distributors do not carry the reporting duty by default, but two things qualify that. First, they hold real duties of their own: importers must verify a product is compliant before placing it on the market and inform the manufacturer without undue delay upon becoming aware of a vulnerability (Article 19); distributors must verify compliance markers and do the same where they become aware of risks. Second, a specific legal mechanism changes those roles: under Article 21 of the EU Cyber Resilience Act, an importer or distributor that places a product on the market under its own name or trademark, or that carries out a substantial modification of a product already on the market, is considered to be a manufacturer and becomes subject to the manufacturer’s Articles 13 and 14 obligations — including the reporting ones. The same principle covers other parties who carry out a substantial modification and make the result available (Article 22). So the question is never just their job title; it is whether that entity’s own market placement makes it a manufacturer under the regulation.

For software businesses, that distinction matters in practice. A Filipino freelancer building an application under contract for a company that sells it in the EU does not, by that fact alone, become the manufacturer with a 24-hour reporting duty. The obligations depend on who places the product on the market under their name. A contractor may well be part of the manufacturer’s compliance work — supporting the vulnerability discovery, the patch development, or the documentation the notification requires — but the notification itself is the manufacturer’s duty, unless the contractor’s own role makes it a manufacturer under Article 21 or 22. The contract decides how the work is shared; the regulation decides where the obligation sits. Developers who build their own products and sell them under their own name in the EU, on the other hand, are manufacturers under the EU Cyber Resilience Act, whatever their size or country. Philippine software companies developing products for the EU market fit exactly that description, which is why the distinction deserves care rather than a general warning.

The Commission’s CRA overview keeps the same proportionality: the requirements apply at every stage of the value chain, but the duties bind the roles differently — manufacturers carry the design, development, maintenance, and reporting obligations; importers and distributors carry verification and cooperation duties; and the enforcement runs through national market-surveillance authorities.

What counts as reportable — and what does not

The EU Cyber Resilience Act’s two trigger categories are deliberately different. An actively exploited vulnerability is a flaw the manufacturer becomes aware is being exploited somewhere — in the wild, against real products. A severe incident has a narrower legal definition: Article 14(5) treats an incident as severe when it negatively affects — or is capable of negatively affecting — a product’s ability to protect the availability, authenticity, integrity or confidentiality of sensitive or important data or functions, or when it has led — or is capable of leading — to the introduction or execution of malicious code in the product or in the systems of its users. Those are the two statutory tests, and Article 14(5) deliberately uses ‘capable of’: an incident that had the capacity to produce either of those effects meets the definition on the statute’s own wording. A near-miss with no such capacity does not automatically qualify as a reportable severe incident — the statutory conditions have to be satisfied. Neither trigger covers the ordinary workflow of finding and fixing flaws: an incident that does not meet the Article 14(5) tests, and a flaw that nobody is exploiting, stay in the product’s normal vulnerability handling. The manufacturer’s awareness of the triggering facts starts the clock.

There is a second audience for the reporting duty: the users themselves. Article 14(8) requires a manufacturer that becomes aware of an actively exploited vulnerability or a severe incident to inform affected users — and where appropriate all users — of the vulnerability or incident, and where necessary of the risk-mitigation and corrective measures users can deploy, ideally in a structured, machine-readable format. If the manufacturer fails to inform users in time, the notified CSIRTs may pass the information to users themselves. That awareness condition is also why documentation matters. The deadlines run from becoming aware, so a company needs an internal practice that answers three questions quickly: what did we learn, when, and through which channel — a researcher’s report, a partner’s disclosure, monitoring logs, or an upstream component vendor. The Commission’s guidance, published 27 July 2026 and addressed to manufacturers, developers, and businesses of all sizes, with particular attention to microenterprises and small and medium-sized enterprises walks through exactly these judgment questions, including what counts as a substantial product modification and how support periods should be understood.

A hypothetical walkthrough

Consider a hypothetical software manufacturer subject to the EU Cyber Resilience Act. The timeline matters because the Act’s clock runs from awareness, and awareness does not wait for a researcher’s formal email. Walk the week explicitly. Tuesday morning: monitoring flags unusual behavior consistent with an exploit attempt against an authentication path. Tuesday afternoon: the internal triage team examines the evidence — the traffic pattern, the failed authentication spikes — and determines that the facts indicate active exploitation of a security-relevant flaw. That internal determination is the moment the manufacturer becomes aware of the triggering facts, and the 24-hour early-warning clock starts from it: it is due Wednesday afternoon. Wednesday: a security researcher’s report confirms the exploitation with working code, updating the confidence level but not moving the clock. Engineering builds the fix in parallel; the early warning goes in on time carrying what is known at that stage — suspected exploitation, the affected versions, the exploitation observed — and whether the manufacturer suspects unlawful or malicious acts, which Article 14 requires the early warning to say.

The legally consistent reading is the one the example enforces: awareness means having the facts that satisfy the reporting threshold, not receiving an outside confirmation. A company that waits for formal researcher contact risks filing late. The documentation of the awareness timestamp is part of the compliance design. The early warning goes into the SRP addressed to the CSIRT of the manufacturer’s main establishment, carrying what is known at that stage. Within 72 hours of the same awareness point, the full notification adds the technical detail: the affected versions, the exploitation observed, the user groups exposed. When the corrective or mitigating measure becomes available — in this example, the patch released eleven days after the initial response — the final report follows no later than 14 days after that availability, documenting the vulnerability’s severity and impact, the security update, and, where identified, the actor exploiting it. Nothing in that sequence is improvised: the manufacturer’s vulnerability process already produced the facts the deadlines need, which is why the preparation section below matters more than the paperwork.

Now consider a different situation: the same internal discovery that finds a flaw in a routine audit — no evidence anyone is exploiting it, no incident — stays within ordinary vulnerability management, and never enters the 24-hour notification process. The legal threshold, not the fear of missing one, drives which branch applies. A company that cannot tell those branches apart at a glance has both a compliance risk and a documentation problem, and the fix is process design, not a panic filing.

Third-party and open-source components

Software products often depend heavily on third-party components — libraries, frameworks, SDKs — the developer does not control. The CRA reaches into that structure: manufacturers are responsible for their product’s security including the third-party components they ship, which means an SBOM-style inventory of dependencies is no longer optional housekeeping: it is the input a compliance process needs, because a vulnerability in a shipped component can itself become the manufacturer’s reportable event. When an upstream library ships a security update, the manufacturer’s assessment of whether and how it affects their product feeds both the risk-management obligations and, where thresholds are met, the reporting duties.

Free and open-source software gets its own treatment. An open-source software steward is a legal person that systematically provides sustained support for the development of specific free and open-source software intended for commercial activities, and ensures the viability of those products. Article 24(3) gives such stewards reporting obligations — for actively exploited vulnerabilities, to the extent the steward is involved in the development of products with digital elements, and for severe incidents to the extent they affect network and information systems the steward provides for that development — applying from 11 December 2027. Two boundaries matter: pure non-commercial open-source involvement in the Act’s meaning sits outside these duties (the Commission points to Recital 18 for that line), and the Act exempts stewards from its administrative-fine regime — an exemption that removes the fines, not the obligations: a steward’s Article 24 duties remain in force. The Commission’s July 2026 guidance and its FAQ walk through where specific projects fall. The Commission’s FAQ and its guidance address that boundary in detail, and anyone operating a foundation-facing project should read that section against their own distribution model rather than assume either extreme.

What applies from December 2027

The September 2026 duties were the EU Cyber Resilience Act’s first phase, and they reach products already on the market: the Commission’s summary states that reporting obligations apply to all products made available on the Union market, including those placed there before the December 2027 deadline. Any natural or legal person may also report vulnerabilities, threats, incidents and near misses to the platform voluntarily. The Act’s main cybersecurity requirements apply from 11 December 2027: products must meet the essential cybersecurity-by-design requirements, handle vulnerabilities across a defined support period, carry CE marking where applicable, and — for products of particular relevance to cybersecurity — undergo a third-party conformity assessment before sale. The Commission’s overview notes that obligations span the whole value chain and that enforcement belongs to national market-surveillance authorities. For most software products the conformity route is self-assessment rather than notified-body assessment; the class of the product decides that.

Between now and December 2027 the practical work is preparation, and much of it is unglamorous: scoping which products are covered, fixing support periods, inventorying third-party components, assigning the compliance owner, and building the internal escalation path from security discovery to any notification decision. The Commission’s EU Cyber Resilience Act guidance gives businesses practical preparation guidance, and ENISA’s SME maturity model exists for smaller organizations that need the assessment framed for their size.

What this means for software businesses now

The reporting clock applies only where the duties bind, but preparation does not wait for December 2027. Six evaluation steps cover most situations under the EU Cyber Resilience Act. Map the product portfolio against the Act’s scope — connected hardware and software with digital elements placed on the EU market. Fix the support-period commitments and check the documentation actually supports the security-update obligations. Inventory third-party components so an upstream disclosure can be assessed same-day. Assign who owns the notification decision and who drafts it, including the contractor arrangements that support it. Register and become familiar with the SRP portal — ENISA publishes an FAQ, user manuals, tutorial videos, a glossary, and runs a dedicated help desk per its platform page. Document the internal thresholds: what evidence counts as active exploitation, what severity review asks, and who signs off. These steps help businesses establish their responsibilities under the EU Cyber Resilience Act rather than defending them after the fact.

For the wider security context around the EU Cyber Resilience Act era, our coverage of this year’s browser zero-day accumulation shows why active exploitation is the Act’s reporting trigger, our MSP-breach analysis explains the vendor-trust risks behind software supply chains, and the small-business cybersecurity checklist covers the operational baseline the Act’s preparation sits on top of.

FAQ

What is the EU Cyber Resilience Act?

The EU Cyber Resilience Act is Regulation (EU) 2024/2847, the European Union regulation that sets mandatory cybersecurity requirements for products with digital elements — connected hardware and software sold on the EU market — across their lifecycle, plus a legally binding incident and vulnerability reporting system. It entered into force on 10 December 2024.

Who must report under the Act?

Manufacturers of covered products — the entities placing products on the EU market under their own name — report actively exploited vulnerabilities and severe security incidents. Open-source software stewards carry reporting duties where they are involved in the development of products with digital elements, applying from 11 December 2027. Importers and distributors hold verification and cooperation duties rather than the reporting duty by default — but an importer or distributor that places a product on the market under its own name or trademark, or substantially modifies an already-marketed product, is legally treated as a manufacturer under Article 21 and carries the reporting duty then.

Do all software developers now have to report vulnerabilities within 24 hours?

No. The 24-hour early warning applies to manufacturers who become aware of actively exploited vulnerabilities or severe incidents affecting their products. A routine bug, or a discovery with no evidence of exploitation and no incident impact, is handled through normal vulnerability management. The thresholds and awareness conditions decide which path applies — a developer contracting software to a manufacturer usually supports the manufacturer’s compliance rather than holding the duty themselves.

What are the 24-hour, 72-hour and final-report deadlines?

An early warning within 24 hours of the manufacturer becoming aware; a more detailed notification within 72 hours; and a final report — no later than 14 days after a corrective or mitigating measure becomes available for an actively exploited vulnerability (Article 14(2)(c)), or within one month after the submission of the 72-hour incident notification for a severe incident (Article 14(4)(c)). The two final-report rules are distinct and use different starting points.

How does ENISA’s Single Reporting Platform work?

The SRP is the single online system (launched 11 September 2026) manufacturers use to submit one notification. It routes to the CSIRT of the manufacturer’s main establishment, shares the information with CSIRTs in other affected Member States, and makes it available simultaneously to ENISA — so one filing covers the whole EU scope. ENISA publishes FAQs, user documentation and a glossary, and runs a help desk.

How do free and open-source software projects fit in?

Under the EU Cyber Resilience Act, steward duties apply where stewards are involved in developing products with digital elements, from 11 December 2027 under Article 24(3). Commercial distribution models can bring projects inside the manufacturer obligations; purely non-commercial involvement generally does not. The Commission’s July 2026 guidance and its FAQ explain the boundary cases.

What should a company do before December 2027?

Confirm which products the EU Cyber Resilience Act covers; document support periods and security-update plans; inventory third-party components; assign the notification-decision owner; register with the Single Reporting Platform; and build the internal escalation path from security discovery to any filing decision. The Commission’s 27 July 2026 guidance and ENISA’s SME resources are the official starting points.

This article is general regulatory information for professionals and businesses; it is not legal advice, and no outcome is promised. Obligations depend on each organization’s products, role in the market, and contracts. Verify requirements against Regulation (EU) 2024/2847, the Commission’s guidance, and your own counsel before decisions.

@online{agron2026eucyber,
  author       = {Agron, Edmon},
  title        = {{EU Cyber Resilience Act: What Developers Must Report in 2026}},
  year         = {2026},
  date         = {2026-11-04},
  organization = {WorldNgayon},
  url          = {https://worldngayon.com/eu-cyber-resilience-act/},
  urldate      = {}
}

TY  - ELEC
AU  - Agron, Edmon
TI  - EU Cyber Resilience Act: What Developers Must Report in 2026
T2  - WorldNgayon
PY  - 2026
DA  - 2026/11/04/
UR  - https://worldngayon.com/eu-cyber-resilience-act/
Y2  - 
ER  -