CRA Reporting Obligations Start September 2026: What EOL Dependencies Mean for Your Compliance

The EU Cyber Resilience Act creates new legal exposure for any product containing end-of-life open-source software. The reporting deadline is six months away, and most teams aren't ready.

On March 3, 2026, the European Commission published its long-awaited draft guidance for the Cyber Resilience Act (CRA), the most ambitious piece of cybersecurity legislation the EU has ever enacted. The 70-page document, now open for stakeholder feedback through March 31, clarifies how the regulation applies to products containing open-source software, and the implications for organizations running end-of-life (EOL) frameworks are significant.

Here's the critical timeline: starting September 11, 2026, manufacturers must report actively exploited vulnerabilities in their products to ENISA and national CSIRTs within 24 hours of becoming aware of them. Full product conformity requirements follow on December 11, 2027. If your product ships with AngularJS, Vue 2, Spring Framework 5, Node.js 18, or any other EOL framework, the CRA just made that technical debt a legal liability.

What the CRA Actually Requires

The CRA (Regulation EU 2024/2847) entered into force on December 10, 2024 and applies to all "products with digital elements," meaning any software or hardware product and its remote data processing solutions, including components placed on the market separately. That scope is broad by design. If you sell software in the EU, the CRA almost certainly covers your product.

The regulation introduces mandatory cybersecurity requirements across the full product lifecycle, from design through maintenance. But the provision that should have every engineering leader's attention right now is Article 14: the vulnerability reporting obligation.

Article 14 Reporting: The September 2026 Deadline

Under Article 14, manufacturers must report any actively exploited vulnerability they become aware of. The reporting timeline is strict and staged:

• 24 hours: Submit an early warning notification to your designated CSIRT and ENISA via the Single Reporting Platform (SRP)
• 72 hours: Submit a detailed vulnerability notification with technical specifics
• 14 days after a patch is available: Submit a final report including root cause analysis, corrective measures, and preventive actions

This isn't optional. This isn't "best effort." This is a legal obligation with enforcement teeth.

And here's the part that catches most teams off guard: these reporting obligations apply retroactively to products already on the market. Article 69(3) of the CRA states that the Article 14 reporting requirements apply to all products with digital elements that have been placed on the market before December 11, 2027. It doesn't matter if your product shipped in 2019. If it's still in use and contains an actively exploited vulnerability, you must detect it and report it starting September 2026.

The Fines Are Real

Non-compliance with the CRA carries penalties of up to 15 million euros or 2.5% of global annual turnover, whichever is higher. For context, that penalty structure mirrors GDPR in scale, and we've seen how aggressively EU regulators enforce those fines.

Why EOL Open Source Is the Weak Link

Most products with digital elements contain open-source components. That's not a problem by itself. The problem emerges when those components reach end of life and stop receiving security updates from their original maintainers.

Consider the reporting obligation chain. To comply with Article 14, your organization needs to:

1. Know what's in your product. You need a complete, accurate Software Bill of Materials (SBOM) that includes every open-source dependency.
2. Monitor for exploited vulnerabilities. You need real-time visibility into which CVEs affect your components and whether they're being actively exploited.
3. Report within 24 hours. You need an internal process that can triage, validate, and escalate an exploited vulnerability to ENISA within a single day.
4. Deliver a patch. The final report requires documentation of corrective measures. That means you need the ability to actually fix the vulnerability.

Step four is where EOL dependencies break the entire chain. When AngularJS, Spring Framework 5.x, Vue 2, or Node.js 18 reached end of life, the upstream maintainers stopped issuing patches. A new CVE gets published, exploitation is confirmed, and your 24-hour clock starts ticking, but there's no patch coming from the community. You're on your own.

Under the CRA, "we're waiting for an upstream fix" is not an acceptable response. The obligation sits with the manufacturer, meaning the organization that places the product on the EU market. If your product contains an EOL component with an actively exploited vulnerability, you either patch it yourself or you face regulatory exposure.

The New "Open-Source Steward" Category

The CRA introduces a novel legal concept: the open-source software steward. This is the first time EU legislation has formally acknowledged the role that foundations, non-profits, and supporting organizations play in the open-source ecosystem.

Under Article 3(14), an open-source steward is defined as a legal person that systematically provides support on a sustained basis for the development of specific free and open-source software products intended for commercial activities, and that ensures the viability of those products.

Key distinctions worth noting:

• Stewards are not manufacturers. They face a lighter regulatory regime under Article 24, which focuses on cybersecurity policies, vulnerability handling cooperation, and reporting.
• Stewards cannot be fined. Article 64(10) explicitly exempts open-source software stewards from administrative fines for CRA infringements.
• Individuals cannot be stewards. The definition requires a legal person (a company, foundation, or association), not a natural person.
• Steward obligations scale with involvement. According to the draft guidance, stewards providing only non-technical support have minimal reporting requirements, while those contributing engineering resources face full reporting obligations for actively exploited vulnerabilities.

