Cyber Resilience Act reporting starts Sept. 11 on an unfinished platform

Editor’s Note: In six days the Cyber Resilience Act starts requiring manufacturers to report actively exploited vulnerabilities within 24 hours of becoming aware. The platform they must file through has no published web address.

ENISA updated its guidance Sept. 4, and the update is the story. No API at launch, so every filing against the clock is a person and a form. No voluntary reporting through it at launch. If it is down, ENISA says to wait. And ENISA discloses that its 72-hour counter can show a report overdue before 72 hours have run from awareness.

A second timing question sits underneath. The regulation’s penalty article is not among the provisions that take effect early, so on the face of the text its fine ceilings apply only from Dec. 11, 2027. No official guidance reviewed addresses enforcement before then.

Anyone checking whether open-source stewards face fines should read the corrected regulation. A July 2025 correction moved the boundary of the penalty exclusions, and the original text gives the wrong answer.

For cybersecurity, privacy, compliance, and eDiscovery readers, the operative question is when a manufacturer became aware – a judgment to be evidenced rather than defined.

Watch for the address and the counter logic.

News Analysis – Cybersecurity Beat

Cyber Resilience Act reporting starts Sept. 11 on an unfinished platform

ComplexDiscovery OÜ Staff

Six days before the Cyber Resilience Act’s reporting clock starts, the system manufacturers must file through has no published address. The European Union Agency for Cybersecurity says the address will appear on its platform page before the platform goes live, and it says the platform is scheduled to go live Sept. 11.

That is the same day the duty attaches. Article 14 of the Cyber Resilience Act applies from Sept. 11, 2026; Articles 35 to 51 have applied since June 11, 2026; and the regulation generally applies from Dec. 11, 2027. From Sept. 11, a manufacturer that becomes aware of an actively exploited vulnerability contained in its product with digital elements must notify the national Computer Security Incident Response Team designated as coordinator and the agency simultaneously, through the single reporting platform established under Article 16. The regulation defines an actively exploited vulnerability as one “for which there is reliable evidence that a malicious actor has exploited it in a system without permission of the system owner.” An early warning is due “without undue delay and in any event within 24 hours” of awareness, a fuller notification within 72 hours, and a final report no later than 14 days after a corrective or mitigating measure is available. The same clock governs severe incidents, except that their final report falls due within one month of the 72-hour notification.

The agency, known as ENISA, updated its platform guidance on Sept. 4, marking almost every answer as changed or new. That update is the most useful document in this story, because it says plainly what the platform will not do.

What the platform will and will not do on day one

The platform ships without a machine interface. ENISA’s guidance states that “no Application Programming Interface (API) will be provided at the initial release of the SRP, so notifications must be submitted through the platform interface,” and adds that such functionality “may be considered in a future phase.” Organizations may automate their own internal workflows up to the point of filing, but the filing itself is a person and a form. Crowell & Moring attorneys Lauren Cuyvers, Grace Tang and Eric Montens reached the same conclusion in a June 12 client alert, telling clients that “There is no API at this stage” and that “Submissions are manual through the SRP, an online platform.” That alert promotes the firm’s CRA services alongside the analysis, and should be read with that in mind.

Voluntary reporting will not be available through the platform either. Article 15 lets manufacturers and other persons report vulnerabilities, cyber threats, incidents and near misses to a coordinating response team or to ENISA on a voluntary basis, and ENISA now says the platform “has not yet implemented the voluntary reporting functionality” and will add it later. The agency’s own procurement record set a wider target: tender ENISA/2025/OP/0001, listed with a maximum budget of 11 million euros over four years and a status of completed, sought a “turnkey solution” whose initial implementation had to support both the mandatory notifications under Article 14 and the voluntary ones under Article 15. The pages reviewed do not explain the gap between what the tender required at initial implementation and what ships on launch day, and the two need not be the same thing.

