FAQEUCyber Resilience Act

EU Cyber Resilience Act FAQ Support Period

The CRA is the period when the manufacturer must handle product vulnerabilities effectively. It must be justified from expected use, disclosed to users, and backed by technical documentation.

This FAQ helps separate support-period length from security-update availability, user instructions, documentation retention, and channel inventory questions.

Author
Sorena AI
Published
Mar 10, 2026
Updated
Oct 15, 2026
Overview

Under the EU Cyber Resilience Act, a is the period during which the manufacturer must ensure that vulnerabilities in a product with digital elements, including its components, are handled effectively. It is separate from a marketing warranty or a generic lifecycle label. This FAQ explains how expected use affects the period, when a period shorter than five years may be justified, what users must be told, how long issued security updates must remain available, and what evidence belongs in the technical documentation. The Regulation is binding; the Commission CRA FAQs and Blue Guide cited below provide non-binding interpretation and product-law guidance.

Search this module

Find a question or answer quickly

17 of 17 questions
Question 1

What does the CRA mean by Support Period?

The CRA defines the as the period during which the manufacturer must ensure that vulnerabilities of a product with digital elements are handled effectively and in accordance with the CRA vulnerability-handling requirements.

Article 13(8) applies that obligation from and throughout the . The obligation covers the product in its entirety, including integrated components.

Recommended next step

Document CRA Support Period decisions with cited evidence

Research Copilot helps teams turn expected-use analysis, user disclosures, security-update availability, and technical-documentation evidence into a reviewable CRA support-period record.

Question 2

Is the CRA Support Period always five years?

No. The CRA sets a minimum of at least five years, but that is not a universal cap or safe default.

If the product with digital elements is expected to be in use for less than five years, the must correspond to that expected use time. If the product is reasonably expected to be used for longer than five years, the Commission FAQ says five years is not sufficient by itself and the manufacturer should consider the Article 13(8) criteria, which may require a longer period.

Question 3

What criteria should manufacturers use to determine the Support Period?

Article 13(8) requires the to reflect the length of time during which the product is expected to be in use.

The mandatory factors are reasonable user expectations, the nature of the product including intended purpose, and relevant Union law determining the lifetime of products with digital elements. Manufacturers may also consider support periods for similar products, availability of the operating environment, support periods of third-party integrated components that provide core functions, and relevant or Commission guidance.

The Commission FAQ adds an important guardrail: manufacturers are not expected to set support periods by simply copying expected use time, except where the expected use time is less than five years. The criteria must be considered proportionately.

Question 4

How does expected product lifetime affect the cybersecurity risk assessment?

Expected use is not only a support-period input. Article 13(3) requires the cybersecurity risk assessment to take into account the length of time the product is expected to be in use.

The Commission FAQ explains that manufacturers should consider product lifetime during design and development and prepare the product so that vulnerabilities, including component vulnerabilities, can be handled effectively throughout the .

Question 5

When can the Support Period be shorter than five years?

A shorter is justified only where the product is expected to be in use for less than five years. In that case, the CRA says the Support Period must correspond to the expected use time.

The Commission FAQ gives examples such as a contact-tracing application intended for a pandemic and some software applications that become unavailable and are no longer in use once a subscription expires. Do not generalize that example to every subscription product; document why the product is genuinely unavailable or no longer in use after the relevant period.

Question 6

Can free and open-source software monetised through support subscriptions use the active subscription duration?

The Commission FAQ describes a narrow scenario: free and open-source software placed on the market may be monetised only through paid support services, and the software may remain in use after the user stops paying for support. In that circumstance, the FAQ says the manufacturer is required to ensure a equal to the duration of the active subscription.

The scenario does not create a general short-period rule for all open-source or subscription software. The evidence file should show the commercial model, what remains usable after support ends, what security support the user receives during the active subscription, and why the chosen follows the CRA expected-use rule.

Question 7

Is the Support Period determined for a product type or for each individual unit?

For physical products, use the Blue Guide concept of : each individual product can be placed on the Union market only once. The Commission FAQ applies this logic to CRA support periods for hardware units.

If a manufacturer places more units of the same hardware model on the market later, the later units need their own determination. Units already placed on the market can continue to be made available after their Support Period expires, but newly placed units still need a Support Period.

