EU CRA 24-Hour Reporting: The Clock That Starts Sept 2026
On September 11, 2026, the EU Cyber Resilience Act’s reporting clock starts.
That is not the date when the entire regulation applies. Most secure-by-design, vulnerability-handling, conformity-assessment, and CE-marking requirements apply from December 11, 2027. But Article 14 reporting begins 15 months earlier for in-scope products on the EU market, including products placed there before the full application date.
From September 11th, a manufacturer that becomes aware of an actively exploited vulnerability contained in its product, or a severe incident affecting the product’s security, must submit an early warning without undue delay and in any event within 24 hours. A person must be able to recognize the trigger, scope the affected products and file through ENISA’s Single Reporting Platform while the investigation is still developing.
How late that machinery arrived is its own signal: the list of national CSIRTs a manufacturer is supposed to report to was published on September 4, 2026, one week before the duty starts. The platform itself is still not live as this goes out. This article is the runbook that lets engineering leaders act now rather than just legal summaries and scary countdowns.
This is engineering guidance, not legal advice. Commission guidance C(2026) 5252 is the interpretive reference used here.
The three EU CRA reporting clocks
Article 14 establishes three reporting stages for actively exploited vulnerabilities. Severe incidents follow the same first two stages but have a different final-report deadline.
| Report | Deadline | What the team must be ready to provide |
|---|---|---|
| Early warning | Without undue delay and in any event within 24 hours of awareness | Manufacturer and product identification, notification type and title, and the limited information then available. Include Member States where the product is available when known. |
| Full notification | Without undue delay and in any event within 72 hours of the same awareness | General information about the vulnerability and exploitation, an initial severity and impact assessment, and corrective or mitigating measures taken or available. |
| Vulnerability final report | Within 14 days after a corrective or mitigating measure becomes available | A fuller description of the vulnerability, severity, impact, exploitation and the correction or mitigation. A documented workaround can start this clock. A patch is not required. |
| Severe-incident final report | No later than one month after the 72-hour notification | A detailed description of the incident, impact, likely threat or root cause, and mitigation applied or in progress. |
The 24- and 72-hour clocks run from the same awareness timestamp. They do not wait for a completed root-cause analysis, a reproducible test case, or a patch.
The vulnerability final-report clock is different. It starts when a corrective or mitigating measure becomes available. If engineering publishes a documented workaround on Tuesday and ships a patch on Friday, Tuesday starts the 14-day clock. Treating this as a patch deadline can make a team record the wrong date.
What starts the clock and what does not
Article 3(42) defines an actively exploited vulnerability as one for which there is reliable evidence that a malicious actor exploited it in a system without the system owner’s permission. A theoretical weakness is not enough. The manufacturer must also determine that the vulnerability is contained in its in-scope product.
Commission guidance describes awareness as reasonable certainty reached after a prompt initial assessment. That does not require complete forensic certainty. A loose internal definition cannot postpone awareness, and delaying the initial assessment does not pause the clock.
Use this decision sequence for every signal:
- Preserve the signal, source, and receipt time in UTC.
- Ask whether there is reliable evidence of real-world malicious exploitation.
- Ask whether the vulnerability is contained in and exploitable in an in-scope product on the EU market.
- If a prompt assessment establishes both with reasonable certainty, record the awareness timestamp and escalate for filing.
- If either answer remains uncertain, document the gap, assign an owner, and continue the assessment immediately.
The signal changes what the team must establish:
| Signal | Does it start the clock? | Engineering response |
|---|---|---|
| CVE publication | Not by itself. A CVE identifies a vulnerability but does not prove malicious exploitation or product impact. | Triage the affected component and versions. Look for exploitation evidence and determine whether the vulnerability is contained in the product. |
| Public proof of concept | Not by itself. Research code demonstrates feasibility, not necessarily real-world malicious exploitation. | Assess reachability and exposure promptly. Monitor for credible exploitation evidence. |
| Known Exploited Vulnerabilities listing | It requires immediate assessment. A KEV listing is reliable evidence that the vulnerability has been exploited in the wild, but it does not answer whether the vulnerability is contained in and exploitable in your product. | Determine product presence, use, and exploitability immediately. Do not require telemetry showing that one of your customers was compromised. |
| Credible customer report | Yes, once prompt assessment produces reasonable certainty that malicious exploitation affects a vulnerability contained in the product. | Preserve the report and indicators, confirm product and version, and record when the threshold was met. Do not wait for complete forensics. |
| The manufacturer’s own telemetry | Yes, when it provides reliable evidence of malicious exploitation of a vulnerability contained in the product. | Preserve the telemetry, identify affected products and versions, record awareness, and begin the filing workflow. |
A CVE is also not an Article 14 notification. Publishing or updating a CVE informs vulnerability databases. It does not notify the coordinator CSIRT or ENISA through the required channel.
For product-impact analysis, the same dependency and data-flow knowledge used in What Is Threat Modeling can help a team distinguish component presence from actual exploitability. The point is not to turn the first four hours into a full threat-modeling exercise. It is to know where the vulnerable code sits, whether an attacker can reach it and which released products inherit the exposure.
The ENISA Single Reporting Platform
Article 16 requires filings through ENISA’s Single Reporting Platform, which routes notifications to the manufacturer’s coordinator CSIRT and, subject to limited exceptions, ENISA.
As of September 8, 2026, the platform is scheduled to be operational by September 11th but is not live. Its public URL has not been published. The list of CSIRTs designated as coordinators, missing until the week before the deadline, was published on September 4, 2026 and now covers all 27 Member States. Re-verify both points on publication day using the ENISA Single Reporting Platform hub (SRP), the European Commission EU CRA reporting page and the cyberresilienceact.eu tracker.
The published guidance already exposes several operational traps:
- There is no API at this stage. Filing means a person completing a form.
- Filers authenticate through EU Login. Those accounts can be created now.
- ENISA advises manufacturers to register on the SRP only when they have a notification. The first platform login may therefore occur during a live event.
- Drafts are visible only to their creator. A backup cannot take over another filer’s unfinished draft.
- Backup invitations expire after seven days. CSIRT validation is not a precondition for filing.
ENISA’s guidance disagrees with itself on the notification cap for a non-validated representative: the FAQ updated on September 8, 2026 says 20, while the August 14, 2026 interface guidance still says 10 on the additional-manufacturer association flow. Do not turn either number into a blanket account rule without checking the live platform and current guidance.
Six things to prepare without an SRP login
- First, identify who will be your primary and backup filers.
- Give the primary and backup filers active EU Login accounts and verify that both can sign in.
- Maintain a product-to-component map with released versions, owners and EU availability.
- Route disclosures, support cases, telemetry, supplier notices and public exploitation alerts into one monitored intake process.
- Create a shared incident record outside the SRP, including UTC timestamps, evidence, product impact, assumptions, and submission data.
- Run a tabletop in which the primary filer becomes unavailable, and the backup must reconstruct the early warning from the shared record.
Treat the SRP as the submission channel, not the incident-management system. A shared external record prevents a private draft from becoming a single point of failure.
The myths that will get teams in trouble
| Myth | Correction |
|---|---|
| “The EU CRA is a December 2027 problem.” | Article 14 reporting applies from 11 September 2026. Most secure-by-design, conformity-assessment and CE-marking requirements apply from 11 December 2027. |
| “Products already sold are grandfathered.” | Article 69(3) extends reporting to in-scope products placed on the EU market before the full application date. It does not pull out-of-scope products into the regulation. |
| “The clock starts when we confirm root cause or produce a fix.” | The 24- and 72-hour clocks run from awareness based on reasonable certainty after a prompt initial assessment. A complete investigation or patch is not required. |
| “Filing a CVE satisfies Article 14.” | A CVE notifies vulnerability databases. Article 14 notifications go through the SRP to the coordinator CSIRT and ENISA. |
| “SaaS is automatically exempt.” | Scope depends on whether the offering is a product with digital elements, including a qualifying remote data-processing solution. A purely browser-only service is generally outside scope, but the SaaS label does not decide the question. |
| “A third-party or open-source flaw is not our report.” | Component origin does not remove the manufacturer’s duty. The question is whether an actively exploited vulnerability is contained in and exploitable in the manufacturer’s in-scope product. |
| “We must report exploitation we knew about before September.” | Commission guidance C(2026) 5252 says there is no duty to retro-report exploitation already known before 11 September 2026. Awareness first reached on or after that date may trigger reporting for an in-scope product already on the market. |
| “We can wait for the CSIRT to verify the account.” | Validation is not a precondition for filing, and the reporting clock does not pause while registration is validated. |
EU CRA violations can carry maximum administrative fines of up to EUR 15 million or 2.5% of worldwide annual turnover. The applicable ceiling depends on the obligation, enforcement context and statutory considerations, including the regulation’s provisions affecting micro and small enterprises. The number should inform governance, not become the incident team’s operating model.
Who owns which clock
The 24-hour problem is primarily an awareness and filing problem. The 14-day problem is a fix-availability and documentation problem. Assigning every deadline simply to “security” hides that difference.
| Clock | Accountable owner | Engineering responsibility |
|---|---|---|
| Awareness and 24-hour warning | PSIRT or product-security incident lead | Establish product presence and exploitability, preserve evidence, identify affected versions and state what remains unknown. |
| 72-hour notification | PSIRT, with legal review where required | Replace early assumptions with severity, impact, affected versions, containment status, and available mitigation. |
| 14-day vulnerability final report | Remediation owner coordinated by PSIRT | Make the correction or mitigation available, record the availability time, and document the technical result. |
| One-month severe-incident final report | Incident-response lead | Complete the root-cause, impact and remediation evidence for the incident record. |
That table assumes a product security function exists. Many manufacturers in scope have none. In that case one person holds the accountable-owner column, usually the engineering leader or the first security engineer, and the split still applies: awareness and filing are one job, correction and documentation are another, even when the same person does both with the help of Trent AI Security Engineer.
The first 24 hours
Intake to hour 4: preserve and assess. Open the shared incident record. Capture the source, receipt time, products and versions mentioned, exploitation evidence, indicators, customers or systems affected, relevant identifiers and people notified. Product security performs the prompt initial assessment. If the threshold reaches reasonable certainty, record awareness and escalate.
Hours 4 to 12: determine product impact. The component owner identifies affected products and version ranges, how the component is used, whether configuration prevents exploitation, which in-scope products are on the EU market, Member States where they are available when known, and any corrective or mitigating measure already available. If reproduction is incomplete, say so. The early warning is designed for limited information.
Hours 12 to 20: prepare the warning. The primary filer drafts from the shared record. The backup reviews the same source material. Confirm the manufacturer, product, notification type, known exploitation, suspected versions, EU availability and immediate mitigation. Mark assumptions and unconfirmed facts. A CVE or EUVD identifier can be included when available but is not required for the early warning.
Hours 20 to 24: file. Stop allowing unresolved technical questions to block the early warning. Move them into the 72-hour work plan. After filing, record the submission time, identifier, filer, information included, known gaps, and platform confirmation.
From 24 hours to the final report
Engineering continues investigating while PSIRT prepares the 72-hour notification. Update the nature of the vulnerability and exploitation, affected products and versions, severity, likely impact, and corrective or mitigating measures taken or available. Submit without undue delay and in any event within 72 hours of the same awareness timestamp.
When a correction or mitigation becomes available, record the exact time and what “available” means: release, customer advisory, configuration change or documented workaround. That event starts the 14-day vulnerability final-report clock. Preserve all three submissions, the awareness decision, product-impact evidence and decisions made at each deadline.
AI-assisted development can make this inventory and context problem harder by introducing code and dependencies faster than periodic review processes can track. What Is Agentic AI Security explains why the surrounding permissions, tools, and workflow matter, while the CWE-Bench benchmark article illustrates the difference between finding possible weaknesses and producing useful security judgment.
Where Trent supports the runbook
Trent supports the detection and product-context layer by continuously analyzing what a team ships and helping product-security owners determine which findings are exploitable in context. That can produce earlier, better-contextualized signals than raw vulnerability counts alone. The inventory Trent builds of the components, services, and agents it finds in what a team ships also gives product-security owners a starting map for the product-to-component list this runbook depends on and for the SBOM work the regulation requires, though the SBOM itself remains a build artifact the manufacturer produces. Trent does not file an Article 14 notification, determine which products are legally in scope, or make the manufacturer’s legal classification. Filing, scoping, and legal classification remain with the manufacturer.
Prepare before the platform opens
None of the six preparation steps requires the SRP to be live. Assign the filers, create their EU Login accounts, map products to components, centralize intake and rehearse the first 24 hours now.
Use a tabletop based on an exploited third-party component in an older in-scope product. Make the primary filer unavailable halfway through. If the backup cannot reconstruct and submit the warning from the shared record, fix the process before a real clock starts.
If product awareness and exploitability context are the missing pieces, request access to Trent. You can also book a demo.
Primary sources
- Regulation (EU) 2024/2847, Articles 3, 14, 16, 64, 69 and 71
- European Commission guidance C(2026) 5252
- European Commission EU CRA reporting page
- ENISA Single Reporting Platform hub
- cyberresilienceact.eu implementation tracker
Reviewed by Julien Brouchier MTS at Trent AI, Eno Thereska, Co-founder & CEO at Trent AI
EU CRA reporting FAQ
When do EU CRA vulnerability-reporting obligations start?
Article 14 reporting applies from September 11, 2026. Most other EU CRA obligations, including secure-by-design requirements, conformity assessment and CE marking, apply from December 11, 2027.
What must be reported within 24 hours under the EU CRA?
A manufacturer must submit an early warning for an actively exploited vulnerability contained in its product, or a severe incident affecting the product’s security. The deadline is without undue delay and in any event within 24 hours of awareness.
When does the EU CRA 24-hour clock start?
<p>It starts when the manufacturer has reasonable certainty, after a prompt initial assessment, that the Article 14 criteria are met. The team does not need complete forensics, confirmed root cause or a patch.</p>
Does a CVE or proof of concept start the EU CRA reporting clock?
Not by itself. A CVE identifies a vulnerability, and a proof of concept may show feasibility. Article 14 requires reliable evidence of real-world malicious exploitation plus a determination that the vulnerability is contained in the manufacturer’s product.
How do manufacturers submit an EU CRA vulnerability report?
They submit through ENISA’s Single Reporting Platform. As of September 8, 2026, ENISA says there is no API at this stage, so an authorized person must complete the web form. Recheck the platform instructions when it goes live.
Do EU CRA reporting duties apply to products already on the market?
Yes. Article 69(3) extends the reporting duty to in-scope products already placed on the EU market. It does not mean every software service or browser-only product is automatically in scope.
What happens after the EU CRA 24-hour early warning?
The manufacturer submits a fuller notification without undue delay and in any event within 72 hours of the same awareness timestamp. For a vulnerability, the final report is due within 14 days after a corrective or mitigating measure becomes available. For a severe incident, it is due within one month after the 72-hour notification.
