CRA reporting readiness: what does it take in practice?

CRA reporting obligations started earlier than many organisations expected. Since 11 September 2026, manufacturers of in-scope products with digital elements need to be able to report actively exploited vulnerabilities and severe product-security incidents to ENISA and the designated CSIRT coordinator, such as the CCB in Belgium.

For many organisations, December 2027 has become the date associated with the Cyber Resilience Act. It is when the CRA becomes broadly applicable to products with digital elements placed on the EU market.

But the first operational reporting obligations arrived earlier. Since 11 September 2026, manufacturers of products within CRA scope must be able to notify actively exploited vulnerabilities and severe incidents affecting product security. The July 2026 Commission guidance confirms that this applies to products already placed on the market before 11 December 2027.

That changes the immediate question. It is no longer only whether an organisation can demonstrate full CRA conformity by 2027. It is whether it can detect, assess, escalate and report a product-security event under tight deadlines today.

Could your organisation determine, document and report a CRA-relevant product-security event tomorrow?

1. Why is the first CRA deadline an operational challenge?

At first glance, reporting sounds like a legal or compliance activity. In practice, the report is only the visible output of a much broader security process.

Before a manufacturer can report an actively exploited vulnerability, it needs to establish which products and versions are affected, whether the vulnerable functionality is reachable, whether exploitation is occurring in the product context, which users may be impacted, what mitigations are available, and who is authorised to make the reporting decision.

Those capabilities typically depend on Product Security, Application Security, Vulnerability Management, Incident Response and Engineering. Legal and compliance stakeholders remain important, but they cannot create the underlying technical evidence after an incident has already started.

The reporting sequence at a glance

2. When does the clock start? The concept of “becoming aware”

The reporting clock does not necessarily start with every vague signal, unvalidated rumour or suspicious support ticket. The Commission guidance explains that the relevant point is reached when, after an initial assessment, the manufacturer has a reasonable degree of certainty that a vulnerability is being actively exploited or that a severe incident has compromised the security of the product.

This distinction is useful but demanding. It means the organisation needs a fast and defensible route from signal to decision. Waiting for perfect certainty may create delay; treating every weak signal as confirmed may create unnecessary escalation. The operational capability lies in the initial assessment.

To make that assessment consistently, teams need agreed criteria, evidence sources and decision ownership. They should be able to reconstruct when a signal arrived, what was checked, when reasonable certainty was reached, who approved the conclusion, and when the external notifications were submitted.

Questions the process must answer

• Who performs the initial technical assessment?
• What evidence is sufficient to conclude that exploitation is active?
• How are affected products, versions and customers identified?
• Who can declare that reasonable certainty has been reached?
• How are uncertainty, dissent and approval recorded?

3. Why does reporting require more than a form?

For an actively exploited vulnerability, the process may require a 24-hour early warning, a 72-hour vulnerability notification and a final report no later than 14 days after a corrective or mitigating measure becomes available. For a severe incident, the process may require a 24-hour early warning, a 72-hour incident notification and a final report within one month after the incident notification.

These notifications must be submitted through ENISA’s Single Reporting Platform (SRP), which provides a single reporting channel and communicates the information to the relevant national CSIRT coordinator, such as the CCB in Belgium.

The early stages therefore cannot depend on drafting from scratch. Product identification, reporting contacts, approval paths, evidence handling and communication templates should already exist. The 72-hour submission then needs an initial technical picture: the nature of the exploit or incident, the affected product, the available impact assessment, measures already taken, measures users can take, and the sensitivity of the reported information.

After awareness, impacted users must also be informed and given relevant risk-mitigation or corrective measures where necessary. Communication should be timely, risk-based and proportionate. It should help users reduce exposure without disclosing technical detail more widely than needed while exploitation remains possible.

A third-party component can still become a product-level reporting issue

A public CVE in a dependency is not automatically reportable by every manufacturer using it. The organisation must determine whether the vulnerability is contained in its product context, whether the vulnerable code is reachable, and whether the condition meets the active-exploitation trigger. That judgement depends directly on the quality of the SBOM (software bill of materials), SCA (software composition analysis) coverage, dependency ownership and product-context reachability analysis.

4. What does this mean for each role?

