From report to notification: when an external report becomes an SRP notification

A report arrives through the website form: a customer says your product has been hacked. Does the 24-hour notification obligation start, or not? The wrong answer costs in two directions: notifying everything clogs the CSIRTs and wears down the process, not notifying a real case exposes you to a deadline already active. The decision has to be made fast, and with a criterion, not on a hunch. This article is that criterion.

For the picture of the platform and the deadlines, the guide The CRA Single Reporting Platform; for who decides and with what authority, The Assigned Representative on the SRP.

The trigger is narrow, not generic

The starting point is that not every external report triggers Art. 14 of the CRA. The obligation targets two defined cases.

The actively exploited vulnerability (Art. 3(42)): a vulnerability for which there is reliable evidence that a malicious actor has exploited it in a system without the owner’s authorisation. The two words that carry weight are “actively” and “reliable evidence”. A responsible-disclosure report describing a flaw, without evidence of real exploitation, stays on the coordinated disclosure channel (Art. 13; the single point of contact of Art. 13(17)), outside the Art. 14 obligation.

The severe incident (Art. 3(44), with the severity criteria in Art. 14(5)): an incident that affects or is capable of affecting the product’s ability to protect availability, authenticity, integrity or confidentiality, or that has led to the introduction or execution of malicious code in the product or in the user’s network.

The pivot concept: “becomes aware”

The 24 hours run from the moment the manufacturer becomes aware of the exploitation or the incident (Art. 14(1) and (3)). Awareness means having reliable evidence and a basis to consider it credible, not the mere receipt of a message. The Commission guidance discusses when the manufacturer is regarded to have “become aware” (FAQ sec. 5.1 and guidance sec. 9.1, non-binding).

The delicate point: you cannot avoid awareness by leaving the channel unattended. If a diligent process would have seen the report, awareness can be imputed to that moment, not to when it was actually read. Triage therefore does not defer the clock, it serves to establish whether the reliable evidence exists, and it must be done without undue delay.

The real pivot: product defect or user configuration

This is where you decide whether you open. The obligation triggers if the exploitation originates in a vulnerability of the product: buggy firmware, default credentials, unauthenticated access, a service exposed by design. If instead the compromise arises only on the user side, such as a device exposed to the internet with a password they chose, it stays an incident on their system, not necessarily a severe incident that has an impact on the security of the product in the sense of Art. 14.

Triage must aim entirely at this distinction. And it is workable even without your own telemetry, as the case below shows.

Concrete case. Small B2C company, WiFi temperature sensors, no cloud and therefore no logs on the manufacturer side. A user reports that the sensor has been compromised and used to attack their home network. A WiFi sensor enlisted in a botnet is the textbook Mirai or Mozi scenario, plausible and almost always traceable to a product defect. Without telemetry the verification shifts to three sources reachable in 24 hours: the router logs and the user’s details, public threat intelligence on that firmware or chipset, direct analysis of a unit with that firmware. If the attack surface shows default credentials or an unauthenticated service, the defect is the product’s and the notification is to be opened.

How you verify in 24 hours without telemetry

Not having logs on the manufacturer side does not remove the obligation, it shifts the verification to three sources that remain available.

The user holds the evidence. Call them back straight away and ask for the concrete: router logs, IPs and times, what they observed, firmware version, whether they had changed the default password, whether the device was reachable from the internet. The bulk of the reliable evidence comes from here.

Public threat intelligence. Is there a known CVE for that firmware? Are there documented botnets on that model? Half an hour of work that weighs heavily on plausibility.

The product itself. Take a unit with that firmware and look at the attack surface: default credentials, open ports, unauthenticated services, update mechanism. If the defect is structural, it shows without the user’s logs.

When the evidence does not arrive in time

Three situations block the triage before the decision is even reached. They must be anticipated, because they are the norm, not the exception.

