11 September: The 24-Hour Clock Starts. Here's What Actually Changes.

Starting 11 September 2026, the Cyber Resilience Act's vulnerability-reporting obligation is active for manufacturers of products with digital elements that fall within its scope. Scope depends on the product, role and placing on the EU market; having a European customer alone is not a complete legal test. Products placed on the market before the broader 2027 application date can still be relevant to these reporting duties.

I'm not going to re-explain the whole CRA here (an earlier post covers that ground). This one is about what actually changes on 11 September, and what needs to already exist before it does, because none of it can be built while an incident is running.

The clock starts at awareness, not disclosure

The obligation is a cascade: an early warning within 24 hours of awareness, a vulnerability notification within 72 hours of awareness, and a final report no later than 14 days after a corrective or mitigating measure becomes available. Reports go through the ENISA Single Reporting Platform and are made available simultaneously to the coordinating CSIRT and ENISA.

That word, aware, is doing more work than it looks like. If a CISA KEV (Known Exploited Vulnerabilities) entry lands naming a library you ship, and nobody on your team sees it for six days because nobody's watching that feed, your 24 hours didn't start on day one. They started on day six, when someone actually noticed. The rule doesn't punish you for a six-day gap you didn't know about. It punishes you for the 24 hours after you did.

Which means the real risk isn't the deadline itself. It's discovering you're affected late enough that the deadline becomes a scramble.

A worked example

Say a KEV entry goes public on a Tuesday morning naming a compression library. You ship that library, vendored, inside a product from 2023.

Tue 09:00  KEV entry published
Tue 09:00–?  Nobody on your team is watching this feed
Tue 09:00–?  Or: someone IS watching, checks it against your SBOM,
             confirms the affected version is in what you shipped
Tue 09:00 + 24h   Early warning due to ENISA and the national CSIRT
                  (Computer Security Incident Response Team)
Tue 09:00 + 72h   Fuller notification due
[+14 days from a fix becoming available]   Final report due

The only variable in that timeline you actually control is the gap between "published" and "confirmed affected." Everything after that is fixed by regulation. So that gap is the only place readiness work can go.

Three things that need to exist before, not during

An SBOM (Software Bill of Materials) you can check quickly. Not eventually, not after someone spends an afternoon grepping through vendored directories. When a KEV entry names a library, you need to answer "do we ship this, and which version" in minutes, not days. That answer only comes quickly if you already have an accurate inventory, built before the question got asked.

A decided reporting path. Decide who declares awareness, who owns the submission through the ENISA platform, which coordinating CSIRT is appropriate, and how internal escalation works outside business hours.

A way to check exposure without waiting on a vendor. A rough version, if you don't have automated feed matching yet, is checking a KEV export against your SBOM by hand:

$ curl -s https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json \
  | jq -r '.vulnerabilities[].cveID' > kev-ids.txt

$ jq -r '.components[].cpe // empty' sbom.json | grep -oP 'cpe:2\.3:a:[^:]+:\K[^:]+' \
  | sort -u > shipped-libs.txt

That's not a real detection pipeline, and I wouldn't pretend it is. It's the manual version of the question you need an answer to, and doing it once, today, tells you a lot about how long the automated version would take to build.

What bomwerk does and doesn't do here yet

To be direct about where things stand: the matching-and-alerting side is further along than a line on a roadmap, but it's still not something you can run. Internally, a finding-state store now tracks when each finding was first and last seen per release, computes the 24-hour, 72-hour, and 14-day deadlines from that original first-seen time, enriches findings against the CISA KEV list, and can generate a deterministic draft of the ENISA Article 14 report. None of that is public. It lives on our development branch, it has its own test suite, and it won't reach a public release until a licensing boundary between the open-source core and the paid pieces is finished, a real blocker we're working through, not a formality. Right now the only part you can actually run is the open-source CLI, built from source: bomwerk scan and the build-evidence commands around it, the accurate SBOM part every other step in this post depends on.

That's not a reason to wait on the SBOM. It's the opposite. The inventory is the one piece of readiness that has to exist before any of the rest of this works, automated or manual, ours or anyone else's.

Nothing about 11 September is dramatic on its own. It's a deadline that was always coming, and now it's here. What matters is whether the three things above already exist, or whether they're about to get built under pressure, during the first incident that actually needs them.