EU Cyber Resilience Act reporting starts on 11 September

Overview

EU Cyber Resilience Act reporting begins on 11 September 2026, more than a year before its main product-security requirements apply in full. From that date, manufacturers must report certain actively exploited vulnerabilities and severe security incidents affecting products with digital elements.

The timetable is demanding: an early warning within 24 hours of awareness, a fuller notification within 72 hours, then a final report on a separate deadline. The European Commission’s 27 July guidance explains how the rules apply, while ENISA is preparing the Single Reporting Platform that manufacturers will use. The immediate task is not to produce a complete compliance programme overnight. It is to make sure a real security alert can reach the right people, be classified against the correct product, and become an adequate first report before the first clock expires.

EU Cyber Resilience Act reporting arrives before full application

The Cyber Resilience Act has been in force since December 2024, but its provisions do not all start together. The European Commission’s implementation timeline identifies three dates that businesses should keep separate.

Rules concerning notification of conformity-assessment bodies began applying on 11 June 2026. The vulnerability and incident reporting obligations begin on 11 September 2026. Most of the Act’s other obligations apply from 11 December 2027.

That sequencing creates a practical trap. A team working towards a December 2027 product-compliance programme can still miss a reportable event in September 2026. Incident reporting therefore needs its own readiness track, with owners, evidence sources and escalation routes that work before the broader programme is complete.

The Commission’s 27 July Cyber Resilience Act guidance announcement confirms that the new guidance is non-binding. It helps manufacturers and other businesses interpret scope, substantial modifications, support periods, reporting and risk assessment, but it does not replace the Regulation or case-specific advice from a competent authority or qualified adviser.

That distinction matters when a security team has to make a close classification decision. Guidance can explain the framework and provide examples. It cannot turn every ambiguous product architecture, contractual role or incident into a universal answer.

Two occurrence types trigger mandatory reporting

The Commission’s CRA reporting page identifies two types of occurrence that manufacturers must notify from 11 September.

The first is an actively exploited vulnerability contained in a product with digital elements. Active exploitation requires reliable evidence that a malicious actor has exploited the vulnerability. A newly disclosed weakness, a scanner finding or a vulnerability in a dependency is not automatically the same thing. That differs from ordinary remediation priority: Pagalishor's Oracle July patch triage guide shows how a large vendor release can demand quick work without making every listed flaw an active-exploitation report.

The second is a severe incident having an impact on the security of a product with digital elements. The Act’s severity test concerns effects on the product’s availability, authenticity, integrity or confidentiality and the conditions set out in Article 14.

Those categories require product-level assessment. A component vulnerability may be important to investigate without being exploitable in the way that component is used in a particular product. Conversely, a flaw inherited through a dependency cannot be dismissed merely because the manufacturer did not write the vulnerable code. The operational question is what is present, reachable and affecting the product.

The 27 July guidance also matters for products already on the EU market. The Commission’s summary says the Article 14 reporting obligations apply to products with digital elements made available on the Union market, including products placed there before the CRA’s main December 2027 application date. A reporting process designed only for new launches would therefore leave a gap around older supported products and installed versions.

Open-source software needs careful role analysis. ENISA says its platform will support reports from manufacturers and open-source software stewards, but their legal obligations are not identical. The Commission’s CRA summary describes reporting duties for open-source stewards to the extent specified by the Act. A repository maintainer, commercial distributor, steward and manufacturer should not be treated as interchangeable labels.

The 24-hour warning is the first test

The first notification is an early warning due within 24 hours after the manufacturer becomes aware of a reportable occurrence.

That is not much time for a company that has not already resolved ownership. A security alert may arrive through a researcher, customer, supplier, automated monitor or national authority. The recipient may know that something is wrong without knowing which shipped versions contain the affected component, whether exploitation is reliable, or which legal entity placed the product on the EU market.

The 24-hour stage exists so an early signal can be shared before every fact is known. It should not be confused with the final technical account. The reporting process needs a controlled way to state what is known, what remains under investigation and why the occurrence appears to meet the reporting threshold.

A workable early-warning path should answer a short set of questions:

• When did the organisation first become aware of the relevant facts?
• Which product and versions may be affected?
• Is the occurrence an actively exploited vulnerability or a severe incident?
• What evidence supports that initial classification?
• Which legal entity is the manufacturer for the affected product?
• Which CSIRT should coordinate the report?
• Who may submit through the Single Reporting Platform?
• Who can approve a preliminary report outside normal business hours?

