How to report through the CRA Single Reporting Platform

How to report through the CRA Single Reporting Platform before a deadline

If you must notify an actively exploited vulnerability or a severe incident under Article 14, which has applied since 11 September 2026, you will submit through the platform interface only. The Single Reporting Platform is accessed with a personal EU Login account protected by multi-factor authentication, and no API was provided at initial release, so internal automation can prepare content but cannot send it. Your organization owns the notification and its content. An implementation partner can set up accounts, define roles and document internal workflows, but it does not submit on your behalf unless you authorize its people as your representatives.

Your readiness depends on three things you can check now. First, count your representatives. Each manufacturer has one Primary Assigned Representative and up to 20 Secondary representatives, and each needs a personal EU Login account with MFA. Confirm who holds each role, that every person can actually sign in, and that someone can reach the primary contact during an incident. Second, map your Member States. The coordinating CSIRT passes notifications to CSIRTs in other Member States where the product is available, so a broad distribution footprint raises the number of parties who may later see your notification and the number of internal contacts you need to keep current. Third, test access before you need it. ENISA advises registering and starting validation only when a notification is required, and registration takes a few minutes for anyone who already has an active EU Login account. Accounts that are not yet registered, MFA devices that are lost, or validations still pending can consume time you do not have inside the 24-hour window.

Ask your CSIRT coordinator, your legal team and your partner to confirm three points in writing before an incident occurs: who holds the primary role, who approves submissions, and who maintains the MFA recovery path. Review the field guidance in ENISA's SRP Glossary for each stage so that the people on call know which fields are required at the early warning and which become required later. Because the platform interface is in English only, make sure staff who will complete the forms can work in that language under pressure.

When to register and validate on the platform

This sequence gets your manufacturer account, representatives and validation in place so that a notification can be submitted without delay when one becomes necessary. ENISA advises starting validation only when you actually need to notify, so the steps below are the path to run when the need arises or when you rehearse it in a quiet period.

Confirm EU Login accounts and multi-factor authentication
Each person who will act for the manufacturer needs a personal EU Login account with multi-factor authentication enabled, because the Single Reporting Platform is accessed only through individual accounts. Confirm that every intended representative can sign in with MFA before you begin, and check that the email address on each account is one the team monitors. You know this step is complete when each representative has signed in successfully once with the second factor working. Accounts that already exist and are active need no new setup, and ENISA notes that registration takes only a few minutes for anyone who already holds one.
Register the manufacturer on the platform
Register your organization as a manufacturer on the Single Reporting Platform using the account of the person who will act as the primary contact. Record the legal details and the registration reference that the platform issues. Registration is separate from validation, and ENISA advises starting validation only when a notification is needed, so you can register early without triggering the validation process. You know this step is complete when the manufacturer appears in your account with a status showing registration, not validation.
Assign the Primary Assigned Representative
Nominate one Primary Assigned Representative for the manufacturer, normally a senior person in the security or product organization who has authority over reporting decisions. ENISA's FAQ says each manufacturer has exactly one Primary Assigned Representative, so this choice determines who is accountable for the link between the manufacturer and the platform. Confirm the nominee's name, role and contact details, and make sure a named deputy is documented internally. You know this step is complete when the platform shows the nominee as Primary Assigned Representative under the manufacturer record.
Add Secondary representatives
Add Secondary representatives who will prepare or submit notifications when the primary contact is unavailable or when the workload is shared. ENISA's FAQ allows up to 20 Secondary representatives per manufacturer, each with a personal EU Login account and MFA. Keep the list short enough that each person can be trained on the interface, and record why each person was chosen. You know this step is complete when each Secondary representative appears under the manufacturer with a pending or linked status and has received the platform invitation.
Submit the representative-manufacturer link for validation
Start validation for the manufacturer and its representatives when you have a notification to make or when you are running a rehearsal. The designated CSIRT checks that each representative is linked to the manufacturer, and this check runs in parallel with reporting rather than before it. Keep the request and any reference number in your incident record, because the validation status is what you will refer to if the CSIRT asks questions. You know this step is complete when the platform shows the link as submitted and the CSIRT's decision is pending or recorded.
Rehearse the path in a quiet period
Run the full path once outside an incident: sign in with each account, open the notification form, complete the fields for the early warning stage on a test basis if the platform allows it, and confirm who can save and who can submit. Validation can overlap with the reporting clock, so an unrehearsed account problem may surface only when you have a live event to report. Confirm with the platform documentation and your designated CSIRT how test entries are handled, because the platform's own guidance is the authority on this point. You know this step is complete when every representative has signed in, opened a notification form and written down any access problem to resolve.
Record the status and the escalation contacts
Document the registration reference, the validation status, the Primary Assigned Representative, the Secondary representatives and the contact route to the designated CSIRT in your incident response plan. Assign an owner to check the status of each account on a fixed schedule, and to re-run validation when a representative leaves or changes role. Note that the platform is available in English only and has no API at initial release, so the record must describe manual submission steps. You know this step is complete when the record is stored with your incident response plan and an owner has been named to maintain it.