Question 8

Does the Support Period start on manufacturing, final sale, activation, or first use?

The reliable CRA answer is to anchor the analysis in , not manufacturing alone, later distributor resale, activation, or first use.

The Blue Guide says a product is placed on the market when it is made available for the first time on the Union market. Manufacturing must be complete, and the transfer can occur without physical handover. Later transactions down the distribution chain are making available, not a second placing-on-the-market event for the same unit.

Question 9

What must users be told about the Support Period?

At the time of purchase, the manufacturer must clearly and understandably specify the end date of the , including at least the month and year, in an easily accessible manner. Where applicable, this may be on the product, packaging, or by digital means.

The user information must also state the type of technical security support offered and the end date of the period during which users can expect vulnerabilities to be handled and to receive security updates. Where technically feasible, the manufacturer must notify users when the product reaches the end of its .

Question 10

What security-update duties apply during the Support Period?

During the , manufacturers must address and remediate vulnerabilities without delay in relation to the risks posed, including by providing security updates. Where technically feasible, new security updates must be provided separately from functionality updates.

Where security updates are available to address identified security issues, they must be disseminated without delay and, unless a tailor-made product arrangement with a business user says otherwise, free of charge and with advisory messages telling users relevant information and potential action to take.

Question 11

Must each security update remain available after it is issued?

Yes. Article 13(9) is separate from the length of the itself.

Each made available to users during the must remain available after issuance for at least 10 years or for the remainder of the Support Period, whichever is longer. This can make update availability last longer than a five-year Support Period.

Question 12

What support-period evidence should the technical documentation contain?

The technical documentation must include the information used to determine the , not merely the final number.

Useful evidence includes the expected-use analysis, user-expectation rationale, intended-purpose and operating-environment assumptions, relevant Union-law lifetime constraints, comparable-product support references, third-party core-component support periods, component vulnerability-handling assumptions, the disclosed end date, and the security-update availability plan.

Keep the evidence connected to the cybersecurity risk assessment. Article 31 requires technical documentation to be drawn up before placement on the market and continuously updated where appropriate, at least during the .

Question 13

Can component support periods cap the finished product's Support Period?

No. Third-party core-component support periods are a factor the manufacturer may consider, but they do not automatically cap the finished product's .

The Commission FAQ says the finished-product manufacturer must comply with CRA vulnerability-handling obligations for the product in its entirety. If an integrated component is no longer supported and a vulnerability cannot be adequately handled by mitigations, the finished-product manufacturer may need to switch the component, develop a patch, disable compromised functions, or remediate by other means.

Question 14

How long must technical documentation and user instructions be kept?

This retention rule is separate from the decision.

The manufacturer must keep technical documentation and the EU declaration of conformity available to market surveillance authorities for at least 10 years after placement on the market or for the , whichever is longer. User information and instructions must also remain available to users and market surveillance authorities on the same 10-years-or-support-period basis, including online where provided online.

Do not read those retention periods as saying the itself is always 10 years.

Question 15

Can market surveillance authorities challenge a short Support Period?

Yes. Market surveillance authorities must monitor how manufacturers applied the Article 13(8) criteria when determining support periods.

The CRA also requires to publish relevant statistics, including average support periods, and guidance with indicative support periods for product categories. Those statistics and indicative periods are not the same as binding legal minimums, but the Commission may later adopt delegated acts specifying minimum support periods for product categories where market-surveillance data suggests inadequate support periods.

Question 16

What is the practical manufacturer checklist for CRA Support Period decisions?

For each product or relevant unit batch, record the placing-on-the-market basis, expected-use analysis, Article 13(8) criteria, component support dependencies, disclosed support end date, security-update distribution method, update availability plan, user notification method, and technical-documentation evidence.

Keep separate fields for the end date, update-retention end dates under Article 13(9), and documentation/user-instruction retention under Article 13(13) and Article 13(18). These clocks are related, but they are not the same obligation.

Question 17

What support-period duties apply to products placed on the market before 11 December 2027?

A product placed on the market before 11 December 2027 is not brought under the full CRA merely because the general application date arrives. Under Article 69(2), the full requirements apply to that product only if it is substantially modified from 11 December 2027.

