Search every question across sub-FAQs

No.

Recital 40 says that where a hardware product, such as a smartphone, is not compatible with the latest version of the operating system it was originally delivered with, the manufacturer should continue to provide security updates at least for the latest compatible version for the support period. So Article 13(10) does not let the manufacturer point users to an upgrade path that the hardware cannot actually use and then stop supporting the compatible branch.

Keep evidence that proves the specific CRA duties on this page, without inventing a separate archive-retention period.

Useful records include the declared support-period end date shown at purchase, release notes and advisory messages for each security update, the update-channel or download record showing the issued update remains available, the fixed-vulnerability disclosure content required by Annex I Part II point (4), and the Article 13(10) analysis showing whether earlier-version users had free access to the latest placed version without additional hardware or software-environment costs.

Not necessarily.

Inference from Articles 13(9) and 13(11): the mandatory rule is to keep security updates available to users, while public software archives are only an optional way to enhance access to historical versions. The CRA therefore does not state that every retained security update must be published in a public archive open to anyone, even though a manufacturer may choose to make updates available that way.

Yes. Manufacturers must accompany products with digital elements with the information and instructions listed in Annex II, either on paper or electronically.

For a visitor reviewing a product page or manual, the practical test is simple: can a user identify the product, contact the manufacturer, report vulnerabilities, understand the intended secure use, install security updates, decommission the product securely, and see the security support period? If those answers are missing, the Annex II pack is incomplete.

Article 13(18) requires the instructions to be clear, understandable, intelligible and legible. They must also be in a language easily understood by users and market surveillance authorities.

For online instructions, the manufacturer must keep them accessible, user-friendly, and available online for at least 10 years after the product is placed on the market or for the support period, whichever is longer. That makes a stable support page, versioned manual, or durable documentation URL more useful than a temporary campaign page.

Annex II requires a practical user information set, not just legal boilerplate. It includes manufacturer identity and contact details; a vulnerability reporting point of contact and the coordinated vulnerability disclosure policy location; product name, type, and unique identification information; intended purpose, security environment, essential functionality, and security properties; significant cybersecurity risks from intended use or reasonably foreseeable misuse; the EU declaration of conformity address where applicable; technical security support and support end date; instructions for commissioning, secure use, updates, decommissioning, automatic-update opt-out, and integration; and SBOM access information if the manufacturer chooses to make the SBOM available to users.

A useful CRA-facing manual should turn those legal categories into product-specific instructions. For example, do not only say "install updates securely"; state where update notices appear, how to verify update authenticity, what happens if automatic updates are disabled, and what administrators should do before decommissioning.

Users must be able to see the manufacturer's name, registered trade name or trademark, postal address, email address or other digital contact details, and, where applicable, website.

Article 13(16) puts that information on the product, packaging, or accompanying document. Annex II point 1 also makes it part of the user instructions. In practice, the product page, manual, package insert, and support site should not disagree about the responsible manufacturer contact.

Annex II requires the single point of contact where vulnerability information can be reported and received, and where the manufacturer's coordinated vulnerability disclosure policy can be found.

Recital 63 explains the practical quality bar: the contact should let users communicate directly and rapidly with the manufacturer, should be easily accessible, and should not rely exclusively on automated tools. A bare no-reply form or generic sales address is unlikely to be a good operational answer if it does not route vulnerability reports to people who can triage them.

Yes. Article 13(19) requires the end date of the support period to be clearly and understandably specified at the time of purchase, in an easily accessible manner, and at least by month and year.

Annex II point 7 separately requires the product to be accompanied by the type of technical security support offered and the end date of the support period during which users can expect vulnerabilities to be handled and to receive security updates. For ecommerce, procurement, and channel sales, that means the support end date should be visible before the buyer commits, not hidden inside post-purchase onboarding.

Yes, where technically feasible in light of the nature of the product. Article 13(19) requires manufacturers to display a notification to users informing them that the product has reached the end of its support period.

The notice should be tied to the product experience or an equivalent user communication channel where the product has no direct interface. Recital 56 says manufacturers should use a user interface or similar technical means where the product has one, and that notifications should be limited to what is necessary to ensure effective reception without harming the user experience.