Set against that, the readiness picture is not uniformly thin. ENISA published its list of CSIRTs designated as coordinators on Sept. 4, and every one of the European Union’s 27 member states appears on it with a contact point. Registration guidance for assigned representatives carries an Aug. 3 update stamp and the interface guidance an Aug. 14 stamp. The agency says the platform underwent user and security testing before launch and that national response teams took part.

Registration is designed to be quick. A representative needs an EU Login account with multi-factor authentication, and ENISA says that where such an account already exists, registering takes a few minutes. One primary representative per manufacturer can invite up to 20 secondary representatives. The coordinating team validates the tie between representative and manufacturer afterward, which does not block filing. ENISA’s Sept. 4 guidance says a representative that has not yet cleared can file as many as 20 notifications for a single manufacturer before validation turns mandatory. The agency’s own interface guide, last updated Aug. 14, puts that ceiling at 10, and the two pages have not been reconciled. The design assumes companies will register when they first need to file, which is a sensible way to spread the load on national teams and an awkward thing to attempt for the first time against a 24-hour clock.

Open-source software stewards sit inside the perimeter, and Article 24(3) sets their exposure in two limbs. The Article 14(1) vulnerability duty reaches a steward to the extent it is involved in the development of the product with digital elements. The Article 14(3) incident duty and the Article 14(8) duty to inform users reach a steward to the extent severe incidents affect network and information systems that the steward provides for that development. Both limbs are tied to development, so what a steward owes follows from the part it plays in building the product and running the systems used to build it. That is a question about the steward’s own function rather than about how far downstream its code travels.

The awareness line, and where it actually comes from

Whoever is filing, the clock starts on awareness, and Article 14 contains no exemption for exploitation a manufacturer already knew about. The trigger in the statutory text is awareness, and the text does not carve out awareness that predates the application date. The exemption practitioners have been discussing comes from somewhere else, and its provenance matters as much as its existence.

ENISA’s Sept. 4 guidance attributes it to the European Commission. A manufacturer, the agency says, “is not required to retrospectively report” an actively exploited vulnerability where it was already aware of the active exploitation before Sept. 11, 2026, citing subsections 5.1 and 5.3 of the Commission’s implementation FAQ. That is guidance rather than statutory text, and the difference matters for what a manufacturer can build on it.

The same answer then closes most of the door it opens. Where a manufacturer becomes aware of active exploitation after Sept. 11, ENISA says the obligation applies, “including where the underlying vulnerability existed or was previously known.” Awareness of a vulnerability is not the exempting fact. Awareness of its active exploitation is, and only where that awareness predates the deadline, which means a 5-year-old bug in a shipped product becomes reportable the moment a manufacturer learns someone is exploiting it. Product age offers no shelter of its own either. Article 69(3) carries the Article 14 duties back to every in-scope product placed on the market before Dec. 11, 2027, and it does so as an express derogation from the rule that older products come into scope only when they are substantially modified.

On the face of Article 71, the duty may begin before the fine regime does. Article 71 accelerates two things and only two: Article 14, from Sept. 11, 2026, and Chapter IV, Articles 35 to 51, from June 11, 2026. Article 64, which sets the penalties, is in neither list, which, in the plain text, puts it at Dec. 11, 2027, with the rest of the regulation. Read that way, the reporting duty runs 15 months ahead of the regulation’s own fine regime. The official materials reviewed do not address what enforcement looks like in the interval, and no authority has confirmed the reading.

When Article 64 does apply, it leaves the penalty rules themselves to member states, requiring only that they be effective, proportionate and dissuasive, and it caps administrative fines for breaches of Article 14, alongside Article 13 and the Annex I essential requirements, at 15 million euros or, where the offender is an undertaking, 2.5 percent of total worldwide annual turnover for the preceding financial year, whichever is higher. Read those as ceilings rather than tariffs. The same article directs authorities to weigh the nature, gravity and duration of the infringement, whether fines have already been applied for similar conduct, and the size and market share of the operator, with microenterprises and small and medium-sized enterprises named for particular regard.

