The CRA Support Period: How to Determine It and Where You Must State It

Every product with digital elements placed on the EU market from 11 December 2027 must carry a defined support period. It is the window during which you must handle vulnerabilities and provide security updates for that product, and it is a commitment you must make before the product ships. Article 13(8) of the Cyber Resilience Act sets out how the period must be determined. Annex II requires you to tell users when it ends. And the reasoning behind the number must sit in your technical documentation, where a market surveillance authority can ask to see it.

The support period interacts with two topics we have covered before. Reporting obligations under Article 14 begin on 11 September 2026, well ahead of the full conformity deadline, as explained in our guide to when CRA reporting becomes mandatory. And because the determination itself must be recorded in the technical file, it connects directly to the CRA technical documentation requirements.

The rule in Article 13(8) and the five-year floor

Article 13(8) states the principle plainly. The support period must reflect the length of time during which the product is expected to be in use. The anchor is real-world use time, so the question to answer is how long buyers will realistically keep the product in service. A connected doorbell screwed to a house wall, an inverter in a solar installation, or a controller inside an industrial line all stay in use far longer than a typical software release cycle, and the support period has to follow that reality.

On top of the expected-use principle sits a floor. The support period must be at least five years. There is one exception. Where the product is expected to be in use for less than five years, the support period must correspond to that shorter expected use time. The exception is for genuinely short-lived products, and if you rely on it you should hold evidence of the shorter use time, because the burden of explaining the number falls on you.

The floor can also move upward over time. The Commission can adopt delegated acts specifying minimum support periods for specific product categories where market surveillance data suggest the periods being offered are inadequate. A category-level minimum would override a shorter period you might otherwise have justified.

For the wider obligation set this sits in, see our explainer on Article 13 manufacturer obligations.

The factors that determine the period

Article 13(8) distinguishes between factors you must take into account and inputs you may additionally consider. Three factors are mandatory.

• Reasonable user expectations. What a buyer of this product category reasonably expects in terms of service life. A consumer expects a smart appliance to outlast its warranty by years.
• The nature of the product, including its intended purpose. A device installed into building infrastructure carries a longer expectation than a novelty gadget.
• Relevant Union law. Where other EU legislation determines the expected lifetime of a product, the support period must be considered against it.

Four further inputs are explicitly permitted.

• Comparable products. The support periods offered by other manufacturers for products with similar functionality.
• The operating environment. How long the platform or operating system your product depends on will itself remain available.
• Integrated components. The support horizons of third-party components that provide core functions. If a chipset vendor ends support in year four of your seven-year period, you need a plan or a different component.
• Guidance. Recommendations from the Commission and from the dedicated administrative cooperation group (ADCO) established under the regulation.

The regulation adds that these matters must be weighed in a way that keeps the outcome proportionate. The determination is a judgment call, but a structured one, and each factor you weigh becomes part of the record you keep.

Where the end date must be stated

Determining the period is half the obligation. Communicating it is the other half.

Annex II lists the information and instructions that must accompany every product with digital elements, and among them is the type of technical security support you offer and the end date of the support period. That is the date until which users can expect vulnerabilities to be handled and security updates to arrive. The statement must be concrete. A specific end date works, and so does a clearly determinable period from the date of purchase. Conditional wording such as "for as long as commercially viable" does not meet the requirement.

Article 13(19) sharpens the precision required. The end date must specify at least the month and the year, and it must be indicated in an easy to access manner and, where applicable, on the product itself, on its packaging, or by digital means. When the period eventually ends, you must clearly communicate to users that the product will no longer receive security updates.

Our user information template covers the Annex II items, including a support period statement in the required form.

What you owe users while the period runs

The support period is the timeframe over which the vulnerability-handling requirements in Annex I Part II remain live for the product. Throughout the period you must, among other duties, identify and document vulnerabilities in the product and its components, address them without undue delay through security updates, operate a coordinated vulnerability disclosure policy, and distribute security updates free of charge together with advisory information users can act on. Where technically feasible, security updates must be provided separately from functionality updates, so users can take a fix without accepting feature changes.

Two clock-related points deserve attention.

• Updates must remain available after release. Under Article 13(9), each security update made available during the support period must remain available for at least ten years after the product was placed on the market or for the remainder of the support period, whichever is longer. Publishing a patch once and later removing it does not satisfy this.
• Reporting duties run on their own timeline. The Article 14 obligation to report actively exploited vulnerabilities and severe incidents applies from 11 September 2026 and runs on its own clock, ahead of the 11 December 2027 conformity deadline.

Document the determination in the technical file

Article 13(8) closes the loop with a documentation duty. The information you took into account to determine the support period must be included in the technical documentation set out in Annex VII. A bare number is insufficient. The file needs to show the reasoning.

In practice, a defensible record contains the following.

• The expected use time and its evidence. Market data, service and warranty statistics, fleet telemetry, or published sector studies supporting how long the product stays in use.
• The factor-by-factor assessment. How user expectations, intended purpose, and any relevant Union law were weighed, plus any comparables, operating environment constraints, and component support horizons you considered.
• Component commitments. Where third-party components provide core functions, the support commitments you obtained from those suppliers.
• The decision itself. The period chosen, the end date communicated to users, who approved it, and when.

Market surveillance authorities can request the technical file, and an unsupported support period is an easy finding for an authority reviewing it. The same file also holds your cybersecurity risk assessment and SBOM, so the support period record should live alongside them from the start rather than being reconstructed later.

What this means for manufacturers

The support period is a product decision with regulatory consequences, and it needs to be made deliberately for every product you place on the market from 11 December 2027.

• Set the period per product, from expected use time. Start from how long the product will actually be used, apply the five-year floor, and treat anything shorter as an exception you must evidence.
• Check your component chain before you commit. Your published period silently binds your suppliers. Confirm that core components are supported for the full window before you state a date.
• State the end date where users will see it. Month and year at minimum, in the Annex II user information, and on the product or packaging where applicable.
• Write the reasoning down now. The determination record belongs in the Annex VII technical file from day one, alongside the risk assessment and SBOM.
• Plan for the duties the period triggers. Vulnerability handling, security updates, and a working disclosure process must run for the whole period, and the reporting obligations start earlier, in September 2026.

A support period chosen with evidence and stated clearly gives you audit-ready ground to stand on. One chosen by habit and buried in a footnote is a finding waiting to happen.