Article 14 is different. Its reporting obligations apply from 11 September 2026 to all in-scope products, including products placed on the market before 11 December 2027. If a legacy product is later substantially modified and placed on the market as a new CRA product event, the manufacturer must determine and disclose a for that modified product under the applicable CRA rules.

The July 2026 Commission guidance, sections 4.4.2 and 5.1, explains that a substantial modification requires reassessing expected use time but does not automatically reset or extend support. Where the factors determining expected use time remain unchanged, support aligns with the remaining original expected use time, even if less than five years. Where the modification changes those factors, recalculate the under Article 13(8).

Primary sources

References and citations

data.europa.eu17 citations
Referenced sections
  • Official Cyber Resilience Act legal text supporting this FAQ and its article-level compliance conclusions.
  • Article 3(20) defines the Support Period; Article 13(8) applies vulnerability-handling duties during that period.
  • Article 13(8) states the five-year floor and the shorter-expected-use exception.
Show 14 more
  • Article 13(8) lists the required and optional criteria for determining the Support Period.
  • Article 13(3) ties expected use time to the cybersecurity risk assessment.
  • Article 13(8) and recital 60 support the short-expected-use exception.
  • Article 13(8) remains the baseline legal rule for expected use and support-period determination.
  • Article 13(8) ties vulnerability handling to placing on the market and the Support Period.
  • Article 13(19) requires purchase-time end-date disclosure and end-of-support notification where technically feasible; Annex II point 7 requires user information about technical security support and the support-period end date.
  • Annex I Part II points 2 and 8 require risk-based remediation without delay, separate security updates where technically feasible, timely dissemination, free updates except for qualifying tailor-made agreements, and advisory messages.
  • Article 13(9) sets the availability rule for each security update issued during the Support Period.
  • Article 13(8), Article 31(2), and Annex VII point 4 require support-period determination information in technical documentation drawn up before placement and updated where appropriate.
  • Article 13(8) allows consideration of third-party core-component support periods, but keeps the support obligation on the product.
  • Articles 13(13) and 13(18) set the separate retention periods for technical documentation, the EU declaration of conformity, and user information and instructions, including online availability.
  • Article 52(16) gives market surveillance authorities and ADCO monitoring and publication roles; Article 13(8) permits delegated acts setting category-specific minimum periods where market-surveillance data indicates inadequate support.
  • Article 13(8), Article 13(9), Article 13(13), Article 13(18), Article 13(19), and Annex VII define the evidence and disclosure fields.
  • Articles 69(2) and 69(3) distinguish the substantial-modification trigger for legacy products from the earlier Article 14 reporting duty; Article 71(2) sets the 11 September 2026 and 11 December 2027 application dates.
"vulnerabilities of a product with digital elements are handled effectively"
More quoted passages
"the support period shall be at least five years"
"reasonable user expectations, the nature of the product"
"taking into account the length of time the product is expected to be in use"
"shall correspond to the expected use time"
"reflects the length of time during which the product is expected to be in use"
"when placing a product with digital elements on the market"
"including at least the month and the year"
"address and remediate vulnerabilities without delay"
"for a minimum of 10 years"
"information that was taken into account to determine the support period"
"support periods of integrated components that provide core functions"
"for at least 10 years after the product"
"monitor how manufacturers have applied the criteria"
"end date of the support period"
ec.europa.eu7 citations
Referenced sections
  • Section 4.5.2 explains that five years is not sufficient where products are reasonably expected to be used longer.
  • Section 4.5.1 explains proportional use of the Article 13(8) criteria.
  • Section 4.1.6 links expected use, design preparation, component vulnerabilities, and the Support Period.
Show 4 more
  • Section 4.5.2 gives examples for products expected to be used for less than five years.
  • Section 4.5.2 addresses the free-and-open-source paid-support-subscription scenario.
  • Section 4.5.3 explains later units of the same hardware model must receive a support-period determination.
  • Sections 4.3.6 and 4.3.7 explain vulnerability handling for integrated components.
"reasonably expected to be in use for longer than five years"
More quoted passages
"not expected to simply set support periods"
"only justified in situations where the lifetime"
"equal to the duration of the active subscription"
"newly placed on the market"
"their products in their entirety"
ec.europa.eu3 citations
Referenced sections
  • Section 2.3 explains that placing on the market is per individual product and occurs only once.
  • Section 2.3 explains first making available, completed manufacture, no physical handover requirement, and later making-available transactions.
  • Section 2.3 supports recording the first placing-on-the-market event for individual products.
