The information you must ship with the product

If you have read the four-document version of CRA compliance — risk assessment, technical documentation, declaration of conformity, SBOM — you have read an incomplete list. The regulation requires information and instructions to accompany the product, in an easily understood language, and requires that information to be part of the documentation you retain. It is also, as it happens, the easiest of the five to produce, because most of it is facts you already know.

The nine points

Seven of the nine are facts you have already collected for the other documents. Points 5 and 8 are the ones that need original writing. That is why this is the cheapest of the five artefacts to produce — and why its absence from most vendors' feature lists is odd.

Point 2: the contact and the disclosure policy

Point 2 has two halves and both are commitments rather than statements.

The single point of contact is where a researcher, a customer or a national CSIRT sends you a vulnerability report. Article 13 separately requires manufacturers to designate a single point of contact enabling users to communicate directly and rapidly with them. Two practical tests: does the address reach a human who will act, and does it still work when the person who set it up has left?

The coordinated vulnerability disclosure policy has to exist, because Annex I Part II requires a policy on coordinated vulnerability disclosure to be in place, and Annex VII point 2(b) names it as part of the technical documentation. Point 2 is about telling users where to find it.

A workable policy is short. What it needs to say: where to report, what you will acknowledge and in what time, how you will handle the report, whether you will credit the reporter, and what you ask of them in return — usually a period before public disclosure. It does not need to be long to be credible; it needs to be specific and to be honoured.

Point 7: the support-period end date, stated twice

Point 7 requires the type of technical security support and the end date of the support period. It is worth separating this from the related duty in Article 13, because they are not the same obligation and satisfying one does not satisfy the other.

That second one has a commercial consequence people miss: the support-period end date has to be visible on the thing a customer buys from — the product page, the datasheet, the storefront listing. Burying it in a PDF manual shipped in the box does not meet a duty expressed as “at the time of purchase”.

And the number itself is a decision with a long tail. The support period must reflect how long the product is expected to be in use and must be at least five years unless the product is expected to be in use for less. Choosing a generous fifteen years is good for customers and good for marketing, and it silently extends your document-retention obligations to match. Decide it on purpose.

Point 8: the URL clause, and the decade attached to it

Point 8 requires detailed instructions on the security-relevant aspects of the product — broadly how to install, operate and maintain it securely, how updates are delivered, what the secure configuration is, and what to do at end of support. It also contains the most convenient permission in the whole regulation: those instructions may be provided by giving an internet address at which they can be found.

That is a genuine simplification. It means you do not have to print a security manual and put it in the box, and you can correct the instructions without reprinting anything.

Point 9: the SBOM clause is conditional

Point 9 is the most commonly misreported provision in the annex. It applies “if the manufacturer decides to make available the software bill of materials to the user” — and then requires you to say where and how it can be accessed.

So the duty is not “publish your SBOM”. The duty is “if you publish it, tell people where”. You will see the stronger claim made confidently; it is not what the text says.

The genuinely mandatory SBOM duties sit elsewhere: it belongs in your technical documentation, and it must be provided to a market surveillance authority further to a reasoned request. Whether your customers get it is a business decision — and there are real arguments both ways, which the SBOM page goes through.

“Easily understood” and what that means for translation

The information and instructions must accompany the product in a language easily understood by users, as determined by the Member State concerned.

This is a familiar mechanism in EU product law and it does not mean twenty-four languages. It means the language question is decided by the Member States where you actually place the product on the market. If you sell into Germany, that is German. If you sell into Germany and France, that is two languages. If you sell into one Member State whose authorities accept English for your category of professional product, that may be English.

Two planning consequences. First, this is a cost that scales with your market list, not with your product — and it is a reason to be deliberate about which Member States you actually sell into rather than defaulting to “the EU”. Second, it makes point 8's URL permission more valuable than it first appears: hosting the instructions means adding a language is publishing a page, not reprinting an insert.

The separate ten-year duty

The user information carries its own retention duty: it must remain at the disposal of users and market surveillance authorities for at least ten years after the product is placed on the market.

This is a third clock, distinct from the one on the technical documentation and the one that runs separately on each security update. It is the reason a single live web page is not a compliance strategy: the current version of your instructions is not evidence of what you told the buyer of a 2027 unit. Version the information, date each version, and keep the old ones.

What to actually produce

One document, not nine. A single “security information and instructions” page or PDF covering all nine points, versioned and dated, with:

1. A permanent home. One URL you commit to, cited by point 8 and by the simplified declaration of conformity.
2. The support end date at the top, as a date, not a duration — and the same date repeated wherever the product is sold, to satisfy the separate at-time-of-purchase duty.
3. A real reporting address and a link to the disclosure policy.
4. An honest misuse section. Point 5 asks what foreseeable misuse creates significant cybersecurity risk. Default credentials left unchanged, exposing an admin interface to the internet, running it outside the security environment it was designed for — write down the ones that apply to your product.
5. A dated version history, and no overwriting.
6. The SBOM line only if you have decided to publish it, and omitted if you have not.