A Cyber Resilience Act (CRA) Annex II package is the user-facing security information that must accompany a product with digital elements. It is not just a generic manual: the Regulation requires specific manufacturer, product, vulnerability-contact, support-period, security-use, update and decommissioning information so users can install, operate and retire the product securely.
For manufacturers, the practical task is to turn those legal items into a release-controlled information set that stays consistent with the product, the technical documentation and the support commitment.
What Article 13 requires before Annex II is even checked
Article 13(18) requires manufacturers to ensure that products with digital elements are accompanied by the Annex II information and instructions, in paper or electronic form. The information must be provided in a language that can be easily understood by users and market-surveillance authorities, and it must be clear, understandable, intelligible and legible.
The same paragraph sets an operational purpose: the information must allow secure installation, operation and use of the product. That matters because a formally complete list of fields is not enough if users cannot understand how to configure or operate the product securely.
Article 13(18) also creates a long availability obligation. Manufacturers must keep the information and instructions available to users and market-surveillance authorities for at least 10 years after the product is placed on the market or for the support period, whichever is longer. If the information is provided online, it must remain accessible, user-friendly and available online for that same period.
Article 13(19) separately requires the end date of the support period, including at least the month and year, to be clearly and understandably specified at the time of purchase in an easily accessible manner. The support-period end date also appears inside Annex II.
The nine Annex II information groups
Annex II sets a minimum list. A practical manufacturer checklist should map every item to an owner and to the exact product or release it describes.
1. Manufacturer identity and contact details
Provide the manufacturer's name, registered trade name or registered trademark, postal address, email address or other digital contact, and the website where the manufacturer can be contacted when one is available.
This information should match the legal manufacturer shown in the product and conformity records. If different business units operate support channels, the user information should still make the responsible manufacturer unambiguous.
2. Vulnerability reporting contact and CVD policy
Provide the single point of contact where users or researchers can report and receive information about vulnerabilities, and indicate where the manufacturer's coordinated vulnerability disclosure (CVD) policy can be found.
Article 13(17) adds an important detail: the single point of contact must let users choose their preferred means of communication and must not limit communication to automated tools.
Operationally, test this contact route before release. A dead mailbox, inaccessible form or unclear ownership can make an otherwise complete document ineffective.
3. Unique product identification
Provide the product name and type, plus any additional information necessary to identify the product uniquely.
The legal text is deliberately broader than a marketing product name. For software, firmware, hardware variants or products with multiple release trains, manufacturers should decide what combination of model, version, release, build or other identifier lets a user and an authority determine exactly which product the information applies to.
The same identity should be usable in technical documentation, vulnerability records, security advisories and support records.
4. Intended purpose and security properties
Describe the intended purpose of the product, including the security environment provided by the manufacturer, the product's essential functionalities and information about its security properties.
This is where generic brochure language becomes risky. The description should be specific enough to establish the assumptions under which the product is expected to be used securely.
Useful content can include required trust boundaries, expected network environment, administrator responsibilities, authentication assumptions, dependency on external security controls and security-relevant operating modes. These statements should remain consistent with the cybersecurity risk assessment.
5. Known or foreseeable circumstances that can create significant cybersecurity risks
Annex II requires information about known or foreseeable circumstances related to intended use or reasonably foreseeable misuse that may lead to significant cybersecurity risks.
This is not a requirement to publish every internal threat model or vulnerability. The user-facing task is to identify conditions the user needs to understand in order to avoid or control significant risk.
Examples may include exposing an administration interface to an untrusted network, disabling a required authentication mechanism, using unsupported dependencies, operating beyond a defined environmental assumption or continuing to use the product after support has ended.
The exact warnings should come from the product risk assessment and real operating assumptions rather than from a generic security disclaimer.
6. Access to the EU declaration of conformity
Where applicable, provide the internet address at which the EU declaration of conformity can be accessed.
Article 13(20) also requires the manufacturer to provide either a copy of the EU declaration of conformity or a simplified declaration with the product. When using the simplified declaration, it must contain the exact internet address where the full declaration can be accessed.
Treat these links as controlled release metadata. A link that later points to the wrong product, obsolete declaration or generic download page can break traceability.
7. Security support and support-period end date
State the type of technical security support offered by the manufacturer and the end date of the support period during which users can expect vulnerabilities to be handled and security updates to be provided.
The support-period date in the user information should agree with the date communicated at purchase under Article 13(19) and with the support-period rationale retained in the technical documentation.
If the manufacturer changes product packaging, sales pages, online manuals or support portals, those channels should not drift into conflicting support commitments.
8. Detailed secure-use instructions
Annex II requires detailed instructions, or an internet address pointing to them, covering six areas.
Secure commissioning and lifetime operation
Explain the measures necessary during initial commissioning and throughout the product lifetime to ensure secure use. This can include credential setup, secure configuration, required services, access controls, network placement, backup or recovery assumptions and other product-specific measures.
Security impact of product changes
Explain how changes to the product can affect the security of data. This is especially relevant where extensions, configuration changes, third-party modules, firmware changes or integration choices alter the security boundary.
Installing security-relevant updates
Explain how security-relevant updates can be installed. The instructions should correspond to the real update mechanism users receive, including any administrator action required.
Secure decommissioning
Explain how to decommission the product securely, including how user data can be securely removed. This should cover the actual storage and account model of the product rather than relying on a generic "factory reset" statement where that would be incomplete.
Turning off automatic security updates
Where the CRA's default automatic-security-update requirement applies, explain how the default setting can be turned off. This instruction should not be interpreted as a recommendation to disable updates; it documents how the user can operate the control provided by the product.
Information for integrators
If the product is intended for integration into other products with digital elements, provide the information the integrator needs to meet the CRA's essential cybersecurity requirements and Annex VII documentation requirements.
For components, libraries, embedded systems and other integration-oriented products, this can be one of the most important parts of the package because the downstream manufacturer needs accurate assumptions, interfaces and security constraints.
9. SBOM access, if the manufacturer makes it available to users
The CRA requires manufacturers to draw up a software bill of materials (SBOM) as part of vulnerability handling, but Annex II does not require the SBOM itself to be made public to every user.
Instead, Annex II says that if the manufacturer decides to make the SBOM available to the user, the information must state where it can be accessed.
That distinction is important: an internal or authority-accessible SBOM requirement should not automatically be turned into an unsupported public-disclosure obligation.
Build Annex II information from controlled product records
The strongest workflow is to generate or maintain the user-information package from controlled records rather than writing it once near certification.
For each Annex II item, record:
- the accountable owner;
- the source record or decision;
- the product, variant and release scope;
- the approved user-facing wording or document;
- the publication channel;
- the effective date;
- the support-period date where relevant; and
- the review trigger.
Typical review triggers include a new release, changed update mechanism, changed support period, new vulnerability-reporting channel, changed security assumptions, changed integration requirements, substantial product modification or a corrected conformity declaration.
This approach makes user information part of release governance instead of a static attachment.
Keep Annex II aligned with Annex VII technical documentation
Annex VII explicitly includes the Annex II user information and instructions in the minimum technical documentation content. That creates a useful consistency check.
The cybersecurity risk assessment may define a security assumption or foreseeable misuse. Annex II may need to communicate the user-facing consequence. The technical documentation may describe the secure-update design. Annex II must tell the user how to install security-relevant updates. The support-period rationale is retained in technical documentation, while the support end date is communicated to the user.
Review these records together. Contradictions between them are a stronger warning signal than a missing document template because they indicate that different parts of the compliance package describe different product realities.
Language, format and online publication
The CRA does not prescribe one specific language for all Union markets. It requires a language that can be easily understood by users and market-surveillance authorities in the relevant market.
For an Austrian market release, manufacturers should therefore make the language decision deliberately and verify that the chosen user information is understandable for the intended Austrian users and authorities rather than assuming that an English engineering manual is automatically sufficient.
Paper and electronic delivery are both permitted. Online delivery is also possible, but the information must remain accessible, user-friendly and available for at least 10 years after placement on the market or for the support period, whichever is longer.
That retention rule should influence website and document-management design. Product pages are often redesigned or removed long before ten years have passed, so durable URLs, archived release-specific documents and ownership for long-term availability are practical controls.
Add an Annex II release gate
Before a product is placed on the market, run a focused gate against the actual release package.
Verify that:
- all nine Annex II groups have been assessed;
- every applicable item has user-facing content or a controlled link;
- product identity matches the shipped release;
- support-period dates agree across purchase information, user instructions and technical documentation;
- the vulnerability contact and CVD-policy location work;
- update and decommissioning instructions match the implemented product;
- integration instructions are present where the product is intended for integration;
- online resources resolve to the correct release and have a long-term retention owner; and
- the final information package is retained with the conformity and release evidence.
Do not treat "manual exists" as the gate result. The question is whether the information required for this exact product is complete, usable and internally consistent.
Keeping those relationships current becomes harder when user instructions, support decisions, vulnerability contacts and release evidence live in separate systems. AA-sec is designed around traceability between requirements, security evidence, decisions and exact product or lifecycle context, which can help teams keep the records feeding Annex II scoped to the right product and release. AA-sec does not determine whether user information is legally sufficient and does not replace manufacturer, engineering or legal judgement.
Key takeaway
Annex II is a product-security deliverable, not just a documentation appendix. Manufacturers need to provide the minimum information required by the CRA, make it understandable and usable for secure operation, keep it available for the required period, and keep it consistent with the product's risk assessment, support commitment and technical documentation.
A release-controlled Annex II checklist gives teams a practical way to prove that the right user information was reviewed for the right product before market placement.
Official sources
- Regulation (EU) 2024/2847 — Cyber Resilience Act — EUR-Lex
- The Cyber Resilience Act - Summary of the legislative text — European Commission
- Cyber Resilience Act - Manufacturers — European Commission