CRA user information generator for apps

The information and instructions Annex II of the Cyber Resilience Act requires, as a page you can publish for one app.

Every product under the CRA must come with information and instructions for its users: who the manufacturer is, where to report vulnerabilities, what the product is for, its known risks, until when it gets security updates, and how to use, update and remove it securely (Article 13(18) and Annex II). Fill in the nine points below and get a Markdown and an HTML page to publish and link from your store listing and from the app.

1 The manufacturer

The company that places the app on the market under its own name, usually the client rather than the agency (see who the manufacturer is).

Name, trade name or trademark Postal address Email or other digital contact Website (where available)

2 Reporting vulnerabilities Single point of contact for vulnerabilities Where your disclosure policy can be found

No policy yet? The security.txt generator writes one, and the disclosure policy guide explains it.

3 The app App name Type of product Version or versions covered Identifiers (recommended)

Annex II asks for any additional information that allows the product to be uniquely identified. Store IDs and bundle or package names do that for an app.

4 Intended purpose and security Intended purpose Essential functions Security environment: where it is meant to run Security properties

State what is true for this app and version only. These lines tell users what they can rely on.

5 Known or foreseeable risks Circumstances that may lead to significant cybersecurity risks

Annex II covers both intended use and reasonably foreseeable misuse. Your risk assessment should already list them; repeat the ones users can act on.

6 EU declaration of conformity Internet address of the declaration (where applicable)

Leave empty if you do not have it yet. The page will mark the point as still to add.

7 Security support Type of technical security support End of the support period (month and year)

Article 13(19) asks for at least the month and year, clear at the time of purchase. Not sure? The support period calculator works it out.

8 Instructions for secure use

Starting text for a typical store-distributed app. Edit each one so it describes what your app really does.

(a) First use and use over time (b) How changes can affect the security of data (c) How to install security updates (d) Removing the app and your data securely (e) How to turn off automatic security updates This product is meant to be integrated into other products (for example an SDK or library)

9 Software bill of materials (optional) Where users can access the SBOM

Only if you decide to make the SBOM available to users. You must have one either way (Annex I, Part II, point 1); the SBOM scanner makes one from a lockfile.

What the CRA asks

Rule	What it means for an app
Content Annex II, points 1 to 9	Manufacturer and contact, vulnerability contact and disclosure policy, product identification, intended purpose and security properties, foreseeable risks, the address of the EU declaration of conformity where applicable, the type of security support and its end date, the instructions in point 8, and the SBOM location if you choose to share it.
Form and language Article 13(18)	Paper or electronic, in a language easily understood by users and market surveillance authorities of the countries where the app is available. Clear, understandable, intelligible and legible.
How long it stays available Article 13(18)	At least 10 years after the product is placed on the market, or the support period if longer. Online information must be accessible, user-friendly and online for that whole time.
Vulnerability contact Article 13(17)	A single point of contact, easy to identify, and users choose how to communicate: not only automated tools.
End of support Article 13(19)	The end date, at least month and year, clearly stated at the time of purchase and easy to find. Where technically feasible, users are told when support has ended.

Where to publish it for an app

Our suggestion, for apps distributed through the stores: publish the page on the manufacturer's website at a stable address, link it from the store listing (the support or website link) and from an About or Security entry in the app's settings, and repeat the end of support date in the store description, where people see it before they install. Keep one page per supported version line, and keep old pages online for the period in Article 13(18) instead of overwriting them. Translate the page for every country where the app is offered in another language.

The requirements apply from 11 December 2027 (Article 71(2)). Writing the page now makes it part of the release routine before it becomes an obligation.

Maintaining apps for clients? Shipmark keeps the SBOM, daily vulnerability checks and the support period for every client app in one place. Founding agencies use it free until 1 April 2027.

Join the free beta

Sources

Regulation (EU) 2024/2847, Annex II: Information and instructions to the user (SpringLex copy of OJ L 2024/2847).
Regulation (EU) 2024/2847, Article 13: paragraphs 16 to 19 (SpringLex copy of OJ L 2024/2847).
Regulation (EU) 2024/2847 (Cyber Resilience Act), EUR-Lex: the authentic text.

The generator runs in your browser and stores nothing: what you type is not saved or sent anywhere. The starting texts are examples for a typical store-distributed app, not statements about your app; check every line before you publish. Not legal advice. Related: How long must you support an app? · Annex I checklist · Does the CRA apply to mobile apps?