The EU Cyber Resilience Act's reporting clock starts September 11, 2026
See what end-of-life open source is putting you at risk, then keep it patched and compliant before the clock starts.
Applies to any company placing products on the EU market — wherever you're headquartered.
Reporting obligations begin in
00
DAYS
00
HOURS
00
MIN
00
SEC
Deadline - September 11, 2026
Before September 11, know what you're standing on.
Sixteen questions across four areas, each tied to the statutory text behind it. See your score, your gaps by section, and what to fix first. No sign-up required to see your results.
16 Questions
4 Sections
~4 minutes
Your CRA Readiness Report
Based on Regulation (EU) 2024/2847. This tool provides general guidance, not legal advice, and is not a compliance certification.
This checklist tells you about your process. Now see what's actually in your code.
The questions above are about whether you have a process: a policy, a contact point, a support-period commitment. They can't tell you whether the open-source components inside your product are already end-of-life today. That's a different, more concrete question, and it's the one that most often turns into a reportable vulnerability under Article 14.
The Cyber Resilience Act's reporting clock starts, and it runs in hours, not quarters.
Manufacturers of "products with digital elements" must report actively exploited vulnerabilities and severe incidents through the new CRA Single Reporting Platform. Once a manufacturer becomes aware that a product has anactively exploited vulnerability(or experiences asevere security incident), a three-stage clock starts:
Early Warning
Within
24 hrs
Initial notification to your national CSIRT via the ENISA Single Reporting Platform (simultaneously visible to ENISA)
Full Notification
Within
72 hrs
A complete notification with the details known so far and any corrective measures taken.
Final Report - Exploited Vuln
Within
14 days
A final report within 14 days of a corrective fix being available.
Final Report - Incident
Within
1 month
A final report within one month for a severe security incident.
This is not just for new products.
The reporting duty applies to products already on the EU market — legacy software included. "We'll deal with it before our next release" doesn't apply. You can't wait this one out.
Reporting comes first, the rest follows.
The full essential requirements (secure-by-design, SBOMs, CE marking) apply later, from December 11, 2027. Reporting is the near-term forcing function landing in September 2026.
Penalties, stated plainly.
Non-compliance with core obligations can carry fines up to €15M or 2.5% of global annual turnover, whichever is higher.
Quick Reference
Reporting deadline
September 11, 2026
Applies to legacy products?
Yes
EU companies only?
No
Max penalty
€15M / 2.5% turnover
Full essential requirements
December 11, 2027
You don't have to be based in Europe to be in scope.
Scope is triggered by market presence, not headquarters location. "This is only for EU companies" is the single most common, and potentially the most costly, misread of the CRA. This applies to you if any of the following is true:
You're a software vendor or ISV selling into the EU
Even indirectly, even through a channel partner — you're a "manufacturer" under the Act whether you think of yourself that way or not.
You have EU customers, a subsidiary, or a single SKU sold in the EU
One product placed on the EU market is enough. Your headquarters location doesn't change that.
You're a security or compliance leader already fielding SBOM and audit requests
Now with a hard external reporting clock added on top of the frameworks you already answer to.
You know there's unsupported open source in the stack — but can't fully account for it
You know there's unsupported open source in the stack — but can't fully account for it
The deadline isn't the hard part.
Knowing what you'd have to report onis.
You can't hit a 24-hour reporting window on a vulnerability in a component you didn't know was there, but your auditors will expect you to. End-of-life, unsupported open source is exactly the stuff that goes under the radar until it is too late. Once a framework stops getting official updates, nobody's watching it, except for HeroDevs.
EOL isn't a CVE
It's the absence of anyone patching new ones. Your CVE scanner isn't built to flag "nobody is fixing new vulnerabilities in this component going forward". No CVE's showing up in scans on EOL software does not mean they are not there, it means your scanner doesn't have the full picture.
It hides in transitive deps
The EOL components most likely to bite you are the ones you didn't choose directly, the dependencies of your dependencies.
Nothing defensible to report
Even if you spot the issue in time, there's no fix coming from upstream,so there's nothing you can point to as a good-faith response and you are out of time to embark on a last minute update or migration.
HOW TO GET READY BEFORE SEPTEMBER
Two steps: see what you're standing on, then keep it defensible.
HeroDevs closes both gaps — the visibility problem and the remediation problem — so you can report in good faith on your own timeline, not the framework's.
Step 1 · Visibility
EOL Dataset tells you which of your open-source components are already end-of-life and unsupported — the risk your CVE scanner isn't built to see. It works alongside your existing SCA tooling, not against it: they show you known CVEs; EOL DS shows you what's gone dark.
Finds abandoned, EOL, and soon-to-be-EOL dependencies — including the transitive ones most inventories miss.
Four clear status states, so you know what's already out of support versus what's coming up.
A defensible inventory you can hand to compliance — the thing you can't report without.
Backed by lifecycle data on 19M+ open-source packages, so the answer for a given component is already there rather than something your team has to research.
Step 2 · Remediation
Never-Ending Support (NES)
Once you know what's EOL, NES keeps it patched, including new CVEs discovered after a framework's official end of life, so you always have something defensible to report. Secure drop-in replacements, on your timeline, immediate resolution, no compromise, no disruptions.
Original framework maintainers on staff — AngularJS, Spring, Vue, Bootstrap and more.
CNA status — HeroDevs can discover and patch CVEs proactively, not just react to public disclosures.
All-severity patching, drop-in install — no breaking changes to your application, immediate remediation.
Letters of attestation — the artifact a compliance officer can hand an auditor.
Questions teams ask us first
Get answers to some of our most commonly asked questions.
Of course, if you can't find the answer you're looking for, feel free to contact us.
Exactly which provisions NES closes, strengthens, and doesn't touch.
Read this as a scoping tool, not a compliance claim. An unmaintained end-of-life component is a hard failure against several provisions, and commercial support converts those to a pass. Others it only strengthens, and some it does nothing for at all.
NES directly closes the gap
An EOL component is a hard failure here. NES converts it to a pass, because a vendor is shipping patches again.
Address and remediate vulnerabilities without delay, including by providing security updates.
The strongest fit — this is literally what NES does.
Handle vulnerabilities per Annex I Part II across the declared support period, minimum five years.
The anchor provision. NES is what lets you declare a 5+ year support period on a stack containing EOL components.
Product placed on the market without known exploitable vulnerabilities.
An EOL dependency with an unpatched CVE is a known exploitable vulnerability at the moment of placing. NES ships the backported fix.
Vulnerabilities can be addressed through security updates.
If upstream is dead there is no update path at all. NES restores one through npm, Maven, or PyPI.
Security updates disseminated without delay and free of charge, with advisory messages.
No maintainer means no dissemination. NES provides both the artifact and the advisory.
Public disclosure of fixed vulnerabilities once an update is available.
HeroDevs advisories and vulnerability directory entries supply this for the component.
Each security update stays available for at least 10 years, or the remainder of the support period.
You can't retain updates that were never issued. NES generates the artifacts; retention stays yours.
NES strengthens the position, you still own the obligation
Due diligence on third-party components
Procuring commercial support for an EOL dependency is a documentable due-diligence act — the best defensible artifact you have.
Notify the component maintainer
With a dead upstream there is no counterparty. NES gives you one.
24-hour, 72-hour, and 14-day reporting
NES doesn't remove the duty. It gives you a corrective measure to reference, which makes the final report achievable rather than an open-ended admission.
Software bill of materials
NES doesn't produce your SBOM — it changes what the SBOM shows.
Coordinated vulnerability disclosure
HeroDevs has a policy for the component; the product-level policy is still yours.
Support-period information for users
NES is what makes a declared support end date credible.
NES does nothing for these, and we won't pretend otherwise.
Product classification (Articles 6–8), substantial modification (Article 20), the EU declaration of conformity (Article 22), conformity assessment procedures (Article 24), CE marking (Article 30), and Article 13(1) as it applies to your own first-party code. If you're behind on conformity assessment, NES is not the answer to that part.
In one line: NES converts an Article 13(8) breach into an Article 13(8) pass, and turns an Article 14 report with no remediation into one with a corrective measure attached. Everything else it supports but doesn't discharge.
Before September 11, know what you're standing on.
Find the end-of-life open source you don't know about, and keep the rest patched and audit-ready — before the reporting clock starts.