Two carve-outs sit in the same article. Article 64(10) removes those fines for manufacturers that qualify as microenterprises or small enterprises, but only for missing the 24-hour early warning under Article 14(2), point (a), or Article 14(4), point (a). The 72-hour notification and the final report stay in scope, and medium-sized firms get no exemption, although their size remains a factor authorities must weigh. The second carve-out is broader: Article 64(10) also excludes any infringement of the regulation by open-source software stewards.

Read the corrected text rather than the one first published, because on this provision they give different answers. A corrigendum published in July 2025 changed the derogation in Article 64(10) from paragraphs 3 to 9 to paragraphs 2 to 9. Paragraph 2 is the tier that covers Article 14, so only the corrected version reaches reporting breaches at all. Work from the original Official Journal text and a steward appears to sit inside the fine regime for a late filing; work from the consolidated text, and it plainly does not. Recital 120 reads the same way as the correction, adding that member states “should not impose other kinds of penalties with pecuniary character on those entities.”

How a U.S. catalog enters a European question

Proving which side of that line a company fell on will not be done from the filings themselves. Article 14 notifications do not land in a public register. They route to the coordinating response team and to ENISA, then onward to other national teams and to market surveillance authorities. ENISA’s own publishing runs to disclosing fixed vulnerabilities to the European Vulnerability Database and to biennial trend reports, not to a running register of who reported what and when. The dated public record of exploitation is being kept somewhere else, by a different government, for a different reason.

The U.S. Cybersecurity and Infrastructure Security Agency maintains the Known Exploited Vulnerabilities catalog, a dated, machine-readable list of flaws for which the agency has determined there is evidence of exploitation. Its Sept. 4 release carried 1,695 entries. Nineteen were added from Aug. 26 through Sept. 4 alone, across 14 vendors and projects including Microsoft, Google, Citrix, Red Hat, SonicWall, PaperCut and ownCloud.

Practitioners should resist the tidy version of what follows. A catalog entry dated before Sept. 11 is not proof that a given manufacturer was aware of active exploitation before Sept. 11, and it is not an exemption. The catalog records CISA’s determination, on CISA’s timeline, for a United States federal remediation program, while the European duty turns on the manufacturer’s own awareness of exploitation of its own product. What the catalog does supply is a public, dated record that anyone can consult afterward, which means a company’s account of when it learned of exploitation will sit beside a timestamp it did not control. Treat that as an evidentiary convenience for whoever asks the question later, not as a legal boundary.

A counter that can show a report overdue

The platform keeps a clock of its own, and the Sept. 4 update discloses that it does not start where the statute starts. ENISA says that in the current release, the 72-hour counter displays a due date 48 hours after the 24-hour report is submitted, rather than counting from the moment of awareness. The consequence is stated on the page: “a notification might be displayed as overdue before 72 hours from when the manufacturer or open-source software stewards has become aware of the event.” The agency says the logic will change in a future release, once a field recording the date and time of awareness becomes required, and that the counters “do not replace the duty” to comply with Article 14.

Outages have a stated answer too, and it is not a paper fallback. If the platform is temporarily unavailable, ENISA says manufacturers “should wait until it becomes available again” and then submit. A company that judges immediate communication necessary may contact its designated response team directly, but the notification must still go through the platform once service returns. No alternative channel discharges the obligation.

Preparation that should already be finished

With no fallback channel and no API to submit through, what remains is preparation, and outside counsel has been consistent about where it sits. In an Aug. 18 client alert, DLA Piper’s Muhammed Demircan, Nicholas De Lacy-Brown, Lorcan Moylan Burke and Rachel De Souza urged manufacturers to document escalation triggers, reporting thresholds and, pointedly, “decision criteria for ‘awareness'” before an event forces the question. They also warned that a single event can trigger the Cyber Resilience Act, NIS2, DORA and the General Data Protection Regulation at once, each with its own thresholds and content requirements, and recommended tabletop exercises aimed at whether the right people can be assembled within 24 hours. Their closing line is the one worth pinning above a desk: “Those that wait until the first vulnerability or incident occurs may find that the greatest risk is not the cyber event itself, but the inability to respond quickly enough to satisfy the regulator.” DLA Piper, like Crowell, is selling services alongside the analysis.

