The CRA 24-Hour Clock Starts September 11 and Your Dependency Graph Is the Liability

On September 11, 2026, the vulnerability reporting obligations of the EU Cyber Resilience Act become enforceable, and if your product with digital elements is on the EU market, you are now a manufacturer under the meaning of the regulation whether or not anyone on your team has ever read Article 14. The headline number everyone quotes is 24 hours, and that number is real, but it is worth understanding what triggers the clock, because it is not 24 hours from a CVE being published, it is 24 hours from the moment you become aware of an actively exploited vulnerability in your product, at which point you owe an early warning notification to both the relevant national CSIRT and ENISA through the single reporting platform. There is a second notification with more detail due within 72 hours, and a final report once a fix or mitigation is available. The part that catches teams off guard is that 'actively exploited' includes exploitation you observe in your own telemetry, so if your on-call engineer sees a payload in the logs that matches a known deserialization gadget in a library you shipped, the clock has started, and it does not care that it is Friday at 6pm. This reaches legacy products too. Anything you placed on the EU market that still receives support falls under scope, so the customer portal you built in 2021 and forgot about is a liability sitting on a shelf, quietly accumulating unpatched dependencies while the compliance date creeps closer.

Most of the teams we talk to are treating the CRA as something the legal or compliance function owns, and that is a category error that will bite them in exactly the wrong moment. A lawyer cannot tell you within 24 hours whether the version of libwebp you bundled through three layers of transitive dependencies is the one with the heap overflow, because that answer lives in your lockfile, your container images, and your build artifacts, not in a policy document. The obligation is legal, but every input to satisfying it is technical. You need to know, on demand, what is actually running in production, down to the transitive dependency and the exact version, mapped back to which customer-facing product ships it, and you need that answer fast enough to draft a notification before the deadline. If your first move after an exploit report is to grep through a Slack thread from 2023 asking whether anyone remembers which service uses that package, you have already lost. We have run enough security audits to know that the gap is almost never the fix itself, it is the time spent figuring out where the vulnerable code even lives, and the CRA turns that latency into a regulatory exposure with real fines attached, up to 15 million euro or 2.5 percent of global turnover for the serious breaches.

This is the section that should make you uncomfortable. AngularJS reached end of life at the end of 2021 and still shows up in enterprise admin panels everywhere. Vue 2 hit EOL at the end of 2023 and a genuinely large chunk of the SaaS world never migrated to Vue 3 because the composition API rewrite was painful and nobody had budget for a UI that 'worked fine'. Node.js 18 went out of support in 2025, and if your Dockerfile still says FROM node:18-alpine, you are running an interpreter that will never receive another security patch. Before the CRA, this was ordinary tech debt, the kind you note in a retro and defer forever. Now it is different, because when a vulnerability lands in an EOL package, there is no upstream fix coming, which means your only compliant response is to have already migrated off it or to be actively maintaining a fork you can patch yourself, and both of those are things you decide months in advance, not in the 24 hour window after exploitation. An EOL dependency in a shipped product is a liability that compounds, because every new CVE against it is one you cannot resolve by bumping a version number. The uncomfortable truth is that the migration you have been deferring became a compliance prerequisite while you were arguing about whether it was worth the effort.

You do not need a six figure GRC platform to get compliant, you need a governed artifact pipeline that produces a real inventory and a defined path from 'exploit reported' to 'notification drafted'. Start with SBOM generation on every build. If you are on a Go or Node stack, syft will generate a CycloneDX document in one step, and you wire it into CI so that no image gets pushed without an SBOM attached as an OCI artifact, which means for any production tag you can pull the exact component list without rebuilding anything. Layer in grype or Trivy scanning that fails the build on known-exploited CVEs, and critically, feed it the CISA KEV catalog so you get signal specifically on the vulnerabilities that are actually being exploited in the wild, since that is the exact trigger the CRA cares about. Store the SBOMs somewhere queryable. We push ours into a small Postgres table keyed on image digest and product, so that when a CVE drops the on-call engineer runs a single query and gets back every affected service and its owner in under a minute instead of an afternoon of archaeology. The last piece is a runbook that treats a KEV match as an incident with the 24 hour clock explicit at the top, with the CSIRT contact and the ENISA platform login already documented, because the worst time to discover you do not have credentials for the reporting portal is while the clock is running.

Six weeks is not enough time to do this properly, so do the version that matters. First, generate an SBOM for every product you have on the EU market, including the ones nobody has touched in two years, and diff those inventories against the CISA KEV catalog to find out today whether you are already shipping something exploited. That single exercise tends to surface at least one genuine surprise per team we have worked with. Second, identify every EOL dependency in that inventory and make an honest call on each one, migrate now, fork and self-maintain, or accept a documented risk with a plan, because 'we didn't know' stops being a defensible answer on September 11. Third, write the runbook and actually test it, run a tabletop where someone pastes a fake exploit report into the channel and you time how long it takes to produce a draft notification, and if that number is over a couple of hours, the gap is your tooling, not your people. We build this kind of governed pipeline into client delivery as a matter of course now, because retrofitting it under deadline pressure is miserable and doing it once, properly, means the 24 hour clock stops being a threat and becomes a query you already know how to run. The regulation is not going away and the date is fixed. The dependency graph you have been ignoring is the thing that decides whether you meet it.