CRA Annex II: User Documentation & Security Information Requirements — What Manufacturers Must Disclose

Post #1031 in the sota.io EU Cyber Compliance Series

The Cyber Resilience Act's Annex II is one of its least-discussed but most operationally consequential sections. While Articles 10–16 define what manufacturers must do, Annex II defines what they must tell users — and the gap between those two obligations is where most compliance programs stumble.

Every product with digital elements placed on the EU market on or after 11 September 2026 must be accompanied by information and instructions that meet Annex II requirements. Non-conformity with Annex II is a direct trigger for market surveillance action under Article 47 and can result in corrective measures including product withdrawal.

This post breaks down all 14 Annex II requirements, explains the documentation workflow implications, and examines why the jurisdiction of your hosting infrastructure affects your ability to deliver on several of these obligations.

What CRA Annex II Requires: The Complete List

Annex II of Regulation (EU) 2024/2847 requires that information and instructions accompany the product — either in physical form, on the manufacturer's website, or embedded in the product itself — in a language easily understood by users. The following 14 elements are mandatory:

1. Name, Registered Trade Name, and Contact Address

The manufacturer's full legal name, registered trade name (if different), and postal address where they can be contacted must appear on the product or its accompanying documentation. This is not optional metadata — it is the legally verifiable identity anchor for market surveillance authorities.

Practical implication: If your legal entity is a Delaware C-Corp with EU operations, you must determine which legal entity name appears on the product. Using a holding company rather than the operating entity creates audit ambiguity.

2. Single Point of Contact for Vulnerability Reporting

A dedicated contact point — email address, web form, or other electronic means — specifically for users to report security vulnerabilities. This is distinct from your general support channel and must be maintained for the product's active support lifecycle.

CLOUD Act collision point: If this contact point routes to a US-hosted ticketing system (Zendesk, Jira hosted on AWS US regions, ServiceNow on Azure US), vulnerability reports submitted by EU users may be accessible to US law enforcement under 18 U.S.C. § 2713 without the manufacturer's knowledge. This creates a situation where your Annex II compliance mechanism itself generates CLOUD Act exposure.

3. Intended Purpose of the Product

A clear statement of the product's intended use, including the environment (IT networks, industrial systems, consumer devices, etc.) and the type of users it targets. This requirement feeds directly into Article 6 classification — Class I and Class II important products must demonstrate that their intended purpose justifies their classification tier.

4. Known Vulnerabilities at Time of Placing on Market

One of the most challenging Annex II requirements: manufacturers must disclose any known vulnerabilities in the product at the time it is placed on the market. This creates a documentation obligation that must be synchronized with your SBOM and vulnerability management pipeline.

This does not mean you must fix all vulnerabilities before shipping — it means you must disclose known ones. The practical implication is that your release process must include a vulnerability inventory review and a disclosure decision workflow as a mandatory gate.

5. Product Functions with Security Properties

A description of the security features built into the product — encryption, access controls, audit logging, update mechanisms, secure defaults. This is the "security features specification" that users need to configure and operate the product securely.

6. Security Measures Required for Intended Use

Where the product requires specific security measures from the user or their environment (firewall rules, network segmentation, OS configuration, credential management), these must be documented explicitly. Products that ship with "secure your own environment" assumptions and no documentation of those assumptions will fail this requirement.

7. Minimum Lifetime for Security Support

Manufacturers must specify the minimum period during which they will provide security updates. This is the end-of-support date commitment — and it must be stated at the time the product is placed on the market, not retroactively.

This is the requirement that will force software manufacturers to commit to support timelines they have historically avoided. A product placed on the EU market in September 2026 must arrive with a published end-of-support date.

Practical implication: SaaS products that deliver continuous updates have a simpler path — their "lifetime" is the subscription term. On-premise or perpetual license products must define an explicit support window, typically measured from the last version release or a fixed calendar date.

8. How and Where to Obtain Security Updates

Where and how users can obtain security updates — automatic update mechanisms, vendor portals, package repositories, or manual download locations. If your product uses automatic updates, the update mechanism's security properties (code signing, integrity verification, authenticated channels) must also be described.

9. Secure Configuration

Where a product has multiple configuration options, manufacturers must document which configurations are considered secure defaults and which require additional security measures by the user. This directly targets the "secure by default" principle in Annex I, Section 2.

