Annex I

Complex systems with long development cycles, legacy components and interoperability constraints are not excluded from the CRA — but those constraints feed into the risk-based approach. Where specific essential requirements cannot (fully) be met (see recital 55), manufacturers must document the constraints, assess the risks and implement compensatory measures.

Key takeaways

• A less secure legacy protocol may be implemented where necessary for interoperability, provided the risks are mitigated by other means; where the product supports both protocols, the secure one must be the default (Example 10).
• Constraints, risks and mitigations must be transparently described in the technical documentation (Art. 31, Annex VII) and user information (Annex II).
• Constraints must be periodically reassessed during the support period; where they can be lifted, the product should be updated accordingly.
• Components purchased before the CRA applies may be integrated where the risk assessment identifies no specific risks and the product as a whole meets the requirements (Example 11).

Products designed before 11 December 2027 but placed on the market after that date do not necessarily require redesign. The manufacturer carries out a current risk assessment; where it shows that existing measures address the risks, compliance can rest on those measures. Historical design and test documentation need not be recreated.

Key takeaways

• The conformity assessment procedure, EU declaration of conformity and CE marking remain mandatory in any case.
• No obligation to provide test results covering the original design phase; tests can be grouped across product families (Section 7.4 of the guidance).
• Vulnerability handling (Annex I Part II), keeping the risk assessment updated (Art. 13(3)) and user information (Art. 13(18)) apply without restriction.

Five years is a floor, not a default: the support period reflects the expected use time, and products expected to be used longer need longer support. Article 13(10) allows manufacturers to address and remediate vulnerabilities only for the version last placed on the market, provided users can upgrade free of charge and without additional costs. A substantial modification does not automatically reset the support period.

Key takeaways

