CRA Article 14 Reporting Is Live. ENISA's Portal Counter Is Not the Legal Clock.

On 11 September 2026, Article 14 of the Cyber Resilience Act (Regulation (EU) 2024/2847) began to apply, and the European Union Agency for Cybersecurity (ENISA) announced the initial operating capability of the Single Reporting Platform at portal.cra-srp.enisa.europa.eu. From that date, manufacturers of products with digital elements must report actively exploited vulnerabilities and severe incidents through the platform, on a 24-hour early-warning clock. The obligation is now law in operation, and the infrastructure it depends on exists.

On 24 August we wrote that the portal was not yet publicly live and that the process had to be drilled without it. This is the sequel. The platform opened on the day the obligation applied, with guidance that ENISA's own pages date to 9 and 10 September. Its first published documentation tells manufacturers three things that matter more than the screens: the platform's deadline counter does not track the legal deadline, registration is meant to happen at the point of need, and the choice of coordinating authority can invalidate a filing. Each of those moves work back onto the manufacturer.

Key Takeaways

• Article 14 has applied since 11 September 2026. Under Article 71, the rest of the regulation applies from 11 December 2027. Under Article 69(3), the reporting duty covers in-scope products already on the market, so the existing portfolio is in scope now
• The clocks are unchanged: 24-hour early warning and 72-hour notification for both triggers, measured from awareness. Final report 14 days after a corrective or mitigating measure is available for exploited vulnerabilities, one month after the incident notification for severe incidents
• ENISA's FAQ states the platform's 72-hour counter shows a due date 48 hours after the early warning is submitted. A notification can display as overdue before the legal deadline, and ENISA says the counters do not replace the legal duty
• One submission reaches the CSIRT designated as coordinator and ENISA at the same time. ENISA's list covers all 27 Member States. Selecting the wrong coordinator may invalidate the notification
• ENISA advises registering only when there is a notification to submit. That supersedes the advice in our August piece to register in the platform's first days
• Exploitation a manufacturer was aware of before 11 September 2026 does not have to be reported retrospectively. Awareness on or after that date triggers the duty, even for an old vulnerability

What Applies From When Under Article 71

Some commentary published around the launch describes the regulation as coming into force on 11 December 2027, or implies that parts of the reporting regime wait until then. The text is more precise. Article 71 sets three application dates. The regulation as a whole applies from 11 December 2027. Chapter IV, on the notification of conformity assessment bodies, has applied since 11 June 2026. Article 14 applies from 11 September 2026, in full and for both triggers.

Two provisions explain the confusion. Article 69(2) says that products placed on the market before 11 December 2027 are subject to the regulation's requirements only if they are substantially modified after that date. Article 69(3) then carves the reporting duty out of that shelter: the obligations in Article 14 apply to all in-scope products placed on the market before 11 December 2027. A manufacturer cannot treat its installed base as outside the regime.

What does wait until 11 December 2027 is the reporting obligation of open-source software stewards under Article 24(3), which both ENISA's launch announcement and the European Commission's reporting page state. Manufacturers have no equivalent deferral.

The clocks are as we have described them since June, and ENISA, the Commission and the regulation agree on them. An actively exploited vulnerability requires an early warning within 24 hours of the manufacturer becoming aware, a vulnerability notification within 72 hours of becoming aware, and a final report no later than 14 days after a corrective or mitigating measure is available. A severe incident having an impact on the security of the product runs the same 24-hour and 72-hour front clocks, with a final report within one month after the submission of the incident notification.

What ENISA Actually Opened on 11 September

ENISA's announcement describes an initial operating capability, and the phrase is accurate. Per ENISA, manufacturers report once, the CSIRT designated as coordinator receives the notification first and shares it with CSIRTs in the other Member States where the product is available, and ENISA receives the notification at the same time. ENISA's FAQ adds the qualification from Article 16(2): simultaneous access holds unless particularly exceptional circumstances apply.

The supporting material is real and usable: an FAQ, a user manual and tutorial video for Assigned Representatives, a glossary, a factsheet and a published list of CSIRTs designated as coordinators covering all 27 Member States, last updated 10 September 2026. The registration and notification guidance pages carry last-updated dates of 9 and 10 September, which is a fair measure of how close to the deadline the system was finished.

The onboarding model is specific. Access runs through individual EU Login accounts with multi-factor authentication. Each manufacturer has one Primary Assigned Representative, who selects the coordinator CSIRT and creates the manufacturer's association, and who can invite up to 20 Secondary Assigned Representatives. The coordinator CSIRT validates the association. Help Net Security reported on 14 September that a representative may file up to 20 notifications while that validation is pending, so an unverified account does not block a first report.

The same report lists what the first release does not contain: the platform is available in English, there is no API, so every notification is entered through the web form, and voluntary reporting under Article 15 is planned for a later phase.

The Counter on the Screen Is Not the Deadline in the Law

The most consequential operational detail in ENISA's FAQ concerns the platform's timers. In the current release, the 72-hour counter shows a due date 48 hours after the early warning is submitted. It does not count 72 hours from the moment the manufacturer became aware. ENISA states that a notification may therefore appear overdue before 72 hours have passed, that a future release will calculate from the awareness timestamp, and that the counters provide visibility only and do not replace the legal obligation to report within the Article 14 timelines.