10. Instructions for Removing Personal Data Before Disposal

Before the product is decommissioned, users must be able to remove personal data it has processed. Manufacturers must document the procedure for doing so. This Annex II requirement closes the loop between CRA and GDPR — a product that cannot be securely wiped creates ongoing GDPR liability beyond its operational life.

11. Guidance for Users with Accessibility Needs

Where security features of the product interact with accessibility settings or assistive technologies, manufacturers must document this interaction and provide guidance for users who depend on accessibility features. This is a newer addition that reflects the intersection of the European Accessibility Act (Directive 2019/882) with CRA product obligations.

12. Liability and Responsibility Statements

Where the manufacturer limits their liability for security issues arising from user misconfiguration or third-party components, those limitations must be disclosed in the accompanying documentation. This does not mean manufacturers can contractually exclude CRA obligations — it means the scope of their responsibility relative to user responsibility must be transparent.

13. Third-Party Component Disclosure

The manufacturer's documentation must reference third-party components integrated into the product, to the extent necessary for users to understand the product's security properties. This requirement pairs with the SBOM obligation in Article 10(1)(k) — the public-facing user documentation need not be the full SBOM, but users must be able to identify major third-party dependencies.

14. Digital Signature or Certificate for Update Verification

Where the product delivers security updates, the manufacturer must provide information enabling users to verify the authenticity and integrity of those updates — typically by publishing code-signing certificates or checksums through an authenticated channel.

The Documentation Workflow Problem

Most software teams have never had to produce Annex II-compliant documentation as a release-blocking artifact. The common gap is that security documentation exists somewhere — in a README, a knowledge base, a security.txt file — but has never been:

1. Formally reviewed against a regulatory checklist
2. Versioned alongside the product release
3. Published at a stable, durable URL at time of market placement
4. Available in the user's language (or demonstrably in a language "easily understood" by the target market)

The CRA does not specify a document format. It specifies content. A well-structured security page on your website that covers all 14 elements and is versioned with each product release satisfies Annex II. A 200-page PDF that is updated annually but does not include the minimum support lifetime satisfies nothing.

Why Hosting Jurisdiction Matters for Annex II Compliance

Several Annex II requirements create operational dependencies on your infrastructure provider:

Requirement 2 (Vulnerability Contact Point): If your vulnerability disclosure inbox or ticketing system runs on US-controlled infrastructure, incoming vulnerability reports — which may contain zero-day details — are subject to CLOUD Act access. EU-native hosting means your vulnerability coordination happens in a jurisdiction that requires an MLAT process before US law enforcement can compel disclosure.

Requirement 8 (Where to Obtain Updates): If your update delivery infrastructure is hosted on a US CDN or PaaS, your update channel is subject to US government content-removal orders. A CLOUD Act-compliant US authority could compel your US-infrastructure provider to remove update packages or intercept update metadata. EU-native update infrastructure eliminates this vector.

Requirement 10 (Personal Data Removal Instructions): If your product processes personal data on US-hosted servers, the deletion procedure must account for whether "deletion" is permanent under CLOUD Act — data deleted from application layer may still exist in backups accessible to US law enforcement. Your Annex II documentation must accurately describe what "deletion" means for your infrastructure stack.

Requirement 12 (Liability and Responsibility): Where you host determines what legal framework governs your security obligations. EU-native hosting under EU-controlled data center operators gives you a cleaner liability story: your obligations under CRA, GDPR, and applicable national law are not complicated by extraterritorial US jurisdiction.

What "Placed on the Market" Means for SaaS

For traditional software products, "placing on the market" is the release date. For SaaS products, every new substantial release that changes the product's security properties may constitute a new market placement event — and triggers Annex II documentation obligations.

The practical interpretation emerging from ENISA guidance is that SaaS manufacturers should:

• Maintain a living security documentation page that is always current with the deployed version
• Version-stamp the documentation with each significant release
• Include a changelog that tracks changes to security properties
• Publish and maintain a security.txt file (RFC 9116) that references the complete Annex II documentation

The security.txt approach has the advantage of being machine-readable, auditable, and easily integrated into market surveillance scanning. ENISA has indicated this approach is consistent with Annex II compliance for SaaS products.

