Cyber Resilience Act 2026: The 24/72-Hour Reporting Workflow for Products with Digital Elements
Transparency note
This article was created automatically with AI. The linked primary sources from the European Commission, ENISA and EUR-Lex were checked during creation on 19 August 2026; no substantive human editorial review took place before publication. The article contains no customer cases or measured project results and provides operational guidance, not legal advice.
Many businesses associate the Cyber Resilience Act with 11 December 2027. That is too late for reporting: from 11 September 2026, manufacturers must report actively exploited vulnerabilities and severe incidents when they affect the security of products with digital elements.
That starts a timed process as soon as a relevant event becomes known. Manufacturers have no more than 24 hours for the early warning and 72 hours for the fuller notification. If product data, owners and evidence are only assembled after the event, a security problem becomes a deadline problem as well.
The good news is that reporting is deliberately staged. The full investigation does not have to be complete within 24 hours. What matters is a workflow that records the event cleanly, escalates it in time, prepares the data required at each stage and preserves evidence of every submission.
In brief
- The earlier date matters: Article 14 applies from 11 September 2026, while most other CRA duties start later.
- T0 must be reliable: The point of awareness starts the deadlines and should change only through a documented, auditable reassessment.
- Technical response and reporting run in parallel: Containment and analysis continue while each reporting stage is prepared.
- Automate internally, control externally: ENISA currently provides no submission API, so the SRP handoff remains a human review step.
- Use one dossier: Product data, decisions, drafts and submission evidence belong in the same case file.
Who this guide is for
Scope before workflow
This guide covers only the operational reporting process under Article 14 CRA. It is aimed at manufacturers of products with digital elements; open-source software stewards are included only to the extent that they are involved under Article 24(3). Not every SME is a manufacturer, not every vulnerability is actively exploited and not every security incident is severe for CRA purposes. The product, business role and event require a separate legal and technical assessment.
The deadlines at a glance
| Stage | Deadline | Process objective |
|---|---|---|
| T0 — awareness | Record immediately | Store the raw signal, first recorded T0, source, product and evidence with an audit trail; version every reassessment |
| Early warning | Without undue delay, within 24 hours at the latest | Submit the minimum data through the Single Reporting Platform |
| Main notification | Without undue delay, within 72 hours at the latest | Add general information, an initial assessment and measures |
| Final: vulnerability | No later than 14 days after a corrective or mitigating measure is available | Complete the description, severity, impact and remedy |
| Final: incident | Within one month after the 72-hour notification | Document cause, impact and ongoing measures |
The SRP provides a single reporting route. It sends the notification to the responsible CSIRT coordinator and, as a rule, to ENISA at the same time. Internally, each submitted version should still be retained with its time and reference.
The internal reporting workflow in seven steps
- 1. Capture signals centrally: Monitoring, support, engineering, external researchers and suppliers need one unambiguous intake route. Every signal creates a case, not just another email.
- 2. Keep T0 traceable: Store the raw signal and first recorded T0 with an audit trail. If a qualified review changes the awareness time, the old and new values and the reason must remain auditable.
- 3. Start technical response and reporting triage in parallel: Containment, analysis and patch work continue while the CRA owner assesses active exploitation or a severe product-security incident. Automation distributes tasks; it does not make the legal classification.
- 4. Enrich the case with product master data: Manufacturer name, product, product type, category and affected Member States should flow from a maintained product register—not from the incident team’s memory.
- 5. Build the 24-hour package and submit it under control: The workflow checks minimum fields, flags gaps and creates a clear handoff. A named person verifies content and identity, enters the notification in the SRP and stores proof of submission.
- 6. Continue the investigation for the 72-hour notification: Technical teams add the nature, impact, initial assessment, measures already taken and measures available to users. Changes from the early warning remain traceable.
- 7. Control the final report and closure: Deadline logic distinguishes a vulnerability from a severe incident. The case closes only after the final report has been submitted, evidence archived and remaining corrective work transferred into the normal product process.
The flow connects product security, engineering and compliance. Our guide to business process automation for SMEs explains how to turn those handoffs into a maintainable end-to-end process.
A field and role matrix for your runbook
These role names are operational recommendations, not an organisational structure prescribed by the CRA. The field groups follow ENISA FAQ Q16; check the then-current SRP form again before the first live report.
| Field group | 24 hours | 72 hours / final | Suggested owner |
|---|---|---|---|
| Master data | Notification type and level, manufacturer or steward, product and title; product type and category optional, add available market details | Confirm or update | CRA coordinator + product owner |
| Actively exploited vulnerability | CVE, EUVD and initial detail where available | 72h: nature of the vulnerability and exploitation, corrective or mitigating measures taken and steps users can take. Final: full description, severity, impact, plus the date and details of the available corrective measure | Product security + engineering |
| Severe incident | Indicate suspected unlawful or malicious acts | 72h: nature, detection and occurrence times, initial assessment, measures taken and steps users can take. Final: detailed description, severity, impact, likely root cause or threat type and ongoing mitigation | Incident lead + engineering |
| Sensitivity | Apply an internal marker where apparent | State at 72h where available; review and carry forward in the final report | Security + CRA coordinator |
| Submission evidence | Submitted version, time and SRP reference | Each new and final version, time and reference | Named submitter + deputy |
What is worth automating without an API
ENISA draws a clear boundary: organisations may automate internal reporting workflows and integrate the requirements into systems and databases, but no submission API is provided at this stage. That does not mean “no automation”. It means a controlled human handoff.
Good automation candidates
- Create a case from monitoring, support or engineering signals
- Preserve T0 history and calculate every subsequent deadline
- Enrich the case from product and contact master data
- Validate fields, assign tasks, remind and escalate
- Version drafts and store submission confirmations centrally
Keep deliberately human
- Decide whether the event is reportable
- Assess sensitive information and approve the wording
- Check identity, case and version before SRP entry
- Sign in and submit through the SRP
- Confirm successful transmission and its reference
Set the right system boundary
A brittle browser bot wrapped around login and submission is not a substitute for an API. A reliable design ends at a clear handoff: fully prepared internally, then checked and submitted externally by an accountable person.
Three weeks to operational readiness
Week 1: Scope and owners
Record products and roles, validate the decision path, name the CRA coordinator, technical lead, submitter and deputy. Define one intake route and the rule for recording T0.
Week 2: Case model and automation
Map the ENISA field groups, generate checklists, implement deadlines and escalation, then test versioning and a two-person handoff with evidence storage.
Week 3: Rehearse two scenarios
Run a tabletop for an actively exploited vulnerability and a severe incident—including absence and an after-hours signal. Fix missing fields and approve the runbook.
Check the latest ENISA information and the real SRP form again as soon as the platform is publicly available. The exercise is not a customer case and produces no marketing metric; its purpose is to make your own process reliable before a real event.
Four metrics that make the process manageable
- T0 latency: Time from the first reliable signal to the documented starting point.
- Field completeness: Share of the data required at each stage that is ready before internal review.
- Deadline risk: Open tasks and approaching breaches per case.
- Evidence rate: Submissions with a fully archived version, reference and timestamp.
These metrics measure the organisation’s own process. They do not prove legal compliance and are intentionally presented without invented benchmarks or customer outcomes. Our guide to monitoring AI workflows adds practical sampling and escalation principles for ongoing operation.
Conclusion: automate deadlines, keep accountability visible
The CRA reporting process is neither just a security ticket nor just a compliance form. It connects product knowledge, technical analysis, deadlines, approvals and reliable evidence. Those handoffs are what affected SMEs need to design before 11 September.
The decisive architecture choice is the automation boundary: data, tasks, deadlines and drafts come together in a structured way; classification, approval and SRP submission remain traceable to accountable people. That creates a workflow that can operate during a real event instead of being invented in the middle of one.
Sources and photo credit
Checked on 19 August 2026.
- European Commission: CRA reporting obligations – updated 31 July 2026; application date, reporting stages, final-report deadlines and the Single Reporting Platform status.
- ENISA: Single Reporting Platform FAQ – updated 3 August 2026; especially deadlines, the current lack of an API and field groups in Q7, Q15 and Q16.
- European Commission: new CRA guidance – published 27 July 2026; scope, risk assessment and reporting obligations with particular attention to SMEs.
- EUR-Lex: Regulation (EU) 2024/2847 – binding legal text, especially Articles 14, 16 and 24.
- ENISA: current SRP interface functions – updated 14 August 2026; roles, dashboard and notification status.
- Photo: Jakub Pabis on Unsplash, Unsplash License; commercial use and editing permitted. The source page identifies a Sony ILCE-7M4 and shows a real circuit board without people or recognisable brand logos.
Do not invent the workflow during the incident.
Lyron can turn security, product and compliance facts into a traceable reporting workflow with deadline logic, field validation, escalation and a controlled SRP handoff. Legal classification stays with you and your qualified advisers; we build the process that gets the right information to them in time.
Discuss your CRA workflowShare this article: