CRA Article 14 Doesn't Care That Your Dependency Is Unmaintained

In two days — on 11 September 2026 — Article 14 of the Cyber Resilience Act (Regulation (EU) 2024/2847) becomes binding. We've already written the submission runbook for what happens when you sit down to file a report, and corrected a common mix-up between getting a CVE assigned and actually meeting your Article 14 duty. Neither post — nor most of the CRA coverage we've seen elsewhere — answers the question that actually determines whether you can comply: what do you do when the vulnerable code is a dependency nobody maintains anymore?

That's not a hypothetical. It's the median case.

Two-thirds of you are behind, and the gap is widening

The 2026 CRA Awareness and Readiness Report, published 8 June 2026 by the Open Source Security Foundation and Linux Foundation Research (843 respondents, up 23% from the 2025 edition, plus a security scan of over 12,000 open source projects), found that 66% of software producers remain unfamiliar with the CRA — up from 62% a year earlier. Awareness is going the wrong direction as the deadlines arrive, not the right one.

The same research body's follow-up analysis (19 June 2026) is more specific about the dependency problem itself:

• The share of organizations that passively rely on upstream projects for security fixes — rather than patching themselves — climbed from 46% to 51% year over year.
• Only 32% produce a software bill of materials (SBOM) for all their products, meaning most organizations don't even have a reliable list of what they'd need to check.
• Q1 2026 alone saw a 394% year-over-year increase in published CVEs across LFX-indexed projects, with high-severity vulnerabilities up 811%.
• Organizations that do maintain private forks of dependencies to keep patching them average 86 forks, at roughly 60 labor-hours per fork per release cycle — about $258,000 in labor cost per release cycle, according to the report's estimate.

Read those together and the shape of the problem is clear: the majority default is to depend on upstream fixes that increasingly don't arrive, on top of not knowing what's actually in the product to begin with. Article 14 doesn't pause for any of that.

The support-period clock you already started

Article 13(8) requires every manufacturer to set a support period for each product with digital elements — the window during which "vulnerabilities of that product, including its components, are handled effectively" per the vulnerability-handling requirements in Annex I, Part II. That period must be at least five years, or shorter only if "the product with digital elements is expected to be in use for less than five years," in which case the support period must match that shorter expected-use time. You don't get to declare a support period and then quietly let it lapse because an upstream dependency stopped shipping fixes — the obligation runs against you, the manufacturer, not against whoever wrote the code you're shipping.

Article 13 also requires you to be transparent about the boundary: the end date of the support period has to be "clearly and understandably specified at the time of purchase in an easily accessible manner," and — where technically feasible — you must "display a notification to users informing them that their product with digital elements has reached the end of its support period." An EOL dependency buried three layers deep in your own product's dependency tree doesn't give you a private exemption from any of this. If you can no longer handle vulnerabilities in that component effectively, the honest reading of Article 13 is that your own product's declared support period has effectively ended too, whether you've formally said so or not.

The retroactive part almost nobody's coverage mentions

Most of the CRA's substantive obligations — Article 13, the Annex I essential requirements, CE marking — only apply in full from the CRA's general application date of 11 December 2027, and even then Article 69 (Transitional provisions) exempts products already on the market before that date, unless they undergo a substantial modification:

"Products with digital elements that have been placed on the market before 11 December 2027 shall be subject to the requirements set out in this Regulation only if, from that date, those products are subject to a substantial modification."

Article 14 is carved out of that grace period explicitly. The same Article 69 text continues:

"The obligations laid down in Article 14 shall apply to all products with digital elements that fall within the scope of this Regulation that have been placed on the market before 11 December 2027."

In plain terms: even a product you shipped years ago, that you have no plans to modify before December 2027, is still on the hook for Article 14 reporting starting this Friday — including for a vulnerability discovered in a dependency you bundled back when it was still actively maintained. "We're not touching that codebase again" is not an exemption from the reporting clock. It's precisely the kind of product this provision targets.

"Waiting for upstream" is not one of your options

Once you accept that the reporting clock runs regardless of whether a fix exists upstream, there are really only four honest responses to an EOL or unmaintained dependency with an actively exploited vulnerability — and each one maps to a different part of the CRA's obligations:

What isn't on that list is "leave it as-is and hope nobody notices" — and specifically not "the maintainer hasn't responded to my issue, so there's nothing I can do." Article 14's clock starts at your awareness of active exploitation, not at the upstream maintainer's response time.

Article 24 confirms the burden doesn't shift to the maintainer

It's worth being precise about who the CRA actually holds responsible here, because Article 24 (Obligations of open-source software stewards) sets a deliberately lighter bar for the entities that steward open-source projects. Under Article 24(1), a steward's core duty is to "put in place and document in a verifiable manner a cybersecurity policy" that fosters secure development and encourages voluntary vulnerability reporting — not the full support-period and reporting apparatus Article 13/14 impose on manufacturers. Article 24(3) narrows a steward's Article 14 exposure specifically to cases where they're directly involved in developing the product, or to severe incidents in their own development infrastructure.

