CRA support period — how to define, record and manage it

The Cyber Resilience Act requires manufacturers to determine a support period for products with digital elements. This is not an “EOL” field filled in after the fact. The decision determines, among other things, how long effective vulnerability handling needs to continue, and the rationale has to be included in the technical documentation.

As a general rule, the support period is at least five years. Where a product is expected to be in use for less than five years, the support period corresponds to that expected use time.

Criteria set out in the CRA

The manufacturer must take into account in particular:

reasonable user expectations;
the nature of the product;
its intended purpose;
relevant EU law determining the lifetime of the product.

The CRA also allows consideration of:

support periods of products offering similar functionality;
availability of the operating environment;
support periods of integrated third-party components that provide core functions;
relevant Commission and ADCO guidance.

The criteria must be applied proportionately.

Do not start with the date

A weak process starts with:

“Let us enter five years because that is what CRA says.”

A stronger process starts with the assumptions:

How long will users reasonably expect to use the product?
For how long can core dependencies be supported?
What is the lifecycle of the hardware or operating environment?
Is the product used in an industrial or other environment where the practical lifetime is longer?
What commitments follow from contracts and other applicable law?
Can the security-update process realistically be maintained for the chosen period?

Approve the end date only after those questions have been considered.

Evidence for the decision

A minimum record can include:

Field	Example content
Product / version	unique identification
Decision date	when the support period was approved
End date	at least month and year
Expected use time	assumption + source
User expectations	contracts, product data, market evidence
Core dependencies	third-party support periods
Operating environment	required systems/platforms
Legal/guidance basis	sources used in the decision
Approver	accountable person/role
Review date	when assumptions are checked again

Users need a clear support end date

Article 13 requires the end date of the support period — at least the month and year — to be clearly and understandably specified at the time of purchase in an easily accessible manner and, where applicable, on the product, packaging or digitally.

This connects an internal lifecycle decision to product communication. If the date in technical documentation, pricing, UI and contract differs, the problem will surface in normal customer operations long before an audit.

The support period is an operating commitment, not just a date

During the support period, the manufacturer must handle vulnerabilities effectively in accordance with CRA requirements. The support-period record should therefore connect to:

coordinated vulnerability disclosure policy;
vulnerability triage and remediation;
security releases;
third-party components;
user communication;
end-of-support monitoring.

The CRA also contains requirements on the continued availability of issued security updates and on retaining documentation for defined periods. Lifecycle management cannot be reduced to one field in a CRM or product catalogue.

How Pulsar can manage the decision

Pulsar can retain the decision, rationale, accountable people, actions and evidence and connect them to risks and documentation. During a later review, the team can see what changed since the previous decision instead of reconstructing the original rationale.

That does not mean Pulsar autonomously decides the correct support period. The assumptions and approval remain the manufacturer’s responsibility.

See Pulsar GRC on one decision lifecycle

Sources

Sources checked: 12 September 2026.