When do CRA vulnerability reporting obligations apply?

The CRA reporting obligation will apply from September 11, 2026. The main body's obligations are scheduled for December 11, 2027. Enterprises should first determine whether their products fall within the scope of the regulation and establish a reporting mechanism; they cannot simply use a compliance checklist based on having software in their product without considering the specific roles involved. For automotive products or medical devices, additional checks against specialized regulations are necessary. Official EU Commission Introduction

When should a vulnerability enter the reporting assessment?

Article 14 focuses on two scenarios: when a manufacturer is aware of vulnerabilities in their product that are actively being exploited, or when there has been a serious event affecting product safety. Ordinary alert notifications from scans and the disclosure of new CVEs do not align with statutory reporting triggers. Teams need to document the time of awareness, product versions, evidence of exploitation or events, and promptly report these details to responsible parties for judgment.

How to interpret the three reporting deadlines

In the case of actively exploited vulnerabilities, early warnings should be submitted within 24 hours upon discovery, and full vulnerability notifications within 72 hours. Final reports on remediation or mitigation measures are typically due 14 days after these measures become available. The 14-day timeframe is not a uniform repair period. For severe incidents, there are separate notification and final report requirements that cannot be directly applied to the vulnerability branch. Warnings do not imply that investigations must be completed at the time of initial submission.

Four records companies should prepare in advance

1. Product Records: Product identifiers, supported versions, market release information, and supplier details to trace vulnerabilities back to specific deliverables.
2. Judgment Records: Intelligence sources, time of discovery, impact analysis, judgment triggers, and their basis; uncertain facts should be clearly indicated.
3. Disposition Records: Temporary mitigation measures, repair plans, validation results, and subsequent changes, retaining the responsible party and timestamp for each decision.
4. Communication Records: Responsible reporter, backup reporters, external reporting channels, and notification procedures to users; avoid information stagnating in a single engineer's email.

A controlled desktop exercise can be used to validate the process: who confirms the product scope, who organizes technical analysis, who submits materials, and who supplements additional information after receiving intelligence.

How the asset inventory supports response

SBOM can help associate components with product versions, still requiring analysis based on actual deployment and vulnerability conditions. Tools can assist in organizing data, tracking issues, and reporting decisions and responsibility mechanisms remain the organization's responsibility. For more information on how this evidence chain enters the development process, see CRA Vulnerability Management: From Component List to Repair Evidence.