The Cyber Resilience Act, Regulation (EU) 2024/2847 (CRA), does not generally apply until 11 December 2027. One earlier milestone is now only a week away: the Article 14 mandatory reporting obligations apply from 11 September 2026. Manufacturers will need to use the CRA Single Reporting Platform (SRP) for two defined occurrence types—actively exploited vulnerabilities and severe incidents affecting the security of products with digital elements.
This is not a 24-hour reporting rule for every vulnerability, product defect or routine service interruption. A manufacturer first needs to establish whether the product is within CRA scope, which occurrence category may apply, and when the organisation became aware of the relevant facts. The immediate operational priority is an escalation path that can move technical evidence to the people authorised to make those decisions.
Which occurrences require an Article 14 assessment?
ENISA’s current FAQ describes an actively exploited vulnerability as one for which reliable evidence shows that a malicious actor has exploited it in a system without the system owner’s permission. A theoretical attack path, scanner result or ordinary vulnerability with no reliable exploitation evidence does not automatically meet that definition.
An incident affecting product security is one that negatively affects, or is capable of negatively affecting, the product’s ability to protect the availability, authenticity, integrity or confidentiality of data or functions. Mandatory incident reporting under Article 14 also requires severity. ENISA’s published SRP fields align that assessment with two criteria: an actual or potential negative effect on the protection of sensitive or important data or functions, or the actual or potential introduction or execution of malicious code in the product or in a user’s network and information systems.
Security teams should preserve the evidence source, affected products and releases, exploitation or incident facts, impact and initial severity rationale. The legal threshold is fact-specific; a CVSS score, customer count or public disclosure status should not be treated as a complete decision rule.
The 24-hour, 72-hour and final-report stages
The reporting clock begins when the manufacturer becomes aware of an actively exploited vulnerability or severe incident. Current Commission and ENISA guidance describes the sequence as follows:
- Early warning within 24 hours: submit without undue delay and, in any event, within 24 hours of awareness. A completed root-cause investigation is not a prerequisite for this first signal.
- Vulnerability or incident notification within 72 hours: submit without undue delay and, in any event, within 72 hours of awareness, including general information and an initial assessment. Later stages update the same SRP notification record.
- Final report: for an actively exploited vulnerability, submit no later than 14 days after a corrective or mitigating measure becomes available. For a severe incident, ENISA’s current FAQ states that the final report is due within one month after the initial notification.
These stages should form one traceable record: discovery, awareness, early warning, 72-hour update, remediation or mitigation, and final report. Record who made each decision and which evidence was available at the time. Internal approvals do not stop the regulatory clock, so the workflow needs weekend, holiday and cross-time-zone coverage.
Reporting route and platform readiness
Manufacturers submit once through ENISA’s SRP. The platform routes the notification to the relevant CSIRT designated as coordinator and, as a general rule, makes it available to ENISA simultaneously. The receiving CSIRT is primarily determined by the manufacturer’s main EU establishment. A non-EU manufacturer will normally need to consider its authorised representative’s place of establishment and the ordering rules in Article 14(7); customer location, cloud hosting location or port of import should not be used as a shortcut.
As of 4 September, the Commission and ENISA state that the SRP is scheduled to be operational by 11 September and that its public URL will be announced before launch. Submitters will use personal EU Login accounts with two-factor authentication. A business can identify its Primary and Secondary Assigned Representatives now, while following ENISA’s current advice to initiate SRP registration and association validation when a notification is actually needed. If the platform is temporarily unavailable, a submission is still required through the SRP once service returns; urgent direct contact with a CSIRT does not replace that step.
Do pre-2027 products need to be covered?
Yes, potentially. Although most CRA obligations generally apply from 11 December 2027, Article 70(3) makes Article 14 applicable to in-scope products with digital elements placed on the market before that date. Reporting readiness should therefore cover relevant installed and supported releases, not only new products planned for launch after 2027.
The reporting obligation is not retrospective for active exploitation that the manufacturer already knew about before 11 September 2026, according to the current ENISA FAQ. Historical investigation records should still be preserved, and new evidence, expanding impact or a separate occurrence after the start date should receive its own assessment. “Legacy release” is not an automatic exclusion.
A practical readiness checklist for the final week
- Map product families, commercial models, hardware, firmware, software and key third-party component versions.
- Route vulnerability mailbox, customer support, field service, SOC, supplier and researcher reports into a defined intake process.
- Document how a technical finding escalates to organisational awareness, including decision ownership and timestamps.
- Prepare decision questions for active exploitation and severe incidents, retaining both evidence and dissenting views.
- Define the minimum product and occurrence fields needed at 24 hours and the impact, mitigation and user-action fields needed at 72 hours.
- Name the reporting owner and backup, prepare EU Login access, map the likely CSIRT route and establish out-of-hours contacts.
- Run a no-submission tabletop exercise to test whether cross-functional approval can meet both windows.
ENISA may update fields and operating instructions as the SRP launches. Teams should use the official page and platform requirements current on the submission date, and date-version their rehearsal material rather than treating it as a permanent regulatory template.
How Qianxin can support readiness
For a defined product, destination market and written scope, Qianxin can support preliminary CRA scope and standards mapping, identification of relevant test needs, sample-to-hardware and software version checks, and consistency reviews across test evidence, technical files and vulnerability-handling records. Whether an occurrence meets the Article 14 threshold, when manufacturer awareness is established, selection of the CSIRT, regulatory submission and legal responsibility remain matters for the manufacturer based on complete facts and applicable law. Qianxin does not submit SRP notifications on behalf of manufacturers.
This article reflects official public information available on 4 September 2026 and provides general compliance information only. It is not product- or incident-specific legal advice or a final conformity assessment.
