CRA reporting: 24 hours, 72 hours and the risk of simplifying the law

• Article 14 reporting for manufacturers has applied since 11 September 2026. Most other CRA obligations apply from 11 December 2027.3
• Article 14 has two distinct mandatory reporting objects: an actively exploited vulnerability (AEV) and a severe incident having an impact on the security of a product with digital elements.4
• The 24- and 72-hour clocks run from the manufacturer's awareness. The Commission's non-binding guidance links awareness to a prompt initial assessment reaching a reasonable degree of certainty; it is neither automatically the first inbound signal nor something management can postpone by internal approval design.5
• The two final-report clocks are different. An AEV final report is tied to the availability of a corrective or mitigating measure; a severe-incident final report is tied to the 72-hour incident notification.4
• Article 14(8) user communication is a separate duty. Article 14 does not create a universal rule saying customers must be notified exactly within 72 hours.4
• Legally, the notification is to the CSIRT designated as coordinator and ENISA. Operationally, it is a single submission through the SRP using the relevant coordinator endpoint, with the notification simultaneously accessible to ENISA.4
• Article 15 voluntary reporting exists in the Regulation, but as of 25 September 2026 ENISA says voluntary Article 15 functionality is not yet available in the current SRP release.1
• Open-source software stewards are not on the manufacturer's September 2026 clock. Their Article 24(3) reporting obligations apply from 11 December 2027.13

One of the first useful distinctions is temporal.

It is accurate to say that the manufacturer's Article 14 reporting obligations began to apply on 11 September 2026. It is not accurate to describe that date as the day the entire CRA became applicable. The Regulation entered into force in December 2024; most of its substantive obligations apply from 11 December 2027, with specific provisions applying earlier.3

That matters inside an organisation because one CRA programme can contain three different kinds of work at the same time: obligations that already apply, future obligations being implemented early, and voluntary readiness measures. If those are all put into one checklist without application dates, “recommended now” can become “legally required now” by accident.

The open-source steward date illustrates the problem. Article 14 applies early to manufacturers. The steward reporting duty is brought in through Article 24(3), and the Commission and ENISA now state expressly that it applies from 11 December 2027.13

So the first field in a CRA playbook should not be “24h or 72h?”. It should be: which legal entity, acting in which CRA role, is subject to this particular obligation?

Product-security teams use the word vulnerability for many different states: a scanner finding, a CVE, a researcher submission, a working proof of concept, a vulnerable dependency, a published exploit, or evidence that attackers are already using the flaw. Article 14 does not treat those states as interchangeable.

It creates two separate mandatory reporting branches.

The CRA definition of an actively exploited vulnerability is unusually useful because it forces the evidence question into the open. Article 3(42) requires reliable evidence of malicious exploitation in a system without the system owner's permission.6

That makes a difference for security research. A researcher may demonstrate exploitability in good faith. A red team may intentionally exercise a weakness under authorisation. A public exploit may make exploitation easier. All of those can be urgent product-security inputs, but none automatically proves the malicious, unauthorised exploitation required by the AEV definition.

This boundary also connects to the wider problem of good-faith security research and authorisation. A product-security workflow should be able to distinguish how an exploit was demonstrated, not merely record a binary “exploited” flag.

The Article 14 clocks are tied to the manufacturer becoming aware of the relevant AEV or severe incident. That sounds simple until an actual signal arrives.

At 17:03 on a Friday, a security mailbox may receive a customer log fragment and a claim that a product vulnerability is being exploited. The report may be incomplete, wrong, or relevant only to a configuration the manufacturer does not ship. Treating every inbound claim as immediate legal awareness would be operationally crude. Treating “we are still investigating” as an indefinite way to avoid awareness would be equally wrong.

The Commission's July 2026 CRA guidance gives a practical middle point. When a suspicious event is detected or brought to the manufacturer's attention, the manufacturer should assess it promptly. The manufacturer is regarded as having become aware when, after that initial assessment, it has a reasonable degree of certainty that a vulnerability in its product is being actively exploited, or that a severe incident has occurred and compromised the security of its product.5

That suggests a useful evidence model with three separate timestamps:

1. signal received — when the information first entered the organisation;
2. initial assessment — what was checked, against which product/version/configuration and with what evidence;
3. awareness threshold reached — when the evidence supported the relevant Article 14 classification.

The CRA does not mandate this exact three-field data structure. It is an operational control. It preserves the difference between intake and legal trigger and makes the timeline reconstructable later.

A weaker model is to define awareness internally as “when the CISO was informed”, “when Legal approved”, or “when the incident committee met”. Governance may participate in the decision, but internal approval architecture should capture the legal trigger rather than redefine it.

