CRA Lifecycle Management: Product Lifecycle Support Requirements under the CRA

CRA Lifecycle Management: Product Lifecycle Support Requirements under the EU Cyber Resilience Act

Most manufacturers file lifecycle support under patch management. The Cyber Resilience Act turns it into a dated commitment you disclose at the point of sale and justify in your technical documentation.

Ask a device team who owns lifecycle support and the answer is usually "the patch team." That answer worked when support meant shipping fixes for as long as the business found it worthwhile. Under the EU Cyber Resilience Act (CRA), lifecycle management becomes a declared support period for each product, with an end date the buyer sees at purchase and reasoning you record in your technical documentation. Part of that regime is already running.

Article 14 reporting has applied since 11 September 2026, and it reaches products you shipped years ago. This is the fourth installment of our six-part EU CRA series, updated in October 2026 to reflect the live reporting obligations and the Commission's July 2026 guidance. The previous installment covered SBOM and technical documentation requirements under the CRA.

This installment follows a product from the day you set its support period to the day that period ends, then covers the devices already in your customers' hands.

CRA Lifecycle Requirements at a Glance

Each row maps an obligation to its source and start date. Share it with your PSIRT, regulatory, and product teams.

Reporting is live now. Every other obligation in this table will apply from 11 December 2027.

What Lifecycle Management Means for a Device Manufacturer

Search for "lifecycle management" and you get three disciplines, each with a different owner and a different finish line. Product security teams inherit the confusion when someone in a planning meeting says "we have lifecycle management covered."

Lifecycle management is the practice of planning and governing something from its first decision to its retirement. What that "something" is changes the meaning.

The CRA speaks to the first row. It takes the "service and support" stage of PLM, the one most teams fund last, and converts it into a legal obligation measured in years.

It also pulls that stage forward. Long-lived defense and industrial programs have planned sustainment at the requirements stage for decades, with a single point of accountability for product support. The CRA applies the same logic and names the manufacturer as that point: you decide how long you will support a product, and record why, before you place it on the market.

The regulation also moves a burden upstream. Asset owners learn that "installed and still working" does not mean "still supported," and that unsupported software turns patch management into exception management. A device that keeps running after its support period ends remains your customer's risk, but the length of that support period is now your decision and your liability. Treat the declared end date as a control boundary that engineering, sales, and support all plan against.

How to Set Your Support Period

Five years is the number everyone remembers from the CRA. It is a floor, not a target, and choosing it by default leaves you with a rationale that is hard to defend.

From 11 December 2027, Article 13(8) will require a support period of at least five years. The only exception is a product expected to be in use for less than five years, in which case the support period matches the expected use time. The governing principle: the support period should reflect how long the product is expected to be in use.

Article 13(8) lists the factors you take into account, proportionately, when you set the number:

• Reasonable user expectations for a product of that kind
• The nature of the product, including its intended purpose
• Relevant Union law that determines the product's lifetime
• Support periods of products with similar functionality placed on the market by other manufacturers
• Availability of the operating environment the product depends on
• Support periods of integrated third-party components that provide core functions
• Guidance from the administrative cooperation groups (ADCOs) and the Commission

Two of these factors deserve extra attention from product security teams. The first is third-party components. If your device depends on an RTOS, a Linux kernel branch, a cellular module, or a vendor SDK, you inherit its end-of-life date, and any support declaration that outlasts that component's maintenance window leaves a gap you will close yourself.

The second is the operating environment. A product that relies on a cloud service, a mobile app, or a host operating system cannot be supported longer than you can keep that environment available or replace it. Article 13(5) adds a related duty: exercise due diligence when integrating third-party components, including free and open-source software, so they do not compromise the product's security.

Whatever number you land on, Article 13(8) requires you to record the information used to determine it in the technical documentation. Write that record for a reader outside your company who will test the reasoning against the factors above.

The Commission's CRA guidance, published 27 July 2026, reinforces the point. It describes five years as a minimum safeguard rather than a default and says support periods should reflect realistic expected use. It also clarifies that a substantial modification triggers a reassessment of the support period but does not automatically reset it.

If your device ships into OT with a 15-year expected life, a five-year declaration fails the expected-use test the regulation itself sets.

What You Owe during the Support Period

Most product plans summarize this obligation as "provide security updates." Annex I Part II is more specific: from 11 December 2027, it will set eight vulnerability handling requirements that run for the whole support period. They group into three jobs: know, fix, and tell.

Know What Shipped

