Cyber Resilience Act: your embedded incident plan
Updated 24 September 2026
Source-checked: 24 September 2026.
For an embedded-product manufacturer, incident reporting needs an operational owner before an incident occurs. Define who assesses an alert, who can obtain reliable product information and who can submit a notification. A shared mailbox without an escalation path is not an incident plan.
The European Commission states that manufacturer reporting obligations for actively exploited vulnerabilities and severe product-security incidents apply from 11 September 2026. ENISA launched the initial operating capability of the Single Reporting Platform on that date. The CRA’s wider requirements generally apply from 11 December 2027. See the Commission’s reporting guidance and ENISA’s launch notice.
Scope: EU Cyber Resilience Act reporting for manufacturers of in-scope products with digital elements. Confirm product scope, exclusions and the responsible legal entity with your regulatory or legal lead. This engineering workflow is not a determination that a particular product falls within the Act.
Separate the reporting triggers
Do not equate every vulnerability-scanner finding with confirmed active exploitation. Keep the evidence behind the classification: the affected component, relevant product versions, available exploitation information and the reasoning used to assess the reporting trigger. Similarly, assess an incident against the applicable severity criteria rather than treating every service interruption identically.
Use two linked records: a technical investigation and a reporting decision. The investigation may evolve; the decision record should show who assessed the available information and when. If the situation is unclear, escalate promptly instead of letting a ticket remain unowned while a deadline may be running.
Put the clocks where the team can see them
Article 14 requires action without undue delay: the early warning has a 24-hour outer limit and the notification a 72-hour outer limit, measured from awareness of the applicable trigger. The vulnerability final report is due within 14 days after a corrective or mitigating measure becomes available. The severe-incident final report is due within one month after submitting the incident notification. These are different clocks. Check Article 14 of the Regulation for the information required and cases where it has already been provided.
A practical incident board should therefore include the awareness timestamp, trigger under assessment, early-warning due time, notification due time and a separately owned final-report milestone. Preserve time-zone information. Record new findings without overwriting the original chronology. Assign a deputy for weekends, leave and supplier time-zone differences.
Prepare the product evidence before an alert
- Identify the product family, hardware revisions and firmware releases affected by a component.
- Maintain a route from a reported component version to the shipped product configuration.
- Keep a current engineering contact for each critical supplier and software component.
- Record which mitigations can be deployed remotely and which need physical service.
- Define who approves customer instructions and how those instructions reach affected users.
- Arrange access to the reporting platform and current official operating guidance before it is urgently needed.
Build a concise evidence bundle rather than forwarding an unfiltered development archive. Include the relevant release identifiers, observed behaviour, affected functions and current mitigation status. Separate verified observations from hypotheses. Avoid including customer data or secrets that are unnecessary for the investigation or notification.
Exercise the handover with a realistic scenario
Run a tabletop exercise using a fictional advisory for a networking library present in two firmware branches. Ask the team to identify affected releases, locate the responsible supplier, find the reporting owner and draft the first internal summary. The useful result is a list of missing links and unclear responsibilities, not a claim that a short exercise proves compliance.
Include an awkward case: a field device on an older firmware branch, an unavailable supplier contact or a report arriving outside normal working hours. Measure how quickly the team can establish a defensible product scope. Preserve the exercise assumptions so a successful rehearsal is not mistaken for a tested response to every incident type.
Keep platform procedure and legal scope current
Use ENISA’s SRP FAQs alongside the Commission guidance. The FAQs address operational and reporting questions, including the treatment of awareness before the reporting start date. Revisit official instructions when the process changes; do not embed an old interpretation permanently in a ticket template.
The CRA policy page is a useful starting point for the wider implementation context. Within the engineering team, the immediate deliverable is simpler: a named response owner, accessible product configuration evidence and a rehearsed escalation route. DVAR’s embedded software and product development work can support the technical foundations; product-specific reporting and legal decisions remain with the responsible manufacturer.