The first two stages look similar across AEVs and severe incidents. The final stage does not.

Those are Article 14 clocks, not a consultancy convention.4

A checklist row saying “final report within 14 days” is therefore wrong as a general CRA rule. It is only relevant to the AEV branch, and even there the 14 days do not start at awareness or at the 72-hour submission. They start when a corrective or mitigating measure becomes available.

Likewise, “final report within 30 days” is an unsafe compression of the severe-incident rule. The Regulation says one month after the 72-hour incident notification.

A deadline is never just a number. It has an event that starts the clock, a reporting object and a required information set.

Article 14(2)(b) and 14(4)(b) concern the 72-hour regulatory notification. Those notifications include available information about corrective or mitigating measures, including measures users can take.4

That is not the same legal duty as directly informing users.

User communication sits in Article 14(8). After becoming aware of an AEV or severe incident, the manufacturer must inform impacted users and, where appropriate, all users of the vulnerability or incident and, where necessary, the mitigation or corrective measures they can deploy. The Regulation expects that communication to be timely, but Article 14(8) does not create a universal “notify customers within 72 hours” rule.4

This is more than drafting hygiene. If an incident playbook says “72h: notify customers”, a team may infer both that user communication can always wait until hour 72 and that the 72-hour regulatory submission is primarily a customer-advisory milestone. Neither follows from the Article 14 structure.

The better architecture runs two related workstreams in parallel: the regulatory reporting branch and the user-protection/communication branch.

The legal recipients and the technical submission path also need to stay distinct.

Articles 14(1) and 14(3) state that the manufacturer notifies the relevant CSIRT designated as coordinator and ENISA. Article 14(7) provides the operational mechanism: the manufacturer submits through the Single Reporting Platform using the relevant coordinator CSIRT electronic endpoint. In the ordinary flow, the information is simultaneously available to ENISA; the Regulation separately provides limited exceptional controls over further dissemination of sensitive notifications.4

For the manufacturer, the ordinary process is therefore one submission path, not two independent reporting workflows.

The SRP became operational on 11 September 2026. ENISA now maintains the platform, FAQs, registration guidance and instructions for Assigned Representatives to submit and update AEV and severe-incident notifications.127

A national implementation can still matter operationally. Latvia provides a useful example: CERT.LV states that it processes CRA SRP notifications for Latvia and publishes a fallback email route for cases where the platform is technically unavailable, with a requirement to register the report in the SRP once service is restored.8 That is a local continuity mechanism around the common EU reporting architecture, not a replacement for the SRP model.

Article 15 allows manufacturers and other natural or legal persons to report vulnerabilities, cyber threats, incidents and near misses voluntarily to a CSIRT designated as coordinator or ENISA.4

That is the legal rule.

ENISA's post-launch FAQ describes a narrower operational state: the current SRP version supports mandatory Article 14 notifications by manufacturers, while Article 15 voluntary reporting will be introduced in a future phase. For non-manufacturers wishing to report a vulnerability or security issue, ENISA currently points them to the relevant national CSIRT.1

This is a useful example of why the Regulation, Commission implementation material and ENISA platform documentation serve different purposes. A legal permission to report voluntarily does not necessarily mean the current user interface already exposes that path to every category of reporter.

Another high-impact simplification is to say that manufacturers and open-source software stewards both entered the same reporting regime on 11 September 2026.

Current Commission and ENISA material draws a different line.

Article 14 applies to manufacturers from 11 September 2026. Open-source software steward reporting is imposed through Article 24(3), and the current official implementation material states that those duties apply from 11 December 2027.13

This does not make 2026 irrelevant for stewards. Security contacts, vulnerability-handling processes, downstream coordination and the ability to work with manufacturers are valuable now. But “prepare now” and “this legal duty applies now” are different statements.

The distinction is also reflected in the current OpenSSF materials: the manufacturer resource guide is framed around the September 2026 reporting milestone, while the steward guide prominently states the December 2027 application date.910

On 8–9 September 2026, I reviewed OpenSSF manufacturer/PSIRT and open-source steward CRA material against Regulation (EU) 2024/2847, the Commission's current implementation material and ENISA SRP guidance.

The useful result was not a count of drafting errors. It was a repeatable pattern showing where legal meaning is lost during compression.

Several types of drift appeared:

• the steward's 2027 application date could be read as if it were the manufacturer's earlier 2026 date;
• a 72-hour regulatory notification could be rendered as a 72-hour consumer-advisory deadline;
• AEVs and severe incidents could be collapsed into a generic “severe vulnerability” concept;
• the different final-report clocks could become one simplified number;
• voluntary Article 15 reporting could appear as a mandatory steward checklist item;
• “CSIRT and ENISA” could be read as two independent submission processes.