Point (1) requires you to identify and document the vulnerabilities and components in your product, including an SBOM that covers at least the top-level dependencies. Point (3) requires effective and regular security tests and reviews.

For firmware, the SBOM question is harder than it looks. A manifest from your build system records what you intended to include. The shipped binary shows what actually went out the door, including statically linked libraries and vendor blobs that never appeared in a package file. When a new CVE lands late in a support period, the inventory that matters is the one tied to the exact release in the field.

Fix It

Point (2) requires you to address and remediate vulnerabilities without delay, including by providing security updates. Where technically feasible, security updates ship separately from functionality updates, so customers do not have to accept a feature change to get a fix.

Point (7) requires mechanisms to distribute updates securely, which for most devices means signed packages and a verified OTA or manual update path. Point (8) requires you to disseminate security updates without delay and, unless otherwise agreed, free of charge, accompanied by advisory messages that tell users what to do.

Tell People

You need a coordinated vulnerability disclosure policy under point (5). Point (6) requires you to facilitate the sharing of vulnerability information, including a contact address where researchers and customers can report issues. Once an update is available, point (4) requires you to publicly disclose information about the fixed vulnerability.

If those three jobs sit with different teams today, the support period is where they have to meet. Our post on IoT vulnerability response under the CRA covers the workflow in detail, and our product security incident response page describes how PSIRTs structure the intake side.

Article 13(21) closes the loop. During the support period, a manufacturer that knows or has reason to believe a product or its processes are non-conforming must immediately take corrective measures, or withdraw or recall the product. That obligation turns a known gap from a backlog item into a compliance event, so the inventory from the first job has to stay current for every release you support.

Keeping Security Updates Available for 10 Years

One CRA requirement outlives the support period itself. Article 13(9) says each security update made available during the support period must remain available for at least 10 years after it is issued, or for the remainder of the support period, whichever is longer.

Run the math on a five-year support period. An update you issue in the final month must remain downloadable for roughly a decade after support ends. If your end-of-support plan includes shutting down the update server, retiring the signing infrastructure, or letting a hosting contract lapse, that plan no longer works.

Budget for:

• Distribution infrastructure that stays online after the product is discontinued
• Signing keys and verification chains that remain valid and protected for the full retention window
• Hosting and access that customers can still find after a reorganization or acquisition

Article 13(10) offers software manufacturers one relief valve. If you place substantially modified versions of a product on the market, you may meet Annex I Part II point (2) for the latest version only, provided users of earlier versions can get that latest version free of charge and without additional costs to adjust their hardware or software environment.

Article 13 also sets a parallel retention rule for records: keep the technical documentation and EU declaration of conformity for at least 10 years after the product is placed on the market or for the support period, whichever is longer.

End of Support: Disclosure, Notification, and Customer Transition

End of life now starts at the point of sale. Article 13(19) requires the end date of the support period, at least the month and year, to be specified clearly and understandably at the time of purchase, in an easily accessible manner. Where technically feasible, you must also notify users when the product reaches end of support.

That changes the conversation with sales and channel partners. In practice, the end date belongs wherever a buyer decides: the product page, the listing or packaging, and the documentation that ships with the device. A buyer comparing two devices can now compare support commitments directly, and your declaration becomes part of the purchase decision.

The legal minimum is disclosure and notification. A credible end-of-support program goes further:

• Give advance notice. Tell customers well before the end date, through the same channels you use for security advisories, so they can plan replacements and budgets.
• Plan the transition. Offer a migration path to a supported product or an extended support arrangement where it makes commercial sense.
• Publish decommissioning guidance. Explain how to wipe credentials, keys, and customer data, and how to take the device off the network safely.
• Keep the update archive live. As covered in the previous section, the updates you shipped stay available under Article 13(9) after support ends.

Settle the "where technically feasible" question during design. If your device has no channel to reach the user when support ends, document why, and decide whether a registration, portal, or in-app message should exist in the next product generation.

Products Already on the Market

Most of the CRA does not reach back to products you have already shipped. The part that does runs on a 24-hour clock.

Under Article 69(2), products placed on the market before 11 December 2027 will be subject to CRA requirements only if they are substantially modified from that date. Article 69(3) carves out one exception: Article 14 reporting applies to all in-scope products placed on the market before 11 December 2027. Reporting has applied since 11 September 2026, and ENISA (the EU Agency for Cybersecurity) launched the initial operating capability of its Single Reporting Platform the same day.

The reporting sequence for actively exploited vulnerabilities and severe incidents runs as follows:

