# Can you meet the EU Cyber Resilience Act's 24-hour reporting clock?

Compliance

By [Sharon Abraham Ratna](https://www.manageengine.com/it-operations-management/cxo-focus/author/#Sharon-Abraham-Ratna) on 20th August, 2026

![A brown gavel on a stack of books, with several more blured books in the background](https://cdn.manageengine.com/sites/meweb/images/it-operations-management/cxo-focus-images/eu-cra.jpg)

**Summary**

Most organization's compliance planning for the European Union's Cyber Resilience Act (CRA) is targeting the December 2027 deadline, for meeting essential cybersecurity requirements and the CE marking that certifies attainment of various EU consumer safety mandated. However, it is critical that organizations must not overlook the fast approaching September 11, 2026 requirement.

From September 11 on manufacturers of products with digital elements must report actively exploited vulnerabilities and severe incidents to their national Computer Security Incident Response Team (CSIRT) and the European Union Agency for Cybersecurity (ENISA) within 24 hours of becoming aware of them. This obligation applies to products already on the market and carries the CRA’s highest tier of penalties making it an immediate operational challenge for CISOs and CIOs. This article covers who is in scope, what each reporting stage assumes you can already do, and what to fix in the weeks remaining. Learn more below.

Ask most enterprise security teams when the Cyber Resilience Act starts to bite and you will hear December 2027. They are not wrong. That is when CE marking and the act's Annex I essential security requirements apply, and it is where most of the vendor commentary has pointed.

However, in reality, the date that arrives first is September 11, 2026, which is just weeks away.

From this date, the Article 14 of [Regulation (EU) 2024/2847](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=OJ:L_202402847) starts to apply. The Cyber Resilience Act is a EU regulation setting cybersecurity requirements for hardware and software products across their life cycle. Article 14 is the piece that requires manufacturers to tell the authorities, within the first 24 hours of detection, when something in their product is being exploited. The Commission [designated this date on 27 July 2026](https://digital-strategy.ec.europa.eu/en/library/commission-publishes-new-guidance-support-timely-cyber-resilience-act-implementation) when issuing its implementation guidance.

The question for the coming weeks is whether you could file an accurate early warning within 24 hours if a vulnerability in a shipped product were exploited tomorrow morning.

## What the EU Cyber Resilience Act requires from 11 September 2026

A manufacturer that becomes aware of an actively exploited vulnerability in a product with digital elements, or of a severe incident affecting that product's security, must notify ENISA and the CSIRT. Reports go through a single channel called the [CRA Single Reporting Platform](https://digital-strategy.ec.europa.eu/en/policies/cra-reporting) to all relevant authorities, so you file once rather than notifying each member state separately.

Note that you need to file this report only on exploitation. A CVE sitting in your dependency tree with no evidence of exploitation is not reportable under Article 14, which keeps the reports volume manageable for authorities.

The penalty exposure, though, is at the top of the scale. Article 64 puts Article 14 in the same tier as the essential requirements, carrying fines of up to EUR 15 million or 2.5% of worldwide annual turnover, whichever is higher. The Commission's [summary of the regulation](https://digital-strategy.ec.europa.eu/en/policies/cra-summary) notes that microenterprises and small enterprises may not be fined for missing the 24-hour deadline specifically which is a slight relief for SMBs.

## Who the Cyber Resilience Act reporting duty actually covers

The compliance responsibility falls on the manufactures who place their products in the EU markets under their own name. If you only buy and run software then Article 14 does not make you responsible and any software built purely for internal use is also exempted because it was never made available in the EU market.

While many organizations are and are not required to comply with these requirements, many are caught off-guard because they believe they are merely software buyers. The catch is, they also ship something built on top of or with the help of the software they had purchased. Classic examples of such products include a customer-facing mobile app, an installable software client for their services, or a firmware in their product line. If any of these reaches the EU customers, then they become the manufacturer for those products and consequently become liable for the 24-hour reporting window.

Then there is the part that can be a bit of a grey area to navigate.

Article 69(2) sets a transitional rule under which products placed on the market before December 11, 2027 fall under the regulation only if they are substantially modified, which suggests your back catalog is untouched.

But this alone does not mean all the products you have placed in the EU market as of now are simply grandfathered away from the regulation.

Article 69(3) creates an exception for Article 14 which is the the CRA's requirement to report actively exploited vulnerabilities and severe cybersecurity incidents. This means that, despite the general exception for the already-existing products in the market, the reporting window still applies to them. You can learn more about this in the [implementation FAQs](https://digital-strategy.ec.europa.eu/en/library/cyber-resilience-act-implementation-frequently-asked-questions).

A product you shipped in 2024 may never need a CE mark, and yet if a vulnerability in it is actively exploited and you learn of that on or after September 11, it is reportable.

## The 24-hour clock is a detection problem that can lead you to a legal one

The countdown to reporting incidents starts the moment you become aware of one. So the bottleneck here becomes how long you take to notice that something in a shipped product is being exploited and to route that to someone authorized to file.

Consider how fast the threat side moves. VulnCheck's [analysis of the first half of 2026](https://www.vulncheck.com/blog/state-of-exploitation-1h-2026) found that 23.43% of the known exploited vulnerabilities it tracked showed evidence of exploitation on or before the day the CVE was published, and that the median time from disclosure to confirmed exploitation fell from 120 days in 2025 to 80 days.

Now, think about what that does to your process. If exploitation frequently precedes the CVE, then a vulnerability feed cannot serve as your awareness mechanism, because in a meaningful share of cases it tells you after the exploitation has begun. And if the feed tells you after the exploitation, then you already need your own strategy in place to detect the vulnerability before hand. This strategy can include your own telemetry, a customer support signal, or a threat intelligence partner.

This is where an [observability strategy](https://www.manageengine.com/it-operations-management/cxo-focus/insights/observability-strategies.html?eu-cyber-resilience-act-reporting) stops being an operations concern and becomes a compliance dependency.

- Track exploitation signals: Match evidence of active exploitation against your own component list rather than triaging by CVSS or other severity scores. A critical vulnerability nobody is exploiting is not reportable. However, you still need to report a medium-severity one that is under attack.
- Instrument the products you can see: When you core products run in environments covered by your [full-stack observability](https://www.manageengine.com/it-operations-management/cxo-focus/guides/whitepaper-fso.html?eu-cyber-resilience-act-reporting) tooling, [IT anomaly detection](https://www.manageengine.com/it-operations-management/cxo-focus/insights/it-anomaly-detection.html?eu-cyber-resilience-act-reporting) and [network detection and response](https://www.manageengine.com/it-operations-management/cxo-focus/insights/network-detection-and-response.html?eu-cyber-resilience-act-reporting) will often surface exploitation before a public advisory does.
- Name an out-of-hours path: Decide who can submit an early warning at 3am on a Sunday, and name a deputy. Your organization will not be compliant with the 24-hour window escalation requirement if your team waits until standard Monday business hours to log an issue.
- Capture evidence from the first hour: The latter stages require a technical account of what happened, so collection starts when the incident does. See what to preserve in our piece on [digital forensics for incident management](https://www.manageengine.com/it-operations-management/cxo-focus/insights/digital-forensics-for-incident-management.html?eu-cyber-resilience-act-reporting).

## What each Cyber Resilience Act reporting stage asks you to produce

Article 14 unfolds in three stages, each measured from the moment of awareness rather than from the start of the attack.

| Stage | Deadline | What you file | What it assumes you already have |
|---|---|---|---|
| Early warning | Within 24 hours | An exploited vulnerability or severe incident exists, and where the affected products are available. | An accurate map of which products ship where. |
| Full notification | Within 72 hours | The nature of the vulnerability or incident, product identification and category, and any corrective or mitigating measures taken. | Product classification against the regulation's Annex III and IV, and an initial technical assessment. |
| Final report | 14 days after a corrective measure is available, or one month for a severe incident. | Description, root cause, severity and impact, and the fix distributed to the member states. | A completed root cause analysis and a release you can point to. |

Along with these requirements, there is an upstream reporting duty. You also need to notify whoever maintains the component of the location of the flaw.

## You cannot report what your software inventory does not show

Here is the finding by ENISA that should worry any CISO looking at the above table. Its [June 2026 survey](https://www.enisa.europa.eu/sites/default/files/2026-06/SBOM%20Adoption%20State%20of%20Play%202026.pdf) of software bill of materials (SBOM) readiness mandate across European organizations found that while 78% of respondents had started to adopt ENISA requirements, only 9% had achieved mature implementation supported by automation, and 44% were still in a pilot or limited rollout.

Most organizations heading into September 11 can produce a component inventory manually for some products but it might require several days.

The formal SBOM mandate sits with the December 2027 requirements, and the CRA does not explicitly oblige you to have one next month. But the 24-hour clock requirement effectively does.

Addressing a CRA reporting requirement like “which products include [X], and in which versions” is challenging when the information lives in a dependency graph three layers deep. It's often not possible to obtain the answers within the required 24-hour deadline. With the right tools to map software and hardware dependencies, you can fulfill the requirement, which also often aligns with other [software development life cycle security](https://www.manageengine.com/it-operations-management/cxo-focus/insights/sdlc-security.html?eu-cyber-resilience-act-reporting) across regulations.

## Where CRA reporting overlaps with NIS2 and DORA

If you are also an essential entity under NIS2 or a financial entity under [the Digital Operational Resilience Act](https://www.manageengine.com/it-operations-management/cxo-focus/insights/digital-operational-resilience-act-dora.html?eu-cyber-resilience-act-reporting), you now must adhere to three distinct directives with similar implementation timetables but different triggers. DORA and NIS2 attach to incidents affecting your operations as an entity, while the CRA attaches to a product you placed on the market, whoever is running it. One event can trigger all three.

So, share the plumbing, not the process: one triage pipeline, one evidence store, and one severity taxonomy mapped to each regime's threshold. Your organization should essentially be moving toward consolidated entry points.

## A three-week readiness checklist

Very little of this depends on the platform for reporting being live, which matters, because ENISA's [Single Reporting Platform](https://www.enisa.europa.eu/topics/product-security/single-reporting-platform-srp) was still in testing in early August, with registration guidance published only on July 31.

- Register the accounts now: Registration runs through EU Login, and those accounts can be created before the platform opens. Do it for a primary filer and a backup.
- Confirm which products put you in scope: List everything you make available in the EU that has a data connection, then name the responsible legal entity for each.
- Classify the portfolio against Annex III and IV: The 72-hour notification asks for it, and doing it under incident pressure can lead to errors.
- Write the early warning as an internal form: Match ENISA's mandatory fields, then evaluate it against a vulnerability from last quarter. Time the rehearsal.
- Ask your team one inventory question: Given a CVE in a common open-source library, how long does it take to name every affected product and version? Anything measured in days is the gap you need to close first.

## The strategic takeaway for CISOs and CIOs

The CRA is set to become a product compliance program by December 2027. For the next three weeks it is narrower.

- Treat September 11 as a detection deadline: Ask your team what your current mean time to awareness is for exploitation of a shipped product. If nobody can answer, that is the finding to take to the board.
- Fund the inventory work before the CE marking work: Component visibility serves the September obligation, the December 2027 SBOM requirement, and every vendor questionnaire in between. Sequence it first.
- Assign one accountable owner: Reporting sits across security, engineering, legal, and support. Build a cross-functional team if you can afford the resources or name one person who is directly in charge of the compliance, and assign a deputy.
- Press your suppliers on the same question: Their Article 14 notifications are how you learn about flaws in components you did not write.

Whether the first months of enforcement prove strict or forgiving is genuinely unknown. Market surveillance authorities are still evaluating their capacity. Planning on leniency wouldn't be wise as there is a non-compliance fine of 2.5% of turnover on the table.