Most of the Cyber Resilience Act's documentation lives in files a user never sees. Annex II is the exception. It prescribes the information and instructions that must reach the user with every product with digital elements, in clear and understandable language, from 11 December 2027. It is the regulation's public interface, and because anyone can check it, including competitors and market surveillance authorities running a desk review, it tends to be where non-compliance is spotted first.
The Annex II sheet also intersects with duties you may already be working on, since it publishes your vulnerability reporting contact and your support period commitment. For the machinery behind those two items, see what manufacturers need to know about vulnerability handling and the SRP reporting form and its data fields. This post works through the sheet itself.
What Annex II requires, item by item
Annex II lists the minimum information and instructions to the user. In practice a conformant sheet covers the following.
- Manufacturer identity. The name, registered trade name or trade mark, and the postal and electronic address where the manufacturer can be contacted, either on the product or, where that is not possible, on the packaging or in the accompanying documentation.
- The vulnerability reporting contact. The single point of contact where vulnerabilities in the product can be reported and received, and where information about the manufacturer's coordinated vulnerability disclosure policy can be found.
- Product identification. Name, type and any additional information enabling unique identification of the product, matching the identifiers used on the Declaration of Conformity.
- Intended purpose and essential functionality. The intended purpose, including the security environment provided by the manufacturer, the product's essential functionalities, and information about its security properties.
- Known risk circumstances. Any known or foreseeable circumstance connected to the use of the product in accordance with its intended purpose or under reasonably foreseeable misuse which may lead to significant cybersecurity risks.
- Where to find the Declaration of Conformity. The internet address where the EU Declaration of Conformity can be accessed, where the simplified route is used.
- Technical security support and the support period. The type of technical security support the manufacturer offers and the end date of the support period during which users can expect vulnerability handling and security updates. This is the item that publishes your Article 13(8) determination.
- Detailed usage instructions. Instructions or an internet address to them, covering the measures needed at initial commissioning and throughout the lifetime to ensure secure use, how security-relevant changes affect the product, how to install security updates, how the product can be securely decommissioned including data removal, and how the default setting enabling automatic updates can be turned off where the product provides it.
- Software bill of materials access. Where the manufacturer decides to make the SBOM available to users, the information on where it can be accessed.
Where the information must live
Annex II information accompanies the product. For hardware that means printed material, an insert or durable on-device access. For software it means the documentation delivered with the download or accessible from within the product. The regulation permits an internet address for the detailed instructions, and most manufacturers publish a per-product security information page and reference it from the packaging or installer. Two constraints shape the choice. The information must be available in a language users in the target market can understand, and it must remain available for the support period, so the page carries the same longevity obligation as the simplified Declaration of Conformity link.
Clarity is a legal requirement rather than a style preference. Annex II information must be clear, understandable, intelligible and legible. A sheet written in the register of a warranty disclaimer fails the intent of the annex even where every item is technically present.
The support period disclosure
The end date of the support period is the single most consequential line on the sheet. It converts your internal Article 13(8) determination into a public commitment that users, buyers and authorities can hold you to, expressed as a date rather than a duration so there is no ambiguity about when it runs out. Procurement teams have started comparing these dates across vendors, which makes the disclosure a competitive statement as well as a compliance one. State it per product and version family, align it with the determination documented in your technical file, and update the published date if you extend support, never the other way around, since shortening a published period after sale invites both regulatory and contractual trouble.
How security.txt complements the SPOC disclosure
Annex II requires the vulnerability reporting contact in the user documentation. RFC 9116 puts the same fact where security researchers actually look, in a security.txt file at a well-known URL on your domain. The two serve different audiences and the strong pattern is to keep them identical. The Annex II sheet names the contact and links the CVD policy, and the security.txt file carries the same contact, the policy link and, as a useful extension, machine-readable support period hints for the product domains you operate. Divergence between the two is a small signal with outsized effect, because it tells a reviewer the disclosure process is maintained in one place and decorated in another.
The mistakes that surface first
Reviewing published sheets against Annex II, the same failures recur.
- The buried SPOC. The reporting contact exists but sits behind a generic support form that routes to sales. The annex requires a contact where vulnerabilities can be reported and received, and a triage-blind funnel does not receive them in any meaningful sense.
- The missing end date. The sheet promises security updates without stating when the commitment ends. An open-ended phrase like "for the supported lifetime" fails the requirement, which asks for the end date.
- Marketing language where instructions belong. Security properties described as selling points, with no commissioning guidance, no update installation steps and no decommissioning procedure.
- Version drift. The sheet describes an earlier hardware revision or software major version, breaking the unique identification chain to the Declaration of Conformity.
- The forgotten misuse item. The known-risk-circumstances item is omitted entirely because writing it requires admitting foreseeable misuse exists. Authorities read its absence as an incomplete risk assessment, not as a clean product.
What this means for manufacturers
Treat the Annex II sheet as a generated artifact rather than a written one. Every item on it restates something that should already exist in your compliance record, the SPOC from your CVD policy, the support end date from your Article 13(8) determination, the identifiers from your Declaration of Conformity, the instructions from your secure deployment documentation. Generating the sheet from those sources keeps it consistent as products evolve, and inconsistency is what reviewers probe first. Work from the Annex II explainer for the legal text and the user information template for a structure you can fill per product, and review the published sheet whenever the underlying determinations change.