The Nine Things Your Product Must Ship With: CRA Annex II, Item by Item

Most CRA compliance effort goes where the engineering is: the risk assessment, the SBOM pipeline, the vulnerability-handling process. Then, a week before the product ships, someone remembers that the regulation also prescribes what the user must receive — and a developer is asked to "write the security page" overnight.

That page is Annex II, and it is not optional garnish. Article 13(18) requires every product with digital elements to be accompanied by the information and instructions set out in Annex II, in paper or electronic form, in language users and market-surveillance authorities can easily understand. It must stay available for at least ten years after the product is placed on the market or for the support period, whichever is longer. And because it sits inside Article 13, failures here fall into the top penalty tier — up to EUR 15 million or 2.5% of worldwide annual turnover (Article 64(2)).

Annex II has nine items. Here is what each one actually requires, and what a good implementation looks like.

1. Who Makes the Product

The name, registered trade name or trademark of the manufacturer, plus a postal address, an email address or other digital contact, and, where available, a website.

Straightforward, with one trap: this must identify the manufacturer in the CRA sense — the entity that places the product on the market under its name (Article 3(13)). For white-label and OEM arrangements, that is the brand on the box, not the factory. If you are unsure which entity that is in your supply chain, work it out first; the Annex II page is a public commitment to the answer.

Article 13(16) additionally requires this contact information on the product itself, its packaging, or an accompanying document — Annex II repeats it in the user information.

2. Where to Report Vulnerabilities

The single point of contact where vulnerabilities can be reported and received, and where the coordinated vulnerability disclosure policy can be found.

This is the user-facing end of the PSIRT and CVD infrastructure you are required to run anyway (Annex I, Part II(5); Article 13(17)). The point of contact must enable direct and rapid communication. In practice: a monitored security@ mailbox or submission form, plus a public link to your CVD policy. A contact-form black hole that answers in three weeks does not meet the "rapid" bar.

3. What the Product Is

Name, type, and any additional information enabling unique identification of the product.

Pair this with Article 13(15), which requires a type, batch, or serial number on the product, its packaging, or accompanying documentation. For software, the practical reading is name plus version scheme — a user reading a security advisory must be able to tell whether their installation is affected. If your advisories say "affects versions 4.2.0–4.7.3" but the product UI nowhere shows a version, item 3 is not doing its job.

4. Intended Purpose and Security Properties

The intended purpose, including the security environment provided by the manufacturer, essential functionalities, and information about the security properties.

This is the item with the longest legal shadow. The intended purpose you state here anchors your risk assessment (Article 13(3)), your classification reasoning, and the boundary of your responsibility. Describe what the product is for, the security environment you assume (for example: "designed for deployment behind a corporate firewall; not hardened for direct internet exposure"), and the security properties users can rely on — encryption at rest, signed updates, role-based access.

Write it carefully: claims made here are claims a market-surveillance authority can test.

5. Known Risk Circumstances

Any known or foreseeable circumstance, related to intended use or reasonably foreseeable misuse, which may lead to significant cybersecurity risks.

The honest-warnings item. If running the device with the default admin interface exposed to the internet is dangerous, say so. If disabling update checks leaves the product unprotected, say so. The regulation explicitly includes reasonably foreseeable misuse — the question is not "what do we recommend?" but "what will real users predictably do, and what should they know before they do it?"

6. Where the Declaration of Conformity Lives

Where applicable, the internet address at which the EU declaration of conformity can be accessed.

Article 13(20) gives you the choice: ship a full copy of the EU Declaration of Conformity with the product, or ship the simplified declaration (Annex VI) — which must contain the exact internet address where the full declaration can be found. If you take the URL route, treat that URL as production infrastructure: it must resolve, publicly, for the life of the obligation. A DoC link that 404s is a visible, trivially checkable non-conformity.

7. Support: What Kind, and Until When

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 security updates.

Two commitments in one item: what support looks like (security updates only? full technical support?) and until when — a real end date. Article 13(19) adds that the end date, including at least the month and year, must be clear at the time of purchase. How to choose and defend the support period is its own topic; Annex II(7) is where the decision becomes public.

8. Security Instructions Across the Lifecycle

Detailed instructions — or an internet address pointing to them — covering six areas.

This is the largest item, and the closest thing the CRA has to a required security manual:

• (a) Secure commissioning and use — the measures needed at initial setup and throughout the product's lifetime: change default credentials, enable MFA, network placement.
• (b) How changes affect data security — what configuration changes or updates mean for the security of user data.
• (c) How to install security updates — even if updates are automatic, describe the mechanism.
• (d) Secure decommissioning — how to retire the product and, specifically, how user data can be securely removed. Frequently forgotten, explicitly required.
• (e) How to turn off automatic security updates — Annex I, Part I(2)(c) requires, where applicable, automatic security updates enabled as a default setting with a clear and easy-to-use opt-out; this item requires you to document where that opt-out is.
• (f) Integrator information — where the product is intended for integration into other products, the information the integrator needs to comply with Annex I and the Annex VII documentation duties. If you sell components, SDKs, or modules, item 8(f) is effectively your compliance datasheet, and your B2B customers will start demanding it as a purchase condition.

9. Where the SBOM Is (If You Publish It)

If the manufacturer decides to make the software bill of materials available to the user: where it can be accessed.

Note what this does not say: the CRA does not require you to publish your SBOM. The SBOM must exist (Annex I, Part II(1)), lives in the technical documentation, and goes to market-surveillance authorities on reasoned request — but user disclosure is a choice. If you make that choice, Annex II(9) requires you to say where it lives.

Practical Drafting Notes

One page, versioned, in the repo. The cleanest implementations treat the Annex II information as a single versioned document (or web page) per product, reviewed whenever the product, support period, or security properties change. Remember the retention rule: available for ten years or the support period, whichever is longer — including online availability if you publish it online (Article 13(18)).

Language. "A language which can be easily understood by users and market surveillance authorities" means, in practice, the languages of the markets you sell into. Budget for translation; a Germany-market product with English-only security instructions is an easy finding for an authority.

Do not write cheques the product cannot cash. Every statement in items 4, 5, 7, and 8 is verifiable against the product's actual behaviour. The document must describe the product you ship, not the product the marketing site describes.

How Seentrix Fits In

Seentrix generates the Annex II information pack from data you already maintain in the platform — manufacturer identity, product identification, intended purpose from the risk assessment, the support-period end date, the vulnerability-reporting contact, and the public DoC URL the platform already hosts. When one of those facts changes, the pack is flagged stale instead of quietly drifting out of date.

The prose that only you can write — the honest risk warnings, the lifecycle instructions that match how your product actually behaves — stays yours. The platform's job is to make sure the nine boxes are all present, current, and consistent with the rest of your technical file.