CRA: prepare vulnerability and incident reporting before 11 September

On 11 September 2026, a very concrete part of the Cyber Resilience Act (CRA) becomes applicable: manufacturers will have to report actively exploited vulnerabilities and severe incidents affecting the security of their products with digital elements.15

This date does not mean that every CRA obligation is already applicable. The regulation's main obligations will apply from 11 December 2027. The reporting mechanism, however, starts in September 2026.2

For a manufacturer, the operational challenge is therefore no longer simply to understand the regulation. It is to answer a much more concrete question: if a vulnerability is exploited tomorrow morning, can we identify the affected product, impacted versions, remediation status and the facts required for an initial report within 24 hours?

Three deadlines, but one timeline to control

For both an actively exploited vulnerability and a severe incident, the process starts when the manufacturer becomes aware of the event.13

An early warning must be submitted without undue delay and, in any event, within 24 hours. A more complete notification must follow within 72 hours. The final report then follows a different timetable: no later than fourteen days after a corrective or mitigating measure becomes available for an actively exploited vulnerability, and within one month after the notification for a severe incident.13

Stage	Maximum deadline	Internal question to resolve
Awareness	T0	What do we actually know, and who qualifies the event?
Early warning	24 h	Which product is affected and what is the nature of the event?
Notification	72 h	What is the scope, which versions are affected, what is the impact and what is the initial assessment?
Final report — vulnerability	≤ 14 days after a corrective measure becomes available	What consolidated analysis and remediation information is available?
Final report — severe incident	≤ 1 month after notification	What are the cause, consequences and definitive measures?

This progression matters: the CRA does not require the company to know the entire story in the first hours. It does, however, require it to identify what it knows, when it knew it and which product that information relates to.

A CVE is not yet a CRA case file

An actively exploited vulnerability is a vulnerability for which there is reliable evidence that a malicious actor has exploited it without the permission of the system owner.35

This creates an important operational distinction. A known vulnerability, even a critical one, does not automatically fall into this category simply because of its severity. The regulatory trigger depends here on reliable evidence of active exploitation.

Conversely, receiving a CVE identifier or a security alert is not enough to constitute the case file. The organisation must still determine which products are affected, which versions embed the vulnerable component, which versions are supported, what measures are available and the current state of the analysis.

This is where vulnerability management meets product lifecycle management.

The real object to track is a product in a given version

An organisation may have a very good vulnerability inventory and still respond slowly to the CRA if that inventory is not connected to the product reference system.

Cybercoria proposes reasoning around a minimal internal case file such as:

cra_case:
  id: CRA-...
  event_type: actively_exploited_vulnerability | severe_incident
  aware_at: ...
  evidence_refs: [...]
  products:
    - product_id: ...
      version_range: ...
      support_status: ...
      markets: [...]
  vulnerability:
    identifier: ...
    component: ...
    exploitation_evidence: ...
  incident:
    security_properties_affected: [...]
    impact: ...
  corrective_measure:
    status: ...
    available_at: ...
    affected_versions: [...]
  reporting:
    coordinator_csirt: ...
    early_warning_at: ...
    notification_72h_at: ...
    final_report_due_at: ...
  evidence_refs: [...]

This structure is a Cybercoria editorial proposal, not a model imposed by the regulation. It highlights the joins that are likely to consume time: event → vulnerability → component → product → version → support → remediation → reporting.

Ambiguous product naming becomes a compliance issue here. If the security team refers to a component by its technical name, support refers to a product by its commercial name and development uses the repository name, the first challenge may simply be proving that everyone is talking about the same scope.

The Single Reporting Platform will not replace preparation

ENISA is setting up a Single Reporting Platform (SRP) intended to serve as the single entry point for CRA reports. It is due to be operational by 11 September 2026.13

The manufacturer will submit its report electronically by selecting the CSIRT designated as coordinator, determined from its main establishment. The platform then organises the routing required by the European framework.3

ENISA has already published user guidance. The process includes an early warning, the 72-hour notification and the final report. A notification may be saved as a draft or updated while it remains open and before the final report has been submitted.4

This interface solves the transmission problem. It does not solve the internal data collection problem. If the company discovers while preparing the report that it cannot state precisely which versions are affected, which component is embedded or who can validate the information, the portal will not shorten that investigation.

Constructed case: one compromised library across three product versions

Consider a fictional software vendor selling an application installed in customer environments. Three branches are still in use: 4.8, 5.2 and 6.0. Only versions 5.2 and 6.0 remain within their support period.

At 09:15, the security team receives reliable evidence that a vulnerability affecting an embedded library is being actively exploited. At 09:40, it confirms that the library is present in all three branches. At 11:10, the product team establishes precisely which versions are affected and their support status. A fix for 6.0 is ready the next day; the 5.2 fix requires more work.

The case cannot be managed only from the vulnerability ticket. At least four reference systems must be connected: software components, product versions, support policy and the remediation release chain.

In a prepared organisation, these relationships make it possible to answer simple questions quickly: where is the component used? which versions are affected? which remain supported? who decides on the corrective measure? when does that measure become available?

In a less structured organisation, the same questions trigger repository searches, exchanges across several teams and sometimes reconstruction of version history.

This case is deliberately simplified. The precise legal qualification of an event, the expected content of each report and the applicable obligations depend on the actual situation and must be assessed against the regulation and official guidance.

The support period becomes cybersecurity data

Guidance published by the Commission on 27 July 2026 provides practical clarification on several CRA concepts, including support periods, substantial modifications, risk assessments and reporting obligations.2

From an information architecture perspective, this reinforces a simple idea: a product catalogue cannot stop at name and version. It must make it possible to retrieve support status, relevant components and associated maintenance decisions.

This information serves several purposes: determining the scope of a vulnerability, organising remediation, informing relevant teams and documenting treatment over time. The CRA therefore turns information sometimes managed mainly as commercial or support data into information that is useful for product cybersecurity governance.

What to test before 11 September

Little time remains before the reporting obligations become applicable. A useful exercise does not necessarily require a full crisis simulation.

Select a real product and a fictional vulnerability in one of its components. Start a timer. Then ask the teams to retrieve: the affected versions; their support status; the product owner; the evidence needed to establish exploitation; remediation status; the coordinating CSIRT; and the people authorised to prepare the report.

Measure above all the time spent finding the information rather than entering it.

ENISA states that representatives will use an EU Login account to access the platform and that validation of their authority to act on behalf of a manufacturer will be carried out by the coordinating CSIRT. Procedures may vary between CSIRTs, and ENISA recommends consulting the latest guidance.3

This point should therefore be part of the exercise as well: know who can act, not only who holds the information.

11 September does not instantly transform the entire product security organisation. It does, however, create a measurable constraint: moving from a vulnerability or incident signal to a traceable product case file within a short regulatory deadline. For many organisations, the best readiness test is now to verify whether that chain can be followed without reconstructing the context at every stage.