Manufacturers can prepare for the CRA Single Reporting Platform before it goes live by organising reporting ownership, EU Login access, product data, evidence, and internal escalation around the staged notification process. ENISA's current guidance gives enough operational detail to build and rehearse that process without assuming that every platform feature is final.
What the Single Reporting Platform changes
The Cyber Resilience Act requires manufacturers to report certain actively exploited vulnerabilities and severe incidents affecting the security of products with digital elements from 11 September 2026. Article 16 establishes a single reporting platform operated by ENISA so that manufacturers can submit through one electronic entry point rather than separately notifying multiple national authorities.
The platform does not remove the need to determine the correct national reporting route. A notification is addressed to the Computer Security Incident Response Team (CSIRT) designated as coordinator according to the rules in Article 14, generally based on the manufacturer's main establishment in the Union. ENISA receives the notification as provided by the regulation, while the receiving CSIRT handles further dissemination to other relevant CSIRTs.
ENISA says the platform is scheduled to be operational by 11 September 2026 and that functional and security testing is under way. Its guidance is being updated as implementation progresses. Product teams should therefore separate two things: the legal reporting obligations, which are fixed by the CRA, and user-interface details, which can still change before launch.
For Austrian manufacturers, the practical preparation task is to know which legal entity acts as manufacturer for each product, where its main establishment is located, and who is authorised to submit on its behalf. That information should be available before an incident occurs, even if the final national coordinator list or platform interface changes.
Start with the reporting role, not the form
ENISA's current user guidance uses the concept of an Assigned Representative, or AR, for manufacturer and open-source software steward users. The guidance distinguishes a Primary Assigned Representative from Secondary or Backup representatives.
An active EU Login account is a prerequisite for SRP registration. Creating EU Login accounts in advance is therefore useful. However, ENISA currently advises manufacturers and open-source software stewards not to pre-register in the SRP merely to create dormant accounts. The association between an assigned representative and a manufacturer is validated by the relevant CSIRT, and ENISA recommends starting that process when a specific notification needs to be submitted.
This creates an important readiness distinction:
- prepare EU Login access before an incident;
- decide who will act as Primary and Backup representatives;
- document who can approve and submit regulatory notifications;
- keep manufacturer legal details ready;
- wait for the current ENISA instruction before initiating SRP registration itself.
The validation process is not intended to block a notification. ENISA states that representative validation can occur in parallel with reporting and does not prevent submission. Even so, organisations should avoid discovering during an incident that the intended reporter has no EU Login account, no access to the necessary legal information, or no internal authority to submit.
Build the data package before the portal is needed
The most effective CRA Single Reporting Platform preparation is not memorising a future user interface. It is making the required information retrievable from existing product-security systems.
ENISA's FAQ now describes the reporting template fields and identifies which data is obligatory, optional, automatically populated, or carried forward between stages. The exact screen layout may evolve, but the underlying information requirements give teams a concrete preparation target.
At minimum, reporting teams should be able to retrieve:
- the manufacturer or open-source software steward identity;
- the affected product and its relevant version or release family;
- the Member States where the product has been made available, where that information is required and available;
- whether the notification concerns an actively exploited vulnerability or a severe incident;
- the awareness time and the evidence supporting that time;
- available identifiers such as CVE or EUVD references;
- the nature of the vulnerability, exploit, or incident;
- corrective or mitigating measures already taken;
- measures users can take;
- the sensitivity of the reported information;
- later-stage severity, impact, root-cause, threat, and remediation information.
These fields should be linked to authoritative internal records rather than copied manually from scattered documents. A reporting case should be able to reference the affected release, SBOM or component inventory, vulnerability record, incident timeline, remediation decision, security update, and relevant market information.
Design around the three reporting stages
The SRP workflow mirrors the staged reporting model in the CRA. ENISA's current submission guidance separates the Early Warning, 72-hour Notification, and Final Report into successive steps associated with the same notification.
Early warning
The early warning is the first regulatory submission. It must be possible to submit it while technical investigation is still incomplete. The internal workflow should therefore focus on establishing the event type, manufacturer and product identity, awareness timestamp, available market information, and the minimum facts needed for a responsible submission.
A common operational mistake is to delay escalation until engineering has a complete root-cause analysis. The CRA's staged model exists because the information improves over time. Internal approval rules should allow a timely early warning based on the facts available at that point.
72-hour notification
ENISA's guidance requires an Early Warning to exist before the 72-hour stage is submitted. At this stage, the reporting team needs more structured technical information: the general nature of the vulnerability or incident, an initial assessment, corrective or mitigating measures, available user actions, and sensitivity information where applicable.
The organisation should define which systems supply these fields and who owns each answer. Product security may own the technical assessment, engineering may own affected versions and mitigation, legal or compliance may review regulatory interpretation, and communications may prepare user-facing measures. The SRP submission should be the output of that coordinated process, not the place where the process begins.
Final report
The Final Report depends on the earlier stages and closes the regulatory reporting sequence. ENISA's current workflow makes the notification non-editable after the Final Report is submitted. That reinforces the need for an internal review step before closure.
For vulnerabilities, the final information includes the vulnerability description, severity and impact, available information about the malicious actor, and the security update or other corrective measure. Severe-incident reporting requires a detailed description, impact, likely threat or root cause, and mitigation information.
Treat the SRP as a manual endpoint for now
Organisations can automate their internal reporting workflow, but ENISA currently states that no API will be provided at this stage for automated SRP submission. That means engineering teams should not build a production dependency on an assumed SRP API.
A better design is to automate everything up to the regulatory hand-off:
- detect and triage the event;
- open a controlled reporting case;
- collect product, component, market, and incident data;
- calculate and preserve legal deadline timestamps;
- generate a reviewed reporting data package;
- assign the authorised representative;
- submit through the current SRP interface;
- store the submission confirmation and later updates back in the case record.
This keeps the internal workflow stable even if ENISA changes the portal screens or later introduces machine-to-machine interfaces.
Rehearse access and reporting without inventing platform behaviour
A useful tabletop exercise can be run before the public SRP URL is available. The objective is not to simulate buttons that may change; it is to prove that the organisation can produce the required facts and decisions within the CRA deadlines.
Use a realistic scenario such as an actively exploited vulnerability in a third-party component used by a supported product. Record the moment the organisation becomes aware, then test whether the team can identify affected versions, determine the manufacturer entity, find market availability information, appoint an authorised reporter, prepare the early-warning data, and continue into the 72-hour data set.
The exercise should produce evidence of gaps. Typical findings include missing product ownership, inconsistent version identifiers, no authoritative record of Member State availability, unclear submission authority, unavailable backup representatives, or vulnerability records that are not linked to release evidence.
Resolve those gaps in normal engineering and governance systems rather than creating a separate emergency spreadsheet that will become outdated.
Protect sensitive reporting information
The CRA requires the reporting ecosystem to handle sensitive cybersecurity information, and ENISA describes security and confidentiality controls for the platform. Internal preparation should apply the same discipline before the data reaches the SRP.
Limit access to reporting cases according to role, preserve an audit trail, protect credentials, and avoid moving sensitive exploit or incident details through uncontrolled email and chat channels. The record should show who changed the assessment, who approved the submission, which information was marked sensitive, and which version of the report was actually submitted.
The receiving CSIRT may, in exceptional circumstances and on justified cybersecurity grounds, delay dissemination of a notification. That is a specific regulatory mechanism, not a reason for an organisation to withhold required reporting internally. Teams should capture sensitivity concerns as part of the reporting case so that they can be expressed correctly in the notification.
A practical readiness checklist for August 2026
With the reporting obligations approaching, product teams can complete a focused preparation cycle without waiting for the final public SRP URL.
- Map manufacturer entities and products. Link each supported product family to the legal manufacturer and its main establishment.
- Name Primary and Backup representatives. Define submission authority, escalation coverage, and substitutes for absence.
- Create EU Login accounts. Verify that intended reporters can authenticate, while following ENISA's current advice on when to initiate SRP registration.
- Structure the reporting data. Map each current ENISA reporting field to an internal system, record, or accountable owner.
- Preserve awareness timestamps. Ensure vulnerability and incident intake processes record when reliable information reaches the organisation.
- Connect release evidence. Make product versions, SBOM data, affected components, mitigation status, and security-update evidence retrievable.
- Maintain market information. Establish a reliable way to identify Member States where affected products have been made available.
- Prepare stage-specific review. Define what can be approved for the early warning, what must be enriched by 72 hours, and what closes the Final Report.
- Run a timed exercise. Test the full reporting case from awareness through draft submissions and evidence retention.
- Monitor ENISA guidance. Re-check the SRP FAQ and user guidance before operational use because the implementation material is explicitly subject to update.
What readiness should look like on launch day
A prepared manufacturer should not need the SRP to discover its own reporting process. When a reportable event occurs, the organisation should already know who owns the case, which legal entity is responsible, how the awareness time is established, where product and market data come from, who can submit, and how each staged report is retained as evidence.
The CRA Single Reporting Platform then becomes the regulatory delivery channel for an operating process that already exists. That is the most resilient preparation strategy while ENISA continues to finalise and update the service before 11 September 2026.
Official sources
- Regulation (EU) 2024/2847 — Cyber Resilience Act — EUR-Lex
- Single Reporting Platform (SRP) — ENISA
- Frequently Asked Questions — ENISA
- CRA SRP guidance - AR User registration — ENISA
- CRA SRP guidance - AR Notification submission and update — ENISA
- Cyber Resilience Act - Reporting obligations — European Commission