CRA update, September 2026: the Single Reporting Platform goes live, the 24-hour clock starts, and the guidance pack triples

The date that has been sitting in every CRA slide deck for two years arrived yesterday. From 11 September 2026, manufacturers of products with digital elements must report actively exploited vulnerabilities and severe incidents through ENISA’s Single Reporting Platform, on a 24-hour, 72-hour and final-report clock.

The platform went live the same morning. So did most of the documentation explaining how to use it. The substantive guidance landed between 9 and 11 September, which means anyone who prepared in August prepared against a materially smaller picture than the one that now exists. Here is what changed, and the parts that should alter your runbook this week.

1. The SRP is live, and it is explicitly “initial operating capability”

ENISA announced the launch on 11 September. The platform is at portal.cra-srp.enisa.europa.eu.

Read the press release and the AR User Manual together and the framing is consistent, and worth taking at face value. ENISA calls this the “initial operating capability”; the manual calls it “the initial release” and “the initial implementation”, and says ENISA “will continue to improve and expand its functionalities over the coming months based on operational experience and user needs.”

What that means concretely, from the updated FAQ (rewritten 11 September, now 31 questions, up from 23 in the July version):

• Only mandatory Article 14 reporting works. Voluntary reporting under Article 15, covering vulnerabilities, cyber threats, incidents and near misses, is not available and arrives in a future phase.
• There is still no API. You may automate your internal workflow; you may not pipe a notification into ENISA. Submission is a human in a web form.
• The platform is English only at launch. ENISA is translating the factsheet and supporting material into all EU languages; whether the platform itself gets additional language versions “will be reviewed in the next phase of the project”, which is not a commitment.
• If you are not a manufacturer, you cannot use it. Contact your national CSIRT directly. A submission from a non-manufacturer may be marked “invalid”.

One clarification that resolves an ambiguity we have seen misread repeatedly. ENISA’s press release says the Article 24(3) reporting obligations “will also apply to open-source software stewards”, and then states that that article applies from 11 December 2027. The FAQ is now explicit in three separate answers: stewards do not report until 11 December 2027, under Article 71(2). If you are a steward, yesterday was not your deadline. Our OSS and the CRA explainer covers the roles.

2. Everything ENISA published in the 72 hours before go-live

The August preparation pack was a factsheet, two guidance pages and an FAQ. As of today the library is this:

Document	Status	Date
CRA SRP – AR User Manual (PDF, v1.1)	New	v1.0 dated 9 Sept; page updated 10 Sept
CRA SRP Glossary (v1.3)	New page, replaces the FAQ field table	10 Sept
AR Interface functions	New	9 Sept
Particular Exceptional Circumstances (PEC)	New	9 Sept (the SRP hub page says 10 Sept)
AR Notification submission and update	Updated	9 Sept
AR User Registration	Updated	10 Sept
List of CSIRTs Designated as Coordinators	New	10 Sept
Platform Terms and Conditions (v1.0)	New	10 Sept
AR User Tutorial Video	New	undated
FAQ	Rewritten	11 Sept
SRP Factsheet (PDF, v1.0)	Unchanged	July

The single most useful document is the AR User Manual. It is a screenshot-by-screenshot walkthrough of registration, login, the dashboard, all three notification stages, updates, and association management. If one person on your team reads one thing before your first notification, it is this.

We have also updated our own ENISA SRP explainer against these documents.

3. Six operational details that change your runbook

EU Login now requires MFA

August’s guidance said you need an EU Login account. The manual and FAQ now say you need an EU Login account with multi-factor authentication enabled, and that ARs who already hold an account without MFA “should enable MFA before their first access to the platform.”

Accounts are personal. The AR who submits uses their own EU Login. A shared inbox and a shared credential is not a workable design here.

There are now two AR roles, and the Secondary role has hard limits

A manufacturer has one Primary AR and up to 20 Secondary ARs. The differences matter for an out-of-hours rota:

• Only a Primary AR whose association is displayed as “Verified” can invite Secondary ARs. If your Primary AR’s association is still pending, you cannot add backups.
• Invitations expire after 7 days.
• A Primary AR sees every notification for the manufacturer. A Secondary AR sees only the notifications they submitted themselves, not those submitted by a colleague on the same manufacturer.
• A Secondary AR can claim the Primary role, but only with the designated CSIRT’s approval.

That third point is the one to design around. If your 24-hour early warning is filed by whoever is on call, and the 72-hour follow-up falls to someone else, the second person may not be able to see the first person’s notification unless one of them is the Primary AR.