The arithmetic rewards a careful reading. A manufacturer that files its early warning at hour 24 sees a due date at hour 72, and the counter is right. A manufacturer that files at hour 6, which is the behaviour the regime wants, sees a due date at hour 54 and may be shown as overdue while 18 legal hours remain. The counter cannot run later than the law, because an early warning filed inside the 24-hour limit always produces a due date at or before hour 72. It can only run earlier.

Two conclusions follow. First, an overdue flag on the portal is not a finding of non-compliance, and a team should not be pushed into filing a thin notification to clear it. Second, and more important, the authoritative record of when awareness occurred sits with the manufacturer. If the legal clock starts at a moment the platform's counter does not use, the manufacturer's own timestamped log is the only evidence of the real deadline. This is the evidence trail we tested in the August drill, now with a concrete reason behind it.

The Coordinator Choice and the Awareness Record

Two further points in the first days' guidance carry legal weight.

The coordinator CSIRT is a determination, not a drop-down. Article 14(7) routes the notification to the coordinator CSIRT of the Member State where the manufacturer has its main establishment in the Union. For manufacturers without one, the article sets a fallback order: the Member State of the authorised representative, then of the importer, then of the distributor, then where most users are located. ENISA's FAQ warns that a wrong selection may invalidate the notification. Crowell's 11 September client alert notes that the main-establishment test turns on where cybersecurity decisions for the product are predominantly taken, observes that this is often an engineering site, not the headquarters, and recommends documenting the analysis before an incident. For a non-EU manufacturer, the answer depends on its importer and distributor arrangements, which makes the question a commercial one as well.

Pre-existing exploitation is outside the duty, and that needs proof. ENISA's FAQ states that a manufacturer already aware of the active exploitation of a vulnerability before 11 September 2026 is not required to report it retrospectively, and that awareness on or after that date triggers the obligation even where the vulnerability was known earlier. Noerr's 15 September note records the same position. Noerr also relays the Commission guidance on when awareness arises: once an initial assessment concludes with a reasonable degree of certainty that active exploitation is occurring. Both points resolve to the same control: a dated register of what the company knew, and when it concluded it.

Why ENISA Says Not to Register Yet

In August we advised assigning the platform onboarding immediately so that registration would happen in the platform's first days. ENISA's guidance, as relayed by both Crowell and Noerr, is the opposite: manufacturers should register on the platform only when they have a notification to submit, which limits the validation workload on the coordinator CSIRTs. ENISA's position governs, and our August advice on that point is superseded.

The preparation that remains is everything short of pressing the button. Name the Primary Assigned Representative and at least two Secondary representatives with out-of-hours cover. Create and test their EU Login accounts with multi-factor authentication. Decide and document the coordinator CSIRT. Read the user manual once, before it is needed. Registration at hour 3 of a real event is then a short administrative step, and the allowance for notifications during pending validation means it does not consume the clock.

What Manufacturers and Deal Teams Do in the First 90 Days

Days 1 to 30: fix the record. Build the pre-11 September awareness register. Write down the coordinator CSIRT determination and the reasoning. Stand up an awareness log that timestamps the moment of reasonable certainty independently of the portal. For smaller manufacturers, this is the evidence gap we described in the June readiness baseline, now with an enforcement date behind it.

Days 31 to 60: run the drill against the published rules. Repeat the classification and early-warning exercise with the real constraints: web-form entry in English, no API, a counter that may show overdue, and a final report keyed to different events for the two triggers. Extend it to suppliers. Noerr and Crowell both recommend contractual notification duties on component suppliers, because a manufacturer must assess whether a component vulnerability is exploited in its own product. Discovery will keep outrunning this machinery, which is the pattern set out in our Velocity Gap doctrine.

Days 61 to 90: join the regimes up. The classification decision made for Article 14 also drives NIS2 reporting, customer notification and the insurer conversation. Our five-frameworks analysis describes why running them as separate programmes hides exposure. The penalty position belongs in the same briefing: Article 64 sets fines for breaches of Article 14 at up to EUR 15 million or 2.5% of total worldwide annual turnover, whichever is higher, and exempts microenterprises and small enterprises from fines for missing the 24-hour early-warning deadline specifically.

For deal teams, the diligence question has changed tense. Before 11 September it was whether a target had a process. Now it is whether the target has had a reportable event since that date, what its pre-application awareness register shows, which coordinator CSIRT it has determined, and whether its importer or distributor arrangements decide that answer. These slot into the proportionate lens we set out in CRA exposure in M&A: a few questions that read the room, carried into the warranties.

How Innovaiden Approaches It

Innovaiden's CRA Article 14 First-90-Days Review takes the regime as it operates and tests a manufacturer or a target against it: the coordinator determination, the Assigned Representative roster, the awareness log and pre-application register, and a timed drill using the platform's published behaviour. The output is a short, dated gap list with owners. The portal is open. What it records is only as good as the record the manufacturer keeps beside it.