The EU's 24-hour vulnerability reporting clock started 3 days ago. Here's a free tool to check if it applies to you.

On 11 September 2026, the first enforceable deadline under the EU Cyber Resilience Act arrived. Almost nobody I've spoken to noticed, because the headline date everyone has in their calendar is December 2027.

That's the date most of the CRA applies. But Article 14 — the reporting obligation — has been live since the 11th.

Here's the short version:

If a vulnerability in a product you've placed on the EU market is being actively exploited, you owe an early warning to your coordinating national CSIRT and ENISA within 24 hours of becoming aware of it. Then a fuller notification within 72 hours. Then a final report within 14 days of a fix being available.

Penalties top out at €15 million or 2.5% of worldwide annual turnover (Article 64(2)).

One relief that's worth knowing and often gets left out: under Article 64(10)(a), those administrative fines do not apply to microenterprises and small enterprises for missing the 24-hour early-warning deadline specifically. That relief covers the deadline only — not the duty to report, and not the 72-hour or final-report stages. If you're a small team, the headline fine number you keep seeing quoted is probably not the one that applies to you.

And the part that catches people: under Article 69(3), this covers products already on the EU market. Not just things you ship after the deadline. That thing you shipped in 2022 that's still being sold? In scope.

"Products with digital elements" is broader than you think

It's software, hardware, remote data-processing solutions, and components placed on the market separately. If you're outside the EU but sell into it through an importer, distributor, or authorised representative, the obligation can still reach you. Being in Ohio doesn't exempt you.

The word that matters is "exploited"

This is where I think most teams are going to get it wrong, in both directions.

Article 14 is not triggered by:

• a critical CVE in your dependency tree
• a CVSS 9.8
• a proof-of-concept on GitHub
• your scanner going red

It's triggered by evidence that the vulnerability is actually being exploited in the real world, in your product. That's a much smaller set. Most CVEs never meet it.

The Commission's July 2026 guidance also clarified something useful about third-party components: if an actively exploited vulnerability comes from a component you integrated, a report is required when that vulnerability is being actively exploited in your product. If the vulnerable code isn't reachable in your build, an Article 14 report isn't required on that basis.

So the question isn't "do I have CVEs." Everyone has CVEs. The question is: is any of what I ship on the list of things being exploited right now?

A free tool for exactly that question

I built cra-watch to answer it. MIT licensed, Python standard library only, no account, no telemetry, no signup.

curl -fsSL https://raw.githubusercontent.com/ntoledo319/cra-watch/main/cra_watch.py -o cra-watch
chmod +x cra-watch
./cra-watch scan

It reads your lockfiles, resolves them against OSV.dev, and intersects the result with the CISA Known Exploited Vulnerabilities catalogue — the closest thing to a public register of what's genuinely being exploited in the wild.

Clean run:

  Advisories  13 component(s) carry at least one known advisory
  KEV feed    1709 entries, catalogue 2026.09.11

  NO KEV MATCHES.

  Nothing in your dependency graph appears on the CISA Known Exploited
  Vulnerabilities catalogue. On this evidence there is no Article 14
  24-hour reporting trigger from a listed component today.

  You do still have advisories on 13 component(s).
  Those are ordinary patching work, not a reporting clock. Article 14
  is about ACTIVE EXPLOITATION, not severity.

Note what it does there: 13 components have advisories, and it explicitly tells you those are not a reporting trigger. That distinction is the whole point. Your scanner's wall of red is patching work. This is a different question.

The other answer:

  2 KEV MATCH(ES) - MANUAL DECISION REQUIRED NOW

  CVE-2021-44228  (GHSA-jfh8-c2jp-5v3q)
    component      org.apache.logging.log4j:log4j-core 2.14.1  [Maven]
    known as       Apache Log4j2 Remote Code Execution Vulnerability
    KEV listed     2021-12-10   ransomware use: Known

  If you confirm exploitation in your product, the clock is:

    Early warning     within 24h    2026-09-15 08:40:10 UTC
    Notification      within 72h    2026-09-17 08:40:10 UTC
    Final report      within 14d    2026-09-28 08:40:10 UTC

Supports 12 lockfile formats (npm, yarn, pnpm, pip, poetry, Pipfile, go.sum, Cargo, Gemfile, composer, NuGet, gradle) plus CycloneDX and SPDX SBOMs.

Exit codes are CI-friendly: 0 clean, 1 KEV match, 2 nothing scannable.

Run it on a schedule, not on push

This is the bit I'd emphasise. The KEV catalogue gains entries continuously. A repo that was clean yesterday can become a reporting question today without a single line of your code changing.

name: cra-watch
on:
  schedule: [{ cron: "0 6 * * *" }]
jobs:
  kev:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: curl -fsSL https://raw.githubusercontent.com/ntoledo319/cra-watch/main/cra_watch.py -o cra-watch.py
      - run: python3 cra-watch.py scan

A one-off audit answers a question about yesterday.

What the tool deliberately does not do

I want to be straight about the limits, because compliance tooling that overclaims is worse than no tooling.

A KEV listing is not proof of exploitation in your product. KEV says a vulnerability is being exploited somewhere in the world. Article 14 asks whether it's being exploited in the thing you shipped. If the vulnerable code path is unreachable in your build, the answer may genuinely be no. The tool can't assess reachability. A person has to.

KEV is not the legal definition of "actively exploited." It's a US government catalogue. It lags, and it isn't exhaustive. Your own telemetry or a customer's incident report can start the clock before CISA lists anything.

Clean output is not a compliance certificate. It means two public data sources don't currently intersect for your dependency graph. That's useful and reproducible. It isn't immunity.

It only sees declared dependencies. No vendored code, no static linking, no container base images, no your-own-source analysis.

Whatever the output, the thing to actually do is write down what you knew, when you knew it, and why you decided as you did. That contemporaneous record is what defends the decision later — far more than any scanner output.

The harder half

Finding the shortlist is the easy part, and it's the part software can do.

The hard part is the decision under a 24-hour clock: who's accountable for pressing send, what an early warning says when you still know almost nothing (answer: very little — it's designed to be thin, and you file it anyway), and what evidence defends a decision not to report when someone asks eight months later.

I also put together a CRA 24-Hour Reporting Kit covering that process side — decision tree, the three clocks worked in UTC, fill-in templates for all three filings, an evidence log, and a 30-minute tabletop exercise. That one's paid ($149), and it's the only thing I'm selling here. The scanner is free and always will be; it's not crippled, time-limited, or a trial.

If you only take one thing from this post, take the scanner and the cron job. The deadline is real, it's already passed, and most teams haven't checked.

---

I'm not a lawyer and none of this is legal advice. Verify against Regulation (EU) 2024/2847 and guidance from your coordinating national CSIRT before filing anything. If I've got something wrong, tell me in the comments — I'd rather fix it than be confidently wrong in public.