Primary and secondary representatives: who can submit

Every manufacturer on the Single Reporting Platform works through a fixed set of named people, not a shared account. The cards below cover how those roles are structured, how each person signs in, how cover is planned, and who holds the authority to notify.

One primary and up to 20 secondaries

Each manufacturer has one Primary Assigned Representative and up to 20 Secondary representatives. The primary is the accountable contact for the manufacturer on the platform, and secondaries are the people who can work on notifications. Decide the count before you register so the list reflects real duties rather than whoever happened to ask for access. Confirm the current limits in ENISA's FAQ before you finalize the list.

Personal EU Login with MFA

Every representative signs in with a personal EU Login account protected by multi-factor authentication. Account creation is the first gate, so check early whether each nominee already has an active account, since that makes registration quick. Ask each person to enroll their own second factor, and keep a record of who holds which account so access reviews can be performed against names.

Why shared logins fail

A shared login hides who submitted a notification, who approved it and when. It also breaks multi-factor authentication, because one device or phone becomes a single point of control for the whole team. Each notification carries accountability for timing and content, so individual accounts are the only way to show who did what. Treat any request to share credentials as a refusal case.

Planning cover for leave

Reporting deadlines do not pause for holidays, so the list should include at least one secondary who can act while the primary is away. Check that each covering person has a working EU Login account and MFA device before the period starts, not during an incident. Write down who covers which product lines, so the backup knows which notifications they may handle.

Deciding who holds notification authority

The platform assigns access, but it does not decide who may commit the organization to a notification. Your leadership must name the person or role with authority to approve a submission, and state whether a secondary may submit without that approval. Record the decision in your incident procedure so an assessor can see who was empowered on a given date.

Keeping the representative list current

People change roles, leave the company or move between product teams, and each change affects who can submit. Review the list on a set schedule and whenever staff change, removing access the same day someone departs. Validation of the representative-manufacturer link runs alongside reporting, so confirm with the designated CSIRT that the link is accepted for every person you intend to use.

Which fields are required at each reporting stage

This table compares the 24-hour early warning, the 72-hour notification and the final report, using the field-level guidance in ENISA's SRP Glossary. Read each row as a stage, then check the glossary for the fields that apply to your notification type. The main takeaway is that a field left blank at the early warning may be mandatory later, so build a separate checklist for each stage.

Stage	Purpose	Field requirements	Checklist action
24-hour early warning	First notice that an actively exploited vulnerability or severe incident exists	Only the fields the glossary marks as required at this stage	List every field marked required for this stage and confirm each has an answer
72-hour notification	Updated assessment with more detail on the vulnerability or incident	Adds fields that are optional or absent at the early warning stage	Carry over early warning answers and add each field the glossary requires here
Final report	Closing account of the vulnerability or incident and the remediation	Adds fields that become required only once remediation is known	Keep a running record so that final report fields can be completed without reconstruction
Fields that become required later	Fields not mandatory at the early warning	The glossary states which fields change status at each stage	Mark these in your checklist with the stage in which they become mandatory
Notification type	Vulnerability and incident notifications may use different field sets	Field requirements differ by notification type in the glossary	Build separate checklists for vulnerability and incident notifications
Glossary version	Field lists can change between platform releases	Field requirements are set by the version of the glossary in use	Pull the current glossary before drafting and record its version in your procedure
Internal ownership	Someone must own each field's source data	Fields draw on product, security and legal information held in different teams	Name an owner for each field group and agree who signs off each stage
Stage-by-stage review	Early warnings are often sent with limited information	Missing required fields at a later stage can delay a complete notification	Review each draft against the checklist for its stage before submission

Using the platform interface and internal automation

Manual submission is the only route to a formal notification today. Each notification is entered field by field in the Single Reporting Platform interface, signed in with a personal EU Login account protected by multi-factor authentication. The platform is available in English only, so teams working in other languages should set up translation of internal drafts before anyone opens the form.

Named individual accounts: Each person who submits must use their own EU Login account, so shared credentials cannot be used for submissions.
Stage-specific fields: Fields not required in the 24-hour early warning can become required in the 72-hour notification or the final report, so check the field guidance for each stage before entry.
Session continuity: Plan for a submitter to finish a draft within one working session, and confirm how the interface handles saved drafts and timeouts in your test environment.
Secondary representatives: Make sure a trained secondary representative can submit if the primary is unavailable.
Record keeping: Save a copy of each submitted notification and its confirmation in your own incident file.