• 'Additional costs' under Art. 13(10) means mandatory hardware purchases or infrastructure replacement — not normal update effort such as personnel time, testing or configuration adjustments.
• Each substantially modified version needs its own declared support period under Art. 13(8) when placed on the market.
• Where unchanged factors (e.g. hardware durability) continue to determine the expected use time, the original support period stands — even where the remainder is less than five years (Examples 54/55: robot vacuum, industrial machinery with re-architected cloud back-end).
• Where the modification changes the use-time factors themselves (e.g. a new computing platform extends a PLC's life), the support period must be recalculated (Example 56).
• Indicate the support end date at the time of purchase (at least month/year) and display an end-of-support notification where technically feasible (Art. 13(19)).
• Manufacturers may voluntarily keep patching earlier versions — including on a paid basis; the CRA does not require free updates for them.

Unlike organisational risk management, the manufacturer's own risk appetite does not count: residual risks must be measured against the product's 'appropriate level of cybersecurity'. Cost or commercial considerations do not justify leaving risks untreated — if necessary, design, functionality or intended purpose must change. Transferring risk to users or third parties is not a permissible compliance strategy.

Key takeaways

• Permissible mitigations include restricting the intended purpose plus clear user information — e.g. an industrial sensor intended only for trusted environments (Example 66).
• Manufacturers may rely on mature platform functions, e.g. the operating system's native encryption and key management instead of building their own (Example 67).
• Annex I Part I point (1) ('appropriate level of cybersecurity') acts as a catch-all: fulfilled where all risks are addressed via the other essential requirements — otherwise additional product-level measures are needed.

Two complementary obligations: the risk assessment (Art. 13(2)) also covers external risks — back-ends, infrastructure, environment — to be mitigated through product-level measures; the CRA does not regulate how external infrastructure is operated. Due diligence (Art. 13(5)) concerns integrated third-party components: the manufacturer defines what the component must deliver and verifies it in a risk-based manner.

Key takeaways

• Examples of product-level mitigation of external risks: cryptographic authentication of remote commands, integrity verification of configuration changes, secure fail states when external services become unavailable.
• Due diligence evidence: the component manufacturer's technical specifications and security documentation, conformity/assurance documentation, and where appropriate the manufacturer's own tests.
• Integrated third-party components belong in the risk assessment but are treated as externally supplied parts whose properties are verified upon integration (recital 34).

RDPS must be covered in the product's risk assessment, technical documentation and conformity assessment — limited to the software modules responsible for the product's functionality and the interfaces those modules use. Downstream back-end systems the product does not directly interact with are not RDPS, but remain external dependencies whose risks must be mitigated at product level.

Key takeaways

• An RDPS serving several products must be declared in each product's technical documentation — the RDPS documentation may be reused across conformity assessments.
• Reusable assurance artefacts for third-party services: NIS 2 evidence (IR (EU) 2024/2690), DORA evidence, certificates under EU cybersecurity certification schemes, ISO/IEC 27001/27017.
• Major changes to third-party services are not a substantial modification of the product — but manufacturers should secure information and security guarantees contractually (SLAs) and revise the risk assessment accordingly.

The Article 14 reporting obligations apply from 11 September 2026 to all products within the CRA's scope — including products placed on the market before 11 December 2027 and products past their support period. 'Becoming aware' means reaching a reasonable degree of certainty after an immediate initial assessment — from that moment the deadlines run (24h early warning, 72h notification, 14 days / 1 month final report).

Key takeaways

• No retroactive reporting: active exploitation the manufacturer already knew about before 11 Sep 2026 is not reportable; where exploitation only becomes known afterwards, the obligation applies.
• Third-party components: only an actively exploited vulnerability that is exploitable/exploited in the manufacturer's own product is reportable — otherwise voluntary reporting (Art. 15) plus upstream reporting to the component maintainer (Art. 13(6)).
• 'Becoming aware' is deliberately aligned with the NIS 2 implementing regulation and the GDPR breach-notification guidelines.
• Informing users (Art. 14(8)) is risk-based: no indiscriminate disclosure — for sensitive environments, detailed information may be limited to affected users; broader disclosure once fixed, and mandatory disclosure of fixed vulnerabilities under Annex I Part II point (4).
• Unlike vulnerability handling, the reporting obligations continue to apply after the support period ends.

The guidance clarifies three obligations: reporting component vulnerabilities and sharing security fixes upstream (Art. 13(6)), the prohibition on placing products with known exploitable vulnerabilities on the market (Annex I Part I), and the 'effective and regular tests and reviews' (Annex I Part II point (3)) — which require input-driven review and adaptation rather than mechanical test repetition.

Key takeaways

• Upstream reporting only for the version actually integrated, following the maintainer's CVD processes; no obligation where the vulnerability is already known (avoid duplicates: check databases/advisories) or the project no longer has a maintainer.
• Only vulnerabilities in the component itself must be reported — not those arising from the manufacturer's own integration.
• Share security fixes in machine-readable, licence-compatible form; the maintainer need not accept the fix, nor must the manufacturer adopt the maintainer's fix.
• A vulnerability is 'known' when listed in relevant public databases (e.g. the European vulnerability database), disclosed via coordinated disclosure, found through the manufacturer's own testing (including AI-powered analysis), or prominently reported in reliable media — a short verification period is permissible.
• Vulnerabilities discovered shortly before release: risk-based decision on whether to postpone the release — weighed against the risks of delay (e.g. where the release also fixes other vulnerabilities).

13 requirements: secure default setup, protection against unauthorized access, confidentiality/integrity of stored and transmitted data, availability, minimization of attack surface, limitation of impact from security incidents, secure update, logging — and more.

6 requirements: identification and documentation of vulnerabilities and components (including SBOM), remediation without delay through security updates, regular testing, publication of information about fixed vulnerabilities, coordinated disclosure policy, distribution of updates over secure channels.

In Annex I Part II point 1: 'identification and documentation of vulnerabilities and components, including by drawing up a software bill of materials in a commonly used and machine-readable format.' CycloneDX and SPDX are considered 'commonly used formats.'

Not automatically. Recital 55 allows certain requirements to be declared not applicable — with justification in the risk assessment in the technical documentation.