What does this mean for your EOL dependencies? When a framework reaches end of life, its original steward or maintainer organization typically stops providing the sustained support that the CRA contemplates. There is no entity ensuring the viability of that software. No one is handling vulnerability reports. No one is coordinating with CSIRTs.

The obligation doesn't vanish. It transfers entirely to the manufacturer: your organization.

The Draft Guidance: What Engineering Teams Need to Know

The March 3 draft guidance clarifies several points that are directly relevant to teams running EOL open source.

Commercial Activity Triggers CRA Obligations

The guidance makes clear that the CRA applies when software is distributed in the course of a commercial activity. Once open-source software is integrated into a commercial product or value-added service, the manufacturer inherits all obligations for vulnerability handling, updates, and documentation. Free open-source projects developed outside commercial activity are generally exempt, but the moment your company ships a product containing that code to the EU market, the obligations are yours.

Support Periods Must Be Defined and Defended

Manufacturers are required to set a "support period" for their products that reflects the expected lifecycle. The CRA states this must be at least five years, and potentially longer for products reasonably expected to remain in use beyond that window. During the support period, manufacturers must provide security updates and handle vulnerabilities.

If your product contains an EOL framework, you need to answer a difficult question: how will you provide security updates for a component whose maintainers have moved on? The CRA doesn't care about your upstream dependency's lifecycle. It cares about yours.

SBOMs Are a De Facto Prerequisite

While the SBOM requirement under Annex I technically isn't enforceable until December 2027, the September 2026 reporting deadline creates a practical dependency. As the CRA text itself states, manufacturers must identify and document vulnerabilities and components by drawing up a software bill of materials in a commonly used, machine-readable format.

You cannot report what you cannot see. If you don't have SBOM-based vulnerability monitoring in place before September 2026, you cannot comply with the 24-hour reporting window. Period.

What Your Team Should Do Now

The September 2026 reporting deadline is six months away. Here's a concrete action plan for engineering and security teams running products with EOL open-source dependencies.

1. Audit Your Open-Source Dependencies

Generate a complete SBOM for every product you ship into the EU market. Identify every component that has reached or will reach end of life before your product's support period ends. Pay special attention to frameworks deeply embedded in your application layer: AngularJS, Vue 2, Angular versions 4 through 17, Spring Framework 5.x, Spring Boot 2.x, Node.js 16 and 18, .NET 6 and 7, and legacy Java and Ruby runtimes.

2. Map Your CRA Exposure

For each EOL component, answer three questions:

• Is this component in a product placed on the EU market?
• Can your team patch a critical vulnerability in this component within 24 hours of discovery?
• Do you have a documented vulnerability handling process for this component?

If the answer to any of these is "no," you have a compliance gap.

3. Establish Vulnerability Reporting Infrastructure

Build the internal workflow that can meet the Article 14 timeline. This means defining triggers and escalation paths for actively exploited vulnerabilities, identifying your designated CSIRT, preparing report templates aligned with the ENISA Single Reporting Platform format, and designating multiple authorized reporters (because exploitation can be discovered on weekends, holidays, or at 3 AM).

4. Secure Your EOL Dependencies

This is the step where most organizations get stuck. You have three options for each EOL component:

• Migrate off the EOL framework. This is the "right" long-term answer, but large-scale migrations take 12 to 24 months and carry significant risk.
• Build internal patching capability. Technically possible, but requires deep expertise in the specific framework's internals, plus ongoing monitoring and response capacity.
• Engage a commercial support provider. This is where Never-Ending Support (NES) solutions come in: drop-in replacements that maintain security patching for EOL frameworks without requiring a migration.

5. Align Legal, Engineering, and Product Teams

CRA compliance is not purely an engineering problem. Product teams need to define and document support periods. Legal needs to assess exposure across your EU-facing product portfolio. Engineering needs to operationalize the vulnerability handling and reporting workflows. Start these cross-functional conversations now.

How HeroDevs NES Addresses CRA Compliance

HeroDevs provides Never-Ending Support (NES) for end-of-life open-source frameworks, and the CRA is exactly the kind of regulatory pressure that NES was designed to solve.

Here's how NES maps to CRA requirements:

Continuous vulnerability patching. NES products are secure, maintained forks of EOL frameworks. When a CVE is published against AngularJS, Vue 2, Spring 5, Node.js 18, or any other NES-supported framework, HeroDevs' security team triages, patches, and ships the fix. This directly addresses the Article 14 requirement that manufacturers be able to deliver corrective measures.