"each individual product can only be placed once"
More quoted passages
"made available for the first time on the Union market"
"placing on the Union market can only happen once"

CRA Blue Guide Concepts FAQ | Placing on the Market, Making Available, Distance Sales

CRA FAQ explaining Blue Guide market-access concepts for products with digital elements: placing on the market, making available, imports, CE marking, operator roles, online sales, stock, and testing exceptions.

CRA CE Marking FAQ | Conformity Assessment, EU Declaration, Evidence

Practical CRA CE marking answers for products with digital elements: conformity assessment, EU declaration, technical documentation, standards, software placement, and launch evidence.

CRA Component Due Diligence FAQ | Third-Party Software, FOSS, SBOMs

Cyber Resilience Act FAQ on manufacturer due diligence for integrated components, third-party software, FOSS dependencies, SBOMs, vulnerability handling, and evidence records.

CRA Conformity Assessment Routes FAQ | Module A, Module B+C, Module H, Important and Critical Products

Cyber Resilience Act FAQ on when manufacturers can use module A, when module B+C or module H is required, and how important and critical products affect the route.

CRA Cybersecurity Risk Assessment FAQ | Article 13, Annex I, Updates

CRA FAQ on Article 13 cybersecurity risk assessments, Annex I applicability, intended purpose, foreseeable use, technical documentation, and update evidence.

CRA Declaration of Conformity FAQ | Annex V, Simplified Declaration, CE Marking

FAQ on the Cyber Resilience Act EU Declaration of Conformity: Annex V contents, simplified Annex VI wording, CE marking link, technical documentation, retention, updates, and operator duties.

Show all related guides (55)

CRA Economic Operators FAQ | Manufacturers, Importers, Distributors, Authorised Representatives

CRA FAQ on economic-operator roles: manufacturers, importers, distributors, authorised representatives, substantial modification, traceability, and evidence controls.

CRA Essential Cybersecurity Requirements FAQ | Annex I Part I and Part II

CRA FAQ on Annex I product cybersecurity requirements, vulnerability handling, secure-by-default design, risk assessment, documentation, lifecycle duties, and user information.

CRA Hardware and Software Boundaries FAQ | Product Scope, Components, RDPS

FAQ on Cyber Resilience Act hardware and software boundaries: combined products, standalone software, source code, components, remote data processing, SaaS and market-placement changes.

CRA Harmonised Standards FAQ | Presumption of Conformity, Common Specifications

Cyber Resilience Act FAQ on how harmonised standards, common specifications, certification schemes, and OJ publication affect CRA conformity evidence.

CRA Important and Critical Products FAQ | Annex III, Annex IV, Conformity Assessment

FAQ on CRA important and critical products, Annex III and Annex IV classification, core functionality, and conformity assessment consequences.

CRA Integrated Components and Dependencies FAQ | Third-Party Software and SBOM Evidence

Cyber Resilience Act FAQ on integrated components, third-party software, remote data processing, SBOM-style evidence, upstream fixes, FOSS dependencies, and manufacturer responsibility.

CRA Interplay With EU Product Laws FAQ | RED, Machinery, Data Act

Official source CRA FAQ on overlap with the Radio Equipment Directive, Machinery Regulation, GPSR, Data Act, exclusions, declarations, documentation, and existing certificates.

CRA Known Exploitable Vulnerabilities at Launch FAQ

FAQ for Cyber Resilience Act launch decisions: known exploitable vulnerabilities, CVEs, component flaws, secure-by-default settings, release gates, Article 14 reporting, and evidence.

CRA Legacy Products FAQ | Pre-11 December 2027 Products

Cyber Resilience Act FAQ on products placed on the market before 11 December 2027, Article 14 reporting, substantial modification, distributor stock, spare parts, and records.

CRA Manufacturer Obligations FAQ | Article 13, Annex I, CE Marking

FAQ for Cyber Resilience Act manufacturers covering Article 13 duties, risk assessment, Annex I, vulnerability handling, support periods, documentation, conformity assessment, reporting, CE marking, and evidence controls.