The reporter does not respond. The clock does not wait for them. The relevant awareness is having reliable evidence, and reliable evidence comes from three sources: if the reporter goes silent, you lose one, not all. The decision is made at the twenty-fourth hour on the best available evidence. If your independent analysis finds a real attack surface, you open even without their confirmation; if it finds nothing and the report stays vague, you document that the reliable evidence is missing and keep investigating. What does not hold before an authority is “we were waiting for the user”: it uses someone else’s unavailability to stop a clock that is yours.

The reporter is not technical. In B2C this is the rule. The remedy is in the intake, not in their competence: the single point of contact form (Art. 13(17)) asks for what a layperson can give, router make and model, screenshots, what they saw and when, firmware version if readable from the app. A channel that depends on the customer’s technical fluency is badly designed.

The AR does not have the competence to assess. The CRA asks that the manufacturer notify, not that whoever operates the platform also be the analyst. The assessment competence must exist and be reachable in time, even on a person different from the one who submits. For the small company with no security in-house, the answer is to pre-build it externally: a retainer with a consultant or a PSIRT callable for triage, decided in advance. The ENISA/CSIRT helpdesk for SMEs (FAQ Q19) supports the assessment, but it does not decide for you and does not stop the clock. The internal AR stays a trained dispatcher, who can run the checklist and knows when to escalate.

The common thread: within the 24 hours the coverage must reach both whoever assesses and whoever has the authority to open. The mechanism that makes it sustainable, the pre-delegation of the early warning, is in The Assigned Representative on the SRP. Whatever the outcome, the log of times (arrival of the report, alert, triage, evidence gathered, decision and rationale) is what demonstrates diligence when the reporter is silent or the call is borderline.

The decision, and what to do in case of doubt

Operational note (my indication, not legal text). Specific and credible report, a product class intrinsically exposed, nothing that disproves it within the 24 hours: open the early warning within the 24 hours. It is deliberately minimal and preliminary, with the initial assessment marked as uncertain. You are not declaring a confirmed vulnerability, you are meeting the early-warning obligation on a credible suspicion. In the 72 hours you go deeper, the final report carries the conclusion. Better an early warning you later refine than a deadline missed on a real case.

The case where you do not open exists, and it is when triage shows within the 24 hours that there is no product defect: a different device, a pure user misconfiguration, a non-credible report. That conclusion must be reached and documented, not obtained by inertia because “we did not have the logs”. Before an authority, the difference between the two postures is entirely here: a tracked decision against a silence.

For credible but not-yet-proven cases there is also the valve of voluntary reporting (Art. 15), which allows you to report without triggering the timelines of the obligation. Useful when you want to be proactive on a suspicion that does not yet meet the reliable-evidence threshold.

The two obligations that trigger together

If the verification confirms the defect, on the same awareness the obligation to inform users also triggers (Art. 14(8)): inform the affected users and indicate the mitigating measures, such as changing the password, updating, disconnecting the device. The notification on the platform is half the work, the other half is the communication to the installed base. If the manufacturer does not inform promptly, the CSIRT can do it in their place.

The precondition: an attended channel

All of this rests on one condition: the single point of contact (Art. 13(17)) must actively alert the AR and the backup, not be an inbox read on return. During a closure a minimum reachability is needed, even outsourced. For a B2C selling to users who report at any hour, reachability on the channel is part of the obligation, because it is what keeps awareness, and therefore the 24-hour clock, under the company’s control instead of a holiday calendar’s.

---

References: Regulation (EU) 2024/2847 (CRA), Art. 3 (points 42 and 44), Art. 13 (in particular par. 17), Art. 14 (par. 1, 3, 5, 8), Art. 15 and Annex I, Part II, point 5. Non-binding guidance: Commission FAQ on CRA implementation (sec. 5.1) and related guidance (sec. 9.1), ENISA pages on the SRP and FAQ (updated 3 August 2026). The notes flagged as operational and the concrete case are my interpretations, not regulatory text. Article numbers verified against the official text of the CRA.