95 Days to CRA Article 14: Your EOL Open Source Is Now a Compliance Liability

CRA Article 14 enters enforcement on September 11, 2026. From that date, if your organization places software products on the EU market and you become aware of an actively exploited vulnerability in those products, you have 24 hours to file an early warning notification with your designated national CSIRT and ENISA, 72 hours for a full vulnerability notification, and 14 days from the availability of a corrective measure for a final report.

This is the first manufacturer-facing deadline in the CRA. It applies to products already on the market, not just new releases. Full product conformity requirements — SBOM documentation, security-by-design, vulnerability management processes — apply from December 11, 2027. But the reporting obligation is live in 95 days, and you cannot meet the 24-hour reporting window without the infrastructure — SBOM, CVE monitoring, escalation process — that takes months to build.

Note the framing of this checklist: defensible posture, not perfect compliance. Full compliance for organizations with significant EOL open source portfolios typically involves migrations that take months to years. The goal for the next 95 days is to demonstrate that you have a documented process, documented coverage for your known gaps, and a clear plan for components that are not yet covered. That is what CRA enforcement actually looks at first.

‍

Why EOL open source is the specific problem

To comply with the 24-hour Article 14 reporting window, you need three things to work simultaneously: the ability to detect that a vulnerability is being actively exploited in your product, an organizational escalation process to triage and notify, and a remediation path to document.

EOL open source breaks the third piece structurally. When a component reaches end of life, its maintainers stop issuing patches. If a vulnerability in an EOL component is actively exploited and you become aware of it after September 11, you have a reporting obligation with no upstream remediation path. You must report the vulnerability, document your response, and explain what corrective measure you are taking — but the upstream project is not producing one.

"We are waiting for an upstream fix" is not a compliant response when the upstream project stopped issuing fixes when it hit EOL. The obligation for remediation sits with the manufacturer.

‍

Step 1: Run a complete dependency inventory now

Standard SCA tools scan package manifests. They identify declared dependencies and their versions. What they do not catch is the long tail of undeclared components — directly vendored code, AI-generated code incorporated without license review, copy-pasted library code, and development-time dependencies that made it into production artifacts.

EOLDS from HeroDevs is a free dependency scanner that goes beyond manifest-based scanning to identify EOL components across the full dependency graph. Run EOLDS against your production codebase and document the output. You need to know what you have before you can document whether you have coverage for it.

The EOL components most likely to appear in Q2/Q3 2026 codebases:

• Node.js v20: EOL since April 30. Already accumulating unpatched CVEs.
• Angular v19: EOL since May 19. No upstream patches from that date.
• AngularJS: EOL since January 2022. Four-plus years of accumulated unpatched vulnerabilities.
• Spring Boot 3.5 and Spring Framework 6.2: EOL June 30. EOL before September 11.
• Django 4.2: EOL since April 2024. Frequently appears in Python applications alongside newer dependencies.

‍

Step 2: Document the coverage status for each EOL component

For each EOL component in your inventory, you need a documented status in one of three categories:

Covered by NES: You have an active NES contract for this component providing continued CVE monitoring and security patches. Document the contract and coverage scope. This is your remediation path for Article 14 reporting purposes.

Migration in progress with a documented timeline: You do not have NES coverage, but you have a documented migration plan with a specific completion date. The plan should be specific enough that a regulator can assess whether it is realistic — a project board with assigned engineers and a target date, not a narrative description of intent.

Uncovered gap: You have identified a component for which you have no coverage and no active migration plan. For each uncovered gap, document the risk treatment — who accepted the risk, on what basis, and what compensating controls exist if any.

The third category creates the most Article 14 exposure. An undocumented gap is worse than a documented one, because it signals the organization does not have the visibility process the CRA requires.

‍

Step 3: Verify your SBOM is current and includes EOL status tagging

As the CRA's practical implications make clear, you cannot meet the 24-hour Article 14 reporting window without a current, accurate SBOM. You need to know what is in your product before you can determine whether a given CVE affects it.

