The EU's Cyber Resilience Act reporting duty is already in effect. Since September 11, 2026, manufacturers of products within scope must report actively exploited vulnerabilities and severe security incidents. The European Commission's reporting page confirms the start date and the reporting deadlines. Waiting for the regulation's wider application date is no longer a workable incident plan.
The practical challenge is connecting evidence of an attack to someone who can file a notification. Your incident response process needs to do that while engineers are still investigating, before they have a complete explanation or a finished patch.
This article reflects the official guidance checked on September 16, 2026. The reporting platform is live, and its documentation has changed since the period before launch.
The deadlines have different starting points
The Commission specifies an early warning within 24 hours of awareness and a fuller notification within 72 hours. The final report for an exploited vulnerability is due within 14 days after a corrective measure becomes available. For a severe incident, the final report is due within a month after the 72-hour notification.
Those are not consecutive blocks on one countdown. The initial deadlines share an awareness starting point; the final deadline depends on the kind of event. Put each trigger in the incident record. Otherwise a team may incorrectly treat the fuller notification as an extension that starts when the early warning is sent.
Prepare a short incident record that can grow as the investigation develops. Keep observed facts separate from hypotheses. Record when evidence arrived, who assessed it, which product and versions appear affected, and what remains unknown. An unfinished investigation needs an owner and a next action, not a silently moving start time.
Old products and newly discovered evidence
The Commission implementation FAQ, updated September 4, explains that Article 69(3) brings earlier products within the reporting obligation when they otherwise fall within scope. It also distinguishes a vulnerability found through legitimate testing from one with reliable evidence of malicious exploitation. A bug bounty finding without that evidence is not, by itself, an actively exploited vulnerability.
For your team, this means keeping a way to identify old releases when a customer reports an attack. The current development branch is not a complete inventory of what customers run. Record the product name, release identifier and responsible contact somewhere support can find without knowing who originally wrote the code.
Do not assume a researcher finding the bug means an attacker has used it. Equally, do not assume a familiar bug is harmless because it already has a ticket. Ask what evidence has changed. A report of exploitation and an old record of the underlying defect answer different questions.
ENISA's current FAQ clarifies the transition: manufacturers do not retrospectively report exploitation they already knew about before September 11. Awareness after that date can trigger reporting even for an older vulnerability. It also confirms that the corresponding steward obligations begin on December 11, 2027. Reporting must happen without undue delay; the stated hours are outer limits.
The platform is available now
ENISA's Single Reporting Platform page now links to the operational portal. Use that official entry point when preparing your incident instructions. Remove any internal note saying the address will be supplied at launch.
The registration guide, updated September 12, requires a personal EU Login account with multifactor authentication. Verification of the representative's association with the manufacturer runs alongside reporting; it is not a prerequisite for the first submission. ENISA advises initiating platform registration when a notification is needed, while the EU Login account can be prepared beforehand.
That distinction matters when assigning preparation work. Confirm that the responsible person can access their own account and authentication method. Do not turn a shared password into your backup plan. Write down how your team will collect the manufacturer information and identify the appropriate coordinating national response team.
The interface guidance, also updated September 12, now permits up to 20 notifications while the association is unverified. A primary representative must be verified before inviting secondary representatives. The primary can access the manufacturer's notifications; secondary access is limited to their own submissions and drafts.
Those permissions deserve a place in your handover plan. A colleague knowing that a report exists does not establish that they can open or update it. Decide how the evidence and the next required action will remain available inside your own incident system, with access restricted to the people handling the case.
A saved draft is not a filed warning
ENISA's submission guide distinguishes saving a private draft from submitting an early warning. It describes the fuller notification and final report as later stages of an existing notification. Missing mandatory fields cause validation errors.
For the incident owner, the important operational question is whether the platform accepted the submission. Keep the notification identifier, submission confirmation and timestamp with the incident record. A screenshot of completed fields or an internal message saying the form is ready is weaker evidence than confirmation that it was submitted.
Rehearse the internal handover with a fictional incident, without filing a test notification into the live service. Have support provide the initial evidence, engineering identify the affected product, and the reporting owner explain what they would submit. Check whether someone can carry that work forward if the original owner becomes unavailable.
What this does not change
This reporting start date does not mean every CRA requirement started at once. The Commission's implementation timeline distinguishes the earlier provisions on conformity assessment bodies, the reporting start and full application on December 11, 2027.
It also does not settle whether every service or every open source project is within scope. Product architecture and the organization's role matter. Resolve that question against the applicable guidance before treating this article as an incident classification decision.
Reporting does not replace containment, a fix or clear communication with affected users. The useful engineering response is to make evidence, responsibility and submission status visible while that work continues. The clock is already running when the reporting trigger is met; the team needs to know who is carrying it.
Written by Dandelion Labs