Do you have to redesign an existing product for the CRA?

Not necessarily: the cybersecurity risk assessment decides. That is the reading in the Commission's guidance on applying the Cyber Resilience Act (CRA, Regulation (EU) 2024/2847), section 2.7, and it is a draft: published on 27 July 2026, not binding (point 8), and in the Commission's words applying only once formally adopted. This guide is for a team whose product was designed before the CRA and will still be sold after it. It is a documentation aid, not legal advice.

Three cases, by date

What counts is when each unit is placed on the market, not when the model was designed. Placing on the market is the first time a unit is made available in the EU (Article 3(21); glossary row placing-on-the-market); the guidance (point 11) quotes the Blue Guide: it refers "to each individual product, not to a type of product".

Case	What applies	Where it is written
A unit placed on the market before 11 December 2027	Article 14 reporting, since 11 September 2026. The rest only if the product is substantially modified on or after 11 December 2027	Article 69(2) and (3); Article 71(2)
A unit of an older design placed on the market on or after 11 December 2027	The whole Regulation. This guide is about this case	Article 71(2); guidance section 2.7
A new design	The whole Regulation, with the risk assessment taken into account from planning onwards	Article 13(1) and (2)

So the units of a 2022 board you have already sold stay outside most of the CRA (glossary row substantial-modification says what would bring them back in). The same board built and sold in January 2028 is inside it.

What the guidance says about an older design

Point 33: compliance "does not necessarily require that those units of the product with digital elements be redesigned". Instead, the Article 13(2) risk assessment finds which Part I requirements of Annex I apply and how they are implemented. Point 34: where the assessment shows the product "already incorporates appropriate and effective security measures addressing the relevant risks", you "may rely on those existing measures". Point 36: such a product "might be placed on the market under the CRA without redesign", if the risk assessment and the technical documentation show it reaches an appropriate level of cybersecurity for its intended purpose and reasonably foreseeable use and meets the essential requirements.

If you cannot show that a risk assessment shaped the original design, point 35 says you perform one now and show from it that the existing measures are adequate. Example 12 walks a microcontroller through exactly this.

What you still owe for an older design

Point 35 keeps the conformity assessment, the declaration and the CE marking whether or not the design had to change; point 39 adds Part II vulnerability handling, an up-to-date risk assessment and the user information.

• A current risk assessment, documented and updated during the support period (Article 13(2) and (3); glossary row cybersecurity-risk-assessment).
• The technical documentation and the conformity assessment (Article 13(12); glossary rows technical-documentation and conformity-assessment). Your product's category decides the procedure: see "What important and critical mean".
• The EU declaration of conformity and the CE marking (Article 13(12); glossary rows eu-declaration-of-conformity and ce-marking). See "The EU declaration of conformity for connected devices".
• The information and instructions to the user (Article 13(18), Annex II; glossary row information-and-instructions-to-the-user).
• Vulnerability handling under Annex I, Part II (Article 13(8); glossary row vulnerability-handling-requirements). See "Coordinated vulnerability disclosure for small teams".
• A support period of at least five years, shorter only if the product is expected to be in use for less (Article 13(8); glossary row support-period). See "What the CRA support period means".
• Article 14 reporting, which already covers every unit. See "Article 14, step by step".

What you are not asked for

• Test records from design work you never documented. Point 38: the conformity assessment evidence "should not be understood as requiring the manufacturer to provide test results covering the original design and development phases". Example 12: the maker "is not required to recreate historical design or test documentation". Two limits: point 38 names products under the procedures of Article 32(1) and no others, and holds only where the assessment shows the existing measures address the product's risks. Tests still needed may be grouped across a product family.
• A separate assessment for a variant that differs only in colour, form factor or memory size (point 176). A different communication interface, software stack, update mechanism or remote connectivity must be reflected in the risk assessment; see the variants section of "Choosing and changing your CRA support period".

When the answer is yes

• The assessment finds a risk the existing measures do not address. Point 163: such risks "may require changes to the design, functionality or intended purpose" of the product, and cost alone is no reason to leave them untreated; point 158 calls "internal risk tolerance, commercial strategy or mere cost considerations" not relevant. Narrowing the intended purpose, for example to trusted environments (point 162), changes the product without redesigning it (argument), if the technical documentation and the user information say so.
• The product cannot do something Annex I asks of it. The usual case is the update mechanism (argument; section 2.7 does not discuss it). Annex I, Part I, point 2(c) asks that vulnerabilities "can be addressed through security updates"; our requirement row part-i-2c reads "Where applicable, the device must be able to take security updates." The point 2 requirements apply on the basis of the risk assessment and "where applicable", and one that does not apply needs "a clear justification" in the technical documentation (Article 13(4)). Part II carries no such opening: Annex I, Part II, point 2 asks you to remediate vulnerabilities "including by providing security updates", Annex I, Part II, point 7 asks for "mechanisms to securely distribute updates", and point 39 keeps Part II in full for older designs. Our reading: a connected product that cannot take a firmware update in the field has those two points to answer whatever its age, and adding a signed bootloader and an update path is a redesign.

Where Declarable helps

In Declarable, a product's Cybersecurity risk assessment screen, under Documents, records the intended purpose, foreseeable use, operating environment and expected time in use, and lets you link each risk to the Annex I requirements it bears on. It does not mark the assessment ready for review while one of those four is blank, or while an Annex I requirement has neither a linked risk nor a written reason. The Technical documentation screen prepares an Annex VII draft and states how many threats the saved assessment lists and which Part I point 2 requirements have neither a linked threat nor a written reason. Neither screen says your product meets a requirement; that judgement is yours.

What is settled and what is not

Settled (evidence): the three cases and their dates (Articles 69 and 71), and the duties listed above for every unit placed on the market from 11 December 2027 (Article 13).

Not settled (as of 14 October 2026):

• Section 2.7 is a draft reading. The cover communication, read on 14 October 2026, says the guidance "will be formally adopted by the Commission at a later date, when all language versions are available. It is only from that moment that it will apply." The Commission page that publishes it, read the same day, says nothing of adoption. Only the Court of Justice can interpret the CRA authoritatively, and the examples "are not intended to replace a case-by-case assessment" (point 8).
• Important and critical products. Point 38 says nothing about the procedures in Article 32(2) to (4); whether those need test records from the original design is open.

We update this guide when the Commission adopts or changes the guidance.