CRA Reporting Starts 11 September 2026: Building the 24-Hour Early-Warning Pipeline

On 11 September 2026 the Cyber Resilience Act’s reporting duties start, and the moment you become aware of an actively exploited vulnerability in one of your products, a 24-hour clock begins. You cannot assemble a 24-hour capability once the clock is already running against you.

Most of the CRA commentary in circulation is about the CE mark and the December 2027 conformity deadline. That is the slow part. The fast part arrives fifteen months earlier. Regulation (EU) 2024/2847 entered into force on 10 December 2024, and while the main obligations apply from 11 December 2027, the Article 14 reporting duties apply from 11 September 2026. Those duties are the ones that will catch teams off guard, because they are not a documentation exercise you can finish in a quarter. They are an operational pipeline that has to run in near real time, and it has to exist before the first live exploit lands, not after.

What actually starts on 11 September 2026

Article 14 places two reporting obligations on the manufacturer of a product with digital elements. The first is triggered by an actively exploited vulnerability in the product. The second is triggered by a severe incident having an impact on the security of the product. Both are reported to the CSIRT designated as coordinator for the manufacturer’s member state and, simultaneously, to ENISA, through a single reporting platform.

The word to sit with is actively exploited. This is not a duty to report every vulnerability you discover in triage. It is a duty that fires when a vulnerability in your product is being used in the wild against real deployments. That distinction is the whole design problem. Your telemetry, your threat intelligence and your product security team have to be able to tell the difference between a vulnerability that exists and a vulnerability that is being exploited, and to make that call fast enough that a 24-hour window is not already half gone by the time a human notices.

Three clocks, not one

The reporting is staged, and the stages are where the engineering lives. For an actively exploited vulnerability the sequence is:

1. Early warning — within 24 hours of becoming aware. A short notification that this is happening, indicating whether malicious acts are suspected. It is deliberately thin; it is a flare, not a report.
2. Vulnerability notification — within 72 hours. General information about the product, the nature of the vulnerability and any exploitation, and any corrective or mitigating measures taken or that users can take.
3. Final report — no later than 14 days after a corrective or mitigating measure becomes available. Full description, severity, impact, and where known, information on the threat actor.

Severe incidents follow the same 24-hour and 72-hour cadence, but the final report is due within one month of the incident notification rather than pegged to a fix. The practical consequence is that the same pipeline has to serve two triggers with two different tail deadlines, and your tooling has to know which clock a given case is on. Getting the trigger classification wrong is not a filing error; it changes the deadline you are held to.

If you already maintain a coordinated vulnerability-handling process under the CRA’s Annex I obligations, the reporting pipeline bolts onto it. If you do not, you are building both at once, and the reporting duty will expose every gap in the handling process underneath it.

The pipeline you have to build

Reduced to its moving parts, the detection-to-notification pipeline is four stages. Detection: telemetry, threat intelligence feeds and support channels that can surface active exploitation of a known or newly disclosed weakness. Triage: a decision, owned by a named person with a named deputy, that classifies a case as an actively exploited vulnerability or a severe incident and starts the correct clock. Assembly: pulling the required fields into the notification template for each stage. Submission: getting the payload to the platform and holding proof that it was sent within the window.

The failure mode is treating this as an email you will write when the day comes. Twenty-four hours sounds generous until the trigger fires at 17:00 on a Friday, the person who understands the product is on a plane, and nobody is sure whether this case even qualifies. The teams that will meet the deadline are the ones that have wired the triage decision to a partially automated notification path and rehearsed it, so that raising an early warning is a button rather than a scramble. Here is the shape of that path — a stub that fires an early-warning notification the moment triage flags a case, so the 24-hour clock is served by machinery, not by memory.

# early_warning.py — posts a CRA Article 14 early-warning on a triage trigger.
# Serves the 24-hour clock automatically; a human still owns the classification.
import datetime as dt
import os
import requests  # organisation's outbound proxy assumed configured

SRP_ENDPOINT = os.environ["SRP_EARLY_WARNING_URL"]  # ENISA Single Reporting Platform
SRP_TOKEN = os.environ["SRP_API_TOKEN"]

def submit_early_warning(case):
    """case: dict emitted by the triage system when a case is
    classified as an actively exploited vulnerability or severe incident."""
    if case["classification"] not in ("actively_exploited_vuln", "severe_incident"):
        return  # nothing to report yet; triage has not confirmed a trigger

    payload = {
        "reporter": case["manufacturer_id"],
        "stage": "early_warning",
        "trigger": case["classification"],
        "product": case["product_name"],
        "aware_since": case["aware_timestamp"],           # starts the 24h clock
        "malicious_suspected": case.get("malicious_suspected"),
        "submitted_at": dt.datetime.now(dt.timezone.utc).isoformat(),
    }

    resp = requests.post(
        SRP_ENDPOINT,
        json=payload,
        headers={"Authorization": f"Bearer {SRP_TOKEN}"},
        timeout=30,
    )
    resp.raise_for_status()
    # Retain the acknowledgement: it is your proof the 24h window was met.
    receipt = resp.json()
    _archive_receipt(case["case_id"], payload, receipt)
    return receipt

The endpoint and schema are not the point — ENISA’s platform specification governs those. The point is that the notification is emitted by the system that makes the triage decision, and the acknowledgement is archived as evidence the moment it returns. That receipt is what you show when someone asks whether you met the window.

The platform that is not there yet

There is a wrinkle worth naming plainly. The Single Reporting Platform that all of this routes through is built and overseen by ENISA, and as of mid-2026 it was not yet live, with a target of being operational by the 11 September date itself. That is a thin margin, and it changes nothing about your obligation. The duty to report within 24 hours is not suspended because the platform’s onboarding materials arrived late. Build your pipeline to the published specification, identify your designated coordinating CSIRT now, and keep a manual submission fallback documented so that a late or wobbly platform launch does not become your compliance failure. Waiting for the platform to appear before you start is not a plan.

Where this sits in the wider reporting estate

If your firm is already in scope for other regimes, the CRA’s 24-hour flare is one clock among several, and they do not align. NIS2, DORA, sector rules and now the CRA each define their own trigger, their own window and their own recipient. A manufacturer that is also a NIS2 essential entity can face two different reporting duties from a single event, on two different clocks, to two different bodies. Mapping those overlaps before an incident is the only way to avoid a team improvising the reconciliation live — which is the argument for holding a single cyber-incident reporting map rather than a pile of per-regime runbooks.

The engineering pattern is not new. It is the same 24-hour and 72-hour muscle that firms have had to build for CIRCIA and, on a longer fuse, for the AI Act’s serious-incident clock. What changes under the CRA is that the trigger is active exploitation of your own product, which means the detection has to reach into how your product behaves in the field, not just how your corporate network behaves.

A 24-hour reporting capability is a capability, not a policy. It is built, wired and rehearsed, or it does not exist. The firms that treat 11 September 2026 as the date to start building will discover, the first time a live exploit is already ticking against them, that the clock does not wait for you to be ready.