Support and maintenance

What happens when a dependency loses support before your product?

A component’s upstream end-of-support date does not by itself shorten the product’s commitment. The manufacturer needs a workable vulnerability-handling plan for the remaining period.

Prepared by CRA Operations · Updated 2026-09-13 · Hypothetical worked examples

The situation

A product has a seven-year support commitment, but an embedded dependency stops receiving upstream fixes in year four. The team needs a maintainable replacement, its own supported remediation path or another substantiated plan. Updating the inventory without arranging ongoing handling leaves a gap.

Facts that change the answer

  • Which supported products depend on the component?
  • Who will identify, assess and remediate future vulnerabilities?
  • Can the plan preserve the declared support period?

Compare the worked results

These examples use the published assessment with the assumptions shown below. Change the facts in your own assessment before relying on its result.

Ongoing component vulnerability handling unconfirmed

Hypothetical example 1

Assessment resultvulnerability handling gap
Key facts in this example
Integrated-component vulnerabilities are reported to maintainers and remediated, with relevant fix code or documentation shared where appropriate
No
All recorded assumptions (17)
Product with digital elements
Hypothetical example product
Reasonably expected use time in years
7
Declared support period in years
7
Reasonable user expectations, product nature and purpose, relevant Union law and other applicable Article 13(8) factors are documented
Yes
The support-period end date is disclosed clearly and accessibly at purchase and in the required user information
Yes
The information used to determine the support period is included in the technical documentation
Yes
End-of-support notification to users
planned or not technically feasible
Vulnerabilities and components are identified and documented, including a machine-readable software bill of materials covering at least top-level dependencies
Yes
Internal and external vulnerability intake, a coordinated vulnerability-disclosure policy and a vulnerability-reporting contact are in place
Yes
Integrated-component vulnerabilities are reported to maintainers and remediated, with relevant fix code or documentation shared where appropriate
No
Security updates are made available without delay, separately from functionality updates where technically feasible, and free of charge unless the tailor-made-product exception applies
Yes
Updates are distributed securely with accessible information on purpose, effect and user action
Yes
Effective and regular security tests and reviews continue during the support period
Yes
Fixed-vulnerability information is shared and publicly disclosed, subject to the justified security-delay exception
Yes
Article 13(10) latest-version-only remediation route
not used
Each security update remains available for at least ten years after issue or the remaining support period, whichever is longer
Yes
Public software archive position
no public archive maintained

Support and handling arrangements recorded

Hypothetical example 2

Assessment resultsupport record ready for review
Key facts in this example
Integrated-component vulnerabilities are reported to maintainers and remediated, with relevant fix code or documentation shared where appropriate
Yes
All recorded assumptions (17)
Product with digital elements
Hypothetical example product
Reasonably expected use time in years
7
Declared support period in years
7
Reasonable user expectations, product nature and purpose, relevant Union law and other applicable Article 13(8) factors are documented
Yes
The support-period end date is disclosed clearly and accessibly at purchase and in the required user information
Yes
The information used to determine the support period is included in the technical documentation
Yes
End-of-support notification to users
planned or not technically feasible
Vulnerabilities and components are identified and documented, including a machine-readable software bill of materials covering at least top-level dependencies
Yes
Internal and external vulnerability intake, a coordinated vulnerability-disclosure policy and a vulnerability-reporting contact are in place
Yes
Integrated-component vulnerabilities are reported to maintainers and remediated, with relevant fix code or documentation shared where appropriate
Yes
Security updates are made available without delay, separately from functionality updates where technically feasible, and free of charge unless the tailor-made-product exception applies
Yes
Updates are distributed securely with accessible information on purpose, effect and user action
Yes
Effective and regular security tests and reviews continue during the support period
Yes
Fixed-vulnerability information is shared and publicly disclosed, subject to the justified security-delay exception
Yes
Article 13(10) latest-version-only remediation route
not used
Each security update remains available for at least ten years after issue or the remaining support period, whichever is longer
Yes
Public software archive position
no public archive maintained

Evaluated on 2026-09-13 using EU Cyber Resilience Act support-period and vulnerability-handling record, version 2026.09.02. A completed example is not a customer Record or a declaration of conformity.

Evidence to keep

  • Component inventory and upstream lifecycle notice
  • Replacement or maintenance plan with an owner
  • Testing and vulnerability-handling arrangements through support end

Keep source artifacts in their controlled systems and record their references, responsible owner and review date with the decision.

Your next step

Link the dependency issue to a product task. Close it with evidence that the product’s vulnerability-handling process remains workable.

Choose your real product or vulnerability case in the workspace. The selected assessment will be highlighted; example answers are not copied into your record.

Sources and application dates

Manufacturer reporting applies from 11 September 2026. Broader product requirements apply from 11 December 2027; these product-readiness examples support preparation. Open-source-steward obligations have their own application date.

These examples structure a decision and do not replace the Regulation, official guidance or product-specific professional advice. Not lawyer-reviewed.

Related situations