Three Weeks Into CRA Reporting: What Early Users Learned and What a "Disclosure Delay" Really Means
CRA reporting obligations have applied since 11 September 2026, and the first public accounts of using ENISA's Single Reporting Platform (SRP) are now in. The short version: the platform works, account verification is the step to do early, and a "disclosure delay" is something a CSIRT can apply to its onward sharing. It never pauses your reporting clock.
Key points
- The platform is usable. Launch-day deployment problems were resolved within hours, according to the first first-hand account.
- Verification takes days, not minutes. One assigned representative waited three business days for a national CSIRT to verify their account.
- The wait does not have to block a report. ENISA has said unverified accounts can file up to twenty notifications before verification becomes mandatory.
- Disclosure delays are about authorities, not manufacturers. The 24-hour, 72-hour and 14-day clock still runs from the moment you become aware of an actively exploited vulnerability.
This is general guidance, not legal advice.
What early users report
On 23 September, Jens Gellynck, the assigned representative at Aikido Security, published the first public account of using the SRP. His assessment was "mostly positive" once the account was set up. Three details matter for planning:
- Launch day was bumpy. He described a few deployment issues on 11 September, with everything online within a few hours. Help Net Security's launch coverage and ENISA's own announcement confirm the platform went live that day.
- Verification is a human step. Getting his account confirmed as a real employee of the company took three business days at Belgium's CSIRT. That is the coordinating CSIRT for a manufacturer established in Belgium.
- Log-in is strict. The platform uses EU Login with mandatory multi-factor authentication and supports passkeys. His advice was to register backup devices so you cannot be locked out during an incident.
If you have not registered yet, start with our guide to registering on the SRP and our explainer on how reports flow through the platform.
Why the three-day wait is less scary than it sounds
A three-day verification queue looks incompatible with a 24-hour early warning. It is not, because ENISA has confirmed that an unverified account can still submit up to twenty notifications before verification becomes mandatory. In practice: register before you need to, but a pending verification should not stop you filing an early warning.
Also worth knowing: ENISA published the list of coordinating CSIRTs for all 27 Member States on 4 September. Know which one is yours. It is the body that will verify your representatives and receive your reports. ENISA also updated its SRP FAQ on 12 September, adding a tutorial video and a factsheet in nine EU languages, according to the cyberresilienceact.eu news log.
What a "disclosure delay" actually means
This is the most commonly misread point of the first weeks.
- What it is. A delegated act (cited by a secondary source as Delegated Regulation (EU) 2026/881; confirm the reference on EUR-Lex) lets the receiving CSIRT delay passing a report on to other CSIRTs and ENISA. The grounds are the nature of the information, the CSIRT being unable to guarantee confidential handling, or the platform's integrity being compromised or temporarily down.
- Who decides. The CSIRT, not the manufacturer. ENISA's guidance of 9 September adds that the mechanism applies to actively exploited vulnerabilities only.
- What it does not do. It does not extend your deadlines. The Article 14 timeline (early warning within 24 hours, notification within 72 hours, final report within 14 days for vulnerabilities, one month for severe incidents) runs from awareness, regardless of any onward delay.
So you cannot "wait for the delay" before you report. You report on time and the authority decides how widely to share it.
What to do this week
Tip: Run one dry run of your 24-hour clock this week. It is the fastest way to find the gap. See the CRA deadlines guide and the readiness checklist.
- Get accounts verified now. Do it before an incident, and add a second representative for cover.
- Register backup MFA devices for every person who might file.
- Write down your coordinating CSIRT and keep the contact route in your incident runbook.
- Rehearse the first 24 hours: who decides a vulnerability is actively exploited, who files, and who approves the wording. Our piece on what triggers a CRA report helps with that decision.
Small and micro enterprises are not fined for missing the 24-hour deadline under Article 64, but the obligation itself still applies, and later reports are still due.
What is still open
The SRP is running, but the wider CRA picture is still moving. Harmonised standards that will give presumption of conformity are not yet published, so treat any single vendor's interpretation as a secondary source and check the regulation itself on EUR-Lex.
Want a calm weekly read on what changes next? Subscribe to The CRA Brief.
Related reading
CRA SBOM Requirements: What Goes Inside, Which Format Versions to Use, and Where VEX Fits
The CRA says your SBOM must be machine-readable but not what fields it needs. Here is what goes inside, which CycloneDX and SPDX versions still count, and why VEX is optional.

Does the Cyber Resilience Act Require Penetration Testing?
The CRA never mentions penetration testing. Annex I, Part II, point 3 requires "effective and regular" security tests - here is what that means in practice.
The CRA Notified Body Capacity Crisis: What Class II and Critical Manufacturers Should Actually Do
Zero CRA notified bodies are listed in NANDO as manufacturers head into the final compliance stretch. If your product is Class II or Critical, here is why the bottleneck exists, who it actually affects, and the sequenced plan that turns waiting into progress.