Before relying on this route, run a dry walkthrough with the people who will submit and confirm that every required field can be completed within your reporting deadline.

What happens after submission and what you still owe

Submitting a notification through the platform does not close your Article 14 obligations. Once the notification is submitted, it is made available to ENISA at the same time, and the coordinating CSIRT passes it to CSIRTs in other Member States where the product is available. That CSIRT also shares information with market surveillance authorities as needed. You do not control these onward flows, so the content you submit must stand on its own for readers in several national authorities, most of whom will not have your internal context. Write each field as if an authority outside your home market will read it first.

The clock keeps running after the first submission. The 24-hour early warning is only the first stage, and the later stages, including the 72-hour notification and the final report, must be sent on time through the same platform. Some fields that are optional at the early warning become required later, so the working draft you build for stage one should be kept current for stage two and three. Confirm in the ENISA glossary exactly which fields change at each stage before you assign owners. Two practical points matter here: the platform is available in English only, so translate internal technical notes before you rely on them, and it has no API at initial release, so each stage is keyed in by a named representative who holds a personal EU Login account with multi-factor authentication. Plan for that person to be available at each deadline. For the rules on any delays the CSIRT may apply to these deadlines, check the sibling playbook on the 24-hour early warning, which sets out how those delays are governed by the regulation.

What to have in place before the first notification

Four checks decide whether a manufacturer can file an Article 14 notification within the deadline. Each one is cheap to test now and expensive to discover during a live incident, so run them before any event occurs.

Active EU Login accounts with MFA

Every person who may file must hold a personal EU Login account with multi-factor authentication, because the platform is accessed only that way. Shared logins and accounts that have lapsed are common failure points. Verify each representative can sign in, that the MFA device is enrolled to that person, and that a second person can recover access if the first is unavailable.

Validated representative-manufacturer link

Each manufacturer has one Primary Assigned Representative and up to 20 Secondary representatives, and the designated CSIRT validates each link in parallel with reporting. Validation takes time that you do not control, so start it only when a notification is likely, but know the steps in advance. Confirm who holds the primary role and that the names on the account match your corporate records.

Named internal decision owner

Someone inside the organization must decide that an event is reportable, approve the content, and authorize submission at each stage. The platform cannot make that judgment. Write the owner's name, deputy and escalation path into the incident procedure. Test it in a tabletop exercise by asking who signs off a 24-hour early warning at an unusual hour and whether that person can log in.

Tested contact path to the CSIRT

Confirm the CSIRT you will notify before you need it, using the main establishment and fallback rules that apply to your organization. Check that the CSIRT's contact channels and the platform route are both reachable from your on-call rota. A test run of the notification path, with a dummy scenario and no live data, shows whether access, time zones and handovers work under pressure.

Stage-by-stage content template

Some fields that are optional in the 24-hour early warning become required in the 72-hour notification or the final report. Build a template for each stage that lists required fields from the ENISA glossary, the sources you will need to fill them, and who drafts each one. Walk a sample vulnerability through all three stages in a tabletop exercise to find gaps in evidence before a real deadline applies.

Questions buyers ask about the CRA reporting platform

Can an implementation partner submit CRA notifications on our behalf?

Partly. The manufacturer owns the reporting duty under Article 14, and the platform is accessed through personal EU Login accounts with multi-factor authentication, so each person who submits or validates must be a named individual at your organization. An implementation partner can prepare the internal triage process, the drafting templates, the evidence pack and the escalation path, and can rehearse the steps with your team. Whether an outside party is named as a representative is a decision for your organization and its legal advisers, so confirm the arrangement with them before the first notification is needed.

How many representatives should we name on the platform?

ENISA's platform FAQ describes one Primary Assigned Representative per manufacturer and up to 20 Secondary representatives, each with a personal EU Login account and MFA. Name enough people to cover working hours, leave and escalation, but keep the list short enough that each person can be trained and kept current. Secondary representatives are a continuity decision: someone must be able to submit within the 24-hour early warning window even when the primary is unavailable. Also confirm with the designated CSIRT how representative-manufacturer links are validated, because that check runs in parallel with reporting.

Does registering on the Single Reporting Platform cost anything?

The supplied ENISA guidance does not describe any fee for registration, and it advises that registration takes a few minutes for anyone who already has an active EU Login account. The main internal cost is people time: account setup, MFA enrollment, training and keeping the representative list current. ENISA advises manufacturers to register and start validation only when they need to submit a notification, which keeps the account administration tied to an actual reporting need. Ask your national CSIRT or ENISA to confirm any charges before relying on this.

Will ENISA add an API to the Single Reporting Platform?

