01What must be reported
Article 14 of the Cyber Resilience Act creates two reporting duties for manufacturers of products with digital elements. They are narrower than they first appear: routine bugs and ordinary patches are not in scope. Art. 14
- Actively exploited vulnerabilities; a vulnerability in your product for which there is reliable evidence that a malicious actor has exploited it in a system without the owner's permission. A vulnerability you discover and patch before it is exploited is handled through your normal vulnerability-handling process, not this reporting channel.
- Severe incidents; an incident that negatively affects, or is capable of negatively affecting, the product's ability to protect the availability, authenticity, integrity or confidentiality of data or functions. The severity criteria sit in Article 14(5).
The duties are not limited to commercial manufacturers. Open-source software stewards carry their own reporting obligations to the extent they are involved with products with digital elements. Art. 24(3)
If a security weakness in your product is actively being exploited, or a security incident has severely affected it, the Article 14 clock starts. Everything else stays within your day-to-day vulnerability handling.
A vulnerability whose active exploitation you already knew about before the reporting obligation applies, on 11 September 2026, does not have to be notified. The duty attaches to the moment you become aware, so it captures what you learn from that date onward and no further back.
This is the part that catches people out, and it is worth being exact about. Article 69(2) sets the general transitional rule: products placed on the market before 11 December 2027 fall under the Regulation only if they are substantially modified from that date. Read alone, that suggests your existing catalogue is untouched.
Article 69(3) then carves Article 14 straight back out of it. By express derogation, the reporting obligations apply to all products with digital elements within the scope of the Regulation that were placed on the market before 11 December 2027, whether or not they are ever modified.
So the two rules run on different axes. A product you sold in 2025 may never need CE marking under the CRA, yet if a vulnerability in it is actively exploited and you become aware of that on or after 11 September 2026, it is reportable. Your installed base is in scope for reporting even where it is out of scope for the product requirements. The Commission reaches the same conclusion in section 5.3 of its FAQs on CRA Implementation. Art. 69(2)–(3)
02The three deadlines
Each report unfolds in three stages, measured from the moment you become aware of the exploited vulnerability or severe incident. The windows are tight, which is why readiness matters. Art. 14(2)–(4)
- Within 24hEarly warning. A first notification that an actively exploited vulnerability or severe incident has occurred, including, for incidents, whether it is suspected to be caused by unlawful or malicious acts.
- Within 72hVulnerability / incident notification. A fuller account: the general nature of the vulnerability and of the exploit, an initial assessment, and the corrective or mitigating measures taken plus those users can take.
- Final reportFinal report. For a vulnerability, no later than 14 days after a corrective or mitigating measure becomes available. For a severe incident, within one month of the 72-hour notification. It sets out the full description, severity, impact and the remediation applied.
Note the asymmetry in the last row: the vulnerability clock is triggered by a fix existing, the incident clock by the earlier notification. They are different mechanics and worth writing into your runbook separately.
03When it starts
The reporting obligations are the earliest major part of the CRA to take effect. While most provisions apply from 11 December 2027, Article 14 applies from 11 September 2026; 21 months after the Act entered into force. ENISA opened the Single Reporting Platform on that same date. Art. 71
The platform is live, and the duty it serves is live with it. ENISA publishes the address as portal.cra-srp.enisa.europa.eu, where you select the Assigned Representative role and sign in with an EU Login account carrying multi-factor authentication. The address was published in ENISA's FAQ update of 10 September 2026, the day before opening.
ENISA marked the launch by publishing an AR User Manual and a set of platform terms and conditions, version 1.0 of 10 September 2026, and by adding four questions to the FAQ: how to connect, when the obligations start, what to do if you are not a manufacturer, and how to report a security problem in the platform itself. The AR User Tutorial Video, promised for launch, went live within days, and the SRP Factsheet followed in nine further EU languages. The platform interface itself still runs in English only, with other languages deferred to a later phase.
Four things did not arrive with it, and much of this page is written around them: voluntary reporting under Article 15 is still absent with no date attached, there is still no API, the 72-hour counter still runs from submission of your early warning rather than from the moment you became aware, and the field that would record when you became aware of an actively exploited vulnerability is still held back for a later release. The harmonised standards underpinning vulnerability handling also remain outstanding, now expected around 30 October 2026 after the Commission's July 2026 draft amendment to standardisation request M/606 pushed the 2026 deadlines back by two months, and not yet cited in the Official Journal.
Unlike CE marking, which you complete once before placing a product on the market, reporting is a live, ongoing duty that begins in September 2026 and can be triggered at any moment thereafter. Being ready is not a one-off project. Build the internal detection-and-reporting process now; the duty applies from 11 September 2026 whether or not the tooling is finished.
04Who you report to
Reports go to ENISA and to the CSIRT designated as coordinator, through a single entry point rather than separate filings to each national authority. That entry point is the Single Reporting Platform, which ENISA establishes, manages and maintains under Article 16. Art. 14 · 16
Which CSIRT is yours follows your main establishment in the Union or, where you are not established in the EU, that of your authorised representative. The receiving CSIRT disseminates the notification onward to CSIRTs in the Member States where the product is available, and to market surveillance authorities as needed. Art. 14(7) · 18
The list of coordinators was published on 4 September 2026
Until 4 September 2026 there was no published answer to the most practical question on this page: which national team actually receives your filing. ENISA has now published a list of CSIRTs designated as coordinators giving one or more contact URLs for every one of the 27 Member States, and restamped it on 10 September 2026, so check your row again before you rely on a copy taken earlier. Ireland points to a dedicated NCSC page for the CRA; Spain gives two separate INCIBE routes, one for incidents and one for vulnerability coordination.
The list tells you who each Member State's coordinator is. It does not tell you which one is yours, and the Article 14(7) test is narrower than most organisations assume. Your main establishment is the Member State where the decisions about the cybersecurity of your products with digital elements are predominantly taken, which may be a development site rather than a registered office or the largest commercial operation. Where that cannot be determined, the fallback is the Member State holding your highest EU headcount. With no EU establishment at all, the order runs: the Member State where your authorised representative acts for the most products, then the importer placing the most products on the market, then the distributor making the most available, then the Member State with the most users. Because this fixes the recipient for every future filing, settle it in advance, with legal input, and write down the reasoning.
Support exists on both sides. ENISA operates a helpdesk, with particular attention to SMEs, and the CSIRTs designated as coordinators are required to provide helpdesk support on the Article 14 duties as well. ENISA also feeds fixed vulnerabilities into the European Vulnerability Database, and publishes a biennial technical trend report, the first due within 24 months of the reporting obligations starting. Art. 17(6)
Dissemination of a reported vulnerability may be paused by the CSIRT, but not by you
The receiving CSIRT may delay or withhold onward dissemination on justified cybersecurity grounds, for a period strictly necessary; for example where a vulnerability is inside a coordinated disclosure procedure. The Commission specified the terms in Delegated Regulation (EU) 2026/881, adopted on 11 December 2025. Where a CSIRT withholds a notification it must tell ENISA immediately, with a justification and an indication of when it will disseminate.
Separately, in particularly exceptional circumstances you may mark one of the narrow conditions in Article 16(2) in your 72-hour notification: that the exploitation is confined to your CSIRT's Member State, that further dissemination would be contrary to that Member State's essential interests, or that dissemination poses an imminent high cybersecurity risk. If you do, ENISA receives only limited information (that a notification was made, general information about the product, the general nature of the exploit, and that security grounds were raised) until the CSIRT releases the full notification.
On 9 September 2026 ENISA published a dedicated guidance page on Particularly Exceptional Circumstances, and it settles a scope question the earlier material left open. PEC can be invoked only on the 72-hour notification of an actively exploited vulnerability. There is no equivalent for a severe incident, and the platform offers no PEC control on an incident notification.
Mechanically it is a toggle at the foot of the 72-hour form, which reveals the three delay reasons plus an optional free-text justification. That justification is not decoration: ENISA says it helps the CDaC decide whether to accept the submission under PEC. Invoking PEC therefore asks for a restriction rather than applying one, and the record simply moves to the state 72h Submitted under PEC while the coordinator decides. Write the justification as though it will be read by someone who has to weigh it against the case for telling other Member States quickly, because it will be.
Neither mechanism pauses your clock. You cannot delay filing; the 24-hour, 72-hour and final-report windows run from awareness. What you can do is flag sensitivity, which limits who sees the content. The decision to hold back dissemination belongs to the receiving CSIRT.
05Registering on the platform
ENISA's registration guidance, restamped 10 September 2026, and its interface guidance, restamped 9 September 2026, show the actual screens. Registration opened with the platform on 11 September 2026, so this is now a flow you can walk rather than read about. ENISA nonetheless asks you not to register pre-emptively, for the reason set out below, which makes knowing the flow in advance more useful rather than less: the first time you follow it may well be under a 24-hour clock.
Appoint two people before you need them
The platform gives each manufacturer two kinds of user account, and you can decide who fills them today. A primary representative registers first and creates the manufacturer's entry on the platform. That person then invites a secondary representative, who holds a backup role against the same manufacturer and can file on its behalf. Both are named individuals at your company. Since submission is manual, a single nominated reporter who is on holiday, asleep or has left is a real operational risk, so treat the second seat as necessary rather than optional.
EU Login is the credential, and both people can create it today
Platform accounts authenticate through EU Login, the European Commission's shared sign-in service used across its online systems. Create one for the primary representative and one for the secondary at ecas.ec.europa.eu, using work email addresses that will still exist in a year. Multi-factor authentication is mandatory: ENISA requires MFA on the EU Login account before first access to the platform, so if your people already hold plain EU Login accounts, have them switch MFA on now rather than during an incident. EU Login accounts are personal, and ENISA operates no separate corporate authentication on top of them. The Commission explains what EU Login is, and how it fits its wider identity framework, on its trusted digital identity pages.
The registration flow
On first access to the platform you select your role, choose your designated CSIRT from a drop-down, authenticate through EU Login, read and accept the legal agreement, confirm your pre-filled personal details (first name, last name, email, legal name), then enter the manufacturer's name, address and additional information. Omitting a mandatory manufacturer field blocks the flow. On completion your account status is "Active" and you hold the "AR Primary User" role, you receive a confirmation email, and the manufacturer entity is created in the platform.
The secondary representative joins by email invitation from the primary, confirms the pre-filled personal and manufacturer details, and is registered in the "AR Backup User" role against the same manufacturer. That invitation expires after 7 days, after which the record is marked "Invitation Expired" and a fresh one must be sent. Set the backup up in the same sitting as the primary; a lapsed invitation discovered mid-incident is an avoidable problem.
The CSIRT checks your representative manually, but that does not block you from filing
Someone has to confirm that a given person really may report on behalf of a given manufacturer, and that check falls to the CSIRT designated as coordinator, which ENISA now abbreviates CDaC. It is a manual step, the procedure varies between CSIRTs, and each CSIRT owns its own approach. Crucially, it happens after your first access to the platform and runs in parallel with your report. In its update of 3 August 2026 ENISA put this beyond doubt: validation by the CDaC is not a prerequisite for fulfilling the CRA reporting obligation, and does not affect your ability to submit notifications. An unvalidated account can still file inside the 24-hour window.
That is also why ENISA advises registering and starting validation only when you actually need to file, rather than pre-registering the whole market and burying the CSIRTs in speculative checks. The preparation you do in advance is the EU Login accounts and the decision about who fills the two seats, not the platform registration itself.
Where a representative attaches their account to a manufacturer through Association Management, the association is created with the status Unverified and a verification request goes to the CDaC. The interface guidance of 14 August 2026 put the ceiling at 10 notifications. The FAQ rewritten on 4 September 2026 doubled it: a non-validated representative may submit up to 20 notifications for one manufacturer before validation becomes mandatory, and the interface guidance restamped on 9 September 2026 now says twenty as well.
Both statements hold together: validation is not a gate on your first filing, but it is not indefinitely postponable either. ENISA does not say what happens at the twenty-first attempt, or whether the ceiling counts events or individual submissions. If you copied "ten" into an internal procedure in August, correct it to twenty. Twenty is generous for a single-product company and still finite for a group filing across several entities, so if that is you, open the conversation with your coordinating CSIRT rather than waiting for an incident to force it.
One account can hold several manufacturers
The same guidance sets out the housekeeping around the two seats. A primary representative invites a backup by email address, which creates a record marked "Pending Invitation" with no role until it is accepted. A secondary representative can request promotion to primary, which goes to the CDaC for review. Either can remove an association, which is then marked "Deleted". And a single account can carry associations with several manufacturers, each added through Association Management and each verified separately.
That last point matters for groups with several manufacturing entities, and for firms acting under Article 18 for manufacturers established outside the EU. It is also where the naming trap below bites hardest.
ENISA's guidance is written for "Assigned Representatives" (AR), with primary users and backup users. That is a platform account role. It is not the authorised representative appointed by written mandate under Article 18 of the CRA. You can have the former without the latter. Keep the two apart in your internal procedure, or you will end up debating a legal appointment when all you need is a second login.
06Filing a report
Reporting runs from a dashboard. You create a notification, then add to the same record at each stage rather than filing three separate things. Each stage has its own tab, and each can be saved as a draft first. The dashboard can be searched by notification ID, manufacturer or title, sorted by title or last update, and filtered by Member State, submission type or an Action Required flag.
The interface guidance, restamped 9 September 2026, is explicit: a primary representative sees every notification associated with the manufacturer, but a secondary representative sees only the notifications they submitted and the drafts they created, and cannot view notifications submitted by another representative for the same manufacturer. Drafts are private to their author, not shared within the company.
Picture the consequence. Someone starts a 24-hour early warning, saves a draft, then becomes unreachable; the backup opens the dashboard and finds nothing, and the 24-hour window has been running from awareness the whole time. Draft the wording outside the platform, in a document your incident team already shares, and use the platform to transcribe it.
- Early warningStart a new notification from the dashboard, complete the mandatory fields, and select an existing manufacturer or add one. On submission it is accessible to your designated CSIRT and, automatically, to ENISA. Email and alert confirmations go to the CSIRT, to ENISA, and to every representative registered for that manufacturer, not only the person who submitted.
- 72-hourOnly available once an early warning exists. Open the same notification and complete the 72-hour tab. ENISA receives it automatically unless you invoke the Article 16(2) conditions, in which case the record is flagged "72h Submitted under PEC" and ENISA's view is limited until the CSIRT releases it.
- Final reportOnly available once both earlier stages exist. ENISA receives it automatically unless the Article 16(2) conditions were invoked.
ENISA's guidance of 3 August 2026 states that the other concerned CSIRTs receive the early warning, the 72-hour notification and the final report only after manual dissemination by the CSIRT designated as coordinator. The 31 July text said this of the final report alone. Nothing about your duty changes, and the CDaC is still bound by Article 16(2) to disseminate without delay, but it is worth knowing that a person at one national CSIRT sits between your report and the other markets where your product is sold.
What is mandatory, and when
ENISA has published which fields are obligatory at each stage. The table is a useful corrective to a widespread assumption: the 24-hour early warning is an alert, not an investigation.
- At 24 hours; the notification type and level, the manufacturer or steward name, the product, and a title. For incidents, whether unlawful or malicious acts are suspected. The Member States where the product is available is required only where you already have it.
- At 72 hours; the general nature of the vulnerability and of the exploit, corrective or mitigating measures taken, and measures users can take. For incidents, when it was detected and when it occurred, plus an initial assessment. Sensitivity is flagged here.
- At the final report; the full description, severity and impact, the date a corrective measure became available, and detail of the security update. For incidents, the likely root cause and ongoing mitigations.
Optional fields worth capturing anyway include the CVE ID and the EUVD ID, both available from the first stage.
Every field has a character limit, and one of them is very short
ENISA's SRP Glossary, first sized at version 1.1 on 5 September 2026 and now at version 1.3 of 10 September 2026, is the ENISA document that publishes the size of each box. Write your internal templates to these limits rather than discovering them at two in the morning:
- 4000 characters for the narrative fields: the summary, general information on the vulnerability or incident, the corrective measures users can take, the full descriptions of severity and impact, the initial assessment, and for incidents the applied and ongoing mitigation measures.
- 2000 characters for the corrective or mitigating measures you have already taken, and for the detail of the security update or corrective measure in the final report.
- 800 characters for the free-text justification that accompanies a PEC request on the 72-hour vulnerability notification.
- 255 characters for the title, the product name, the product version range, the component name, the attack vector, the sensitivity justification and the likely root cause.
- 100 characters for the malicious actor that exploited the vulnerability. That is roughly one line, so plan to name the actor or point to an indicator reference rather than describe the campaign.
The glossary also confirms a small convenience: the Member States where the product is available field arrives pre-filled with your own coordinating CSIRT, and you add the other markets yourself.
Editing, and the point of no return
A submitted notification can be updated, and the platform automatically sends an alert and an email to your CSIRT plus ENISA and any CSIRTs that already received it through dissemination. Two limits apply: a closed notification cannot be updated, and the record becomes non-editable once the final report is submitted.
Watch the alerts tab, including at the weekend
Each account has an Alerts tab, colour coded: unread alerts are light blue and turn grey once opened, and red alerts appear only where something exceptional has happened. The example ENISA gives is a designated CSIRT that has invalidated a submission. Filing is therefore not the end of the exchange, and no Article 14 deadline moves because a notification came back at you. Whoever watches that tab has to be watching it out of hours, which is a further argument for a monitored team mailbox behind both seats rather than two personal addresses.
The platform's 72-hour counter does not count from awareness
The FAQ discloses how the on-screen countdowns actually behave, and they do not track the legal deadline. ENISA updated the FAQ on 10 September 2026, the day before opening, and left this answer standing, so the behaviour described here is the behaviour that went live. In the current release the 72-hour counter displays a due date 48 hours after the 24-hour report is submitted, not 72 hours after you became aware. ENISA states plainly that a notification may therefore appear overdue before 72 hours have run from awareness, and that the logic will be changed in a later release to count from the "date and time when you became aware" field for both vulnerabilities and incidents.
The final-report counters differ again. For a severe incident the counter shows one month after the 72-hour notification. For an actively exploited vulnerability there is no counter at all, because the deadline depends on when a corrective measure becomes available, which the platform cannot know.
ENISA is explicit that the counters exist for visibility and do not replace the duty in Article 14. Start your clock at the moment of awareness and record it in your incident log. Filing your early warning quickly, which is exactly what the law wants, makes the on-screen counter stricter than the legal one. An on-screen "overdue" flag is not a finding of non-compliance, and a green counter is not a defence.
At launch the platform does not record when you became aware
On 5 September 2026 ENISA replaced its field-by-field SRP Glossary with version 1.1, and two footnotes in it matter more than anything else on the page. For an actively exploited vulnerability, the field Date/time when you become aware carries the note that it will be available in the next release of the platform. For a severe incident, the note says that in the current release the equivalent field is named Date/time the incident was detected.
Put beside the counter logic above, that closes a circle. The FAQ said the 72-hour counter would be corrected once the awareness field arrived; the glossary said the field arrives in a later release. Neither moved before opening: ENISA revised the glossary again to version 1.3 on 10 September 2026 and left both footnotes intact. So from day one the platform captures no awareness timestamp for vulnerabilities at all, and for incidents it captures the moment of detection, which is not the moment of awareness.
Under the Commission's guidance of 27 July 2026 you become aware once an initial assessment gives you a reasonable degree of certainty that a vulnerability in your product is being exploited or that a severe incident has occurred. Detection normally comes earlier, sometimes much earlier. Since the platform records the detection moment and not the assessment moment, the record it holds is not the moment Article 14 measures from. Keep your own timestamped note of when the initial assessment concluded and who made that call. If a market surveillance authority ever asks why an early warning arrived when it did, that note, not the platform, is your evidence.
ENISA added an answer on outages on 4 September 2026. If the SRP is temporarily unavailable, wait until it is back and then submit. Where immediate communication is necessary in the meantime, you may contact your designated CSIRT directly, but the notification must still go through the platform once service returns.
Worth stating clearly, because ENISA does not: nothing in the CRA pauses the 24-hour, 72-hour, 14-day or one-month windows during an outage. Timestamp the outage and any direct contact you make, and keep both alongside your awareness timestamp.
ENISA states that no application programming interface will be provided at the initial release, and that API functionality may be considered in a future phase. You can automate detection, triage and drafting internally, but the submission itself is a person completing a browser form. Plan that hand-off deliberately, and make sure more than one person can perform it out of hours and at a weekend.
The platform will eventually accept voluntary reports of vulnerabilities, cyber threats, incidents and near misses, from any natural or legal person rather than manufacturers alone. The 31 July 2026 FAQ said this would be enabled after 11 September 2026. It was not. The platform that opened accepts only mandatory notifications under Articles 14 and 24, and Article 15 voluntary reporting is deferred to a future phase with no date attached.
ENISA now spells out the consequence for everyone else. If you are not a manufacturer and you want to report a vulnerability or other security issue, contact the relevant national CSIRT directly, because a submission made through the platform instead may be marked "invalid". Nothing legally required is missing, but there is no low-stakes practice run, and a disclosure process that planned to route non-exploited vulnerabilities through the SRP still has nowhere to send them.
07What you can do today
Meeting a 24-hour window is an operational problem, not a paperwork one. Now that the platform is open the list below is no longer preparation for a future event; the duty is running, and anything here you have not done is an exposure rather than a plan.
- Create your EU Login accounts, with MFA switched on. For the primary reporter and at least one backup. It takes minutes at ecas.ec.europa.eu, and the platform will not let anyone in without multi-factor authentication, so enabling it is part of the task rather than a refinement of it.
- Identify your designated CSIRT. ENISA published the list of coordinators for all 27 Member States on 4 September 2026, so this is now a task you can finish. Apply the Article 14(7) main-establishment test, pick your row, and write down the reasoning.
- Build the 24-hour form internally. A short template matching ENISA's mandatory early-warning fields, so your first real filing is transcription rather than composition. Keep it somewhere both representatives can open, because platform drafts are visible only to whoever created them.
- Name the people, including out of hours. Decide who judges that a report is due, who drafts it and who submits it. Since there is no API, the last step is a named human at a keyboard.
- Keep an accurate SBOM. You cannot report on a component you did not know you shipped. Maintain a software bill of materials and keep it current as releases change.
- Monitor it continuously. Match your components against known-vulnerability sources so an actively exploited flaw surfaces in hours, not weeks. Our SBOM & vulnerability analyzer tracks your bill of materials against the NVD and the EU vulnerability database (EUVD).
- Confirm what is actually in scope. The 72-hour stage asks for product type and the Annex III or IV category, so settle classification before you need it. The classification tool answers that, and the compliance matrix ties reporting to the wider Annex I vulnerability-handling duties it sits within.
- Decide who reads the alerts tab out of hours. A designated CSIRT can invalidate a submission, and the alert that says so lands in the platform rather than in your inbox alone. Put a monitored mailbox behind both representative seats.
- Do not rely on the platform's countdown. Log your awareness timestamp yourself. The 72-hour counter on screen runs from submission of the 24-hour report, not from awareness, so it can flag a filing as overdue before the legal deadline has passed.
- Read the AR User Manual, and watch the tutorial video. ENISA published the manual at launch and added the AR User Tutorial Video within days, so between the two, plus the guidance pages, you have the fullest available description of the live platform.
- Check that you picked the right coordinator before you file. ENISA now warns that selecting the wrong CSIRT designated as coordinator may get the notification invalidated, leaving you to resubmit to the correct one with the clock still running.
08Follow it at the source
This page reflects the position on 11 September 2026, the day the platform opened. It will keep moving, and ENISA edits its pages quietly rather than announcing every change. In the week before launch the FAQ was rewritten on 4 September 2026 and updated again on 10 September 2026, the list of coordinators appeared on 4 September 2026 and was restamped on 10 September 2026, the Glossary reached version 1.1 on 5 September 2026 and version 1.3 on 10 September 2026, guidance on Particularly Exceptional Circumstances arrived on 9 September 2026, and the AR User Manual and the platform terms and conditions were published on 10 September 2026. For support questions ENISA publishes a helpdesk address on the hub page, cra-srp-helpdesk [at] enisa.europa.eu. These are the primary sources; everything above is our reading of them.
We previously suggested recording the stamp alongside anything you copy into an internal procedure. That advice needs a caveat. Between 7 and 9 September 2026 ENISA substantially rewrote the AR Notification submission and update page while leaving its stamp reading 3/08/2026: the terminology moved to CDaC throughout, references to a national endpoint data layer were dropped, submission confirmations now go to every assigned representative of the manufacturer rather than only the submitter, and the early warning is now expressly said to reach other concerned CSIRTs only after manual dissemination. If a guidance page matters to your procedure, keep your own dated copy of the text rather than trusting the date ENISA prints on it.
Launch day made the point again. In the morning of 11 September 2026 the AR Interface functions page still read 14/08/2026 and still put the unverified cap at ten; by the afternoon it read 9 September 2026 and said twenty, with no announcement. The hub page lists the PEC guidance as updated 10 September 2026 while the page itself reads 9 September 2026, and the Glossary went from version 1.1 to version 1.3 in the same quiet way. Where two ENISA pages disagree, treat the FAQ as the more current of the two.
- ENISA · The Single Reporting Platform itself (live from 11 September 2026); select the Assigned Representative role and sign in through EU Login with multi-factor authentication. This is where notifications are filed.portal.cra-srp.enisa.europa.eu
- ENISA · Single Reporting Platform; the hub page, with the factsheet, the user manual, the helpdesk address and links to every guidance page.enisa.europa.eu/topics/product-security/single-reporting-platform-srp
- ENISA · SRP frequently asked questions (updated 10 September 2026); legal basis, deadlines, routing, the field table, the counter logic, what to do during an outage, and the platform address. Rewritten on 4 September and extended the day before launch. The most current of ENISA's SRP pages, and the one to prefer where they conflict.enisa.europa.eu/topics/product-security/single-reporting-platform-srp/frequently-asked-questions
- ENISA · CRA SRP AR User Manual (10 September 2026); the launch-day manual for assigned representatives, and the fullest single description of the platform as it actually opened.enisa.europa.eu/topics/product-security/single-reporting-platform-srp/cra-srp-ar-user-manual
- ENISA · List of CSIRTs designated as coordinators (published 4 September 2026, updated 10 September 2026); contact points for all 27 Member States. Identify your row using the Article 14(7) test in section 04.enisa.europa.eu/topics/product-security/single-reporting-platform-srp/list-of-csirts-designated-as-coordinators
- ENISA · CRA SRP Glossary (version 1.3, 10 September 2026); field-by-field guidance on what each reporting field means, how to complete it, its expected format, its character limit and the stage at which it applies. Note the address: ENISA moved the glossary to a glossary2 URL and the older one is still linked from some of its own pages, so check the version line at the top before you rely on a copy.enisa.europa.eu/topics/product-security/single-reporting-platform-srp/cra-srp-glossary2
- ENISA · SRP user registration guidance; the step-by-step registration flow for primary and backup users, with interface screenshots.enisa.europa.eu/topics/product-security/single-reporting-platform-srp/cra-srp-guidance-ar-user-registration
- ENISA · SRP notification submission guidance; how the early warning, 72-hour notification and final report are filed and updated, and what each status triggers.enisa.europa.eu/topics/product-security/single-reporting-platform-srp/cra-srp-guidance-ar-notification-submission-and-update
- ENISA · SRP interface functions guidance (9 September 2026); settings, manufacturer associations, the dashboard and the alerts tab. Restamped on launch day itself, and now agrees with the FAQ that an unverified association may file up to 20 notifications.enisa.europa.eu/topics/product-security/single-reporting-platform-srp/cra-srp-guidance-ar-interface-functions
- ENISA · CRA SRP terms and conditions (version 1.0, 10 September 2026); the terms you accept when you register on the platform, published the day before it opened.enisa.europa.eu/topics/product-security/single-reporting-platform-srp/cra-single-reporting-platform-terms-and-conditions
- ENISA · SRP guidance on Particularly Exceptional Circumstances (9 September 2026); when PEC applies, the toggle and delay reasons on the 72-hour form, and what the coordinating CSIRT does with the justification. The fifth guidance page, and the only one that addresses PEC directly.enisa.europa.eu/topics/product-security/single-reporting-platform-srp/cra-srp-guidance-particular-exceptional-circumstances-pec
- European Commission · CRA reporting obligations; the policy page, including the FAQs on CRA Implementation whose section 5 covers reporting. Last updated 31 July 2026 and still written in the future tense on launch day, so use ENISA's pages for the platform itself.digital-strategy.ec.europa.eu/en/policies/cra-reporting
- European Commission · CRA application guidance (27 July 2026); point 9.1 sets out the reporting obligations of manufacturers and open-source stewards. Our summary of the guidance covers the rest.digital-strategy.ec.europa.eu/en/library/commission-publishes-new-guidance-support-timely-cyber-resilience-act-implementation
- EU Login; create the account the platform uses, and enable multi-factor authentication on it. Do this now.ecas.ec.europa.eu/cas/login
For the binding text, Articles 14 to 17 set out the reporting ecosystem and Article 16 establishes the platform; read them in our regulation reader. Milestone dates are tracked on the state of play page.
09Common questions
What must I report under the CRA, and how quickly?
Actively exploited vulnerabilities and severe incidents affecting the security of your product. An early warning within 24 hours of becoming aware, a fuller notification within 72 hours, and a final report within 14 days of a corrective measure being available for a vulnerability, or within one month of the 72-hour notification for a severe incident. Art. 14
When do the reporting obligations start?
11 September 2026; 21 months after the Act entered into force, and well ahead of full application on 11 December 2027.
Who do I report to?
ENISA and the national CSIRT designated as coordinator, through the single reporting platform established under Article 16. Your CSIRT follows your main establishment in the Union, or your authorised representative's if you are not established in the EU.
Is the list of coordinating CSIRTs published?
Yes, since 4 September 2026. ENISA publishes contact points for all 27 Member States. The list identifies each Member State's coordinator; which one is yours still follows the Article 14(7) main-establishment test, which turns on where decisions about your products' cybersecurity are predominantly taken.
Do I have to report every bug or vulnerability?
No. Only actively exploited vulnerabilities and severe incidents are reportable. Vulnerabilities you find and fix before exploitation are managed through your ordinary vulnerability-handling process.
Is ENISA's single reporting platform available yet?
Yes. It opened on 11 September 2026, the same day the Article 14 obligations began to apply, at portal.cra-srp.enisa.europa.eu. Select the Assigned Representative role and sign in with an EU Login account that has multi-factor authentication enabled. ENISA published the address in its FAQ on 10 September 2026, the day before opening.
What is missing from the platform that opened?
Four things worth planning around. Voluntary reporting under Article 15 is absent, with no date. There is no API, so submission is a person filling in a browser form. The 72-hour counter runs from submission of your early warning rather than from awareness, so it can show a filing as overdue before the legal deadline has passed. And the field recording when you became aware of an actively exploited vulnerability is held for a later release. The platform is also English only for now.
What do I do if the platform is down when I need to file?
ENISA's answer, added 4 September 2026, is to wait and submit once it is available again. If immediate communication is necessary meanwhile, you may contact your designated CSIRT directly, but the notification must still go through the platform afterwards. Note that nothing in the CRA pauses your deadlines during an outage, so timestamp the outage and any direct contact.
Does the platform's countdown match my legal deadline?
Not exactly. In the current release the 72-hour counter shows a due date 48 hours after you submit the 24-hour report, not 72 hours after you became aware, so a filing can display as overdue before the legal deadline has run. ENISA says the logic will change in a later release, and that the counters do not replace the Article 14 duty. Keep your own clock, started at awareness.
Does the platform record when I became aware?
Not at launch. The SRP Glossary, version 1.3 of 10 September 2026, states that the awareness field for an actively exploited vulnerability arrives only in a later release, and that for a severe incident the current field records the moment of detection. Detection usually precedes awareness, which the Commission's July 2026 guidance ties to an initial assessment reaching reasonable certainty. Keep your own record of when that assessment concluded.
Can I invoke PEC on a severe incident?
No. ENISA's guidance of 9 September 2026 states that Particularly Exceptional Circumstances apply only to the 72-hour notification of an actively exploited vulnerability. There is no PEC control on a severe incident notification. Note too that invoking PEC is a request: the coordinating CSIRT decides whether to accept it, helped by the optional justification you supply.
How long can each field be?
The glossary publishes limits: 4000 characters for the narrative fields, 2000 for measures already taken and for security-update detail, 800 for a PEC justification, 255 for the title, product, component, attack vector and root cause, and only 100 for the malicious actor. Build your internal template to those sizes.
Should I register on the platform straight away?
ENISA says no, and advises registering only when you actually need to file, rather than pre-emptively. What you should do now is create the EU Login accounts the platform uses, with multi-factor authentication enabled, for a primary reporter and a backup. The coordinating CSIRT validates your account after first access rather than ahead of it, and ENISA confirms that this validation is not a prerequisite for meeting the reporting obligation and does not block submission.
Is there a limit on filing before my CSIRT verifies me?
Yes, and the figure changed. ENISA's interface guidance of 14 August 2026 put it at 10 notifications; the FAQ rewritten on 4 September 2026 and the interface guidance restamped on 9 September 2026 both say a non-validated representative may submit up to 20 notifications for one manufacturer before validation becomes mandatory. Validation is not a gate on your first filing, but it is not indefinitely postponable either.
Can my backup reporter see a draft I started?
No. The dashboard shows only the drafts created by the logged-in representative, so a half-written early warning is invisible to your backup. Keep the drafting outside the platform, in a document your incident team shares, and use the platform to transcribe it.
Can I submit reports through an API?
No. ENISA states that no application programming interface will be provided at this stage. You can automate internal detection and drafting, but submission is a person completing a browser form.
What does the 24-hour early warning actually have to contain?
Less than most people expect. The mandatory fields are the notification type and level, the manufacturer or steward name, the product, a title, and for incidents whether unlawful or malicious acts are suspected. The substantive analysis is due at 72 hours, not on day one.
Is there a standard format or template for reporting yet?
The data fields are published. ENISA's FAQ sets out which are obligatory at the 24-hour, 72-hour and final-report stages, so you can build a matching internal template today. The Commission may still specify the format and procedure further through implementing acts.
Can I delay a report if disclosure would be risky?
Not the filing. The 24-hour, 72-hour and final-report windows run from awareness and nothing pauses them. You may flag sensitivity: under Article 16(2) you can mark narrow conditions that limit what ENISA sees until the CSIRT releases the full notification. The decision to delay onward dissemination belongs to the receiving CSIRT, under Delegated Regulation (EU) 2026/881, adopted on 11 December 2025.
Do I have to report exploitation I already knew about before September 2026?
No. The obligation applies once you become aware, and does not extend to vulnerabilities whose active exploitation you were already aware of before 11 September 2026.
Does reporting apply to products I placed on the market years ago?
Yes. Article 69(2) says products placed on the market before 11 December 2027 fall under the Regulation only if substantially modified from that date, but Article 69(3) expressly derogates from that for Article 14: the reporting obligations apply to all in-scope products placed on the market before 11 December 2027, modified or not. A product may therefore be out of scope for the CRA's product requirements while still being in scope for reporting. Art. 69(2)–(3)
Does any of this apply to open-source projects?
Open-source software stewards have reporting obligations to the extent they are involved with products with digital elements, under Article 24(3). The Commission's 27 July 2026 guidance addresses open source in more detail.
Where do I get help if I am a small company?
ENISA operates a helpdesk with particular attention to SMEs, and the CSIRTs designated as coordinators are also required to provide helpdesk support on the Article 14 duties. ENISA publishes a helpdesk address, cra-srp-helpdesk [at] enisa.europa.eu, for questions not answered by the FAQ or the guidance pages. The AR User Manual was published at launch, and the tutorial video followed within days.