CRA reporting needs a product incident desk

The Cyber Resilience Act is starting to look less like a product-law file and more like a support desk that has not been built yet.

ENISA published its SME CRA Survey Report on 24 June 2026, after surveying smaller organisations in February and March. The timing matters: the first CRA reporting duties for actively exploited vulnerabilities and severe product-security incidents start on 11 September 2026, which is close enough to expose weak internal ownership.

Reporting is the first operational test

The CRA is broad. It covers products with digital elements and puts security requirements into the product lifecycle. For many SMEs, the first visible stress test will not be a full conformity assessment. It will be a short clock after someone reports that a product is being exploited.

ENISA’s Single Reporting Platform page describes the practical rhythm: an early warning without undue delay and within 24 hours, a fuller vulnerability or incident notification within 72 hours, then a final report on a later schedule. Those deadlines do not ask whether the company has a legal memo. They ask whether the company can find the right product owner at 16:30 on a Friday.

That is why a small product incident desk is the right first artefact. Not a new department. Not a platform procurement. A named routine that connects support, engineering, security, legal and management before the first real report arrives.

The desk is mostly a routing file

For an SME manufacturer or software product company, the useful first version is deliberately plain:

Desk item	Minimum version
Owner	One accountable product-security lead and one backup
Intake	One monitored email address or ticket queue for vulnerability reports
Product list	Products with digital elements, versions, support periods and responsible teams
Triage rule	Criteria for active exploitation, severe incident and ordinary vulnerability
Evidence pack	Logs, affected versions, customer impact, mitigation and disclosure status
Notification template	Draft fields for the 24-hour warning and 72-hour notification

Source: ENISA Single Reporting Platform FAQ and Regulation (EU) 2024/2847. Last verified 2026-07-01.

This is not glamorous work. It is the minimum line between “we heard about a vulnerability” and “we know whether it is reportable, who decides, and what evidence is missing.”

SMEs should not wait for the portal

ENISA says the Single Reporting Platform is scheduled to be operational by 11 September 2026, with testing before launch. That can tempt smaller firms to wait for the interface before designing the workflow.

The better order is the reverse. The portal is only the submission channel. The hard parts sit inside the company: recognising that a support message may describe exploitation, linking it to a product and version, deciding whether severity is high enough, and preserving evidence while someone prepares a notification.

The Commission’s CRA pages frame the regulation as a way to make digital products more secure through the lifecycle. That lifecycle language matters. Reporting is not a one-off compliance ceremony. It is an extension of product maintenance.

Procurement will notice the missing owner

Even SMEs that do not manufacture complex hardware may feel the rule through procurement. Larger customers will ask whether suppliers can handle product-security reporting, name support periods and explain vulnerability handling. A vague answer will look risky before the formal deadline bites.

The practical supplier question is simple: if a vulnerability is reported tomorrow, who opens the file?

If the answer is “the CTO probably”, the company has a person, not a process. If the answer includes a queue, a product register, severity criteria and a backup owner, the firm has the beginning of a CRA-ready desk.

The July job

The next useful month is not for buying software. It is for running one tabletop test on a real product.

Pick one connected product or software package. Invent a plausible exploited vulnerability. Start the clock. Can the company identify affected versions, decide whether the case is severe, draft the first notification fields and name the customer action before the 24-hour marker?

If not, the gap is not abstract compliance. It is routing. Fixing that in July is cheaper than discovering it in September, when the official platform is live and the first report is no longer a rehearsal.