No API was provided at the platform's initial release, and notifications must be submitted through the platform interface. ENISA's FAQ says organizations may automate their internal reporting workflows, so your internal ticketing, triage and drafting tools can be automated up to the point of submission. Plan for a manual submission step and a person who performs it. Do not design an integration that assumes an API exists. Check ENISA's FAQ for later releases before changing the process, and confirm any future interface with ENISA directly.

What does the work require from our internal teams?

The platform itself needs little engineering, but the reporting duty needs decisions and records. Your product security or PSIRT lead must own the awareness assessment, legal must confirm the notification scope and the CSIRT choice, and engineering must supply the technical facts for each stage. Expect a named owner for triage, a drafting process for the 24-hour early warning, the 72-hour notification and the final report, and a log of decisions. ENISA's SRP Glossary sets out which fields are required at each stage, so the team should read it before the first live event.

Can a partner help us prepare the reporting workflow?

Yes. DeployOpen plans, implements, documents and supports self-hosted open-source platforms in your own infrastructure, and it can prepare the internal systems and evidence that support CRA reporting, such as ticket routing, vulnerability intake, logging and runbooks. A fixed-scope engagement would define the written deliverables, the systems covered and the timeline before work starts. DeployOpen does not submit notifications as your manufacturer representative and does not issue any conformity or compliance certificate. Your organization owns the reporting duty, and a quote follows from the agreed scope.

When should we register and start validation on the platform?

Register and start validation when you need to submit a notification, not earlier, as ENISA advises. Registration itself is quick for anyone with an active EU Login account, but the CSIRT validation of the representative link runs alongside reporting, so starting it only when a notification is needed can still delay a live submission. The practical approach is to rehearse the account setup in a planning exercise, keep the representative list documented, and check that every named person can log in with MFA before an event occurs.

What an implementation partner can and cannot do for this step

The manufacturer owns every notification it makes through the Single Reporting Platform, including the decision to submit, the content of each stage and the authority of the people who log in. An implementation partner can prepare the ground around those decisions. That work includes setting up the EU Login accounts and MFA enrollment for the Primary Assigned Representative and any Secondary representatives, writing the internal runbook that says who triages a finding and who approves a submission, building a field-by-field checklist drawn from ENISA's SRP Glossary for the 24-hour early warning, the 72-hour notification and the final report, and running tabletop exercises so the team can practice the steps before a real event starts.

A partner cannot submit a notification on the manufacturer's behalf in a way that changes who is accountable for it, and it cannot decide whether a vulnerability is actively exploited or whether an incident is severe. Those judgments belong to the manufacturer and must be documented. A partner also does not certify compliance with the Cyber Resilience Act, and it does not issue any report, attestation or acknowledgment that a notification was accepted. Outcomes come from the designated CSIRT and, where relevant, the national market surveillance authority. Before engaging anyone, confirm in writing which named person in your organization holds the Primary Assigned Representative role, and confirm with the CSIRT you identified which validation steps apply to your representative link.

When you scope the work, ask the partner to state each deliverable as a document, configuration or exercise that your staff keep and operate after the engagement ends. Ask for the account and role mapping, the runbook, the checklist and the exercise record, and confirm who owns each one. Ask how the partner will handle the lack of an API, since the platform had no API at initial release, so the runbook must show that every submission is typed into the platform interface by an authorized representative. Confirm the platform's current interface language and any changes against the ENISA platform FAQ before the work is fixed in scope.

How DeployOpen prepares your team to report

DeployOpen works on the reporting side of the CRA as a readiness partner. We help your team set up the accounts, roles, internal workflow and evidence it needs before a notification is due, while your organization keeps ownership of every submission and decision. We do not file notifications or act as your representative on the platform.

How we scope

Engagements are fixed-scope, with the scope, deliverables and timelines agreed in writing before work starts.
We confirm which products and manufacturer entities need platform accounts, and who would hold the primary and secondary representative roles.
The written scope states which internal workflows, templates and runbooks are included, and which reporting decisions remain with your organization.

How we build

We map the EU Login setup, MFA enrollment and access approvals for each named representative before any live notification.
We build an internal intake workflow that records when awareness starts and routes the event to the right owners quickly.
We prepare field-by-field worksheets based on the ENISA glossary so each stage of the notification has its data ready.

How we hand over

You receive the documented runbook, representative register, role assignments and completed field worksheets as written deliverables.
We walk your team through a tabletop exercise that rehearses a 24-hour early warning using an illustrative vulnerability scenario.
Handover covers what to confirm with the designated CSIRT and ENISA directly, since platform behavior and guidance may change.

How we support

Ongoing support, upgrades and continuous testing are available as retainers, so the reporting process can be kept current.
A retainer can cover periodic review of representative accounts, role changes and updates to the internal workflow.
Ask any provider to confirm in writing which platform changes they will track and how they will update your runbook.

How to report through the CRA Single Reporting Platform