The awareness time needs disciplined recording. An alert timestamp alone may not establish when the manufacturer became aware of a reportable occurrence, but reconstructing that decision days later is a weak control. Incident records should preserve the original signal, triage steps, key evidence and the point at which the classification was escalated.

The 72-hour notification needs more than an alert summary

A full notification follows within 72 hours of awareness. By then, the manufacturer is expected to provide a more developed assessment.

The additional time should be used to confirm the product identity and affected versions, analyse exploitation or incident impact, preserve indicators and timelines, and document mitigation already taken. Security, engineering and product teams may need to establish whether vulnerable code is reachable in the shipped configuration and whether observed activity affected the product itself rather than an unrelated internal system.

This stage exposes weak product inventories. A company may have a vulnerability scanner yet still lack a reliable link between a component, a build, a commercial product name and the customers or markets receiving that version. A software bill of materials can help, but only if it reflects what actually shipped and can be queried during an incident.

The same is true of ownership records. A central security team may understand the vulnerability while being unable to identify the manufacturer’s main establishment, the responsible product entity or the appropriate CSIRT. Those are poor questions to settle while a 72-hour deadline is running.

Preparation should connect four records that companies often maintain separately: the product catalogue, released versions, component or dependency data, and incident-response evidence. The reporting workflow does not need to merge every system into one database. It does need a dependable route from a security signal to the affected product and reporting entity. The same mapping discipline appears in Pagalishor's CISA KEV deadline analysis, although the CRA test and reporting destination are different.

One useful control is a product-level evidence packet that can be assembled without waiting for a reportable event. It can identify the released build, component inventory, support owner, market entity, logging source and normal update channel. During an incident, the team then adds exploitation evidence, observed impact and mitigation status. This does not decide the legal threshold in advance. It removes clerical uncertainty from the first hours, leaving technical and legal reviewers to focus on the classification that actually matters.

Final reports run on two different clocks

The final-report deadline depends on what was reported.

For an actively exploited vulnerability, the Commission says the final report is due no later than 14 days after a corrective or mitigating measure becomes available. That formulation links the deadline to the availability of the measure, not simply to the 72-hour notification.

For a severe incident, the final report is due within one month of the 72-hour notification.

These clocks should be encoded separately in the incident workflow. Treating “final report” as one generic 30-day task risks applying the wrong deadline to an exploited vulnerability. The system should record the occurrence type, the 72-hour submission time and, where relevant, when a corrective or mitigating measure became available.

A final report should reconcile the early account with the completed investigation. Material changes in scope, affected versions, impact, root cause or mitigation should be explained, not silently overwritten. That gives authorities a usable record and prevents the organisation’s internal incident history from diverging from what it submitted.

The final report is also where technical remediation and reporting need to meet. A fix may exist in source control before it is built, tested or available to users. Teams should define what “available” means for their delivery model using the Regulation, current official guidance and appropriate legal interpretation. An article cannot settle that question for every cloud service, embedded device, mobile application or distributed software package.

The Single Reporting Platform is the submission route

Manufacturers will report once through the CRA Single Reporting Platform. ENISA is responsible for establishing, managing and maintaining it.

The ENISA SRP FAQ describes the platform as a single electronic entry point. A manufacturer will select the CSIRT designated as coordinator, generally based on the location of its main establishment, and the notification will be addressed to that CSIRT and ENISA. The receiving CSIRT will disseminate the information to other relevant CSIRTs in Member States where the product is available, subject to the Act’s exceptional provisions for delayed dissemination.

Reporting once does not remove the need to prepare the underlying jurisdiction and product information. Someone still has to know the reporting entity, its main establishment, where the product is available and which details belong in the notification.

ENISA says the platform is scheduled to be operational by 11 September, with a testing period expected beforehand. Its FAQ points organisations to the data fields needed for reporting. That makes field mapping a useful preparation exercise even before production submission begins.

Teams should avoid assuming that a familiar EU vulnerability service is the correct destination. ENISA’s EU Vulnerability Database FAQ says the EUVD and CRA Single Reporting Platform serve different purposes. The SRP handles CRA reports, including sensitive reports about active exploitation. The EUVD is designed to make information about publicly known vulnerabilities accessible. A CVE publication process does not substitute for a CRA notification.