Worth flagging honestly: ENISA’s own documents are inconsistent here. The FAQ and the body of the manual both say a Secondary AR cannot view notifications submitted by another AR for the same manufacturer; the FAQ section at the back of the manual says both roles “can open, review, and edit the notification(s) associated with their manufacturer.” Two sources against one, so we have taken the restrictive reading, but plan your rota so that it works either way.

You can report before you are verified, up to 20 times

CSIRT validation of the AR–manufacturer association happens in parallel with reporting and does not block submission. The new limit, stated in both the FAQ and the manual: an unverified AR may submit up to 20 notifications for that manufacturer before verification becomes mandatory.

ENISA’s advice is unchanged and still counter-intuitive: register when you actually need to submit, not pre-emptively, to avoid swamping CSIRT validation queues. Registration takes minutes if the EU Login account already exists.

The 72-hour counter is currently wrong, and ENISA says so

This is the detail most likely to cause a false alarm in week one. From FAQ 26:

In the current release, the 72-hour counter displays a due date/time 48hrs after submission of the 24-hour Early Warning.

So a notification can be flagged “Report is late” on your dashboard before 72 hours have actually elapsed since you became aware. ENISA says the logic will be corrected in a future release to run from the “became aware” field.

Two consequences. First, do not manage your legal deadline off the platform counter. Track awareness time in your own incident record. Second, ENISA is explicit that the counters “do not replace the responsibility” to comply with Article 14, so an on-time report that the dashboard colours red is still on time.

For actively exploited vulnerabilities there is no final-report counter at all, because the deadline runs from when a corrective measure becomes available. For severe incidents the counter runs one month from the 72-hour notification.

Picking the wrong CSIRT invalidates the notification

New, and sharp: “If the wrong CDaC is selected, the notification may be invalidated and will need to be resubmitted to the correct CDaC.” You select the CSIRT designated as coordinator at login, before you even reach the form.

ENISA has now published the list of designated CSIRTs for all 27 Member States, with contact links. The gap we flagged in August is closed. The selection rule is Article 14(7): the Member State of your main establishment, meaning where decisions about the cybersecurity of your products are predominantly taken. If that cannot be determined, the establishment with the most EU employees. If you have no EU establishment, the cascade runs authorised representative → importer → distributor → most users.

Settle this once, write it into the runbook, and do not make an on-call engineer work it out at 3am.

One notification per event, for the whole group

Also new: only one notification is required for any given actively exploited vulnerability or severe incident, “even when a manufacturer has multiple branches or subsidiaries in the EU and/or its parent company is headquartered outside the EU.” Coordinating that internally is the manufacturer’s problem, not the platform’s.

And if the platform is down: wait for it to come back and submit. You may contact your designated CSIRT directly in the meantime, but the SRP submission is still required afterwards. Note also that a Final Report is not editable once submitted.

4. The data fields moved, and grew

The reporting field list no longer lives in the FAQ. It now sits in the SRP Glossary, version 1.3, which gives every field a definition, completion instructions, a worked example, an expected format and a character limit, mapped across Early Warning / 72-hour / Final Report.

It is a better document than the table it replaces, and it is longer: 39 fields, with definitions, completion instructions and, for free-text fields, character limits. Fields that were not in the July data-field table include Summary, Product Version, Component name, Attack vector, End of support indicator, Mitigating measure expected shortly, and User action able to reduce impact.

On classification, the August position holds: Product Type, Product class and Product category are all optional at the 24-hour Early Warning, then carried forward and updated. So classification is not a blocker on your first emergency filing, but you will be asked for it under pressure, and the Glossary tells you to select on the product’s core functionality, “not only its commercial name”. If you have not done it, our free compliance check takes a couple of minutes.

Two caveats printed in the Glossary itself, which tell you how fresh this build is:

• “Date and time when you become aware of the Actively Exploited Vulnerability” is not in this release, and arrives in the next one.
• For severe incidents, the equivalent field is currently labelled “Date and time when the incident was detected”.

Which is precisely why the 72-hour counter is computing off submission time rather than awareness time.

5. PEC: how delayed dissemination actually works in the product

Commission Delegated Regulation (EU) 2026/881 of 11 December 2025 specifies the terms and conditions for applying the cybersecurity-related grounds on which a CSIRT may delay dissemination. The grounds themselves are in Article 16(2) of the CRA. ENISA’s new PEC guidance now shows what that looks like as a control in the form.

The mechanics:

