CRA Single Reporting Platform Integration
The CRA's Single Reporting Platform is a web form and case management system that ENISA runs, not an API, with no published roadmap for one. Registration runs through named individual Assigned Representatives, and one notification record moves through three stages that lock for good once the final report is submitted.
15 min read
36 views
Key takeaways: CRA Single Reporting Platform integration 5
What the CRA Single Reporting Platform is actually built to do today, and where a team needs to build its own automation instead of waiting for one.
- No API at launch, and no published roadmap for one Submission is a web form only. ENISA says organizations may automate their own internal workflows, but no programming interfaces will be provided at this stage, so build internal automation and decide account custody without waiting for one.
- The platform's Assigned Representative is not the Regulation's authorized representative Accounts belong to individual users, a primary and a backup, tied to a manufacturer entity, not to the Article 3(15) authorized representative role, and the two should never be conflated in an internal process.
- Validation is not a prerequisite, and ENISA's own timing advice creates a trap Decide who the primary and backup representatives are and give them working EU Login accounts now, before an incident starts the 24-hour early warning clock set by Article 14(2)(a) and Article 14(4)(a).
- One record moves through three stages, and the final report locks it for good Everything a team might still want to correct has to be correct before the final report, so put a real review step in front of that submission.
- The published field schema is the best available intake checklist Twelve common fields, fourteen vulnerability-specific fields and thirteen incident-specific fields show exactly what evidence to capture at detection time, when it is cheapest to collect.
In short: The EU Cyber Resilience Act, Regulation (EU) 2024/2847, requires manufacturers to file notifications of actively exploited vulnerabilities and severe incidents through a single reporting platform, established under Article 16, that ENISA runs as a web form and case management system rather than an API at this stage. Registration runs through named individual Assigned Representatives rather than a company account, and one notification record moves through three stages, early warning, the 72-hour notification and final report, becoming non-editable once the final report is submitted.
There is no API, and no roadmap for one
Most compliance deadlines eventually reduce to an integration problem: point a webhook at a vendor endpoint, map a payload, done. The Cyber Resilience Act's Single Reporting Platform does not offer that shortcut. It is a web form with a login screen, a case management view and a defined set of fields, built for a human to fill in, not for a system to call. Whatever automation exists around it, your team has to build.
ENISA is explicit about this in its own guidance on the platform, and its own wording answers the question every engineering lead asks first: “Organisations might automate reporting workflows and integrate reporting requirements into their systems and databases, however no Application Programming Interfaces will be provided at this stage.”
That sentence does two things at once. It tells you that your own internal automation is fine and expected, ENISA even encourages it, but it also tells you the platform itself is not going to meet you halfway. There is no published roadmap for a future API, and nothing in the guidance suggests one is coming before the launch date. A team planning to file its first notification by opening the form manually is not behind schedule. It is planning for the system as it actually exists.
This constraint should reshape how an engineering organization scopes this project. The work is not an integration sprint against a third-party API contract. It is building the internal machinery that decides, quickly and correctly, what goes into that form, who is authorized to submit it and what happens the moment a candidate incident is flagged.
The platform itself is not an ENISA product built on discretion. Article 16(1) of the Regulation establishes it for the mandatory notifications required under Article 14, puts ENISA in charge of its day-to-day operations and lets Member States and ENISA run their own electronic notification end-points inside that single architecture, in order to simplify the reporting obligations of manufacturers. Article 14(7) ties a manufacturer's own submission duty to one of those same electronic notification end-points, so the account model described next sits on infrastructure the Regulation itself defines rather than on anything ENISA invented independently. That simplification is scoped to the CRA's own reporting duty. It does not fold in the separate NIS2 or DORA reporting obligations a company might also carry.
Two people, not a manufacturer account
There is no such thing as a manufacturer account on the Single Reporting Platform. What exists instead are user accounts held by individuals in the role of Assigned Representative, in two variants: a primary and a backup, each associated with a manufacturer entity inside the platform.
The Assigned Representative role on this platform is not the authorized representative defined in Article 3(15) of the Regulation, a natural or legal person established within the Union who holds a written mandate from a manufacturer to act on its behalf for specified tasks, under the wider text at Regulation (EU) 2024/2847. That distinction matters more than it looks. The two share an abbreviation and nothing else. One is a mandate for specified tasks under the Regulation, open to any manufacturer regardless of where it is established. The other is a login on a reporting tool. Conflate them in an internal process document and someone will eventually assign the wrong person, or the wrong company function, to a role that was never legally required of them.
Authentication runs through EU Login, the European Commission's shared identity service, and accounts for it can be created well ahead of any incident. Registration itself follows a fixed sequence:
- Open the platform
- Select the Assigned Representative role
- Choose the coordinating CSIRT for the organization from a dropdown list
- Authenticate through EU Login
- Accept the platform's legal agreement
- Confirm the personal details EU Login already carries
- Enter the manufacturer's own details
Supplying those manufacturer details is what creates the manufacturer entity inside the platform, the first time anyone from that organization registers.
A backup representative does not go through that same manufacturer-creation step. They join by invitation from the primary representative, and that invitation carries an expiry of seven days. Miss the window and the invitation record moves into an expired state rather than staying open, and the primary has to send a fresh one. For an organization that treats the backup role as an afterthought, filled in only when the primary is unavailable, build a calendar reminder around that expiry rather than discovering it during an actual incident.
The validation paradox
One detail in ENISA's guidance creates a genuine operational trap for a well-intentioned team. Validation of an Assigned Representative by the coordinating CSIRT happens after registration, and the guidance says plainly that it “is not a prerequisite for fulfilling the CRA reporting obligation”, meaning an account that has not yet been validated by the CSIRT can still submit a report against the clock.
That reads like good news, until ENISA's next piece of advice cuts the other way: organizations “are advised to register and initiate the validation process only when they need to submit a specific notification”, rather than creating accounts ahead of time as a matter of housekeeping.
Followed literally, that advice produces this sequence. A vulnerability is confirmed as actively exploited on a Tuesday afternoon. The 24-hour early warning clock, set by Article 14(2)(a) for actively exploited vulnerabilities and Article 14(4)(a) for severe incidents, starts. Nobody at the organization has an EU Login account tied to an Assigned Representative role yet, because the guidance said not to bother until this exact moment arrived. Now the first thing that has to happen, provisioning a named human with an EU Login identity and walking them through the registration sequence, competes for time with the 24 hours the Regulation actually gives you.
The practical fix does not require ignoring ENISA's advice, just narrowing what it applies to. Registering the manufacturer entity and starting CSIRT validation can reasonably wait until a real notification is on the table, exactly as advised. Deciding who holds the primary and backup Assigned Representative roles, and making sure those specific people already have working EU Login accounts, is a piece of preparation that costs nothing to do now and nothing to maintain. Do that part in advance regardless of what the rest of the guidance says about timing, because it is the one piece of the paradox that is entirely within your control before an incident ever happens.
One record, three stages
It helps to stop thinking of the early warning, the 72-hour notification and the final report as three separate filings, because inside the platform they are not. One notification record is created at the early warning stage and then advanced through the later stages by reopening that same record, not by starting over. The exact deadlines for each stage are covered in detail elsewhere in this cluster; this article is about how the platform treats them as one evolving record rather than three independent filings.
The early warning creates the record and pre-fills it with the user type, manufacturer or open-source software steward. From there the submitter selects an existing manufacturer entity already registered on the platform, which may show as approved or as still pending CSIRT validation, or adds a new one on the spot. The record can be saved as a draft at this point rather than submitted immediately, which matters for a team that wants a second set of eyes before anything goes to a regulator.
Later stages reuse that same record rather than opening a new one. The 72-hour notification and the final report are filed by reopening the case from the dashboard and completing the corresponding stage, and each stage requires the one before it to have actually been submitted, so a team cannot skip from a saved draft straight to a final report. Outside that fixed sequence, Article 14(6) lets the coordinating CSIRT request an intermediate report on status updates at any point it considers necessary, a request a team should be ready to answer without treating it as one of the three scheduled stages.
The record's state reflects exactly where it sits in that sequence: draft, early warning, 72-hour notification submitted, a distinct variant of that stage for particularly exceptional circumstances and final report submitted. That last state closes the loop for good, and a team needs to plan around it accordingly. The record itself becomes non-editable once the final report goes in. Anything a team might still want to correct, a detail that changed, a root cause that got clearer, a number that was wrong, needs to be right before that submission, not after. The engineering consequence is straightforward: put a real review step in front of the final report button, because there is no edit button on the other side of it.
Updates the platform does allow, at the earlier stages, are not silent either. When a notification is updated, the platform alerts the coordinating CSIRT, and it also alerts ENISA and any CSIRTs that had already received the record through earlier dissemination. An update is visible to everyone who has already touched the case, which is a reasonable design choice and also a reason not to treat the draft stages as a scratchpad for information the team has not actually confirmed.
Dissemination is partly manual at launch
Submitting a report and having the right authorities see it are not the same event, and the gap between them is larger than most teams assume. Article 16(2) of the Regulation puts onward dissemination to CSIRTs in other Member States in the hands of the coordinating CSIRT rather than the platform itself, and requires that CSIRT to disseminate without delay, subject to the delay grounds the same paragraph sets out for exceptional and particularly exceptional circumstances. At launch, that legal design plays out as a manual step. ENISA's own guidance states it directly: “Concerned CSIRTs will receive the Early Warning only after manual dissemination by the CSIRT Designated as Coordinator.”
The 72-hour vulnerability notification behaves a little differently. Article 16(2)'s particularly exceptional circumstances variant is tied specifically to the notification referred to in Article 14(2), point (b), the vulnerability's 72-hour notification, not the incident's 72-hour notification under Article 14(4), point (b). ENISA receives that vulnerability notification automatically under Article 14(7), which requires the notification to be simultaneously accessible to ENISA, but only in the ordinary case, where particularly exceptional circumstances have not been invoked. Invoke that variant and the automatic path to ENISA no longer applies in the same way.
For a team building an incident timeline that a customer, a board or an auditor might eventually ask to see, state this distinction plainly rather than assuming it away. A confirmation that a submission went through, whatever form that confirmation takes on the platform, tells you the record moved from draft to the next stage. It does not tell you every relevant national authority has already seen it, and the timing of that onward step sits with a CSIRT's own process, not with anything a submitting team controls or can accelerate by resubmitting.
The published field schema is the most actionable thing here
Of everything ENISA has published about the platform, the reporting template itself is the piece an engineering team can act on immediately, before the platform even goes live. It exists as a table, broken down field by field, within the same body of ENISA guidance already cited in this article, including ENISA's guidance on notification submission and update. Every field carries a marker showing how it behaves at each of the three stages:
- Obligatory
- Carried over unchanged from the previous stage
- Carried over but updatable
- Optional
- Obligatory only where the information is actually available
- Automated, not even shown to the person filling in the form
The schema breaks into three groups.
| Field group | Field count | Applies to |
|---|---|---|
| Common fields | 12 | Both vulnerability and incident reports, among them the Member States where the affected product has been made available and, per ENISA's published field schema, the product's risk classification as default, important or critical |
| Vulnerability-specific fields | 14 | Vulnerability reports only, including a CVE identifier and an identifier from the European vulnerability database |
| Incident-specific fields | 13 | Incident reports only. The Regulation's own minimum content for an incident early warning includes whether the incident is suspected of being caused by unlawful or malicious acts, under Article 14(4), point (a) |
None of that structure is secret, and none of it requires waiting for the platform to open. A team can pull the published field list today and check it against whatever intake form, ticket template or incident runbook currently captures a candidate vulnerability or incident internally. The value of doing that now is timing rather than novelty: these are exactly the fields that need to exist at the moment of detection, which is the cheapest point in the whole process to capture them and also the point where teams under pressure routinely skip them. Reconstructing a CVE identifier or a precise list of affected Member States three days into an incident, from memory or from logs that have already rotated, costs far more than adding two fields to an intake ticket in advance. Populating the vulnerability-specific fields correctly also depends on the broader vulnerability handling duties a manufacturer already carries under the Regulation, not just what this platform's form happens to ask for.
Treat the schema as a checklist for your own tooling rather than as documentation to read once and file away. Wherever an internal tracker is missing a field the platform requires, that is a specific, dated task, not a general compliance reminder.
Status, logistics and what this platform is not
The platform is scheduled to be operational by 11 September 2026, the date the Article 14 reporting obligation itself begins to apply. Its public URL had not been published as of this writing and will be announced closer to launch. Do not build a bookmark, a script or a runbook around a guessed address; wait for ENISA's own announcement.
Set expectations now around two more launch details. Voluntary reporting sits squarely within the platform's legal scope: Article 16(1) establishes the single reporting platform for the mandatory notifications under Article 14 and for the voluntary notifications an organization can make under Article 15(1) and (2) alike. What is missing is purely operational. ENISA has said voluntary reporting is not available at launch and is planned to be enabled afterward, so the gap sits between what the law already covers and what the launch build actually offers, not between what the Regulation allows and what it does not. The platform's user classes are manufacturers and open-source software stewards specifically. Importers and distributors, who carry their own obligations elsewhere in the Regulation, are not user classes of this particular system, so do not plan an importer or distributor account into an onboarding process.
ENISA runs a dedicated helpdesk mailbox for platform questions and has indicated it expects to run a webinar shortly before the service goes live, a reasonable moment to raise anything this article leaves unresolved once the actual interface is visible.
One last conflation is common enough to name directly. The Single Reporting Platform is not the European vulnerability database. They are separate systems, established under separate instruments, serving different functions. A report filed on one is not automatically visible in the other. Build an internal process with that separation in mind rather than assuming a single filing covers both.
How Pharos Production helps
The work described above is not legal work, and none of it waits for the platform's URL to be published. It is intake design, identity provisioning and a review gate, the kind of work our compliance and regtech engineering practice builds daily, and every piece of it can be built against the published field schema and the account model this article describes right now.
We build the internal intake that mirrors the platform's published fields exactly, tied to the detection tooling that already exists inside a client's environment, so the twelve common fields, the fourteen vulnerability-specific fields and the thirteen incident-specific fields get captured as part of the normal triage flow rather than reconstructed under pressure three days into an incident. Deciding and documenting who holds the primary and backup Assigned Representative roles happens before that decision has to be made during a live 24-hour clock, with EU Login access provisioned for those two people ahead of time. A review step sits in front of the final report submission too, because the platform gives a team exactly one chance to get that stage right.
Sources: ENISA, Single Reporting Platform frequently asked questions (enisa.europa.eu/topics/product-security/single-reporting-platform-srp/frequently-asked-questions); ENISA, CRA SRP guidance on Assigned Representative user registration (enisa.europa.eu/topics/product-security/single-reporting-platform-srp/cra-srp-guidance-ar-user-registration); ENISA, CRA SRP guidance on notification submission and update (enisa.europa.eu/topics/product-security/single-reporting-platform-srp/cra-srp-guidance-ar-notification-submission-and-update); Regulation (EU) 2024/2847 of the European Parliament and of the Council (eur-lex.europa.eu/eli/reg/2024/2847/oj), Articles 3(15), 14, 15, 16 and 18.
FAQ
Quick answers to common questions about custom software development, pricing, process and technology.
Type to filter questions and answers. Use Topic to narrow the list.
Showing all 7
No matches
Try a different keyword, change the topic or clear filters
-
No, not at launch. ENISA's own guidance states that organizations might automate their own reporting workflows and integrate reporting requirements into their internal systems and databases, but that no Application Programming Interfaces will be provided at this stage.
Submission is a web form only, and there is no published roadmap for an API to follow.
-
Partly, and the boundary is not where this often gets summarized. Article 18(3) sets a floor rather than a ceiling: the mandate a manufacturer gives an authorized representative must allow that representative to do at least three things, keep the EU declaration of conformity and the technical documentation at the disposal of market surveillance authorities, respond to their reasoned requests and cooperate with them on request.
A manufacturer can extend the mandate beyond that baseline. The first of those three mirrors a duty the manufacturer itself carries under Article 13(13), so the mandate genuinely puts a manufacturer obligation into the representative's hands. Article 18(2) draws the real limit elsewhere: the manufacturer's own Article 13(1) to (11), Article 13(12) first subparagraph and Article 13(14) obligations, including the essential cybersecurity requirements and vulnerability handling duties, never form part of any mandate. Either way, the manufacturer remains the party the Regulation holds responsible; appointing a representative reallocates who performs specified tasks, not who answers for the product.
-
No. Validation of an Assigned Representative by the coordinating CSIRT happens after registration and is explicitly not a prerequisite for fulfilling the CRA reporting obligation, so an unvalidated account can still file a notification against the clock. ENISA nonetheless advises registering and starting validation only when a specific notification actually needs to be submitted, which is worth reading as advice about the manufacturer registration step, not about deciding in advance who the primary and backup representatives will be.
-
No. They are three stages of a single notification record. The early warning creates the record, and the 72-hour notification and the final report are filed later by reopening that same record from the dashboard, with each stage requiring the previous one to have already been submitted.
-
Only up to a point. The record becomes non-editable once the final report is submitted.
Updating an earlier stage is possible and triggers alerts to the coordinating CSIRT, to ENISA and to any CSIRTs that previously received the record through dissemination, but there is no path back into a record once the final report stage is reached.
-
Not necessarily. Article 16(2) of the Regulation requires the coordinating CSIRT to disseminate a notification to CSIRTs in other Member States without delay, subject to the delay grounds that same paragraph sets out for exceptional and particularly exceptional circumstances.
At launch, that legal duty plays out as a manual step. ENISA's own guidance confirms that concerned CSIRTs receive the early warning only after manual dissemination by the coordinating CSIRT. The 72-hour vulnerability notification behaves differently. Article 16(2)'s particularly exceptional circumstances variant is tied specifically to the notification referred to in Article 14(2), point (b), the vulnerability's 72-hour notification, not the incident's 72-hour notification under Article 14(4), point (b). ENISA receives that vulnerability notification automatically under Article 14(7), which requires the notification to be simultaneously accessible to ENISA, but only in the ordinary case, where particularly exceptional circumstances have not been invoked. A team's submission being accepted does not fix the timing of who else has seen it, and that timing sits outside the submitter's control.
-
Yes. Where necessary, the CSIRT designated as coordinator that first received a notification may request an intermediate report on relevant status updates about the actively exploited vulnerability or severe incident, separate from the early warning, the 72-hour notification and the final report.
A team's incident process should have a way to respond to that kind of ad hoc CSIRT request without treating it as one of the platform's own scheduled stages.
I work with startup founders who need a dedicated software development team but don’t want to gamble on hiring, random outsourcing, or opaque delivery.
Most founders face the same problem sooner or later.
Early technical and team decisions lock the product into tech debt, slow delivery, missed milestones and constant re-hiring. By the time this becomes visible, fixing it is already expensive.As a CTO and software architect, I help founders design, build and run dedicated development teams that work as a true extension of the startup. Not as a black-box vendor.
My focus is on complex products where mistakes are costly:
- Web3 and blockchain platforms
- FinTech and regulated products
- High-load startup systems
- MVP → scale transitions
We don’t do body-shopping.
We don’t sell generic outsourcing.Instead, we help founders:
- build the right team structure from day one
- keep technical ownership and transparency
- scale delivery without losing control
- avoid vendor lock-in and hidden risks
Teams are aligned with the product roadmap, business goals and long-term architecture. Not just short-term velocity.