Annex II requires instructions on how security-relevant updates can be installed. It also requires instructions on how to turn off the default setting enabling automatic installation of security updates where that default setting exists.

Annex I adds two visitor-relevant points. First, where security updates are available to address identified security issues, they must be disseminated without delay and, except for the tailor-made business-user exception, free of charge. Second, those updates must be accompanied by advisory messages that give users relevant information, including potential action to take.

Yes. Annex II requires information on secure decommissioning of the product, including how user data can be securely removed.

That answer is especially important for connected products, appliances, industrial devices, gateways, and software accounts that may retain credentials, keys, logs, configuration, or user content. A useful instruction set should tell users what can be erased, what cannot be erased locally, what must be revoked in a cloud console, and how to confirm the product is no longer connected.

After becoming aware of an actively exploited vulnerability or a severe incident having an impact on the security of the product, the manufacturer must inform impacted users and, where appropriate, all users. The notice must cover the vulnerability or incident and, where necessary, the risk mitigation and corrective measures users can deploy.

This is not the same as publishing every vulnerability detail to the whole internet. Article 14(8) is aimed at getting actionable information to impacted users. The CRA also says the information should be provided, where appropriate, in a structured, machine-readable format that is easily automatically processable.

Yes, with an important timing qualification. Annex I Part II point 4 requires manufacturers, once a security update has been made available, to share and publicly disclose information about fixed vulnerabilities, including affected product identification, impact, severity, and clear remediation information.

The same point allows delayed public disclosure in duly justified cases where the manufacturer considers the security risks of publication to outweigh the security benefits, until users have had the possibility to apply the relevant patch. That makes patch availability, advisory wording, and customer notification timing part of the same transparency workflow.

No general user publication duty appears in these provisions. The CRA requires manufacturers to draw up technical documentation, keep it available for market surveillance authorities, and update it where appropriate. Annex VII lists user information and instructions as part of the technical documentation, but it does not turn the whole technical file into a public user document.

For user-facing transparency, focus on the specific disclosures the CRA does require: Annex II instructions, support-period information, vulnerability contact details, EU declaration access where applicable, security-update advisories, fixed-vulnerability disclosures, and Article 14(8) user notices.

Yes. The manufacturer must either accompany the product with a copy of the EU declaration of conformity or provide a simplified EU declaration of conformity.

If a simplified declaration is used, Article 13(20) requires the exact internet address where the full EU declaration can be accessed. Annex II point 6 also requires the internet address for the EU declaration of conformity where applicable.

Importers must check that the product bears CE marking, is accompanied by the EU declaration of conformity and Annex II user information in a language easily understood by users and market surveillance authorities, and that the manufacturer has met the CRA obligations on CE marking, manufacturer contact details, and support-period purchase disclosure.

Importers also have their own user-facing contact duty. They must indicate their name, registered trade name or trademark, postal address, email address or other digital contact, and website where applicable on the product, packaging, or accompanying document. The contact details must be in a language easily understood by users and market surveillance authorities.

Distributors must act with due care and verify that the product bears CE marking and that the manufacturer and importer have met specified transparency and document obligations, including manufacturer identification, Annex II user instructions, purchase-time support-period disclosure, EU declaration access, and importer contact details.

A distributor that knows, based on information it has, that the manufacturer has ceased operations and can no longer comply with the CRA must inform relevant market surveillance authorities without undue delay and, by any available means and to the extent possible, users of the products placed on the market.

An importer or distributor is treated as a manufacturer under the CRA when it places a product with digital elements on the market under its own name or trademark, or carries out a substantial modification of a product already placed on the market.

That matters for user information because the Article 13 and Article 14 duties then attach to that importer or distributor as the manufacturer-equivalent actor. Private-label products and materially modified products therefore need the same support-period, contact, vulnerability reporting, update, and user-notice planning as original manufacturer products.

Check the product page, purchase flow, package, manual, support portal, release notes, vulnerability disclosure page, and update channel together. The same product identity, manufacturer contact, vulnerability contact, support end date, EU declaration location, and security-update instructions should be consistent across all of them.

Then check the risky-use content against the cybersecurity risk assessment. If secure use depends on conditions such as a protected network, trained administrator, supported integration pattern, enabled automatic updates, or timely patching, the user information should say so in language the expected user can act on.