The reporting obligation under the Cyber Resilience Act applies from 11 September 2026 and runs through a single channel, the single reporting platform operated by ENISA. On 14 August the Agency updated the operating instructions for that platform and added a rule that did not appear in its July answers: a representative whose association with the manufacturer has not yet been verified may submit no more than ten notifications. Three weeks before the deadline, the conditions of use of the channel through which a legal obligation is discharged are still being settled in guidance pages, and the address of that channel is not yet public.
What was updated in August
The legal framework was already settled in July, when the European Commission published its guidance on the application of the regulation and ENISA updated its answers on the platform. That step, and the three separate dates that Article 71 of Regulation (EU) 2024/2847 sets for entry into application, were covered on this blog in the piece explaining what starts on 11 September and what does not. What has changed over the past fortnight does not concern the rule, it concerns the way the rule is performed.
ENISA has split its guidance into three separate pages, each describing step by step how the representative appointed by the manufacturer is to use the platform: user registration, notification submission and update, and interface functions. The first two are marked as last updated on 3 August, the third on 14 August. Those same pages warn that the information is provided according to current best knowledge and may be subject to change, and invite readers to consult the latest available version before applying the instructions. That is a reasonable caveat for a user manual; it is less so for the document which, in the absence of anything else, describes how an obligation backed by penalties is to be discharged.
The ten-notification limit for the unverified representative
The substantive novelty sits in the page dated 14 August, in the passage explaining how to associate an account with an additional manufacturer. The association is created with the status “Unverified” and generates a verification request addressed to the CSIRT designated as coordinator, which reviews and approves it. In the meantime, ENISA writes, “as unverified AR you can submit only up to 10 notifications”: a representative who has not been verified may submit up to ten notifications and no more.
The limit must be read alongside what the registration guidance, updated eleven days earlier, states at the outset: validation of the representative by the coordinating CSIRT takes place after registration, “is not a prerequisite for fulfilling the CRA reporting obligation”, runs in parallel with the reporting process and does not affect the ability to submit notifications through the platform. The two statements do not contradict one another, yet taken together they say something other than either says alone: verification is not a precondition for reporting, but the ability to report without it is quantitatively capped. None of the pages consulted specifies what happens once the tenth notification has been submitted, nor within what time the CSIRT is to rule on the verification request.
When to register: ENISA’s guidance
In order not to add to the workload of the CSIRTs designated as coordinators, ENISA advises registering and starting the verification process only when a specific notification actually has to be submitted, rather than creating an account pre-emptively. The advice is consistent with the administration’s interest, less so with that of the party bound by the obligation, because the early warning under Article 14(2)(a) must be submitted without undue delay and in any event within twenty-four hours of the manufacturer becoming aware of the actively exploited vulnerability or of the severe incident.
Anyone following that advice to the letter will have to complete, within those twenty-four hours, the entire sequence described in the guidance: opening the platform website, selecting the role, choosing the designated CSIRT, authenticating through EU Login, reading and accepting the legal agreement, confirming the pre-filled personal details and entering the manufacturer’s details. The only step that can genuinely be taken in advance is the creation of the EU Login account, which ENISA says can be set up now. Everything else presupposes a platform that cannot yet be reached, and the sequence will in any case have to be worked through while an incident is under way.
The platform’s functions for the representative
The 14 August page also describes the working environment, and that description reveals constraints worth knowing beforehand rather than during. The dashboard displays the notifications accessible to the associated manufacturer, but only the drafts created by the user who is logged in: one representative cannot see drafts prepared by another representative associated with the same manufacturer. The primary representative may invite a secondary representative for the same manufacturer, and the secondary may ask to take on the primary role, the request being forwarded to the CSIRT designated as coordinator. Red alerts, ENISA specifies, appear only where an exceptional or critical action has occurred, for instance where a designated CSIRT has invalidated a submission.
That last point deserves attention, because the guidance does not say what effect the invalidation of a submission has on compliance with the twenty-four and seventy-two hour deadlines, nor whether and how the notification is to be resubmitted. On the published sources, that information is not available.
The notification template and its legal nature
In its frequently asked questions, updated on 3 August, ENISA publishes the table of fields for the reporting form, indicating for each whether it is mandatory or optional at the twenty-four hour stage, at the seventy-two hour stage and in the final report. In practice, that is the notification template. Article 14(10) of the regulation, however, provides that it is for the Commission to further specify, by means of implementing acts, the format and procedures for the notifications referred to in Articles 14, 15 and 16. That is a power and not a duty, so its non-exercise amounts to no omission; the fact remains that three weeks before the deadline the actual reporting template sits in a frequently asked questions page rather than in a binding act, and as such may be amended with no procedure and no publication.
In the same answers ENISA makes clear that organisations may automate their internal reporting workflows, but that no application programming interface will be made available at this stage. Anyone managing a broad product portfolio will therefore have to fill in by hand, one at a time, forms designed to be submitted within twenty-four hours. It is the same asymmetry already noted in relation to the self-assessment model for small and medium-sized enterprises, where the supporting tool arrives ahead of the substantive obligations yet carries no legal weight of its own.
The public address still missing
The first step of the registration procedure, in the guidance dated 3 August, reads literally as opening the platform website, with the parenthesis “URL to be provided at launch”. The frequently asked questions confirm that the public address will be communicated on the same page before the platform goes live, and that a testing period is expected before 11 September, without giving any dates for it. The only appointment fixed in relative terms is the webinar ENISA foresees holding two weeks before the platform enters into service, while security will be checked through user and security testing before launch and through periodic re-checks afterwards. The only firm date in all of this remains the date of the obligation itself.
What is left to do in these weeks does not depend on the platform. Organisations need to settle who inside the organisation has the authority to qualify a fact as an actively exploited vulnerability or as a severe incident and to trigger the notification, because the twenty-four hours run from awareness and not from remediation; to identify the CSIRT designated as coordinator that is competent by reference to the main establishment in the Union, under Article 14(7); and to create in good time the EU Login accounts of the people who will actually report. They also need to decide, in the light of the ten-notification ceiling, whether it is really preferable to wait for the first incident before starting the verification of the association, as ENISA suggests with the CSIRTs’ workload in mind, or whether it is more prudent to start it earlier, knowing that the risk of waiting falls on the manufacturer. This is a matter of internal organisation and accountability, of the same kind the European framework is moving towards the top of the company, and it needs deciding now, because 11 September will not move.