For developers and product teams. Product teams do not need to become regulatory specialists. They do need to make product facts available quickly when an incident occurs.

• Maintain clear ownership for products, versions, deployment models and supported configurations.
• Link vulnerabilities and incidents to affected releases, components and customer environments.
• Preserve technical evidence and document mitigations, patches and workarounds.
• Escalate suspicious product-security signals instead of leaving them in ordinary support queues.

For Application Security and Product Security leads. The role shifts from finding vulnerabilities to enabling product-level decisions under time pressure.

• Provide an intake and triage process for reports from researchers, customers, suppliers and internal teams.
• Define exploitability, reachability and product-impact assessment criteria.
• Connect SBOM/SCA results, threat models and architecture knowledge to incident analysis.
• Maintain a decision log that shows how awareness and reportability were determined.

For incident response and PSIRT teams. CRA reporting readiness depends on a PSIRT (Product Security Incident Response Team) or equivalent operating model that connects technical investigation, product ownership, authority reporting and customer communication.

• Define escalation thresholds for actively exploited vulnerabilities and severe product-security incidents.
• Prepare 24-hour, 72-hour and final-report workflows and templates.
• Coordinate corrective measures, user guidance and ongoing updates.
• Exercise the workflow before a real event creates deadline pressure.

For CTOs and CISOs. Leadership needs assurance that the process works in practice, not only that a policy exists.

• Which products are in CRA scope, including products already on the market?
• Who owns the decision to report?
• Could the organisation determine active exploitation within 24 hours?
• Does the organisation know how ENISA and the designated CSIRT coordinator fit into the workflow?
• Could it prove the timeline of awareness, triage, approval, submission and user communication?

5. How do you build the reporting readiness bridge?

Most organisations do not need to invent entirely new security disciplines. The building blocks already exist in mature AppSec and product-security programmes. The work is to connect them into a repeatable, evidence-driven operating process.

6. How does this connect to AppSec and product security?

CRA reporting readiness is not separate from secure development. Secure SDLC practices create the product knowledge and traceability needed during an event. Threat modelling identifies abuse paths, critical assets and telemetry needs. OWASP SAMM can help assess whether governance, design, implementation, verification and operations practices are repeatable rather than informal.

SBOM and SCA capabilities become operational inputs to component analysis. Vulnerability management determines severity, exploitability, ownership and remediation. Incident response brings investigation and coordination. Product-security governance connects these capabilities to accountable decisions and customer communication.

The practical gap is often not the absence of every capability. It is that the capabilities operate in isolation. A useful readiness programme connects them before a real event forces the organisation to improvise.

The bottom line

The first operational CRA deadline was not December 2027. It was 11 September 2026, and the obligations now apply.

The organisations best prepared are those that can identify, assess, escalate and communicate product-security issues quickly and consistently. A large compliance function cannot compensate for weak product visibility, unclear PSIRT ownership or slow technical triage.

The good news is that the required building blocks are familiar: vulnerability management, PSIRT operations, threat modelling, SBOM/SCA, incident response and secure development practices. The challenge is turning them into one operational process that produces timely decisions, reliable evidence and proportionate communication.

That is the bridge organisations need to build now, before the first real event puts it to the test.

Next step. Our CRA Reporting Readiness Check assesses whether you can meet the reporting obligations today, from product scope and vulnerability intake to the ENISA workflow and evidence logging. Discover the CRA Reporting Readiness Check

Going further. Download our white paper “10 practical clarifications from the CRA guidance”. Download the white paper

Frequently asked questions

Is every public CVE in a component we use reportable?
No. It depends on whether the vulnerability is contained in your product context, whether the vulnerable code is reachable and whether it meets the active-exploitation trigger.

What is due within 72 hours?
An initial technical picture: the nature of the exploit or incident, the affected product, the available impact assessment, measures already taken, measures users can take, and the sensitivity of the information.

Do we need a new security function?
Usually not. The building blocks exist in mature AppSec and product-security programmes. The work is to connect them into one repeatable process.

Sources: European Commission CRA guidance, July 2026, Section 9.1 on reporting obligations. ENISA, CRA Single Reporting Platform (SRP).

This article offers a practical security reading of the CRA and the Commission guidance. It is not legal advice.