Drop-in compatibility. NES products are designed as drop-in replacements for their EOL counterparts. You swap the registry source (npm, Maven, NuGet, RubyGems, PyPI), update your dependency resolution, and your existing code continues to work. No rewrite. No migration risk. This means you can close your CRA compliance gap in days, not months.

SBOM and VEX documentation. HeroDevs generates SBOMs in CycloneDX and SPDX formats for NES products, along with Vulnerability Exploitability eXchange (VEX) documents that clarify the status of known vulnerabilities. This maps directly to the CRA's SBOM and transparency requirements.

Private registries. NES products are delivered through private registries that your CI/CD pipeline can consume directly. This gives your organization a controlled, auditable source for security-patched versions of EOL frameworks, supporting the documentation and traceability requirements of the CRA.

Defined support periods. Every NES product has a published support commitment, giving your product team a defensible answer to the CRA's support period requirement.

The CRA doesn't require you to migrate off EOL frameworks overnight. It requires you to demonstrate that vulnerabilities in those frameworks can be identified, reported, and patched within mandated timelines. NES provides exactly that capability.

The Competitive Reality

The September 2026 reporting deadline isn't a soft target. EU market surveillance authorities will have enforcement power, and the regulatory infrastructure (ENISA's Single Reporting Platform, designated CSIRTs, conformity assessment bodies) is being stood up right now.

Organizations that treat this as a 2027 problem are already behind. The reporting obligations that take effect in September 2026 apply to every product currently on the EU market. If you're shipping software with EOL dependencies into Europe today, the clock is ticking.

The CRA changes the calculus on EOL open source. What was previously a risk management decision, balancing migration costs against potential exposure, is now a regulatory compliance question with defined penalties and timelines. Engineering teams need to act accordingly.

‍
FAQ

‍
What is the EU Cyber Resilience Act (CRA)?The CRA (Regulation EU 2024/2847) is EU cybersecurity legislation that applies to all "products with digital elements" — essentially any software or hardware product sold in the EU market. It entered into force on December 10, 2024 and introduces mandatory cybersecurity requirements across the full product lifecycle, including vulnerability reporting, security updates, and SBOM documentation.

When do CRA obligations take effect?The first major deadline is September 11, 2026, when Article 14 vulnerability reporting obligations become enforceable. Full product conformity requirements follow on December 11, 2027. Critically, the September 2026 reporting requirements apply to all products already on the EU market — not just new releases.

What does Article 14 actually require?Manufacturers must report actively exploited vulnerabilities in their products on a strict timeline: an early warning notification within 24 hours of discovery, a detailed vulnerability notification within 72 hours, and a final report including root cause analysis and corrective measures within 14 days of a patch being available. These reports go to ENISA and your designated national CSIRT via the EU Single Reporting Platform.

Why does EOL open source create a specific CRA problem?When a framework reaches end of life, its maintainers stop issuing security patches. If a new CVE is published and actively exploited, your 24-hour reporting clock starts — but there's no upstream patch coming. The CRA places the obligation on the manufacturer (your organization), not the upstream maintainer. "We're waiting for an upstream fix" is not a compliant response.

Which EOL frameworks are most relevant to CRA compliance?Any EOL component in a product placed on the EU market creates exposure. High-priority frameworks to audit include AngularJS, Vue 2, Angular versions 4 through 17, Spring Framework 5.x, Spring Boot 2.x, Node.js 16 and 18, .NET 6 and 7, and legacy Java and Ruby runtimes.

What are the penalties for non-compliance?Fines can reach up to 15 million euros or 2.5% of global annual turnover, whichever is higher — a penalty structure comparable in scale to GDPR.

Do I need an SBOM to comply with the CRA?Yes, in practice. While the formal SBOM requirement under Annex I isn't technically enforceable until December 2027, you cannot meet the September 2026 24-hour reporting window without knowing what's in your product. SBOM-based vulnerability monitoring is a prerequisite for Article 14 compliance, not a 2027 problem.

How does HeroDevs NES help organizations meet CRA requirements?NES provides continuously patched, drop-in replacement packages for EOL frameworks including AngularJS, Vue 2, Spring 5, and Node.js 18. When a CVE is published against a supported framework, HeroDevs ships a fix — directly addressing the CRA's requirement that manufacturers be able to deliver corrective measures. NES also provides SBOMs in CycloneDX and SPDX formats and VEX documents to support transparency and audit requirements.

How do I know if my product is covered by the CRA?If your organization places any software or hardware product on the EU market — including SaaS products and products with remote data processing components — the CRA almost certainly applies. The regulation is deliberately broad in scope. If you're unsure, legal review of your EU-facing product portfolio is the right starting point.

‍

‍