CRA Market Surveillance and Enforcement FAQ | Authorities, Corrective Action, Safeguards

Cyber Resilience Act FAQ on market-surveillance authorities, investigations, corrective action, withdrawal, recall, safeguards, sweeps, documentation access, and penalties.

CRA Module B+C FAQ | EU-Type Examination, Conformity to Type, Notified Bodies

CRA Module B+C FAQ explaining EU-type examination, conformity to type, notified-body evidence, production control, CE marking, declarations, and certificate changes.

CRA Module H FAQ | Full Quality Assurance, Notified Body Surveillance, CE Marking

CRA Module H FAQ explaining the full-quality-assurance route, notified-body assessment, quality-system scope, technical documentation, CE marking, declarations, and records.

CRA Notified Bodies FAQ | Scope, Modules B+C and H, Certificates

Practical CRA FAQ on when notified bodies are needed, how CRA bodies are designated, what their notified scope means, and how Module B+C and Module H assessments work.

CRA Open-Source Software FAQ | FOSS Scope, Stewards, Manufacturers

Cyber Resilience Act FAQ for free and open-source software: commercial activity, steward duties, manufacturer due diligence, vulnerability handling, public documentation, and user obligations.

CRA Over-the-Air Updates FAQ

Cyber Resilience Act FAQ on OTA updates, automatic security updates, secure update distribution, support-period evidence, and offline update paths.

CRA penalties and fines FAQ | Article 64 fine caps

FAQ on EU Cyber Resilience Act Article 64 penalties: maximum fine tiers, turnover caps, national enforcement, economic operators, reporting duties, and open-source steward carve-outs.

CRA Product Families FAQ | Variants, Shared Assessments, Family Reuse, Conformity Scope

CRA FAQ on product families, variant grouping, shared technical documentation, conformity evidence, and when cybersecurity-relevant differences need separate assessment.

CRA Products With Digital Elements Scope FAQ

EU Cyber Resilience Act FAQ on products with digital elements, software, firmware, remote data processing, components, exclusions, market placement, and CRA operator boundaries.

CRA Remote Data Processing Solutions FAQ | Product Scope, Cloud and Backend Boundaries

FAQ on how the EU Cyber Resilience Act treats remote data processing solutions, manufacturer-controlled backends, third-party cloud services, SaaS, risk assessment, documentation, and user information.

CRA Reporting Obligations FAQ | Article 14, CSIRTs, ENISA, User Notices

Cyber Resilience Act FAQ on Article 14 reporting for actively exploited vulnerabilities and severe incidents, including timing, CSIRT routing, ENISA access, user notices, and evidence.

CRA Secure-by-Default FAQ | Default Configuration and Annex I Controls

Cyber Resilience Act FAQ on secure-by-default configuration, automatic security updates, attack surface reduction, authentication, data minimisation, user information, and tailor-made products.

CRA Security Updates vs Functionality Updates FAQ

Cyber Resilience Act FAQ on classifying security updates, functionality updates, support-period duties, automatic updates, user notices, and substantial-modification review.

CRA Substantial Modification FAQ | Updates, Repairs, Manufacturer Duties

Cyber Resilience Act FAQ on when software updates, repairs, spare parts, and post-market changes become substantial modifications and trigger CRA manufacturer, evidence, and conformity duties.

CRA Tailor-Made Products FAQ | Bespoke Products, Market Placement, Evidence

FAQ on when a bespoke product may be treated as tailor-made under the EU Cyber Resilience Act, what the carve-out changes, and what manufacturers still need to document.

CRA Technical Documentation FAQ | Annex VII Evidence and Technical File

CRA FAQ explaining Annex VII technical documentation, risk assessment evidence, conformity assessment files, vulnerability handling records, product families, RDPS, language, and authority access.

CRA Transition Period FAQ | Entry Into Force, Application Dates, Reporting, Legacy Products

CRA FAQ on the transition period covering entry into force, 2026 reporting, 2027 application, legacy products, stock, customs timing, and software versions.

CRA Update Availability and Software Archives FAQ

FAQ on CRA security-update availability, support-period notices, optional public software archives, historical versions, and Article 13(10) software-version limits.

CRA User Information and Transparency FAQ | Annex II Instructions

