Article 13

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.

Manufacturers integrating FOSS components into their own products do not become responsible for those components' individual CRA compliance — not even by contributing code to their maintenance. The due diligence obligation (Art. 13(5)) and upstream obligations (Art. 13(6)) apply. Eight scenarios (Examples 27–34) walk through the typical constellations of developers, foundations and integrating manufacturers.

Key takeaways

• Individual developer with a donation link: no CRA obligations; integrating manufacturers owe due diligence (Examples 27, 34).
• FOSS intended for integration by other manufacturers and not monetised is not placed on the market — its publisher may be a steward (Examples 25/26, 29).
• A FOSS component's CRA status is unaffected by manufacturers integrating it into monetised products.
• Package repositories likewise bear no CRA obligations (Example 34).

The yardstick is not the scale of the change but its effect on the risk profile: where an update alters the assessed intended purpose or introduces new risks not covered by the risk assessment, it is a substantial modification. Security updates generally are not. Four assessment criteria (para. 110) structure the case-by-case analysis.

Key takeaways

• Features already anticipated and assessed in the original risk assessment do not trigger a substantial modification — nor does later activation of assessed, dormant functionality (Examples 42/43).
• Even small features can be substantial: a 'remember me' login storing tokens locally introduces new risks (token theft, session hijacking — Example 44).
• Security updates are substantial only exceptionally — e.g. where they fundamentally alter the intended purpose, data flows or dependency structure (Examples 49/50: local encryption becomes a cloud service; external key management replaces internal).
• Assessment criteria (para. 110): new threat vectors, new attack scenarios, changed likelihood, changed impact of known scenarios.
• Regardless of classification: the risk assessment and technical documentation must be kept continuously up to date (Art. 13(7), Art. 31(2)).

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).

Variants sharing the same architecture, security-relevant design, intended purpose and risk exposure may share a single risk assessment, technical documentation set, conformity assessment procedure and EU declaration of conformity. The sole decisive factor is whether the differences between variants are relevant to cybersecurity.

Key takeaways

• Irrelevant: colour, form factor, memory size and other non-security-relevant characteristics.
• Relevant: differing communication interfaces, software stacks, update mechanisms or remote connectivity — such differences must be reflected in the risk assessment and documentation.
• The shared declaration of conformity must clearly identify the covered variants; new variants introducing new risks require an update.

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.

Five worked cases illustrate the boundary: for a mobile banking app, the self-developed banking interface is RDPS, downstream ledger/account systems are not, and the third-party SaaS support chat is a third-party component. Smart thermostat and industrial robot: the manufacturer's own cloud software on third-party IaaS is RDPS. E-reader: third-party SaaS storage is not RDPS but must be treated as a component. The cellular network is a mere communication channel — no RDPS, no due diligence required.

Key takeaways

• The CRA covers only the parts of the system the product directly interacts with — risks from systems behind them (e.g. a compromised ledger) must be mitigated at product level (strong back-end authentication, integrity protection, secure channels).
• With third-party IaaS: document the RDPS and the IaaS reliance in the technical documentation; obtain e.g. NIS 2 evidence from the provider.
• Network infrastructure (5G, ethernet, Wi-Fi, routers) is a communication enabler, not data processing whose absence would prevent a product function.

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).

Per-product risk assessment, compliance with Annex I requirements, implementing vulnerability handling under Annex I Part II, preparing technical documentation under Annex VII, EU declaration of conformity and CE marking, and free security updates throughout the support period.

At least five years, unless the expected product lifecycle is shorter. For industrial machinery with 15-year lifecycles, the support period must be correspondingly longer — this is a requirement, not a recommendation.

Not publicly. The SBOM is part of the technical documentation and must be made available to market surveillance authorities on request. Publication to end customers is optional but can be demanded in B2B procurement.

Fines up to €15 million or 2.5% of global annual turnover (whichever is higher), product recalls, and bans on placing the product on the market. Article 64 sets out the penalties in detail.

Yes, as soon as the individual unit is placed on the market on or after December 11, 2027 — what counts is the unit, not the product line. Stock produced in 2026 falls under the CRA if sold after the deadline. Only units placed on the market before that date remain exempt, provided they are not substantially modified.

Proven sequence: product inventory with risk assessment, gap analysis against Annex I, per-product SBOM build-up, vulnerability handling process with ENISA reporting capability, technical documentation under Annex VII, and finally the EU declaration of conformity. For manufacturers with many product variants, centralized component tracking is the biggest efficiency lever.