OpenSSF's EU Policy Advisor responded to the review point by point and invited passage-level replacement wording. The currently published OpenSSF manufacturer and steward resource guides now clearly distinguish several of those points, including the steward application date, the two final-report clocks and the voluntary character of Article 15.910

Legal requirements still have to be simplified for operational use; nobody wants to search a long Regulation during an incident for the sentence controlling the next action. The point is narrower: simplification needs its own verification method.

Before compressing a legal requirement into one operational sentence, I would check seven fields.

If one of these fields changes, the shortened sentence is no longer merely shorter. It has changed the rule.

The same test is useful beyond the CRA. It applies whenever law or policy is converted into a workflow engine, Jira form, SOC playbook, automated compliance check or governance control.

A tabletop test tells you more than another policy document.

At 17:00 on Friday, a product-security team receives credible evidence suggesting that a vulnerability in a company product is being actively exploited against customers in several EU Member States. Attribution is incomplete. There is no patch. The full impact is not yet known. Some of the people named in the compliance policy are already offline.

A functioning Article 14 process should be able to answer, without inventing the process during the event:

1. Which product and versions may be affected?
2. Which legal entity is the CRA manufacturer?
3. What is the original evidence source, and has the original evidence been preserved?
4. Who performs the prompt initial technical assessment?
5. When does the evidence reach the reasonable-degree-of-certainty threshold for an AEV or severe incident?
6. Who records the awareness time and rationale?
7. Who has working SRP access, and who is the backup reporter?
8. What can be stated truthfully in the 24-hour early warning while uncertainty remains?
9. How do investigation, remediation and user protection continue in parallel?
10. Which 72-hour and final-report clock applies, and who owns it?

If several answers begin with “we would work that out during the incident”, the organisation does not yet have an Article 14 reporting process. It has a deadline written in a policy.

The CRA does not prescribe a particular folder structure for Article 14 events. But an organisation that may later need to explain when it became aware and why it classified an event in a particular way needs more than scattered chat messages and manually copied timestamps.

I would run the event from one canonical evidence package containing, at minimum:

• the original signal and source;
• original technical evidence;
• affected product and version mapping;
• relevant third-party component mapping;
• signal-received, assessment and awareness timestamps;
• the classification decision and its rationale;
• changes in classification as evidence develops;
• the submitted 24-hour early warning and its version;
• investigation findings;
• the 72-hour submission;
• user communications and mitigation instructions;
• the patch, workaround or other corrective measure and the time it became available;
• the final report;
• later corrections or updates.

The purpose is not documentation for its own sake. Another competent person should later be able to reconstruct what the organisation knew, when it knew it, what it concluded and why it acted as it did.

That is the same evidence-preservation principle used in defensible vulnerability prioritisation: do not collapse signals with different meanings if the decision may later need to be reconstructed.

Article 14 interacts with several existing security processes. It does not replace them.

Vulnerability management identifies, evaluates, prioritises, remediates and verifies vulnerabilities.

Coordinated vulnerability disclosure provides an intake and coordination path for vulnerability reports. A CVD report can become an input to an Article 14 assessment; it is not itself Article 14 reporting.

Incident response investigates, contains and recovers from a security event. CRA reporting uses information from that process, but the regulatory clock does not wait for complete forensics.

User communication protects affected users and has its own Article 14(8) basis.

Other legal and contractual notification regimes may create parallel clocks, recipients and thresholds. A CRA submission does not automatically discharge GDPR, NIS2, DORA, sector-regulator or contractual notification duties where those apply.

The sensible architecture is to share evidence and chronology across these processes without pretending that they are legally identical.

Before calling an organisation ready for Article 14, I would want clear answers to these questions:

• Is the legal manufacturer known for every potentially in-scope product?
• Can the team distinguish a vulnerability, an exploitable vulnerability, an AEV and a severe incident?
• Is there an out-of-hours owner for the initial assessment?
• Is awareness recorded separately from first signal receipt?
• Are SRP Assigned Representatives active, with working backups?
• Has the organisation rehearsed a 24h and 72h submission using incomplete information rather than an idealised finished incident report?
• Is user communication a separate workstream rather than a mistaken 72h checklist item?
• Does the workflow know which final-report clock to start?
• Is Article 15 voluntary reporting kept separate from mandatory Article 14 reporting?
• Are manufacturer and open-source steward roles mapped separately?

If those answers exist, the 24-hour clock becomes an operational constraint that can be managed. Without them, the deeper problem is not that the deadline is short. It is that the organisation does not yet know what it has to do, when, or why.