• PEC applies only to an actively exploited vulnerability, and only at the 72-hour stage. Not to severe incidents; not at the early warning.
• You toggle a PEC indicator near the bottom of the 72-hour template, then select a delay reason and, optionally, a free-text justification for the CSIRT.
• The three grounds are those in the third subparagraph of Article 16(2): exploitation confined to the coordinating CSIRT’s Member State; dissemination would be contrary to that Member State’s essential interests; or dissemination itself poses an imminent high cybersecurity risk.
• The notification status stays “72h Submitted”; the dissemination status becomes “72h Submitted under PEC”. ENISA receives the PEC reasons but not the full content, until the coordinating CSIRT releases it.
• The CSIRT decides. Invoking PEC is a request, not a switch.

If your product touches national security customers or you ship to a single Member State, this is worth a dry run before you need it.

6. What did not change: harmonised standards

The Commission’s CRA standardisation page still carries a last-update date of 31 July 2026 and still lists no standard cited in the Official Journal. We searched EUR-Lex for a citation act referencing Regulation (EU) 2024/2847 and found none. The horizontal deliverables under standardisation request M/606 that were expected over the summer have not been cited.

Until citation happens, the Article 27 presumption of conformity is unavailable for every product category. The practical consequence is unchanged from July and August: if your plan for a Class I product was Module A with full application of harmonised standards, that route does not yet exist, and the fallback is a notified body. Article 35(2) asks Member States to “strive to ensure” a sufficient number of notified bodies by 11 December 2026, an endeavour clause rather than a hard obligation, which is precisely why it is worth planning around rather than relying on. Check the key dates if you are planning a certification window.

What to do this month

1. Check that your AR’s EU Login has MFA enabled. An account without it will fail at first access. This is a five-minute fix and a very unpleasant discovery to make at hour 22 of 24.
2. Decide your designated CSIRT now and write it down. Apply Article 14(7) to your corporate structure, find your CSIRT on ENISA’s published list, and put it in the runbook. The wrong choice means resubmission.
3. Name your Primary AR and get the association verified before you need backups. You cannot invite Secondary ARs until the Primary association shows “Verified”, and invitations expire in 7 days.
4. Fix your rota for the Secondary AR visibility limit. If the 24-hour and 72-hour filings could be made by different people, make sure the Primary AR is in the loop, or the second person will not see the first person’s notification.
5. Track the awareness timestamp yourself. The platform’s 72-hour counter currently runs from submission of the early warning, not from awareness, and can show “late” when you are not.
6. Read the AR User Manual and walk the tutorial video before a real incident. The first time you see this interface should not be while a 24-hour clock is running.

Sources

All primary, all official.

• ENISA press release: The CRA Single Reporting Platform is launched (11 September 2026)
• ENISA: Single Reporting Platform (SRP), topic hub
• ENISA: CRA SRP – AR User Manual (PDF, v1.1; v1.0 dated 9 September 2026, page updated 10 September 2026)
• ENISA: CRA SRP Glossary (v1.3, 10 September 2026)
• ENISA: Frequently Asked Questions (updated 11 September 2026)
• ENISA: CRA SRP Guidance – AR User Registration (10 September 2026)
• ENISA: CRA SRP Guidance – AR Notification submission and update (9 September 2026)
• ENISA: CRA SRP Guidance – AR Interface functions (9 September 2026)
• ENISA: CRA SRP Guidance – Particular Exceptional Circumstances (PEC) (9 September 2026)
• ENISA: List of CSIRTs Designated as Coordinators (10 September 2026)
• ENISA: CRA Single Reporting Platform – Terms and Conditions (v1.0, 10 September 2026)
• ENISA: CRA SRP – AR User Tutorial Video
• ENISA: CRA Single Reporting Platform Factsheet (PDF, v1.0)
• ENISA: CRA Single Reporting Platform, the platform itself
• European Commission: Cyber Resilience Act – Reporting obligations (updated 11 September 2026)
• European Commission: Cyber Resilience Act – Standardisation (last updated 31 July 2026)
• European Commission: Guidance on the application of the CRA, C(2026) 5252 and annex (27 July 2026)
• European Commission: FAQs on the CRA Implementation (PDF)
• EUR-Lex: Regulation (EU) 2024/2847 (Cyber Resilience Act)
• EUR-Lex: Commission Delegated Regulation (EU) 2026/881 of 11 December 2025 on delaying dissemination of notifications
• European Commission: CRA standardisation request M/606, C(2025)618
• EU Login account creation

This article is general information about the EU Cyber Resilience Act, not legal advice, and reading it creates no advisory relationship. It reflects our reading of the regulation and the guidance available on the date shown above, both of which change. Classification, deadlines and obligations turn on the specific facts of your product. Verify against the primary sources before you rely on any of it, and take professional advice for decisions that carry legal or financial consequences. See our terms.