Use the tracker to preserve the support-period decision rather than only the final date. Record the product and version, expected use, the Article 13 factors considered, third-party dependencies, approved support period, supported versions, security-update capability, vulnerability-handling owner, disclosed end date and reassessment triggers. Keep the rationale linked to Annex VII technical documentation.
Track the Decision, Not Only the End Date
A support-period record should show why the selected period is appropriate for the product. Article 13 requires manufacturers to include the information considered when determining the support period in the technical documentation. A date field with no reasoning is therefore weaker than a controlled decision record.
Identify the Product and Versions Covered
Record the product identifier, family, model and supported versions covered by the decision. A product family can share one rationale only where expected use, functionality, operating environment and support assumptions are genuinely common. Keep variant-specific differences visible where they change the support decision.
Estimate How Long the Product Is Expected to Be in Use
Article 13 anchors the support period to the length of time the product is expected to be in use. Use product type, intended purpose, deployment context, replacement cycles and customer expectations to form a defensible estimate. Do not equate expected use automatically with the manufacturer's preferred sales or upgrade cycle.
Record Reasonable User Expectations
Reasonable user expectations are an express Article 13 factor. A router, industrial controller, operating system or embedded component can reasonably be expected to remain in use for a different period from a short-lived application. Record the evidence used to understand the expected lifecycle of the product category and customer environment.
Record the Nature and Intended Purpose of the Product
The product's nature and intended purpose can justify a longer or, in limited circumstances, shorter expected use period. Record whether the product is hardware, software, embedded technology, subscription software or another type, together with the environments and functions that influence how long users are expected to rely on it.
Check Relevant Union Law Affecting Product Lifetime
Article 13 requires relevant Union law determining the lifetime of products with digital elements to be considered. The tracker should provide a field for any product-specific lifetime rule identified by legal or compliance review rather than assuming that the CRA is the only relevant lifecycle rule.
Consider Similar Products and the Operating Environment
Manufacturers may consider support periods of products offering similar functionality and the availability of the operating environment. Record comparable products only where they are genuinely relevant, and note dependencies such as operating systems, platforms or infrastructure that can affect realistic continued use.
Consider Core Third-Party Component Support
Article 13 allows the manufacturer to consider support periods of integrated third-party components that provide core functions. Record key dependencies and supplier support commitments, but do not simply copy the shortest supplier support period. The manufacturer remains responsible for determining the finished product's support period.
Apply the Five-Year Minimum Correctly
The support period is at least five years unless the product is expected to be in use for less than five years. Where expected use is shorter, the support period corresponds to that expected use time. Where expected use is longer than five years, the support-period determination should reflect that longer expected use rather than treating five years as an automatic maximum.
Track Vulnerability Handling and Security-Update Capacity
The support period is the period during which vulnerabilities, including component vulnerabilities, must be handled effectively in accordance with Annex I Part II. Track product-security ownership, supported branches, security-update mechanisms, monitoring coverage and escalation paths so the published support commitment is backed by operational capability.
Keep Market Status Separate From Support Status
A product can stop being newly sold or placed on the market while existing deployments remain supported. Track end of sales, end of new market availability and end of security support separately. This prevents discontinued products from disappearing from vulnerability handling too early.
Record the Disclosed Support Information
Keep the internal decision aligned with the support-period information provided with the product under the CRA user-information framework. If product pages, documentation or customer portals communicate an end date, the tracker should identify the controlled source and ensure changes are reviewed consistently.
Use Reassessment Triggers
Review the support-period decision when product use expectations change materially, a core dependency loses support, the operating environment changes, significant product functionality is modified, relevant Union law changes or new Commission or ADCO guidance becomes applicable. Preserve the previous decision and the reason for the change.
Official sources
Read the full legal text and Commission material for precise wording, qualifications and updates.