Your SBOM needs to be current as of the September 11 enforcement date, and it should include EOL status indicators for components that have passed their upstream EOL date. Most modern SBOM tooling supports custom fields or extension properties for EOL status. An SBOM that is several months old or does not distinguish between maintained and EOL components does not give you the visibility the 24-hour reporting window requires.

‍

Step 4: Confirm your vulnerability disclosure process covers EOL components

For maintained open source, the vulnerability disclosure process runs through the upstream project. For EOL components, it does not. The project does not issue advisories for EOL versions. CVEs will be documented as affecting an EOL version with no upstream remediation available.

Article 14 requires a continuous vulnerability disclosure process. For EOL components, your organization must be the source of that process. That means having a monitoring mechanism that identifies new CVEs affecting your EOL components — CVE database monitoring, NES security advisories, or equivalent — and a response process for assessing and addressing what is found.

If you have NES coverage for an EOL component, the vulnerability disclosure process is provided by HeroDevs as part of the NES service: CVE monitoring, security advisory issuance, and security patch backporting. If you do not have NES coverage, you need to document your own equivalent process.

‍

Step 5: Get any remaining NES coverage contracts in place before September 11

If there are EOL components in your inventory that are uncovered and for which you want NES coverage before Article 14 enforcement — particularly Node.js v20, Angular v19, Spring Boot 3.5, or AngularJS — 95 days is a workable but not unlimited window. Enterprise procurement cycles typically run 30 to 60 days. Starting that process now is the practical move.

‍

The numbers that explain why this matters

65% of organizations experienced a software supply chain attack in the year preceding the 2026 OSSRA report. The open door for the majority of those attacks was exactly the category of vulnerability that EOL open source creates: known, documented, exploitable vulnerabilities in components that no longer receive patches from their maintainers.

Article 14 is the regulatory framework that makes that exposure an organizational liability with a 24-hour reporting clock. The documentation work of the next 95 days is not bureaucratic overhead — it is the difference between a defensible compliance posture and a documented absence of required process on the first day of enforcement.

‍

FAQ

When does CRA Article 14 enforcement begin? CRA Article 14 reporting obligations begin September 11, 2026. From that date, manufacturers of products with digital elements placed on the EU market must report actively exploited vulnerabilities within 24 hours and severe incidents within 72 hours. Full CRA product conformity requirements apply from December 11, 2027.

Does Article 14 apply to products already on the market? Yes. The reporting obligations apply to all products with digital elements already on the EU market, not just new releases. If a product you shipped in 2023 contains a component with an actively exploited vulnerability after September 11, the 24-hour clock starts.

What is the minimum documentation required for Article 14 readiness regarding EOL open source? At minimum: a current SBOM identifying all open source components including EOL components, documented coverage status for each EOL component (NES contract or migration timeline), and a documented vulnerability monitoring and disclosure process that covers EOL components. Undocumented gaps — EOL components with no coverage and no migration plan — are the highest-risk compliance exposure.

What is EOLDS and how does it help with CRA preparation? EOLDS is a free dependency scanner from HeroDevs that identifies EOL components across the full dependency graph, including components not visible to manifest-based SCA tools. Running EOLDS gives organizations a complete inventory of EOL components, which is the foundation for all subsequent CRA compliance documentation.

Does NES satisfy the Article 14 vulnerability disclosure requirement for EOL components? Yes. NES for covered EOL components includes CVE monitoring, security advisory issuance, and security patch backporting — providing the vulnerability disclosure and remediation process that Article 14 requires and that EOL upstream projects no longer provide.

What does CRA enforcement look like practically? Enforcement is handled by national market surveillance authorities in EU member states. Initial enforcement typically focuses on whether organizations have the required processes in place — SBOM documentation, vulnerability monitoring, and coverage for known gaps — rather than immediately penalizing individual vulnerabilities. A documented, defensible compliance posture is the practical goal for September 11.