The working guide / Product security

Single Reporting Platform explained

Understand Single Reporting Platform, its role in CRA product security and the evidence your team should keep. Read the practical definition.

The Single Reporting Platform is ENISA’s electronic route for CRA notifications. In CRA work, the term should be understood in the context of the product, its supported release and the relevant legal duty.

What it means in practice

Set up access and review current ENISA instructions in advance. Keep submission acknowledgments. An internal draft is not a filed notice; the manufacturer needs a named submitter and an authorised backup.

How to use the term in a product review

Begin by asking which product version the discussion concerns. Record the source of the information and the person responsible for reviewing it. A familiar acronym can conceal different assumptions between a firmware engineer, a compliance manager and a supplier. Write down the intended meaning in the technical evidence so those assumptions can be checked later.

Distinguish an input, an engineering conclusion and a formal conformity decision. A tool output can be a useful input without proving that an obligation is fulfilled. A reviewer needs to see the underlying artifact, the relevant requirement and the rationale connecting the two. Keep uncertain facts visible and assign a follow-up rather than silently turning an unknown into an approval.

Read the practical guide for the operational workflow and the Cyber Resilience Act overview for the broader obligations. Connect product evidence to the release inventory and ensure the incident contact understands the Article 14 process.

A useful question to ask your supplier

Ask for an example linked to an actual release and a description of who reviews it. Clarify what is automated, what an engineer decides and what remains the manufacturer’s responsibility. This separates a useful deliverable from an unexplained label in a sales presentation. External tools and advisers can support the work, but the manufacturer remains accountable for product obligations.

An illustrative engineering scenario

For example, a team may prepare an early warning in an internal portal yet fail to submit it because the authorised account owner is unavailable. A realistic drill tests access, review authority and a substitute, as well as drafting. Keep submission identifiers, actual timestamps, approved versions and acknowledgments. Review current platform instructions because workflows can change. An internal approval or saved draft does not stop the deadline clock. Roja prepares copy-ready drafts; the customer reviews and submits through its authorised account.

Review questions for the product owner

Ask which product and supported version the evidence describes, which facts were checked directly and which remain assumptions. Identify the reviewer who can explain the result and the artifact that supports it. A document should not become authoritative merely because it appears in a customer portal. If its boundary is narrower than the finished product, make that limitation clear to everyone relying on it.

Check how this information enters the release process. Decide who updates the record after a component change, a new function, a supplier advisory or a change in the product’s support status. Keep older decisions available for older supported versions. Copying the latest release’s conclusion onto every branch can hide differences that matter to vulnerability handling and customer communication.

A handover that remains useful

Give the next engineer the source reference, the technical conclusion, the remaining uncertainty and the next action. Define what evidence would close an open question, who owns that work and when the team will review it. This turns a glossary concept into a practical engineering task rather than an unexplained acronym.

External suppliers can help create and maintain these records, but the manufacturer still needs to understand the basis for its decisions. Clarify which work is automated, which requires engineering judgment and which needs a separate conformity or legal specialist. Preserve the reasoning in a form your team can inspect and export. The goal is continuity across releases and personnel changes, with an evidence trail that remains connected to the actual product.

Sources

General engineering information, reviewed on the date above. Product-specific interpretations and current standards should be checked before a conformity decision. Roja helps manufacturers prepare for the Cyber Resilience Act. We do not certify products or provide legal advice.