The concrete steps are small and mostly clerical. Create the EU Login accounts and turn on multi-factor authentication now, because doing it during an incident burns hours the clock is already counting. Decide who the primary representative is and who the backups are. Identify the coordinating response team for your member state of main establishment from the list ENISA published Sept. 4. Decide in advance who makes the awareness call and on what basis, and record the reasoning alongside the time. The trigger is not something an organization sets for itself. ENISA points readers to subsection 5.1 of the Commission’s implementation FAQ on how a manufacturer becomes aware, and to Section 9.1 of the Commission’s July 27 guidance for the details. Read both before setting the internal criteria your team will apply.

One step belongs to the records people rather than the security team. The platform does ask for a time: ENISA’s glossary, updated Sept. 5, lists a field for the date and time you became aware of an incident, which the current release labels as the moment the incident was detected, and an equivalent field for actively exploited vulnerabilities that the agency says arrives in the next release. What the platform will not do is evidence the answer you enter. That proof sits in ordinary business records, in the ticket that logged a threat-intelligence alert, the vendor advisory in an inbox, the chat thread where an engineer said the exploit looked real, and those artifacts will substantiate whether a filing was timely and whether the pre-Sept. 11 position is available at all. Organizations that already run legal holds have the machinery, and the change is recognizing that a routine security ticket has become a potentially dispositive document in a regulatory question. Remember, too, that Article 14 requires a manufacturer to inform impacted users of the vulnerability or incident, a duty that sits alongside the filing and that no platform performs on anyone’s behalf.

Six days out, the deadline is fixed, and the address is not. Which of those two facts will your incident response plan meet first?

News sources

• Single Reporting Platform (SRP) frequently asked questions (ENISA)
• List of CSIRTs Designated as Coordinators (ENISA)
• CRA SRP Glossary (ENISA)
• CRA SRP guidance, Assigned Representative interface functions (ENISA)
• Implementation of the Single Reporting Platform, tender ENISA/2025/OP/0001 (ENISA)
• Regulation (EU) 2024/2847, the Cyber Resilience Act, consolidated text (EUR-Lex)
• Corrigendum to Regulation (EU) 2024/2847, 2 July 2025 (EUR-Lex)
• Cyber Resilience Act reporting obligations (European Commission)
• Frequently Asked Questions on the CRA implementation (European Commission)
• Guidance to support timely Cyber Resilience Act implementation (European Commission)
• Known Exploited Vulnerabilities Catalog (CISA)
• The CRA’s 24-Hour Rule: Preparing for the Cyber Resilience Act’s September 2026 Reporting Obligations (DLA Piper)
• EU Cyber Resilience Act Countdown: 11 September 2026 Incident/Vulnerability Reporting Deadline (Crowell & Moring)

Assisted by GAI and LLM Technologies

Additional reading

• Europe’s draft cloud rule would put vendor ownership in the audit file
• The eight-hour clock starts today: EU e-evidence orders now land on covered U.S. providers’ EU addressees
• California’s AI Transparency Act arrives alongside Europe’s Article 50
• Federal magistrate judge treats LinkedIn’s Relativity aiR workflow as TAR
• One benchmark, three directions: 2026 legal rates rise, flatten and fall at once
• Confidence cools, commitment holds: full results from the 1H 2026 eDiscovery Business Confidence Survey
• Complete look: ComplexDiscovery OÜ’s 2025 to 2030 eDiscovery market size mashup
• The workstream of eDiscovery: Considering processes and tasks

Source: ComplexDiscovery OÜ

ComplexDiscovery’s mission is to enable clarity for complex decisions by providing independent, data‑driven reporting, research, and commentary that make digital risk, legal technology, and regulatory change more understandable for practitioners, policymakers, and business leaders.