Eighteen Days to the CRA's Reporting Gate. The Portal Is Not Live Yet. Your Process Has to Be.

On 11 September 2026, eighteen days from now, the Cyber Resilience Act's first hard obligation lands on manufacturers: Article 14 reporting of actively exploited vulnerabilities and severe incidents, on a 24-hour early-warning clock. The deadline has been fixed since the regulation entered into force in December 2024. What is new is the state of the infrastructure it depends on: as of late August, ENISA's Single Reporting Platform, the portal through which those reports must flow, is not yet publicly live. Onboarding guidance was updated on 3 and 14 August, functional and security testing is under way, and ENISA says the platform will be operational by the 11 September start date. The public URL has not been published.

That combination should change how the final stretch is spent. A company waiting to "see the portal" before preparing has inverted the problem. The portal is the easy part: a form, filled from information you either have ready or do not. The hard part is everything upstream of the form, and all of it can be rehearsed now: deciding within hours whether an event is reportable and under which trigger, producing an early warning from incomplete information, and having a named person empowered to submit at 3 a.m. on a Saturday. The companies that will meet a 24-hour clock in October are the ones that have already failed it once, in a drill, in September's first week.

We set out the readiness baseline in June, in the CRA's first obligation gate and what readiness requires. This piece is the operational end of that argument: the drill to run in the eighteen days that remain.

Key Takeaways

• 11 September 2026: Article 14 reporting becomes mandatory for manufacturers of products with digital elements placed on the EU market, wherever the manufacturer is established
• Two triggers, two final clocks: actively exploited vulnerabilities (final report within 14 days of a corrective measure) and severe incidents (final report within one month of the notification). Both share the 24-hour early warning and 72-hour notification front clocks
• ENISA's Single Reporting Platform is not yet publicly live: guidance updated 3 and 14 August, testing under way, operational "by 11 September". You cannot rehearse against the portal, so rehearse the process
• The 24-hour clock starts at awareness, not at analysis. The classification decision (which trigger, which clock) is the step most teams have never practised, and it determines the rest
• The report is written from the evidence trail, not from memory. If decisions are not timestamped as they happen, the 14-day and one-month final reports become reconstruction exercises under deadline
• For targets in live M&A processes, Article 14 readiness is now a diligence question: an acquirer asking "show me your reporting drill" three weeks before the gate is asking a fair question

What Exactly Lands on 11 September

Article 14 creates two distinct reporting duties, and the distinction is not pedantry, because the clocks differ.

An actively exploited vulnerability in your product, one you become aware is being used against systems in the wild, must produce an early warning to ENISA and the CSIRT designated as coordinator within 24 hours of awareness, a fuller vulnerability notification within 72 hours, 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, but its final report is due within one month of the incident notification.

Classifying an event correctly, and quickly, is therefore the first operational skill Article 14 demands. An exploited vulnerability and a severe incident can look identical in the first hours. The obligation does not wait for certainty: the early warning is designed to be filed on incomplete information, which is precisely why teams that have never drafted one under time pressure struggle when the clock is real.

The reports flow through ENISA's Single Reporting Platform, established under Article 16. Which brings us to the current, slightly awkward fact.

The Portal Is Not Live. That Is Information, Not an Excuse

As of late August 2026, the Single Reporting Platform's public access URL has not been published. ENISA has released onboarding guidance for registration and notification submission (updated 3 August) and for the platform's interface functions (updated 14 August), says functional and security testing is under way, and has committed to the platform being operational by 11 September, with a webinar planned roughly two weeks before launch.

Read one way, this is uncomfortable: the ecosystem's absorption infrastructure is being finished inside the final month, a pattern our Velocity Gap analysis would predict, since the constraint in vulnerability handling is almost never discovery and almost always the machinery that absorbs it.

Read the operationally useful way: the portal's lateness removes the last excuse for late preparation, because it clarifies what preparation is. Nobody can practise the submission screen. Everybody can practise everything that feeds it. When the portal opens, the difference between companies will not be who saw the form first. It will be who arrives with the classification decision tree, the templates, and the ownership map already tested.

The Drill: Five Tests, One Afternoon

A workable Article 14 drill fits in an afternoon and needs no portal. Run one scenario of each type: a report from a security researcher that a vulnerability in your product is being exploited at a customer, and a severe incident in your own build or update infrastructure.

Test 1: classification. Present the scenario to the people who would actually receive it (support, security, engineering on-call) and time how long it takes to reach a defensible answer to one question: is this an actively exploited vulnerability, a severe incident, both, or neither? Record who made the call and on what basis. This is the decision the final-report clock hangs on, and in most organizations it has never been made even once.

Test 2: the awareness moment. Article 14's clocks start at awareness. Decide, in writing, what counts as awareness for your organization, and who is empowered to start the clock, including at night and on weekends. If the honest answer is "whoever notices escalates to someone who is sometimes reachable", the drill has found its first gap.

Test 3: the early warning at hour 12. Have the team draft the actual early warning half a day into the scenario, using only the information the scenario has revealed by then. The point is to discover that the early warning is short, structural, and fileable on incomplete information, and to convert that discovery into a pre-agreed template so that no one is composing prose against a 24-hour deadline.

Test 4: ownership of the submission. Name the person who registers on the Single Reporting Platform when it opens, the person who submits, the approver, and the backup for each. ENISA's onboarding guidance exists now; assign someone to it this week, so registration happens in the platform's first days rather than during your first incident.

Test 5: the evidence trail. At the end of the drill, attempt to reconstruct the timeline of decisions from records alone: timestamps, tickets, messages. The final report at 14 days or one month is written from this trail. If the drill's own history cannot be reconstructed without asking people to remember, the incident's will not be either. This is the same evidence-not-capability gap the June baseline identified; the drill makes it concrete.

The output of the afternoon is not a pass. It is a short list of specific gaps, each with an owner, closable inside the eighteen days.

The Deal-Side Angle

For companies in or near a transaction, the September gate has a second audience. An acquirer running technology and cyber diligence on an EU-exposed product target in September has a new, cheap, high-signal question: show me your Article 14 process, and show me the drill you ran. A target that can produce a dated drill report with named owners answers a governance question before it is asked. A target that cannot has handed the deal team exactly the kind of read-the-room finding we described in CRA exposure in M&A: not a conformity audit, a single question that reveals the state of the whole system.

What This Changes for the Executive Team

Schedule the drill this week, not the review. The remaining window is enough to run the exercise, find the gaps, and close the top three. It is not enough for a committee to first agree the scope of a review of the process that would precede the drill. Run it rough; the roughness is the finding.

Assign the platform onboarding now. Registration on the Single Reporting Platform is administrative work with a named owner, doable from ENISA's published guidance in the platform's first days. It should not be discovered as a prerequisite at hour 20 of a real incident.

Treat the classification decision as the crown jewel. The 24-hour and 72-hour clocks are logistics. The decision of what an event is, made quickly, defensibly, and on the record, is the capability. It is also the part of the process that survives beyond compliance: the same classification discipline feeds NIS2 reporting, customer contractual notification, and the insurer conversation.

How Innovaiden Approaches It

Innovaiden runs the drill described above as a facilitated exercise: two scenarios against the real statutory clocks, the classification decision tree built live with your team, early-warning and notification templates left behind, and a one-page gap list with owners, dated before 11 September. For companies already through our CRA readiness baseline, the drill is the operational test of it; for companies starting cold, it is the fastest honest picture of where the reporting gate will find them. The gate does not reward the best-documented intentions. It rewards the team that has already practised.