Practical CRA FAQ on Annex II user instructions, support-period disclosure, vulnerability contacts, update notices, importer and distributor information.

CRA Vulnerability Handling FAQ | Support Periods, Components, Reporting

Practical CRA FAQ on vulnerability handling: SBOMs, remediation, coordinated disclosure, component issues, security updates, support periods, Article 14 reporting, and user notices.

Cyber Resilience Act Module A FAQ | Internal Production Control

FAQ on when CRA Module A internal production control is available, when it is blocked, and what documentation, testing, standards, and evidence it still requires.

EU Cyber Resilience Act Core Functionality FAQ | CRA Product Classification

CRA FAQ on core functionality, product boundaries, remote data processing, integrated components, ancillary functions, and software changes that affect product classification.

EU Cyber Resilience Act Repairs and Spare Parts FAQ

CRA FAQ for repairs, spare parts, legacy products, security updates, substantial modification, and responsibility after product changes.

CRA Applicability Test for Products With Digital Elements

Check whether the EU Cyber Resilience Act applies to a hardware, software, firmware, open-source, or connected product before conformity planning.

CRA Article 14 Reporting Obligations for Vulnerabilities and Incidents

Article 14 guide to CRA reports for actively exploited vulnerabilities and severe product-security incidents, including deadlines, CSIRT routing, users, and evidence.

CRA Conformity Assessment and CE Marking

How to choose a Cyber Resilience Act conformity route, prepare technical documentation, issue the EU declaration of conformity, and affix CE marking.

CRA deadlines and compliance calendar | EU Cyber Resilience Act

Track the Cyber Resilience Act entry into force, staged application dates, Article 14 reporting deadlines, transitional rules, and review dates.

CRA Essential Cybersecurity Requirements in Annex I

A source-grounded guide to the Cyber Resilience Act Annex I requirements for product security, vulnerability handling, secure-by-design controls, documentation, and evidence.

CRA Penalties and Fines: Article 64 Caps and Enforcement Context

Article 64 of the EU Cyber Resilience Act sets administrative fine ceilings for Annex I, manufacturer, reporting, economic-operator, notified-body, and information-request breaches.

CRA Products with Digital Elements Scope | EU Cyber Resilience Act

Apply the EU Cyber Resilience Act scope test for software, hardware, remote data processing, components, open-source software, exclusions, and economic-operator roles.

CRA Requirements | Annex I, Manufacturer Duties and CE Evidence

Map Cyber Resilience Act requirements from Annex I to manufacturer duties, vulnerability handling, user information, technical documentation, declaration of conformity, and CE marking evidence.

CRA SBOM and Vulnerability Management Template

Build a CRA-ready SBOM and vulnerability handling record with component inventory, triage, remediation, disclosure, reporting, update, and technical documentation fields.

CRA vs RED Cybersecurity Delegated Act

Compare the EU Cyber Resilience Act with the RED cybersecurity delegated act for connected and radio equipment, including scope, timing, evidence, and transition treatment.

CRA Vulnerability Handling and Disclosure | Article 14 Reporting and Security Updates

How EU Cyber Resilience Act manufacturers should run vulnerability intake, remediation, coordinated disclosure, Article 14 reporting, secure updates, and evidence records.

EU CRA Compliance Program for Manufacturers and Economic Operators

Build a Cyber Resilience Act compliance program around product scope, Annex I security requirements, conformity assessment, technical documentation, vulnerability reporting, and market surveillance.

EU CRA vs UK PSTI Product Security Regime

Compare EU Cyber Resilience Act and UK PSTI product-security scope, duties, evidence, dates, actors, and enforcement for connected products.

EU Cyber Resilience Act Checklist for Product Security and CE Marking

A CRA checklist for products with digital elements: scope, Annex I security controls, vulnerability handling, Article 14 reporting, technical documentation, conformity assessment, CE marking, and support-period evidence.

EU Cyber Resilience Act FAQ

Direct CRA FAQ answers on scope, economic-operator roles, essential requirements, vulnerability reporting, conformity assessment, CE marking, support periods, and market surveillance.

EU Cyber Resilience Act Technical Documentation and Audit File

Build a CRA technical file around Article 31 and Annex VII: product scope, risk assessment, vulnerability handling, conformity evidence, testing, updates, and retention.