The CRA Single Reporting Platform Has No API: A Submission Runbook for 11 September 2026

On 11 September 2026, Article 14 of the Cyber Resilience Act (Regulation (EU) 2024/2847) becomes binding — 15 months before the CRA's general application date of 11 December 2027. If a product with digital elements that you manufacture has an actively exploited vulnerability, you have 24 hours from the moment you become aware to file an early warning with ENISA's Single Reporting Platform (SRP), the reporting channel established under Article 16.

Most CRA coverage stops at that headline: the three deadlines, the scope, the penalties. What it doesn't cover is what actually happens when you sit down to file a report — because until this summer, nobody outside ENISA knew. ENISA published its first step-by-step SRP instructions on 31 July 2026, followed by interface guidance on 3 August and 14 August 2026. Those documents contain four operational facts that change how you should be preparing right now, with the deadline 11 days away.

Fact 1: There is no API

If your incident-response plan assumes the SRP works like every other reporting integration in your stack — a REST endpoint, an API key, a JSON payload triggered automatically from your alerting pipeline — that assumption is wrong. Per ENISA's own guidance, published 31 July and confirmed 6 August 2026:

"No reporting API will be provided at this stage: internal workflow can be automated up to the point of submission, but a human will be typing into a browser at the end of it."

That's a hard ceiling on automation. You can automate detection, triage, severity assessment, and even the drafting of the notification text. You cannot automate the act of filing it. Any design doc, runbook, or vendor pitch that describes "integrating with the ENISA SRP API" is describing a system that does not exist as of this writing — and there is no published timeline for one to exist before the 11 September deadline.

Fact 2: Submitted reports are non-editable

Once you click submit, that notification is final. ENISA's guidance is explicit:

"Once submitted the notification becomes non-editable."

This inverts the normal incident-response instinct of "file something quickly, refine it later." Under the SRP, refinement has to happen before submission, not after. If your internal sign-off process (legal review, technical accuracy check, a second pair of eyes on the CVE/EUVD reference) currently happens after the report goes out the door, it needs to move to before — which is a process change, not a technical one, and the kind of thing that's much easier to fix in week 1 of September than during an actual live incident.

Fact 3: Unverified accounts are capped at ten notifications

ENISA's 14 August 2026 SRP interface guidance caps unverified representative accounts at ten total notifications. ENISA also clarified on 3 August 2026 that verification is not a prerequisite for meeting the 24-hour obligation — an unverified account can still file within the window. But the ten-notification ceiling means verification status is not a detail you want to discover mid-incident, particularly if you manage CRA reporting across multiple product lines or a portfolio of client products.

Fact 4: Platform drafts don't survive a handover

Reports drafted inside the SRP are visible only to the representative who created them — there is no shared team view of in-progress drafts. If your primary reporter is unreachable (a holiday, a weekend, sick leave) and a backup has to pick up a report mid-draft, the platform itself gives them nothing to work from. Any draft content needs to live in a shared, offline document that both the primary and backup representative can access — the platform is a submission tool, not a collaboration tool.

The three-stage timeline (Article 14)

The stages themselves aren't new — they've been public since the regulation was adopted — but they're worth restating precisely, because the clock does not pause for platform readiness or represented-account status:

Source: Article 14 text, cross-checked against cyberresilienceact.eu's reporting summary. These windows run from the moment your organization becomes aware — not from when a patch exists, and, per ENISA's own June 2026 messaging, not from when the platform itself goes live.

Which CSIRT is "yours"

Article 14(7) sets a determination hierarchy for which CSIRT is your designated coordinator — the body your notification actually routes to before ENISA and other Member States see it:

• If you're established in the EU: the CSIRT of the Member State where you have your main establishment.
• If you're not established in the EU: the CSIRT tied to your Article 18 authorised representative — and if you have representatives in multiple Member States, the one covering the highest product volume, followed by importer location, then distributor location, then user concentration.

This is one of the six things on ENISA's own pre-launch checklist (published 24 August 2026) that you can determine today, with zero platform access, and should not leave until an incident forces the question.

What to actually do in the next 11 days

1. Create EU Login accounts now for a primary representative and at least one backup, via ecas.ec.europa.eu. No approval process, no reason to wait.
2. Determine your coordinating CSIRT using the Article 14(7) hierarchy above, and write it into your incident runbook — not into someone's memory.
3. Draft your report skeletons offline, in a shared document your whole on-call rotation can access, not as SRP platform drafts. Cover all three stages (early warning / 72-hour / final) for each product family you ship.
4. Get your account verified as soon as you register on the platform, rather than defaulting to unverified status and discovering the ten-notification cap under pressure.
5. Move your review step before submission, not after — legal sign-off, technical accuracy check, and confirmation that the vulnerability is actually actively exploited (not just disclosed) all belong pre-submit, given reports can't be edited afterward.
6. Plan for coverage gaps. Assign a real backup representative and make sure they have offline access to draft content — the 24-hour clock doesn't check who's on holiday.

