Cyber Resilience Act reporting obligations apply from 11 September 2026, earlier than the Regulation's main product requirements. Manufacturers must notify actively exploited vulnerabilities and severe incidents affecting the security of products with digital elements. The clock begins when the manufacturer becomes aware, so a workflow that starts only after legal confirms reportability is structurally late. Product telemetry, customer support, threat intelligence, vulnerability disclosure, suppliers, and incident response all need one awareness and escalation model.
The European Commission reporting guidance describes staged submissions through the CRA Single Reporting Platform: an early warning within 24 hours, a fuller notification within 72 hours, and a final report on the applicable schedule. The workflow must preserve uncertainty while the investigation develops. Early reports are not finished forensic narratives; they are controlled regulatory events tied to a product, awareness time, known impact, cross-border distribution, and planned mitigation. Design the evidence trail before the first real case tests it.
Define the reporting boundary and accountable manufacturer
Start with the in-scope product inventory, support status, versions, Union availability, legal manufacturer, main establishment, CSIRT route, and vulnerability contact. Reporting can apply to products made available before the main CRA application date, so do not restrict the register to new 2027 launches. Map white-label products, acquired portfolios, components sold separately, remote processing, and end-of-sale versions still supported. For each, name the person authorized to submit, an alternate, and counsel who can advise without becoming a bottleneck.
Suppliers, importers, distributors, open-source projects, researchers, and customers may surface the first signal. Contracts and disclosure pages should require rapid routing of exploitation or severe product-impact information without promising that every CVE is reportable. Link the workflow to the incident-response guide for containment mechanics, then add CRA-specific product scope, legal role, deadlines, platform submission, and authority communication. Maintain a tested out-of-hours route because awareness at 02:00 cannot wait for a weekly product meeting.
Classify actively exploited vulnerabilities and severe incidents
Do not equate vulnerability presence with active exploitation. The case needs credible information that a malicious actor has exploited the vulnerability, plus product identity and relevance. Sources can include validated customer evidence, telemetry, incident artifacts, a supplier statement, a researcher demonstration coupled with malicious use, or reliable public intelligence. Record the evidence, confidence, affected versions, attack prerequisites, and time it reached a person or system acting for the manufacturer. A queue label such as critical CVE is not enough.
A severe incident is assessed through its impact on the security of the product with digital elements, not simply the manufacturer's corporate network. Triage should capture whether the incident compromises the product's protective functions, availability, authenticity, integrity, confidentiality, or users through the product. Separate a compromise of a build system that could alter released artifacts from an ordinary office endpoint event with no product consequence. When facts are incomplete, record the competing hypotheses and next evidence needed; uncertainty is a managed state, not a reason to leave the clock blank.
| Signal | Decision question | Evidence | Immediate action |
|---|---|---|---|
| CVE appears in a component | Is the affected code present and has malicious exploitation occurred? | SBOM match, reachability, supplier and threat evidence | Open product case; do not report solely from a match |
| Customer reports compromise | Did the product vulnerability or security behavior enable it? | Logs, version, configuration, attack path and impact | Contain, preserve awareness time, escalate reportability |
| Build or update channel is breached | Could released product integrity or update trust be affected? | Signing, pipeline, artifact and distribution records | Stop release, protect keys, identify product population |
| Researcher provides exploit | Is there evidence of malicious exploitation beyond controlled research? | Disclosure correspondence and external intelligence | Remediate and monitor; reassess active exploitation |
| Hosted dependency fails | Does the event severely affect an in-scope product's security? | Service dependency, security effect and affected territories | Activate incident and legal assessment |
Build a timed Cyber Resilience Act reporting triage
Model the case as explicit states: signal received, product matched, awareness candidate, reportability under review, reportable, early warning submitted, 72-hour notification submitted, corrective measure available, final report submitted, and closed. Every transition should capture actor, timestamp, evidence, policy version, and reason. Assign a clock owner who can see remaining time and a technical owner who can update facts. The incident commander coordinates response; the regulatory owner protects submission quality; neither should silently overwrite the other's record.
Define awareness in policy and train teams to escalate before they debate it informally. Preserve the earliest plausible timestamp, when the signal was received, when credibility was established, and when reportability was decided. Counsel can later determine the legally controlling point, but missing timestamps cannot be reconstructed reliably. Use the incident-playbook planning guide to rehearse roles and handoffs. The exercise should begin with ambiguous supplier or customer evidence, not a perfectly labeled CRA event.
Prepare 24-hour, 72-hour, and final notifications
The 24-hour early warning should identify the event type, affected product where known, awareness timing, initial severity or impact, suspected unlawful or malicious acts, and cross-border relevance without presenting assumptions as facts. Use approved placeholders for unknown fields and name the next update owner. The 72-hour notification can add vulnerability or incident details, affected versions, exploitation or compromise evidence, severity assessment, indicators where appropriate, mitigation, and distribution footprint. Version every submission and retain the platform receipt.
For an actively exploited vulnerability, the final report is due no later than 14 days after a corrective or mitigating measure becomes available; for a severe incident, the Commission describes the final report as due within one month of the 72-hour submission. The final package should reconcile prior statements, explain root cause and impact, identify corrective measures, report deployment or user guidance, and close discrepancies. If a corrective measure changes, record why the final-report trigger was or was not reached. The CRA summary provides the timetable, while the Regulation remains authoritative.
| Stage | Decision-useful minimum | Quality control | Retained proof |
|---|---|---|---|
| Early warning within 24 hours | Event class, product, awareness, initial impact and suspected malicious activity | Unknowns labeled; no unsupported attribution | Payload, approver, timestamp and receipt |
| Notification within 72 hours | Affected versions, technical facts, severity, exploitation or incident evidence and mitigation | Product and territory data reconciled | Submitted version and investigation snapshot |
| Vulnerability final report | Root cause, corrective measure, availability date and affected population | Fourteen-day trigger documented | Release, advisory and report receipt |
| Incident final report | Cause, full impact, mitigation, recovery and lessons | Prior estimates reconciled | One-month deadline and closure approval |
| Material correction | Changed fact and reason | Legal and technical owners agree | Correction history without deleting prior record |
Coordinate the platform, CSIRT, ENISA, and internal records
Manufacturers report once through ENISA's Single Reporting Platform to the CSIRT for the Member State of their main establishment; the receiving CSIRT handles further dissemination under the CRA framework. Register accounts, strong authentication, authorized submitters, backups, and secure browsers before go-live. Test platform access during the announced testing period and maintain a documented contingency route for platform unavailability. A shared spreadsheet with credentials is not continuity planning. Submission authority should be narrow, monitored, and recoverable.
The regulatory case should link, rather than duplicate, incident, vulnerability, product, release, customer, and legal records. Store restricted submission content according to need-to-know, but expose deadlines and assigned actions to responders. Use the SaaS audit-log guide to specify immutable events for classification changes, approvals, exports, and submissions. Reconcile platform receipts and internal timestamps daily during an open case, especially when teams operate across time zones.
Connect corrective measures and customer communication
Regulatory reporting does not replace correction or user protection. Product security must decide whether to disable a feature, revoke credentials, rotate signing material, release a patch, update detection, publish configuration guidance, or withdraw a release. Track the measure by exact version and channel, test that it removes the exploit path, and monitor adoption. The final report should not claim remediation merely because code merged. The vulnerability-management guide offers a useful remediation queue; add regulatory deadlines and support-population evidence.
Customer communication should explain who is affected, what action is needed, supported workarounds, update authenticity, and where to obtain help. Coordinate regulatory, security-advisory, support, status-page, and contractual notices so they do not contradict one another. Avoid publishing exploit-enabling detail before mitigation is available, but do not withhold actionable protection. Record who approved each audience message, delivery channels, translations, and receipt or reach evidence. Importers and distributors need a defined route to the same current guidance.
Exercise and measure the reporting workflow
Run at least three scenarios: active exploitation in a direct component, a severe compromise of an update service, and ambiguous customer telemetry that ultimately is not reportable. Inject a weekend, unavailable approver, incomplete product inventory, and platform access failure. Measure time to product match, awareness escalation, classification, early warning approval, submission, corrective decision, customer message, and evidence reconciliation. Also measure false escalation and cases with no documented non-reporting rationale. Speed without a defensible decision record is not readiness.
After each exercise or real event, update contacts, templates, product data, decision criteria, and technical telemetry. Report readiness to leadership as overdue actions, unsupported products, missing submitter coverage, and exercise outcomes, not a generic compliant status. The reporting workflow becomes dependable when responders can move uncertain evidence through a controlled clock while remediation continues. That operating capability must exist before September 2026, not be assembled during the first exploited vulnerability.
Key takeaways
- Route product-security signals into one timestamped case model before reportability is known.
- Separate vulnerability severity from evidence of active exploitation.
- Treat product impact as the key boundary for severe-incident analysis.
- Prepare staged notification templates that preserve unknowns and reconcile later facts.
- Connect platform submission to corrective releases, customer protection, and retained receipts.
- Exercise ambiguous and out-of-hours cases before obligations apply on 11 September 2026.
CRA reporting obligations FAQ
Does every critical CVE require a CRA report?
No. Article 14 reporting distinguishes actively exploited vulnerabilities from vulnerability presence alone. Teams still need to assess and remediate serious flaws, but reportability requires the applicable CRA criteria and product facts.
Can legal review pause the 24-hour clock?
The workflow should assume it cannot. Escalate credible facts immediately, preserve plausible awareness timestamps, and conduct technical and legal assessment in parallel. An early warning can identify unknowns; an undocumented wait for certainty creates deadline risk.
Do reporting duties cover products sold before 2027?
The Commission states that Article 14 reporting applies to products with digital elements already made available on the Union market. Maintain historical product and support data so incidents can be matched to those versions.
Conclusion
A CRA reporting program is a timed product-security workflow, not a form-filling task. It succeeds when the manufacturer can identify the product and awareness point, classify credible evidence, submit honest staged information, protect users, and reconcile the final record. Building that path early gives responders room to investigate while the regulatory clock keeps moving.