User documentation

CRA Annex II: The User-Facing Documentation You Must Ship With Your Product

Last updated · July 13, 2026

Most CRA documentation conversations focus on the technical file - the internal evidence package you keep for market surveillance authorities. That's Annex VII. Annex II is different, and it's the one your product, technical-writing, and compliance teams need to own together. It governs what you publish to users, and it has to ship with the product.

This guide covers what Annex II requires, how to present it, how long to keep it available, and how to produce it without creating a parallel documentation universe.

TL;DR — Annex II of Regulation (EU) 2024/2847 lists the security information manufacturers must provide to users when placing a product on the EU market. It is distinct from Annex VII (the internal technical file). The obligation sits in Article 13 and is enforceable from 11 December 2027. The information must be kept available to users and market surveillance authorities for at least 10 years after market placement, or the support period — whichever is longer.

Annex II vs Annex VII: the distinction that matters

These two annexes are frequently conflated. They serve completely different audiences and purposes.

	Annex II	Annex VII
What it is	Information and instructions to the user	Content of the technical documentation
Primary audience	Users of the product; also readable by market surveillance authorities	Market surveillance authorities; kept internal
How it is delivered	Shipped with the product — paper or electronic; must remain available online if provided that way	Retained by the manufacturer; provided to authorities on reasoned request
Legal hook	Article 13 (manufacturer obligations)	Article 31 (technical documentation)
Retention period	At least 10 years after market placement, or the support period — whichever is longer	At least 10 years after market placement, or the support period — whichever is longer
Relationship between them	Annex VII must include a copy of the Annex II user information as part of the general product description	Annex VII references Annex II — they are complementary, not interchangeable

The practical upshot: Annex VII is your internal evidence file. Annex II is your public-facing security documentation. Both matter, but they go to different places and serve different readers.

Note also that Annex II is separate from the EU Declaration of Conformity (Annex V) and from CE marking. The Declaration is a legal statement of conformity; Annex II is operational guidance for the people actually using the product.

What Annex II requires: a practical checklist

Annex II of Regulation (EU) 2024/2847 lists 14 specific categories of information manufacturers must communicate to users. The regulation groups them loosely; the checklist below organises them into four logical clusters to make production easier.

1. Who you are and how to reach you

Manufacturer identity: name, registered trade name or registered trademark, and postal address - or, where the manufacturer is not established in the EU, the name and address of the authorised representative or importer.
Contact for vulnerabilities: Annex II requires manufacturers to publish the single point of contact where information about vulnerabilities of the product can be reported and received. This is the same contact that must appear in your coordinated vulnerability disclosure (CVD) policy - not a generic support inbox, but a channel specifically for security reports.
CVD policy location: a reference to where the manufacturer's policy on coordinated vulnerability disclosure can be found. In practice, a URL to your published CVD page is sufficient.

Practical note: The single point of contact and the CVD policy URL are two of the most commonly missed items in early drafts. They are also the items most likely to be checked first by a market surveillance authority, because they are easy to verify and directly linked to the vulnerability-handling obligations in Annex I, Part II.

2. Product identification

Name, type, and unique identifiers: name and type and any additional information enabling the unique identification of the product - batch number, serial number, or version number as applicable.
Intended purpose, essential functions, and security properties: a description of what the product is for, what it does, and what security properties it has been designed to provide.
Assumed security environment: the operational environment in which the product is intended to be used, including any assumptions about the surrounding infrastructure or user behaviour that the security design depends on.

3. Risk and support information

Known and foreseeable cybersecurity risks: Annex II requires manufacturers to disclose any known or foreseeable circumstance, related to the intended purpose or reasonably foreseeable misuse of the product, which may lead to significant cybersecurity risks. This is not a full risk assessment - that lives in Annex VII. It is a plain-language summary of the risks users need to know about.
Type of technical security support and end date of the support period: Annex II requires manufacturers to state 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. The end date must include at least the month and year, and must be clearly and understandably specified at the time of purchase. The support period itself must be at least five years from the date of market placement, unless the product's expected usable life is shorter.
How security updates are delivered: detailed instructions, or a URL pointing to such instructions, explaining how security updates are obtained and installed.
SBOM access (if applicable): Annex II, point 9, requires manufacturers who decide to make the software bill of materials available to users to state where the SBOM can be accessed. Publishing the SBOM to users is not mandatory - but if you do publish it, the location must appear in the user documentation.

4. Secure use and end of life