The one thing you can actually automate: report assembly, not submission

Given there's no API, the realistic automation boundary is assembling a complete, structured report body — ready to be pasted into the SRP's web form by whoever is on call — rather than pretending you can skip the human step. A small script that pulls from your incident data and formats it against the fields ENISA's guidance describes removes the most error-prone part of a 24-hour deadline: writing clean, complete prose from scratch while the clock runs.

from dataclasses import dataclass, field
from datetime import datetime, timezone


@dataclass
class CRAReportDraft:
    """Assembles CRA Article 14 report text for manual submission to the
    ENISA Single Reporting Platform. There is no submission API (per ENISA
    guidance, July-August 2026) -- this produces text for a human to paste
    into the SRP web form, not a payload for an automated client.
    """
    product_id: str
    product_version: str
    euvd_reference: str | None
    vulnerability_summary: str
    actively_exploited: bool
    publicly_disclosed: bool
    awareness_timestamp: datetime = field(
        default_factory=lambda: datetime.now(timezone.utc)
    )

    def early_warning_text(self) -> str:
        """Stage 1 -- must be submitted within 24h of awareness_timestamp."""
        deadline = self.awareness_timestamp
        return (
            f"EARLY WARNING (Article 14, Stage 1)\n"
            f"Product: {self.product_id} v{self.product_version}\n"
            f"EUVD reference: {self.euvd_reference or 'not yet assigned'}\n"
            f"Awareness timestamp (UTC): {deadline.isoformat()}\n"
            f"24h deadline (UTC): {deadline.isoformat()} + 24h\n"
            f"Actively exploited: {'yes' if self.actively_exploited else 'no'}\n"
            f"Publicly disclosed: {'yes' if self.publicly_disclosed else 'no'}\n"
            f"Summary: {self.vulnerability_summary}\n"
        )

    def detailed_notification_text(self, severity: str, affected_versions: list[str],
                                    mitigations: list[str]) -> str:
        """Stage 2 -- must be submitted within 72h of awareness_timestamp."""
        return (
            f"DETAILED NOTIFICATION (Article 14, Stage 2)\n"
            f"Product: {self.product_id}\n"
            f"Severity: {severity}\n"
            f"Affected versions: {', '.join(affected_versions)}\n"
            f"Mitigations available to users: {', '.join(mitigations) or 'none yet'}\n"
            f"Exploitation details: {self.vulnerability_summary}\n"
        )


# Usage: generate the text, review it with whoever owns pre-submission
# sign-off, then paste it into the SRP form. This script's job ends where
# the browser starts.
draft = CRAReportDraft(
    product_id="acme-api-gateway",
    product_version="2.4.1",
    euvd_reference=None,
    vulnerability_summary="Authentication bypass in the session-refresh endpoint, "
                           "confirmed under active exploitation via anomalous token reuse.",
    actively_exploited=True,
    publicly_disclosed=False,
)
print(draft.early_warning_text())

Note what this script does not do: it does not call anything named enisa_api_key, submit_notification(), or any HTTP endpoint. It produces text. That's the correct scope for automation against a platform that, per ENISA's own words, ends with "a human typing into a browser."

Sources

• ENISA — Single Reporting Platform (SRP), official page — go-live date, purpose, CSIRT/manufacturer usage.
• cyberresilienceact.eu — "ENISA Published Step-by-Step Single Reporting Platform Instructions on 31 July 2026" — no-API and non-editable quotes, account setup, unverified-account cap.
• cyberresilienceact.eu — "Eighteen Days to CRA Reporting: What You Can Prepare Before the Platform Opens" — pre-launch checklist, draft-visibility limitation, CSIRT determination.
• cyberresilienceact.eu — "With Reporting Due on 11 September 2026, ENISA's Single Reporting Platform Is Still Not Live" — platform status as of 29 June 2026.
• Cyber Resilience Act, Article 14 — Reporting obligations of manufacturers
• Cyber Resilience Act, Article 16 — Establishment of a single reporting platform
• Cyber Resilience Act, Article 18 — Authorised representatives
• Cyber Resilience Act, Article 71 — Entry into force and application