The asymmetry is the point: if you integrate an open-source dependency into a commercial product, you are the manufacturer under Article 13, and the reporting duty under Article 14 sits with you — not with the (often unpaid, sometimes no-longer-active) upstream project. That's true even when the honest, sympathetic reading of the situation is "the maintainer burned out and nobody replaced them." The regulation doesn't have a burnout exception.

Finding out how exposed you actually are

Given that only 32% of organizations produce a complete SBOM, the first practical step is usually the audit itself, not the compliance decision. The endoflife.date project maintains a free, community-run API of EOL dates for common frameworks and runtimes — not a CRA-official source, but a reasonable starting point for a first pass across a dependency list before you get into per-component detail:

"""
CRA exposure scan: flag SBOM components that are past their upstream
end-of-life date and where you don't control patching. Not a substitute
for a real SBOM tool -- a first-pass triage before the Article 13(8)/14
conversation.
"""
import datetime as dt
import json
import urllib.request
from dataclasses import dataclass


@dataclass
class Component:
    name: str               # endoflife.date product slug, e.g. "nodejs"
    cycle: str               # release cycle, e.g. "16"
    you_control_patching: bool  # in-house fork/patch capability, or pure upstream dependency?


def eol_status(product: str, cycle: str) -> dict | None:
    url = f"https://endoflife.date/api/{product}/{cycle}.json"
    try:
        with urllib.request.urlopen(url, timeout=5) as resp:
            return json.load(resp)
    except Exception:
        return None  # unknown to endoflife.date -- needs a manual check


def article14_exposure(components: list[Component]) -> list[dict]:
    today = dt.date.today()
    flagged = []
    for c in components:
        data = eol_status(c.name, c.cycle)
        if not data:
            continue
        eol_raw = data.get("eol")
        if eol_raw in (False, None):
            continue  # still supported upstream, not flagged
        eol_date = dt.date.fromisoformat(eol_raw) if isinstance(eol_raw, str) else today
        if eol_date > today:
            continue  # EOL date is in the future
        flagged.append({
            "component": f"{c.name}@{c.cycle}",
            "eol_since": eol_date.isoformat(),
            "days_past_eol": (today - eol_date).days,
            "you_control_patching": c.you_control_patching,
            "next_step": (
                "Migrate, fork, or buy commercial support -- Art.14 runs "
                "on your awareness, not upstream's release schedule."
                if not c.you_control_patching else
                "Confirm your patch pipeline actually covers this "
                "component before you rely on it in an incident report."
            ),
        })
    return flagged


# Example: a product still shipping a runtime that went EOL in 2023.
inventory = [
    Component(name="nodejs", cycle="16", you_control_patching=False),
    Component(name="python", cycle="3.13", you_control_patching=False),
]
for finding in article14_exposure(inventory):
    print(finding)

Run that against a real SBOM (or a manually assembled list, if you're in the 68% majority without one yet) and you get a short, prioritized list of exactly the components this whole post is about — the ones where "we'll wait for upstream" quietly became your default compliance posture without anyone deciding it on purpose.

Before Friday

1. Run the SBOM/EOL cross-check above, or the equivalent in whatever SBOM tooling you already have, against every product with digital elements you ship into the EU — including the ones you have no plans to touch again before December 2027. Article 69 doesn't exempt them from Article 14.
2. For every EOL hit, pick one of the four honest responses — migrate, fork-and-patch, buy commercial support, or formally end support with a user notification — before an actively exploited vulnerability forces the decision under a 24-hour clock.
3. Don't count on the upstream maintainer or Article 24 to absorb the obligation. If you're the one shipping the product, you're the manufacturer under Article 13, full stop.
4. If you land on "buy commercial support," treat the vendor's patch SLA as part of your own Article 13(8) vulnerability-handling story — you still have to be able to show it's actually being met, not just that you signed a contract.

Sources

• Cyber Resilience Act, Article 13 — Obligations of manufacturers — support-period minimum duration (para. 8) and end-of-support disclosure/notification requirements (para. 19), directly quoted above.
• Cyber Resilience Act, Article 14 — Reporting obligations of manufacturers
• Cyber Resilience Act, Article 24 — Obligations of open-source software stewards — steward cybersecurity-policy duty (para. 1) and narrower Art.14 exposure (para. 3), directly quoted above.
• Cyber Resilience Act, Article 69 — Transitional provisions — pre-2027 product exemption and the explicit Article 14 carve-out, directly quoted above.
• OpenSSF / Linux Foundation Research — 2026 CRA Awareness and Readiness Report (published 8 June 2026) — 66% unfamiliarity stat, sample size, project-scan methodology.
• Linux Foundation — "The CRA Readiness Reality: What Changed (and What Didn't) Between 2025 and 2026" (19 June 2026) — upstream-reliance percentage, SBOM production rate, CVE growth, private-fork labor cost.
• HeroDevs — Never-Ending Support — cited as evidence a commercial paid-EOL-support market exists, not as a legal source.
• endoflife.date — community-run EOL date registry used in the audit script above.