The CRA Single Reporting Platform: Integrating Your PSIRT With ENISA’s New Front Door

From 11 September 2026 the Cyber Resilience Act gives your vulnerability process a new front door: ENISA’s Single Reporting Platform. Most teams are treating it as a form to fill in under pressure. It is better understood as a new external state your PSIRT has to drive.

The reporting obligations in Article 14 of the CRA come into application on 11 September 2026. From that date, if you place products with digital elements on the EU market, you must notify an actively exploited vulnerability or a severe incident affecting the security of your product, and you must do it against three clocks that start the moment you become aware. The route for that notification is the Single Reporting Platform that ENISA establishes under Article 16. This is a design problem before it is a compliance problem, and the firms that treat it as a data-entry task will discover under real incident pressure that data entry is the part that fails.

What the platform actually is

Two articles do the work. Article 14 sets the obligations and the deadlines. Article 16 establishes the platform through which you discharge them. The design intent is report-once: instead of notifying every national authority in every market where your product is sold, you submit through a single electronic entry point. The notification goes simultaneously to the CSIRT designated as coordinator in the Member State of your main establishment and to ENISA. That receiving CSIRT then disseminates it, via the platform, to the coordinators in the other territories where the product is available, and onward to the relevant market surveillance authorities.

That routing is why the platform is a genuine front door and not just another regulator’s inbox. One submission fans out across the EU. The awkward truth, at the time of writing, is what sits behind the door. ENISA has indicated that the initial release will be a web interface, with access and registration instructions published ahead of go-live and a testing window before September, and that a machine API is not part of the first release. You may automate everything up to the submission boundary; the submission itself is expected to be a human filling in a web form. That constraint shapes the whole design, so build for it rather than against it.

The three clocks are one state machine

The deadlines are well known by now: an early-warning notification within 24 hours of becoming aware, a fuller notification within 72 hours, and a final report — no later than 14 days after a corrective measure is available for an actively exploited vulnerability, or within a month of a severe incident being handled. Teams tend to write these on a whiteboard as three deadlines. That is the wrong mental model. They are three states of a single object, and the object is one reportable event.

Model it that way and the engineering falls out cleanly. Each reportable event has one immutable field that everything else hangs off: the awareness timestamp. Every clock is measured from it, so it must be captured deliberately and defensibly — who knew what, when — not reconstructed afterwards from a Slack thread. The event then moves through early-warning submitted, 72-hour notification submitted, and final report submitted, with the platform’s own acknowledgement as the transition evidence. I have written separately about building the 24-hour early-warning pipeline; the point here is that the pipeline does not end at 24 hours. The same object has to survive for a fortnight and arrive at each gate with more detail than the last, without anyone re-keying what was already known.

Design the intake so the report composes itself

Your PSIRT already holds most of what the platform asks for — it just holds it in the wrong shape. The intake design that works is a mapping exercise: for each field the Single Reporting Platform expects at each stage, name the system of record in your own estate that owns it. Product identity and affected versions come from your software bill of materials. Suspected malicious cause, required in the early warning, comes from triage. Severity and impact, required at 72 hours, come from your classification step. Corrective and mitigating measures come from the fix and release process.

Do that mapping once, in advance, and the 24-hour report is not a scramble to gather facts — it is a projection of facts you already have, assembled into the platform’s structure. Because there is no API yet, the practical target is a pre-composed submission packet: the web form’s fields, populated from your tooling, ready for a named human to review and paste. The human step stays; the fact-finding step does not. That is the difference between a two-hour drafting exercise at 2 a.m. and a five-minute review.

Deduplication: one vulnerability, many reports

The failure mode nobody plans for is duplication. A single underlying flaw can surface as several CVEs, affect several products, and arrive through several intake channels — a researcher email, an automated scanner, a customer ticket — within hours of each other. Without a correlation key, you file three overlapping early warnings, then contradict yourself at 72 hours when the picture consolidates. Regulators reading three inconsistent notifications about the same flaw is precisely the impression you are trying to avoid.

So give every reportable event a stable internal identifier at the moment of awareness, and make deduplication a deliberate step: when a new signal arrives, the first question is whether it belongs to an existing event or opens a new one. The correlation also runs sideways. The same vulnerability can trigger a CRA report, a NIS2 incident notification and a DORA report on different clocks to different authorities — a problem I have set out in one vulnerability, three reporting clocks. One internal event, many external obligations, is the model that keeps those consistent. If you are an open-source steward rather than a manufacturer, the obligations differ; the steward category is worth reading before you assume Article 14 applies to you unchanged.

Status tracking so nothing ages out

The last piece is the timer. Once the event exists with its awareness timestamp, the 24-hour, 72-hour and final-report gates are derived, not remembered. The system should surface what is due, escalate as a gate approaches, and refuse to let an event sit un-progressed while a clock runs down. Store the platform’s acknowledgement for each submission as the evidence that the gate was met, because that is the artefact a market surveillance authority will ask to see. This is the same discipline the board should already be applying across every reporting regime it faces, which is why the cyber-incident reporting map belongs on the wall next to the state machine.

Treat ENISA’s platform as a new front door wired into the vulnerability process you already run, and the 24/72/14-day sequence becomes an automated state machine with one deliberate human hand on the submit button. Treat it as a form to find at the moment you need it, and the clock will already have started before anyone knows which form it is.