Secure commissioning: the necessary measures during initial commissioning to ensure the product is set up securely.
Secure use throughout the lifetime: guidance on how to use the product securely over its operational life, and how changes to the product or its environment may affect its security.
Turning off automatic security updates: Annex II requires manufacturers to explain how the default setting enabling automatic installation of security updates can be turned off, where such a default is required by Annex I. This is relevant where the product ships with automatic updates enabled by default - users must be told how to disable that setting if they need to.
Secure decommissioning: instructions for securely retiring the product, including how user data can be securely removed.
Information for integrators (where applicable): where the product is intended for integration into other products, the information necessary for the integrator to comply with the essential cybersecurity requirements.

Presentation and availability rules

The regulation is explicit about how the information must be presented. Article 13 states that the information and instructions:

must be provided in a language which can be easily understood by users and market surveillance authorities;
must be clear, understandable, intelligible, and legible;
must allow for the secure installation, operation, and use of the product.

The information may be provided in paper or electronic form. If provided online, the manufacturer must ensure it is accessible, user-friendly, and remains available online. Article 13 of the CRA requires manufacturers to keep the Annex II information at the disposal of users and market surveillance authorities for at least 10 years after the product has been placed on the market, or for the support period, whichever is longer. The same retention rule applies whether the documentation is hosted on a product page, a dedicated support portal, or a documentation site.

Don't let your docs go dark. If you host Annex II information online, you are responsible for keeping it accessible for the full retention period — even after the product reaches end of support. Plan your URL structure and hosting accordingly before you publish. A product page that disappears when a product is discontinued is a compliance failure.

How to produce this without reinventing your docs

The good news: most of what Annex II requires maps directly onto documentation that good product teams already produce - or should produce. The gap is usually not content, but structure and completeness.

Here is how the Annex II items map to typical documentation artefacts:

Annex II item	Where it typically lives
Manufacturer identity and contact	Product page, README, packaging
Vulnerability contact and CVD policy URL	security.txt, product security page, README
Product name, type, version, serial	Packaging, about screen, product page
Intended purpose and security properties	Product overview / datasheet
Assumed security environment	Security guide or hardening guide
Known cybersecurity risks	Security guide, release notes
Support type and end date	Product page, purchase flow, support page
How to get security updates	Update guide, release notes
SBOM location (if published)	Security page, documentation index
Secure commissioning	Getting started guide / quick-start
Secure use and configuration changes	Security guide, admin guide
Turning off automatic updates	Admin guide, settings reference
Secure decommissioning	End-of-life guide, admin guide
Integrator information	Integration guide, developer docs

The practical approach is to audit your existing documentation against this table, identify gaps, and fill them - rather than creating a standalone "Annex II document". A well-structured security section in your product manual or a dedicated security guide on your documentation site will satisfy the requirement, provided it covers all the items and meets the presentation rules above.

Link your CVD contact and support end date prominently. These two items are the ones users and regulators are most likely to look for first. Put them somewhere obvious — the top of your security page, the product's main support page, and ideally in the product itself (an about screen or help menu). Don't bury them in a PDF appendix.

The support end date deserves special attention

The end date of the support period is one of the most operationally significant items in Annex II. It must be specified at the time of purchase - meaning it needs to appear in the purchase flow, on the product page, or on packaging, not just in a manual that users read after buying. It must include at least the month and year.

This date is also the anchor for your retention obligations. Once you know the support end date, you know the minimum period for which you must keep the Annex II documentation available.

The relationship to your CVD contact

The single point of contact for vulnerability reports in Annex II is the same contact that underpins your coordinated vulnerability disclosure policy under Annex I, Part II. Publishing it in your user documentation is not just an Annex II obligation - it is also how security researchers and users find their way into your vulnerability handling process. Make sure the contact is monitored, routes to a human, and is consistent across your security.txt file, your CVD policy page, and your product documentation.

Use this widget to check your Annex II coverage

The interactive checklist below lets your team work through each Annex II item and mark it as covered, in progress, or missing - so you can see at a glance where the gaps are before your documentation goes to review.

A note on compliance vs legal advice

This guide explains what Annex II of Regulation (EU) 2024/2847 requires, based on the text of the regulation as published in the Official Journal of the EU and the European Commission's CRA summary. It is not legal advice. The harmonised standards that will provide presumption of conformity with the CRA's requirements are still being developed. For product-specific conformity assessment planning, work with qualified legal counsel and, where required, a notified body.

Stay current as the harmonised standards land. Subscribe to The CRA Brief at /subscribe — a plain-English digest covering CRA developments, standards updates, and practical guidance for product teams building for the EU market.