Conformity Assessment and Annex II

For Class I products, Annex II documentation must be produced and maintained as part of the manufacturer's internal conformity assessment (Module A, Annex VI of CRA). For Class II products, the notified body conducting conformity assessment will review Annex II documentation as part of the EU-type examination process.

Non-compliant documentation does not automatically trigger fines — it triggers a corrective action request from the national market surveillance authority. Failure to correct within the specified timeframe escalates to Article 47 non-conformity decisions, which can include product withdrawal from the EU market.

The maximum administrative fine for Annex II non-compliance (as a non-conformity with a product requirement) is €15 million or 2.5% of worldwide annual turnover, whichever is higher, under Article 64(2). For most software manufacturers, the 2.5% turnover threshold will be the binding constraint.

Building an Annex II Compliance Checklist

A practical checklist for release managers to verify Annex II compliance before a product is placed on the EU market:

The CRA Documentation Stack: What You Need by September 2026

The minimum viable CRA-compliant documentation stack for a SaaS product targeting the EU market:

1. security.txt (RFC 9116) — machine-readable vulnerability contact, encryption key, acknowledgments, policy URL
2. Security page (e.g., /security) — covers requirements 1–3, 5–9, 12–14
3. Privacy / data deletion page — covers requirement 10
4. Release notes with security changelog — covers requirement 4 per release
5. Lifecycle / support policy page — covers requirement 7 (the end-of-support commitment)
6. Accessibility statement — covers requirement 11 where applicable
7. SBOM (machine-readable, e.g., CycloneDX) — satisfies Article 10(1)(k) and supports requirement 13

For a SaaS manufacturer already investing in security engineering, most of this documentation probably exists in some form. The CRA compliance task is largely about formalizing, versioning, and publishing what you already know about your own security posture.

Why EU-Native Hosting Simplifies Annex II Delivery

Beyond the specific CLOUD Act risks described above, EU-native hosting simplifies Annex II compliance in three structural ways:

Jurisdictional clarity: Every statement you make in Annex II documentation about security properties, data handling, and update mechanisms is backed by a legal framework (GDPR, CRA, national cybersecurity laws) that your documentation can reference without carve-outs for extraterritorial jurisdiction. There is no "except where US law requires otherwise" footnote needed.

Audit consistency: When a national market surveillance authority reviews your Annex II documentation, they expect it to accurately describe your actual security posture. If your actual security posture includes CLOUD Act exposure, your documentation must either disclose that (which creates commercial risk) or omit it (which creates legal risk). EU-native hosting eliminates this dilemma.

Update infrastructure integrity: Your Annex II documentation commits to how users verify update integrity. If your update infrastructure is US-hosted, that commitment is subject to unilateral US government action. EU-native update infrastructure means your Annex II commitments are yours to keep — not subject to a US court order modifying them without notice.

What Comes Next in the CRA Series

This post covers Annex II documentation obligations. Upcoming posts in the sota.io CRA series will cover:

• CRA Article 12: User Notification Requirements — when and how manufacturers must notify users of actively exploited vulnerabilities, security incidents, and end-of-support timelines
• CRA Article 15: Market Surveillance — how national authorities will enforce the CRA, what triggers an investigation, and what manufacturers can expect from a conformity assessment review
• CRA Open Source Stewards — the separate obligations for open source software stewards under Article 14 and Recital 19, and how they differ from manufacturer obligations

sota.io and CRA Annex II

sota.io runs entirely on EU infrastructure — German data centers, under German and EU jurisdiction, with no US parent company and no CLOUD Act exposure. For SaaS manufacturers building Annex II-compliant products, this means your hosting provider's infrastructure posture does not contradict your documentation commitments.

Our vulnerability disclosure contact, update infrastructure, and operational data all sit within the EU legal framework — so the statements you make in your Annex II documentation reflect your actual security posture without extraterritorial caveats.

Deploy your next release on sota.io →

CRA Annex II requirements cited are from Regulation (EU) 2024/2847 of the European Parliament and of the Council. The September 2026 enforcement date applies to Articles 14–16; full manufacturer obligations under Articles 10–13 apply from the same date. Market surveillance authorities in each EU member state are responsible for enforcement under Article 47.