• Early warning within 24 hours
• Notification within 72 hours
• Final report within 14 days after a corrective measure is available for a vulnerability, or within one month of the notification for a severe incident

The Commission's July 2026 guidance confirms there is no retroactive reporting for exploitation known before 11 September 2026. It also states that security updates are generally not substantial modifications, so patching a legacy product does not by itself pull it into the full regime.

The hard part is operational. Filing an early warning within 24 hours requires knowing whether the affected component is in your product at all. For a device that shipped years ago, you may have no source access, no build records, and no SBOM, which makes a binary-derived inventory of legacy firmware a reporting prerequisite.

A scope note, correcting an implication in the original version of this post: Article 2(2) excludes products covered by the Medical Devices Regulation (EU) 2017/745, the In Vitro Diagnostic Medical Devices Regulation (EU) 2017/746, and vehicle type approval under Regulation (EU) 2019/2144. Medical devices regulated under the MDR or IVDR follow their own regime, which our healthcare product security page covers.

Key Takeaways and Where to Start

The CRA turns the service and support stage of your product lifecycle into a dated, documented commitment that someone outside your company can check.

• The support period is a declaration. At least five years under Article 13(8), set by expected use and justified in your technical documentation.
• Annex I Part II defines the work. SBOM, remediation, testing, disclosure, and secure, free distribution of updates for the full support period.
• Updates outlive support. Article 13(9) keeps each security update available for at least 10 years after issue, or longer if the support period runs longer.
• End of support starts at sale. Article 13(19) requires the month and year at the time of purchase.
• Reporting is live for every in-scope product. Article 14 has applied since 11 September 2026, including to legacy products.

Put these five questions to your team this month:

1. What support period have we declared for each product, and can we defend the rationale?
2. Which third-party components reach end of life before our support end date?
3. Can we produce an SBOM for every shipped version, including legacy firmware?
4. Where will our security updates be hosted in year 10?
5. Who files the 24-hour early warning, and with what information?

Non-compliance with Annex I and Articles 13 and 14 carries fines under Article 64(2) of up to EUR 15 million or 2.5% of worldwide annual turnover, whichever is higher. For the broader regulation, see our EU Cyber Resilience Act overview and our CRA compliance page.

Finite State generates SBOMs from the firmware binaries you actually ship, including legacy releases without source. We monitor those components for new vulnerabilities across every release in your support period, prioritize findings by reachability, and produce audit-ready documentation for your technical file. See how this works for device manufacturers and vulnerability management, or request a demo to walk through it on your own firmware.

FAQ

What is lifecycle management in product security?

Lifecycle management in product security is the practice of governing a product's security from design through end of support. For connected devices sold in the EU, the Cyber Resilience Act makes it concrete: you declare a support period, handle vulnerabilities under Annex I Part II for that period, keep each security update available, and disclose the end date at the time of purchase. Article 14 reporting, which has applied since 11 September 2026, sits on top of that.

How long is the CRA support period?

The CRA support period is at least five years under Article 13(8), unless the product is expected to be in use for less than five years. It should reflect how long the product is expected to be in use, and the information used to set it goes in the technical documentation. The Commission's July 2026 guidance describes five years as a minimum safeguard rather than a default, so long-lived industrial devices typically need a longer declared period.

Does the CRA apply to products already on the market?

Only partly. Products placed on the market before 11 December 2027 will fall under the full CRA only if substantially modified from that date, per Article 69(2). Article 14 reporting is the exception: under Article 69(3), it has applied to all in-scope products since 11 September 2026, regardless of when they were placed on the market. Security updates alone generally do not count as substantial modifications, according to the Commission's July 2026 guidance.

Do CRA security updates have to be free?

Yes, unless otherwise agreed. Annex I Part II point (8) requires manufacturers to disseminate security updates without delay and free of charge, accompanied by advisory messages telling users what action to take. The "unless otherwise agreed" wording leaves room for negotiated arrangements, typically with business users of custom products. Security updates should also ship separately from functionality updates where technically feasible, and each one must stay available for at least 10 years after issue.

What is the difference between product lifecycle management and asset lifecycle management?

Product lifecycle management is the maker's view, covering a product from concept through design, production, service and support, and end of life. Asset lifecycle management is the owner or operator's view, covering equipment from acquisition through deployment, maintenance, upgrade, and disposal. The CRA regulates the maker's side, specifically the service and support stage, which it turns into a declared support period of at least five years with a disclosed end date.