What should teams do first when a CRA reportable vulnerability is discovered?

Teams should immediately preserve evidence, timestamp awareness, and decide whether the issue is an actively exploited vulnerability, a severe incident, or both. Then they should route the case to the authorised filing path, because the first 24 hours determine whether the organisation can meet the early-warning obligation and maintain a defensible record.

Start With Evidence Preservation, Not Interpretation

The first move is to lock down facts, because CRA reporting is time-sensitive and the case can quickly become unreportable or defensively weak if the timeline is unclear. Teams should preserve logs, alert records, affected build or deployment artefacts, hashes, and any operator notes that show when the issue was first detected and who knew about it. That record supports both the reporting decision and any later supervisory review.

Teams also need to classify the event immediately against the reporting trigger, since a reportable vulnerability may overlap with an active exploitation event or a broader severe incident. The practical question is not just “what was found?” but “what is the safest defensible classification right now?” For teams that struggle with asset and secret visibility, NHIMG’s Ultimate Guide to NHIs notes that only 5.7% of organisations have full visibility into their service accounts, which is a reminder that weak observability makes early case handling harder, not easier.

In practice, many teams lose the reporting race before they lose technical control, because the evidence needed to prove timing and severity was never captured in the first hour.

Route the Case Through the Authorised Filing Path

Once evidence is preserved, the next step is to route the matter to the people who can make the reporting call and file it on time. That usually means security, product, legal, compliance, and incident response working from one shared case record, not separate email threads. The organisation needs a single owner for the reporting workflow, because the early-warning obligation depends on coordinated judgement, not scattered awareness.

Teams should establish, from the outset, whether the issue is purely a vulnerability report, a vulnerability with active exploitation indicators, or a severe incident that must be handled as both. The classification matters because it changes the urgency, the escalation path, and what needs to be documented. A good filing path should therefore capture minimum required facts, preserve timestamps, and keep the initial narrative stable while investigation continues. The supporting operational discipline is similar to what broader control catalogues emphasise for incident handling, logging, and response, including CIS Controls v8.

Record first detection time, internal notification time, and any evidence of exploitation.
Assign one case owner who can coordinate legal, technical, and regulatory decisions.
Freeze the initial report text so later findings do not overwrite the original timeline.

These controls tend to break down when severity triage is left to the engineers who found the issue, because they may fix the flaw before the reporting record is complete.

Common Variations and Edge Cases

Tighter reporting discipline often increases workload, which means teams must balance speed against accuracy rather than pretending both come for free. Some findings are straightforward, but others sit on the boundary between vulnerability, exploitation, and incident response, and current guidance suggests treating that boundary as a governance decision rather than a technical argument.

One common edge case is an issue that is discovered internally but may already be in the wild. Another is a weakness that is serious, but not yet confirmed as exploited. In those cases, the safest first step is still the same, preserve evidence and escalate into the authorised path, because premature closure is harder to defend than a well-documented initial report. When external advisories or threat context are needed to support that judgment, teams can cross-check against CISA cyber threat advisories or ENISA Threat Landscape material for contemporaneous threat framing.

For connected products, the reporting question may also be shaped by regulatory exposure under the EU Cyber Resilience Act, so teams should not assume that internal remediation alone is sufficient. The practical edge is simple: if the case might be reportable, handle it as if the clock has already started.

Risk and Threat Considerations

The main risk is delay, because reportable vulnerability handling is time-bound and incomplete first response can leave the organisation without a defensible timeline. A second risk is misclassification, where teams treat an exploited weakness as a routine defect and miss the reporting path that should have been opened.

Failure mechanism: The failure usually comes from fragmented ownership, unpreserved evidence, and late recognition that exploitation indicators or incident severity change the reporting obligation. Once the first narrative is overwritten or the timestamps are lost, the organisation may no longer be able to show when it became aware of the issue or why it chose a particular filing path.

Impact: The organisation can miss the early-warning deadline, weaken its regulatory position, and lose the ability to reconstruct what happened cleanly. Operationally, that also makes remediation, external communication, and later audit review much harder.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

CIS Controls v8 set the technical controls, while NIS2 define the regulatory obligations.

Framework	Control / Reference	Relevance
CIS Controls v8	17 — Incident Response Management	Reportable vulnerabilities need fast triage, escalation and evidence handling.
	8 — Audit Log Management	Preserving timestamps and logs is essential to defend the reporting timeline.
Recommendation — Align intake and escalation so vulnerability cases are logged, owned and routed through incident response quickly. Preserve and protect logs and timestamps needed to reconstruct discovery and notification timing.
NIS2	Incident reporting	CRA reportable vulnerabilities sit in a broader EU product and incident reporting context.
Recommendation — Map the internal case workflow to the applicable EU reporting duties and escalation deadlines.

Practitioner Guidance

What to prioritise: Preserve the initial evidence set before any remediation or cleanup work starts. The first question is whether the case can be proven, not whether it can be fixed quickly.

Decision rule: If there are signs of active exploitation, broaden the case immediately to incident handling and do not wait for complete technical confirmation before opening the reporting path. If the facts are still unclear, classify conservatively and keep the original timeline intact.

What to verify: Confirm that one named owner can state when the vulnerability was found, who was notified, and what filing route was chosen. If that cannot be answered from the record, the process is already behind.

Practitioner takeaway: The first job is to make the event reportable in a way that can still be defended later, because speed without evidence discipline is what usually creates the real failure.