Search every question across sub-FAQs

Where a substantial modification may affect CRA compliance or changes intended purpose, compliance should be verified again and, where applicable, the product should undergo a new conformity assessment.

If a third-party conformity assessment was used, a change that might lead to a substantial modification should be notified to the third party where applicable.

No. Existing tests and documentation can be reused for parts of the product that are not affected by the substantial modification.

The person placing the modified product on the market must still update the technical documentation for impacted requirements, demonstrate why unchanged parts do not need new evidence, take responsibility for the modified product's conformity, and draw the required declaration of conformity.

Keep enough evidence to show the change was assessed against the CRA test rather than only approved as an engineering release.

A useful file links the release scope to the original intended purpose, risk assessment, threat model, affected architecture, Annex I Part I controls, vulnerability-handling impact, user instructions, test results, conformity route, declaration status, and any third-party assessment notification.

Users should receive practical information tied to the actual change: what changed, whether action is needed, any configuration or security-update steps, changed support information, and any known constraints introduced by replacement parts or interoperability measures.

For security updates, the CRA separately requires security updates to be disseminated without delay and accompanied by advisory messages with relevant information, including potential user action. Where technically feasible, new security updates should be provided separately from functionality updates.

Products with digital elements placed on the market before 11 December 2027 are subject to CRA requirements only if, from that date, they are subject to a substantial modification.

The Commission FAQ gives a practical contrast: a non-substantial bug-fix update for a smart TV placed on the market in 2027 does not require bringing that TV into full CRA conformity, but a later update that adds smart-home-control functionality and qualifies as substantial does.

Yes. For products placed on the market before 11 December 2027 where the CRA was not applied at initial placement, the draft guidance says manufacturers must be able to demonstrate to a market surveillance authority that later updates do not constitute substantial modifications.

A cybersecurity risk assessment covering Article 13(2) elements, plus documented compliance reasoning, should make that position easier to support.

The manufacturer must comply with the CRA in its entirety before placing the substantially modified product on the market, and then for the duration of that product's support period.

Teams should treat this as a release gate: confirm product scope, update the risk assessment and technical documentation, choose or confirm the conformity assessment route, prepare conformity evidence, update user information, and confirm vulnerability-handling processes before the modified product is made available.

The CRA defines the Support Period 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 placing on the market and throughout the Support Period. The obligation covers the product in its entirety, including integrated components.

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 Support Period 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.

Article 13(8) requires the Support Period 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 ADCO 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.

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 Support Period.

A shorter Support Period 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.

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 Support Period equal to the duration of the active subscription.

This is not a general rule that all open-source or subscription software can use a short period. 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 Support Period follows the CRA expected-use rule.

For physical products, use the Blue Guide concept of placing on the market: 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 Support Period 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.

The reliable CRA answer is to anchor the analysis in placing on the market, 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.

At the time of purchase, the manufacturer must clearly and understandably specify the end date of the Support Period, 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 Support Period.

During the Support Period, 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.

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

Each security update made available to users during the Support Period 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.

The technical documentation should preserve the information used to determine the Support Period, 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 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 Support Period.

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.