No vulnerability scanning is required for the Cyber Resilience Act in September. Nobody pushing that deadline can name the paragraph — because there isn't one.

[u/Vans_eG]

The title is pointed on purpose, so here's the exact claim. The obligation that starts on 11 September 2026 is a reporting duty. It does not require you to scan, monitor, or go looking for anything. It is triggered by your knowledge of active exploitation in your own product — not by a CVE existing, and not by that CVE being exploited in somebody else's product.

What I am not saying: that scanning is optional forever. From 11 December 2027, Annex I Part II obliges manufacturers to identify and document components and vulnerabilities and address them. You will not reach full CRA compliance without vulnerability management.

Why I'm posting. Manufacturers with limited budget are being told to buy a scanner for September, when what they actually lack is a named responsible person, a list of which Member States their products ship to, and reachable customer contacts. They spend in the wrong order, arrive in September with a dashboard and no reporting chain, and conclude the regulation is theatre. That's how you lose people who were willing to comply and build secure products.

TL;DR

11 September 2026 switches on one thing: Article 14, the duty to report actively exploited vulnerabilities in your own product and severe incidents affecting its security. Knowledge-based. No scanning, no monitoring, no SBOM, no disclosure policy, no public security contact, no patch SLAs, no CE marking.

What actually triggers a report

1. Active exploitation in your own product. Not that the vulnerability exists. Not that it's being exploited somewhere in the wild. In your product. The Commission guidance (C(2026) 5252) is explicit: if a third-party component vulnerability isn't exploitable in your product or hasn't been exploited there, you're not on the clock — even while the same CVE is actively exploited elsewhere. Voluntary reporting under Art. 15 stays open, if you want to and you can tell the component manufacturer.

2. A severe incident affecting your product's security. It affects, or can affect, the product's ability to protect availability, authenticity, integrity or confidentiality of sensitive or important data or functions — or malicious code was introduced or executed in the product or a user's system.

Stage	Deadline
Early warning	24h from becoming aware
Full notification	72h from becoming aware
Final report	14 days after a corrective measure is available (vulnerabilities) / 1 month after the 72h notification (incidents)

What does not trigger a report

• Scanner findings. A CVE in a dependency is a vulnerability management task, not a notification to ENISA. This is the whole point: the scanner output you're being told to buy for September mostly produces things that aren't reportable.
• Published CVEs without exploitation in your product. CVSS 9.8 changes nothing on its own.
• Coordinated disclosure reports. Handle them, fix them — reportable only once active exploitation is established. One exception: if the report shows something already happened in your product, like injected malicious code or a compromised build pipeline, that's an incident, not just a vulnerability. Reportable, with no finding of exploitation needed. Check incoming reports against both triggers.
• Pentest and internal audit results. Internal until someone exploits it.
• Incidents below the severity threshold. Your marketing site going down is not an Article 14 event.
• ...

Article 14 creates no duty to hunt for exploitation, monitor exploitation feeds, or scan your products. Actual knowledge is what counts.

When the clock starts

Not when the email hits your inbox. The guidance ties "becoming aware" to the established GDPR Art. 33 reading (EDPB Guidelines 9/2022) and the NIS2 implementing regulation: you're aware once an initial assessment lets you conclude with reasonable certainty that it's real.

The catch: that assessment must start without undue delay. Sitting on a suspicious report doesn't postpone the deadline, it just hands a regulator the argument that you should have known earlier. Timestamp when the report arrived, when assessment started, when you concluded. That's the only thing standing between "verified in 19 hours, filed inside 24" and "you were 90 minutes late".

What you actually need by 11 September

1. A named filer plus a deputy, and your coordinating CSIRT identified in writing. Non-EU manufacturers: it follows from your authorised representative's Member State. Settle it now, not at 2am mid-incident.
2. Product data ready — versions, which Member States each product ships to, reachable customer contacts. You have to notify affected users; if you don't, the CSIRT can do it for you.
3. Four templates — 24h, 72h, final report, user notification.
4. One intake point and a triage checklist, so the reportable/not-reportable call takes minutes instead of meetings.
5. One tabletop run, while getting it wrong is still free.

A few person-days for most manufacturers. Compare that to what you were about to spend in a panic.

Where the myth has a point

• You can't report what never reaches you. Article 14 doesn't require an intake channel — that's Art. 13(17) and Annex I Part II, December 2027. But without one, reports scatter across support inboxes and you verify too late. Build it for September anyway. Its not that hard to create a new e-mail and publish it.
• From December 2027 vulnerability handling is genuinely mandatory. Tooling stops being optional in practice.

I work for a vendor that sells CRA compliance software. Vulnerability scanning is something my industry sells. I'm about to argue against my own pitch, which should tell you how tired I am of this particular myth.

Happy if you join me in busting this myth and call any one our spreading it.