An APAC manufacturer hit by an actively exploited vulnerability in 2026 faces a 24-hour reporting deadline. Without a single channel, that manufacturer would also face 27 different national CSIRTs to choose from, each with its own intake form, its own escalation contact, its own clock interpretation. The Single Reporting Platform exists to collapse that fan-out into one door. Article 16 of the CRA is the legal mandate for the platform; ENISA is its operator; and on 11 September 2026 the platform becomes the only legitimate way to file an Article 14 notification.
That date matters more than people realise. Article 14’s reporting obligations enter application fifteen months before the rest of the CRA’s substantive obligations. A manufacturer who only watches the 11 December 2027 full-applicability date will discover, in late 2026, that its first compliance test arrived early.
The infrastructure is one door. The compliance work behind that door is two reporting tracks, three clocks per track, and a Member-State routing decision the manufacturer does not get to make. Anyone who treats the SRP as "just a form" gets the easiest part right and the substantive part wrong.
§ 01What gets reported — mandatory and voluntary
Article 14 carries the mandatory categories. Two of them, distinct by intent and by legal basis:
- Actively exploited vulnerabilities in products with digital elements — Art 14(1). Not theoretical, not hypothesised: a vulnerability where exploitation has been observed or is being observed.
- Severe incidents affecting product security — Art 14(3). The structural counterpart to vulnerability reporting: when something has actually gone wrong with a product’s cybersecurity in the field.
Article 15 carries the voluntary lane. Any natural or legal person may notify vulnerabilities (not yet exploited), cyber threats, incidents, and near misses. The voluntary lane is interesting for a reason that is not obvious: a manufacturer who reports a vulnerability voluntarily under Art 15 — before it becomes "actively exploited" — does not trigger the Art 14 24-hour clock. For a coordinated vulnerability disclosure (CVD) workflow where the patch is not yet ready but a CSIRT relationship needs to start, this is a usable mechanism rather than a fallback.
§ 02Three clocks per track, anchored differently
The most-quoted summary of Article 14 is "24h / 72h / 14d". That summary is incomplete in a way that matters when a real incident lands.
| Track | 24 hours | 72 hours | Final report |
|---|---|---|---|
| Vulnerability — Art 14(2) | Early warning, from becoming aware | Vulnerability notification | 14 days, anchored on corrective measure available |
| Severe incident — Art 14(4) | Early warning, from becoming aware | Incident notification | 1 month, anchored on 72-hour notification submission |
The two final-report clocks anchor to different events. This is easy to miss. Many summaries collapse them into "14 days" as if it were a single deadline. It is not. A severe incident’s final report runs a separate one-month track that starts when the 72-hour notification is submitted, not when corrective measures are available, and not when the issue was first detected. A team that drafts an incident-response runbook against the wrong anchor will be late on the right clock.
§ 03Who receives the report — and where APAC manufacturers actually land
The default routing under Art 14(7) sends the notification to two destinations simultaneously: the CSIRT designated as coordinator in the Member State of the manufacturer’s main establishment, and ENISA. The receiving CSIRT then disseminates onward across the EU CSIRT network — subject to the dissemination-delay grounds covered below.
For a manufacturer with no main establishment in the Union — which is most APAC OEMs — the third subparagraph of Art 14(7) sets a four-step cascade:
| Order | Member State chosen by | Tie-breaker |
|---|---|---|
| (a) | Where the authorised representative is established | Highest number of products |
| (b) | If no AR: where the importer places products on the market | Highest number of products |
| (c) | If no importer: where the distributor makes products available | Highest number of products |
| (d) | If none of the above: where the most users are located | Highest number of users |
The order matters in a way Art 18 alone does not surface. Choosing an authorised representative is not just a box-check on the manufacturer obligation list — it is the decision that determines which Member State’s CSIRT receives every Article 14 notification for the lifetime of that product line. Fragmenting AR appointments across multiple Member States to "spread risk" instead spreads obligations and complicates routing. There is one practical exception built into the regulation: under the third subparagraph, point (d), a manufacturer may continue submitting subsequent notifications to the same CSIRT it first reported to, even if the user-base distribution shifts. But the initial designation is the one that does most of the work.
§ 04Two paths to delay — and they are not the same path
"Submit once and the rest happens automatically" describes the default. Two separate mechanisms can introduce delay or restrict access, and they are routinely conflated. Disentangling them is worth doing, because they trigger differently and they sit on different sides of the manufacturer-CSIRT-ENISA triangle.
Path one: receiving CSIRT delays dissemination to other CSIRTs. This is the path the Commission Delegated Regulation adopted on 11 December 2025 codifies. The Delegated Regulation supplements Art 14(9) and identifies three categories of cybersecurity-related grounds under which the CSIRT initially receiving the notification may delay forwarding it onward.
| Category | Trigger | Delegated Reg. article |
|---|---|---|
| Nature of the notified information | Cybersecurity risk of dissemination outweighs benefits — e.g. a risk-mitigation measure is expected within 72 hours, or the CSIRT is acting as a trusted intermediary in an ongoing CVD process under NIS2 Art 12(1). | Art 3 |
| Receiving CSIRT cannot guarantee confidentiality | The relevant CSIRT is itself affected by a cybersecurity incident, or there is sufficient reason to believe its capabilities are inadequate to protect the information. | Art 4 |
| SRP itself compromised or unavailable | ENISA has informed the CSIRTs Network that the platform’s confidentiality cannot be assured. | Art 5 |
The Delegated Regulation also contains a carve-out the explainers of this regime tend to skip: under Recital (7), if the manufacturer indicates that the product is made available only on the market of the Member State of the CSIRT initially receiving the notification, that CSIRT need not disseminate the notification to any other relevant CSIRT at all. For an APAC OEM whose EU subsidiary sells exclusively into one Member State (rare for hardware, more common for niche software products), the dissemination question never arises — not because of delay grounds, but because the geographic scope makes onward dissemination unnecessary by definition.
Path two: manufacturer marks sensitive content; ENISA gets only partial information. This is the Article 16(2) path, which sits inside the CRA itself rather than in the Delegated Regulation. In particularly exceptional circumstances — specifically where the manufacturer actively flags one of the three conditions in Art 16(2)(a) to (c) inside the 72-hour vulnerability notification (Art 14(2)(b)) — ENISA receives only partial information: that a notification was made, general information about the product, the general nature of the exploit, and that security-related grounds were invoked. The full notification is disseminated to the relevant CSIRTs and ENISA only when conditions allow. Note that this manufacturer-marking mechanism is scoped to the vulnerability notification under Art 14(2)(b); it does not extend to the severe-incident 72-hour notification under Art 14(4)(b).
The two paths are independent. Path one is a CSIRT-to-CSIRT decision about onward dissemination, made after the report is received. Path two is a manufacturer-side choice about ENISA’s access to the report content, made at the moment of submission. A real incident may trigger one, both, or neither. Treating them as the same mechanism — or assuming the manufacturer can request the dissemination delay — is a common mistake.
data.europa.eu/eli/reg_del/2026/881/oj). Per Article 6, it enters into force on the twentieth day following publication — 10 May 2026. The European Commission’s Implementation page may still list the act as “publication pending” due to lag in updates; the OJEU text governs. Verbatim sources cited above: Article 3(a), (b), (c), (d) for the four nature-of-information delay conditions; Article 4(a), (b) for the specific-CSIRT confidentiality grounds; Article 5 for the SRP-platform-compromised ground; Recital (2) for the scope of the manufacturer-side Art 16(2) marking (limited to the 72-hour vulnerability notification under Art 14(2)(b)); Recital (7) for the single-Member-State carve-out.
§ 05What ENISA does beyond running the platform
The platform is the most visible part of ENISA’s role under Article 16. The wider role, articulated in the ENISA SRP FAQ and in Article 17, includes:
- Helpdesk, particularly for SMEs, alongside the Member State CSIRTs designated as coordinators (which provide their own helpdesk under Art 14(6)).
- Biennial trend reports, with the first due within 24 months of reporting obligations starting — that places the first report no later than around September 2028.
- Disclosure of fixed vulnerabilities to the European Vulnerability Database (EUVD) operated by ENISA under NIS2.
- Specifications on the technical, operational, and organisational measures for the SRP, in cooperation with the CSIRTs network — under Art 16(5).
The biennial trend report is worth pausing on. Notifications submitted to the SRP feed ENISA’s biennial state-of-cybersecurity report under NIS2 Article 18. What an APAC manufacturer reports in November 2026 becomes part of how the EU describes its own cyber posture in the autumn of 2028. Reporting accuracy, in that sense, has a longer half-life than the immediate incident.
§ 06Three things to do before September 2026
The list is shorter than the consultancy decks suggest. Three items, sequenced by what depends on what:
| Action | Why it has to be first | Source |
|---|---|---|
| Designate the authorised representative — for non-EU manufacturers — and understand which CSIRT that decision delivers you to. | The cascade in Art 14(7) third subparagraph runs on this designation. Every other reporting decision flows from which Member State’s CSIRT receives the notification. | Art 14(7), Art 18 |
| Build the internal triage capability. Named owner, escalation path, drafting templates, a tabletop exercise. 24 hours is short; the bottleneck is internal escalation, not technical assessment. | The clock starts when a reasonable engineer first thinks "this looks like an actively exploited vulnerability". Designating the owner after the clock has started is how teams miss the 24-hour mark. | Art 14(2)(a), Art 14(4)(a) |
| Decide the CVD posture. Article 15 voluntary reporting is a tool, not just a fallback — the question is whether you want CSIRTs in the loop before a vulnerability becomes "actively exploited". | Once a vulnerability is actively exploited, the 24-hour clock runs whether you wanted CSIRT involvement or not. Voluntary disclosure earlier preserves choice and aligns with Delegated Reg. Art 3(d) on CVD-based dissemination delay. | Art 15, Delegated Reg. Art 3(d) |
Note what is not on this list: a full vulnerability handling programme. That sits in Article 13 and Annex I Part II, and applies from 11 December 2027. The September 2026 deadline only triggers when a manufacturer "becomes aware of" a qualifying event. No event, no Article 14 action. The runway between September 2026 and December 2027 is fifteen months wide, and using it for the construction work that Article 13 mandates — rather than compressing that work into the runway before September 2026 — is what separates a calm 2026 from an expensive one.
The SRP is the door. The cascade decides which Member State opens it. The two clocks decide what happens after. Knowing which is which is the first compliance test of the CRA, and it lands fifteen months before most teams expect.