End-of-life dependency management is a planning problem as much as a vulnerability problem. The best time to address an unsupported library is before a critical vulnerability appears and while replacement remains operationally manageable.
Component End of Life Can Become Product Security Risk
An unsupported dependency may stop receiving vulnerability fixes even while the finished product remains within its CRA support period. Manufacturers should therefore treat component support status as an input to product lifecycle risk rather than waiting for a known vulnerability to appear.
Track Component Support Status
Record known support dates, maintenance status and upstream activity for important dependencies. For commercial components, use supplier support commitments; for open source, monitor project release activity, security notices and governance signals.
Use Support Information During Component Selection
A dependency near end of life may be a poor choice for a product expected to remain supported for years. Article 13 allows manufacturers to consider support periods of integrated third-party components providing core functions when determining product support.
Plan Replacement Before Support Ends
Create migration plans for critical dependencies with announced end-of-life dates. Replacement can involve API changes, data migration, retesting and recertification work, so waiting until the final supported release creates avoidable product risk.
Decide Whether Internal Maintenance Is Realistic
Where replacement is not immediately possible, the manufacturer may need to maintain a fork or backport security fixes. That decision should consider source availability, engineering capability, testing burden and how long the internal maintenance commitment must continue.
Assess Unsupported Components During Vulnerability Triage
An unsupported dependency can increase remediation complexity because there may be no upstream fix. Vulnerability response should identify whether the manufacturer must patch internally, isolate vulnerable functionality or accelerate replacement.
Keep the SBOM and Inventory Current After Migration
When a dependency is replaced, update the release-linked SBOM and component inventory so historical and current product versions remain distinguishable. This preserves accurate exposure analysis for older supported releases.
Document Lifecycle Decisions
Record why an unsupported dependency was retained, replaced or internally maintained, including compensating controls and target dates. This creates a defensible link between component lifecycle decisions and the product cybersecurity risk assessment.
Official sources
Read the full legal text and Commission material for precise wording, qualifications and updates.