If upstream support ends while the CRA product remains inside its support period, the manufacturer needs a product-level risk decision. Depending on the circumstances, options can include replacing the dependency, maintaining or forking it, backporting a correction, isolating the vulnerable functionality, deploying a temporary mitigation or redesigning the affected product component.
Unsupported Upstream Software Does Not Automatically End Manufacturer Responsibility
Article 13(8) requires vulnerabilities of the product, including its components, to be handled effectively throughout the manufacturer's support period. An upstream project reaching end of support does not automatically shorten the support period already determined for the CRA product. The manufacturer should therefore treat dependency end of life as a lifecycle risk that needs its own remediation or migration plan.
- Track upstream support dates.
- Compare them with the product support period.
- Identify lifecycle gaps.
- Plan remediation before upstream support ends.
Component Due Diligence Starts Before the Dependency Is Integrated
Article 13(5) requires manufacturers integrating components sourced from third parties to exercise due diligence so those components do not compromise the cybersecurity of the product. Support status is therefore relevant during component selection. Teams should consider whether a dependency is actively maintained, whether security updates are available, how long the upstream project is expected to be supported and whether replacement is practical if maintenance ends.
- Review maintenance status.
- Review security-update history.
- Review expected upstream support.
- Plan replacement or migration.
Maintain a Software Bill of Materials
Annex I Part II point 1 requires manufacturers to identify and document vulnerabilities and components, including through a software bill of materials in a commonly used and machine-readable format covering at least top-level dependencies. A software bill of materials helps identify which supported product versions contain an unsupported dependency and which vulnerability cases may require product-specific action.
- Track component names.
- Track component versions.
- Track affected product versions.
- Keep dependency information current.
Article 13(6) Applies to Vulnerabilities in Integrated Components
When a manufacturer identifies a vulnerability in a component integrated into the product, Article 13(6) requires the manufacturer to report the vulnerability to the person or entity manufacturing or maintaining the component and to address and remediate the vulnerability in accordance with Annex I Part II. The provision expressly includes a vulnerability in an open source component.
- Identify the affected component.
- Report the vulnerability upstream.
- Assess the effect on the CRA product.
- Address and remediate the product vulnerability.
An Abandoned Upstream Project May Have No Active Maintainer
An unsupported dependency can exist because the upstream maintainer has stopped issuing releases or the project has effectively been abandoned. In that situation, the manufacturer may have no practical upstream fix to consume. That does not automatically make the product vulnerability disappear. The manufacturer should assess alternative remediation strategies that it can control at the product level.
- Confirm whether an active maintainer exists.
- Check whether a maintained successor exists.
- Assess product-level remediation options.
- Document the lifecycle risk.
Replacement Is Often the Cleanest Long-Term Remediation
Replacing an unsupported dependency with a maintained alternative can remove both the immediate vulnerability and the continuing lifecycle risk. Replacement can still require substantial engineering work because APIs, data formats, behaviour or licensing may differ. The manufacturer should test security-sensitive behaviour and avoid assuming that a newer dependency is automatically compatible or secure merely because it remains maintained.
- Identify maintained alternatives.
- Review compatibility.
- Review security properties.
- Test the replacement thoroughly.
Maintaining or Forking the Component Is Another Possible Strategy
Where replacement is impractical, a manufacturer may decide to maintain an internal or public fork of an unsupported dependency. The CRA does not require one particular maintenance model. A fork transfers more security responsibility to the manufacturer because it must monitor vulnerabilities, develop fixes, test changes and manage divergence from any remaining upstream ecosystem.
- Assign component-maintenance ownership.
- Monitor new vulnerability information.
- Maintain a patch process.
- Test the fork within the product.
Share Relevant Modifications With the Component Maintainer Where Appropriate
Article 13(6) states that where the manufacturer has developed a software or hardware modification to address the vulnerability in the component, it shall share the relevant code or documentation with the person or entity manufacturing or maintaining the component where appropriate, in a machine-readable format where appropriate. This can help upstream remediation and reduce duplication across products using the same component.
- Identify relevant modification material.
- Share code or documentation where appropriate.
- Use machine-readable formats where appropriate.
- Preserve the upstream communication record.
Temporary Mitigation Can Reduce Risk While Permanent Remediation Is Prepared
If replacement or a permanent component fix cannot be completed immediately, a temporary mitigation can reduce exposure. Examples can include disabling vulnerable functionality, restricting network access, applying configuration changes or isolating the affected component. The mitigation should be verified against the actual attack path and should remain clearly distinguished from permanent remediation.
- Identify immediate risk reduction.
- Verify the mitigation.
- Communicate user action where required.
- Continue work on permanent remediation.
Component Support Periods Can Inform Product Support Planning
Article 13(8) allows manufacturers, when determining the product support period, to take into account the support periods of integrated components that provide core functions and are sourced from third parties. This makes dependency lifecycle planning relevant before market placement. It does not automatically mean the manufacturer's support period can be shortened later merely because a chosen dependency becomes unsupported earlier than expected.
- Review core component support periods.
- Identify mismatch with expected product use.
- Plan migration before market placement where possible.
- Document significant lifecycle assumptions.
Maintain Evidence for Unsupported-Dependency Decisions
The vulnerability record should identify the dependency, affected versions, upstream support status, product exposure, communication with the upstream maintainer, remediation options considered and the selected treatment. Where the manufacturer chooses replacement, backporting, a fork or temporary mitigation, relevant verification results should remain connected to the vulnerability case.
- Dependency and version.
- Upstream support status.
- Affected product versions.
- Upstream communication.
- Remediation decision.
- Verification evidence.
Official sources
Read the full legal text and Commission material for precise wording, qualifications and updates.