SRP readiness starts inside the company

The highest-value preparation is a rehearsal that begins with an imperfect alert, not a polished compliance form.

Choose one relevant product and simulate a report arriving on a Friday evening. Require the team to identify the shipped versions, validate whether vulnerable functionality is reachable, find the reporting entity, select the responsible CSIRT, draft the early warning and preserve an approval record. Then continue the exercise through the 72-hour notification and the correct final-report clock.

The exercise should test absence as well as presence. What happens when the component inventory is stale, the product owner is unavailable, exploitation evidence is credible but incomplete, or several entities sell related versions? A plan that works only when every field is known immediately does not match the purpose of an early warning.

Companies can prepare reusable material without pre-judging future incidents:

• Product names, identifiers, supported versions and responsible entities
• Main-establishment and CSIRT-routing information
• Authorised SRP users and backup submitters
• Security and legal contacts with out-of-hours coverage
• A record of where shipped-component evidence can be queried
• A template separating confirmed facts, preliminary assessment and unknowns
• A decision log for awareness time and reportability
• A timer for the 24-hour, 72-hour and applicable final-report deadlines
• A process for correcting or supplementing earlier information
• Evidence that a submission was completed

Templates should help teams move quickly, but they should not turn uncertain facts into boilerplate assertions. A short, accurate early warning is more defensible than a confident narrative built from assumptions.

Public discussion points to ownership and inventory friction

Recent public Reddit discussions about CRA readiness repeatedly raise three operational questions: who owns the report, whether the company can identify vulnerable dependencies in shipped products, and whether teams are preparing for September 2026 or still planning only around December 2027.

Those discussions offer useful questions for a rehearsal. They are not reliable evidence of market-wide readiness. The threads reviewed were small, several contributors disclosed commercial interests, and some posts promoted compliance products or linked analyses. Engagement was too limited to support claims about what “most companies” have done.

The practical concerns still deserve attention because they can be tested internally. A company either can or cannot identify its reporting owner. It either can or cannot connect a vulnerable component to a shipped product. It either has or has not rehearsed the 24-hour route. Those are better readiness measures than an anecdotal estimate of industry preparedness.

Tools may help with inventories, workflow and evidence collection. They do not decide legal scope on their own. A dashboard that labels every dependency vulnerability “CRA reportable” would erase the distinction between a known flaw and reliable evidence of active exploitation affecting a product. The distinction also separates CRA reporting from a normal exploited-flaw patch guide: remediation can be urgent even while the Article 14 threshold is still being tested.

The July guidance narrows uncertainty without removing judgement

The Commission’s July package addresses recurring implementation questions, including which products fall within scope, what may amount to a substantial modification, how support periods work, and how risk assessment and reporting should be approached.

That is valuable, but “guidance published” should not be translated into “every product question is settled.” The Commission expressly describes the guidance as non-binding and says it may issue more guidance under Article 26.

Manufacturers therefore need a decision process that can preserve uncertainty without stopping the clock. Product-security staff can establish the technical facts. Product and supply-chain owners can explain how the software or device is made available. Legal and compliance teams can assess the applicable role and reporting threshold. The submission owner must bring those strands together quickly enough to meet the staged deadlines.

Where the answer remains genuinely unclear, the organisation should use the official material and obtain advice appropriate to its facts. This article provides an operational preparation framework, not a legal conclusion about any product or event.

A useful August checkpoint is one completed rehearsal

By the end of August, a manufacturer does not need to have completed every task associated with the December 2027 deadline to improve its September readiness. It should, however, be able to demonstrate one full reporting rehearsal for a real product line.

The evidence should show who received the alert, when awareness was recorded, how the product and versions were identified, why the event was or was not classified as reportable, which CSIRT route was selected, what entered the early warning, and how the later deadlines were calculated.

Any failure in that rehearsal becomes a concrete repair item. A missing component map calls for inventory work. An uncertain manufacturer record calls for entity mapping. A delayed approval calls for an out-of-hours escalation rule. An inaccessible submission account calls for SRP onboarding and backup access.

The first legal clock begins on 11 September 2026. The safest operational assumption is that the first qualifying alert will not wait for a convenient weekday, a complete investigation or the broader 2027 compliance programme.