Find the actively exploited flaws in your dependencies
On 11 September the 24 hour clock starts when you know. Here is how to spot an actively exploited dependency in your own project.
Open any security newsletter this week and you will find a product described as exploited in the wild. Most of the time it is enterprise software that you do not ship, so you scroll past. The phrase that matters is "exploited in the wild". Tomorrow, evidence of that kind about your own product starts a 24 hour clock. The bar for that evidence is set by the regulation, and it is narrow.
The clock starts on knowledge
Article 14 of the Cyber Resilience Act applies from 11 September 2026. If you are a manufacturer and you learn that a vulnerability in your product is actively exploited, you send an early warning within 24 hours and a full notification within 72 hours. Recipients are the CSIRT designated as coordinator in your member state, and ENISA. The ENISA single reporting platform becomes operational the same day (Article 16).
The countdown starts when you become aware. Not when an authority writes to you.
Article 3(42) sets the bar for "actively exploited": reliable evidence that a malicious actor has exploited the vulnerability in a system without the owner's authorisation. That is a narrower thing than a CVE. Most of your open vulnerability tickets will never meet it.
You need two lists
The first list is what is inside your product. Annex I, Part II, point 1 asks for a software bill of materials covering at least the top-level dependencies. That requirement lands on 11 December 2027, so nobody is late. Building the SBOM now is mostly tooling work on a file you already have, and it is the input for everything below.
The second list is what is known to be exploited. The CISA KEV catalogue, roughly 1 700 entries, is the closest public approximation.
Cross the two lists. That is the method.
A made-up case
I invented the publisher below to show the method end to end.
Take a small publisher who sells a self-hosted log viewer. One Docker image, a binary for macOS, forty paying customers. The lock file has around six hundred packages, most of them transitive.
Run the lock file through an SBOM generator, send the package identifiers to OSV.dev, then mark every result that appears in KEV. Typical outcome on a project that age: a dozen known vulnerabilities, two of them in KEV, both in transitive dependencies nobody chose on purpose.
Now the real work starts, and it is not automated. For each KEV hit, answer three questions. Is the installed version in the affected range? Does your code reach that function at all? Can an input from a user get there? A vulnerable XML parser that only ever reads a config file you wrote yourself is a different situation from one that parses uploads.
That triage is what turns a scanner output into a decision you can defend.
What the catalogue does not say
KEV tells you a vulnerability has been exploited somewhere. It does not tell you your product was attacked, and it does not tell you your build is reachable. Read Article 3(42) against the facts you actually hold, and write down the reasoning with a date. If you conclude the duty is not triggered, that note is your record.
If you are unsure, Article 15 exists. It provides for voluntary notification.
Four things to have before Friday
A security contact that someone reads, published in a security.txt file. Annex I, Part II, points 5 and 6 ask for a coordinated vulnerability disclosure policy and a contact address.
An SBOM regenerated at each release, stored with the release.
A one page procedure naming who decides, who sends the notification, and where the templates sit. Include the final report: 14 days after a corrective or mitigating measure is made available.
A short note on informing users. Article 14(8) says that after you learn of an actively exploited vulnerability or a severe incident, you inform affected users without undue delay, and where relevant about the mitigation they can apply. In a structured, machine readable format where possible. The regulation does not give you a template for that message.
Fines under Article 64 apply from 11 December 2027. The duty under Article 14 starts on 11 September 2026, without a penalty attached before that date.
First check if this is even about you
All of the above assumes you are a manufacturer under Article 3(13). A browser-only service is outside the scope (recital 12). Open-source work outside commercial activity is outside too (recital 18). Selling a plugin under your own name puts you inside, company or not.
The scope test runs through eight questions and gives you the article references for your case: https://crakit.eu/scope/
Not legal advice.
This is not legal advice.