Cenitia launchesLaunching September 2026 — first 250 founders get the launch price locked for life.

Reserve your spot →
Cenitia
How it worksLibraryGlossaryRegulationsToolsAbout
Reserve your spot
How it worksLibraryGlossaryRegulationsToolsAbout

On this page

  • Why Article 69 matters more than most CRA articles
  • Article 69(1) — existing notified body certificates
  • Article 69(2) — the grandfather rule for legacy products
  • "Placed on the market"
  • "Substantial modification"
  • Operational effect
  • Article 69(3) — the Article 14 carve-back
  • How Article 69 interacts with the rest of the Regulation
  • Common mistakes
  • A per-SKU roadmap that maps to Article 69
  • How Cenitia helps
  • Frequently asked questions
  • Related from the Library
  • Further reading
← Library
reference·CRA·12 min read

CRA for existing products already on the EU market: the Article 69 transitional rules

CRA Article 69 explained: grandfathering for products placed on the EU market before 11 December 2027, substantial modification test, Article 14 reporting carve-back.

By Vladimír Vician · 29 June 2026

TL;DR

Article 69 of the Cyber Resilience Act (Regulation (EU) 2024/2847) is the rule that decides whether your existing EU-market product needs to comply. The default — Article 69(2) — grandfathers products placed on the market before 11 December 2027 unless they undergo a substantial modification from that date (Article 3(30)). Article 69(3) is the only carve-back: the Article 14 reporting obligations apply to ALL in-scope legacy products from 11 September 2026, regardless of grandfathering. Existing EU type-examination certificates issued under other Union harmonisation legislation remain valid until 11 June 2028 under Article 69(1). Plan a per-SKU roadmap now: either keep selling pre-2027 inventory with Article 14 reporting in place, or commit to substantial modification and full CRA conformity.

If you manufacture, import or distribute connected hardware in the EU, the most consequential CRA question for your existing portfolio is not the December 2027 deadline itself — it is what happens to the units you already shipped before that deadline. The answer sits almost entirely in Article 69 of Regulation (EU) 2024/2847 — the transitional provisions article. Read alongside the Article 3 definitions, Article 69 sets a default grandfather rule, a single carve-back for reporting, and a six-month transitional window for legacy notified body certificates. This guide walks through each paragraph with the verbatim text.

For the cut-over dates themselves see our CRA timeline and reporting obligations and CRA December 2027 readiness guides. For the Article 14 process that the carve-back imposes, see the ENISA 24-hour reporting guide.

Who this is for

Product managers, compliance leads and legal counsel at hardware and IoT manufacturers, EU importers and authorised representatives planning their CRA portfolio strategy for products already placed on the EU market. This article is a reference walk-through of Article 69 — for binding interpretation in your specific case, consult a notified body or EU compliance lawyer.

Why Article 69 matters more than most CRA articles

Most CRA commentary focuses on the future-state obligations: Annex I essential requirements, the Article 13 manufacturer duties, the Article 14 reporting process, conformity assessment under Modules A through H. Article 69 instead answers the messy operational question every manufacturer with an existing EU footprint has to face: "what about the 50 000 units already in retail channels, the firmware-update fleet of 200 000 devices in the field, and the EU type-examination certificate I just paid for under the RED?"

The article runs to three paragraphs. Each one answers a distinct question. Each one is short. None of them have been amended since the OJEU publication on 20 November 2024.

Article 69(1) — existing notified body certificates

The verbatim text of Article 69(1):

"EU type-examination certificates and approval decisions issued regarding cybersecurity requirements for products with digital elements that are subject to Union harmonisation legislation other than this Regulation shall remain valid until 11 June 2028, unless they expire before that date, or unless otherwise specified in such other Union harmonisation legislation, in which case they shall remain valid as referred to in that legislation."

Three implications.

First, scope of paragraph 1 is narrow. It covers EU type-examination certificates and approval decisions — Module B / Module B+C / Module H outputs from notified bodies under the RED, the Machinery Directive, the EMC Directive, the Low Voltage Directive and any other Union harmonisation legislation with a cybersecurity cybersecurity component. It does NOT cover internal-control Module A self-declarations, which are not "issued" by a third party.

Second, the sunset is fixed at 11 June 2028. That date sits exactly six months after CRA general application (11 December 2027). Manufacturers therefore get a six-month window during which a pre-existing RED Article 3(3)(d), (e) and (f) certificate can substitute for a CRA conformity assessment output — but only if the certificate is still valid on 11 December 2027.

Third, the certificate's own expiry can shorten the window. If your RED Module B certificate is dated to expire on 1 March 2028, that earlier date wins. And if the underlying Union harmonisation legislation specifies a different sunset for cybersecurity certificates ("unless otherwise specified in such other Union harmonisation legislation"), that legislation wins.

For most connected-radio manufacturers, this paragraph means: an EN 18031 compliance package signed off by a notified body in late 2025 or 2026 buys regulatory cover until 11 June 2028, after which a fresh CRA conformity assessment is required for any product still being placed on the market.

Article 69(2) — the grandfather rule for legacy products

The verbatim text of Article 69(2):

"Products with digital elements that have been placed on the market before 11 December 2027 shall be subject to the requirements set out in this Regulation only if, from that date, those products are subject to a substantial modification."

Two terms-of-art here. Both are defined in Article 3 of the Regulation.

"Placed on the market"

Article 3(21) defines placing on the market as "the first making available of a product with digital elements on the Union market". The corresponding Article 3(22) defines making available on the market as "the supply of a product with digital elements for distribution or use on the Union market in the course of a commercial activity, whether in return for payment or free of charge".

The phrase that matters is first making available. It is the manufacturer's first commercial supply of a specific unit into the EU. After that, a distributor selling that already-placed unit to the next economic operator is "making it available" but not "placing it on the market" again — the Union-law clock started ticking the moment the manufacturer first supplied it.

Practical consequence: if you ship 50 000 units to your EU distributor on 1 October 2027, every one of those 50 000 units is "placed on the market" before 11 December 2027, even though most of them will sit in retail warehouses and be sold to end-users in 2028. The grandfather rule attaches to each unit at the moment of the manufacturer's first supply, not at the moment of retail sale.

"Substantial modification"

Article 3, point 30 defines substantial modification as:

"a change to the product with digital elements following its placing on the market, which affects the compliance of the product with digital elements with the essential cybersecurity requirements set out in Part I of Annex I or which results in a modification to the intended purpose for which the product with digital elements has been assessed."

The test has two prongs, joined by OR. A change is substantial if EITHER it affects Annex I Part I compliance OR it modifies the intended purpose. The first prong is technical (cryptography swap, removed authentication, expanded attack surface). The second prong is functional (the product is now used for a purpose it was not previously assessed for — e.g. a sensor previously assessed as a local-only device now uploads to a cloud).

Routine bug-fix updates and security patches that do not alter the trust model are NOT substantial modifications. A patch that closes a CVE without changing the cybersecurity posture is exactly the kind of routine maintenance the CRA expects manufacturers to do — and it does not trigger full CRA conformity.

Operational effect

If you (a) shipped the unit before 11 December 2027 and (b) it has not been substantially modified since, the CRA Annex I essential requirements, the Article 13 manufacturer obligations and the conformity assessment requirements do not apply to that unit. You can keep selling pre-2027 inventory through normal distribution channels until it runs out.

The day you push a substantial modification — whether on day one of 2028 or in 2030 — the modified product steps fully into CRA scope. That includes Annex I Part I product requirements, Annex I Part II vulnerability handling (SBOM, security update process, public disclosure), conformity assessment under the right Module, the Declaration of Conformity citing Regulation (EU) 2024/2847, and the technical file built to CRA Annex I expectations.

Reserve your spot — Cenitia launches September 2026

One email at launch · cancel any time

Article 69(3) — the Article 14 carve-back

The verbatim text of Article 69(3):

"By way of derogation from paragraph 2 of this Article, the obligations laid down in Article 14 shall apply to all products with digital elements that fall within the scope of this Regulation that have been placed on the market before 11 December 2027."

This is the single paragraph that catches most legacy fleets — and it catches them earlier than December 2027.

Article 14 sets the 24-hour notification duty for actively exploited vulnerabilities and severe incidents. Article 71(2) sets the Article 14 application date as 11 September 2026 — fifteen months earlier than the rest of the Regulation. Article 69(3) closes the loop: even legacy products grandfathered out of Annex I and Article 13 must still comply with Article 14 reporting, from 11 September 2026.

The practical implications:

  • A device first sold in 2022 is still subject to Article 14 reporting in 2026.
  • A device first sold in 2026 (before CRA general application) is still subject to Article 14 reporting from 11 September 2026.
  • A device first sold in 2027 before 11 December is still subject to Article 14 reporting — Article 69(2) grandfathers it from Annex I obligations, but Article 69(3) keeps it inside Article 14.
  • A device shipped in 2028 is in full CRA scope (no grandfathering applies).

For most fleets this means the 24-hour reporting process must be fleet-wide from day one, not "new products only". See the September 2026 reporting checklist for the operational walk-through.

How Article 69 interacts with the rest of the Regulation

ProvisionApplies to grandfathered legacy products?Notes
Article 13 (manufacturer obligations)No — unless substantially modifiedDefault grandfathered by 69(2)
Article 14 (reporting)Yes — for all in-scope productsExpress derogation in 69(3); applies from 11 September 2026
Annex I Part I (essential requirements)No — unless substantially modifiedDefault grandfathered by 69(2)
Annex I Part II (vulnerability handling)No — unless substantially modifiedDefault grandfathered by 69(2), but Article 14 reporting can effectively require parallel processes
Conformity assessment (Articles 32–34)No — unless substantially modifiedDefault grandfathered by 69(2)
EU Declaration of Conformity (Article 28)No — unless substantially modifiedDefault grandfathered by 69(2)
Article 18 EC REP appointmentYes — if you place new productsAn EC REP is required for placing post-2027 products, regardless of legacy fleet status
Article 64 penaltiesYes — for breach of Article 14 in legacy fleetTier 1 fines of up to EUR 15 million or 2.5 % worldwide turnover apply to Article 14 breaches per Article 64(2)

Common mistakes

  • Treating the grandfather rule as automatic. Article 69(2) only protects you if you can prove the unit was placed on the market before 11 December 2027 AND has not been substantially modified. Without shipping records and a documented modification log, the burden of proof flips against you in a market surveillance enquiry.
  • Missing the Article 14 carve-back. Manufacturers reading only Article 69(2) see "grandfathering" and assume legacy fleets are fully out of CRA scope. Article 69(3) deletes that assumption for reporting. Build the Article 14 process fleet-wide.
  • Confusing "placed on the market" with "sold to end-user". Article 3(21) anchors the test to first manufacturer supply, not retail sale. A unit shipped to an EU distributor in October 2027 and sold to an end-user in March 2028 is a pre-CRA unit, not a CRA-scoped unit.
  • Assuming routine security patches trigger substantial modification. They generally do not. The Article 3(30) test is about Annex I Part I compliance or intended purpose, not about every code change. Build a documented "substantial modification" decision flow with engineering and legal sign-off so you can defend each release.
  • Forgetting that Article 69(1) certificates expire on 11 June 2028, not 11 December 2027. Some compliance plans wrongly assume the RED-era certificate sunsets at CRA general application. It does not — you have six extra months.
  • Treating the carve-out in Article 2 as a CRA escape. Carve-outs in Article 2 (medical devices under MDR/IVDR, type-approved motor vehicle systems, aviation, marine) remove the product from CRA scope entirely. They are not "transitional" — they are permanent. Don't confuse them with Article 69(2) grandfathering.

A per-SKU roadmap that maps to Article 69

For each SKU on your EU portfolio, decide three things before December 2027:

  1. Last placing-on-market date. When do you stop shipping new units into the EU? After that date, every unit must be either (a) sold from existing pre-2027 stock or (b) shipped under full CRA conformity.
  2. Modification posture. Will the product receive substantial modifications post-2027? If yes, plan for full CRA conformity from the first modified release. If no, plan for an end-of-life trajectory with only security maintenance.
  3. Article 14 readiness. For every SKU still in the field on 11 September 2026 — including those you stopped shipping years ago — implement the Article 14 reporting process. This is the operational lift that most plans underestimate.

Cenitia models this per-SKU. When you flag an SKU as "last shipped 31 October 2027" and "no planned substantial modification", the platform automatically scopes its CRA obligations to Article 14 only and surfaces the September 2026 reporting checklist. When you flag a substantial modification, it expands scope to full Annex I and Article 13.

How Cenitia helps

Cenitia treats Article 69 as a first-class object in the compliance vault. Each SKU carries a placing-on-market date, a modification log, a substantial-modification decision trail with engineering and legal sign-off, and a per-SKU CRA scope status that updates automatically when the modification log changes. The Article 14 reporting workflow is configured fleet-wide so that 2022-vintage devices and 2028-vintage devices share the same notification pipeline, with per-SKU routing to the correct national CSIRT and to ENISA.

When the European Commission issues implementing acts on substantial modification scope, or when ENISA publishes guidance on Article 14 reporting practice, Cenitia's regulation watcher flags every SKU whose status may need re-evaluation.

Reserve your spot — Cenitia launches September 2026

One email at launch · cancel any time

Frequently asked questions

Does the Cyber Resilience Act apply to products already on the EU market before 11 December 2027?

Article 69(2) of Regulation (EU) 2024/2847 provides the default rule: products placed on the market before 11 December 2027 fall under the CRA only if they are subject to a substantial modification from that date. The Annex I essential cybersecurity requirements, the Article 13 manufacturer obligations and conformity assessment do not retroactively bind every unit on store shelves. Article 69(3) creates one explicit exception — the Article 14 reporting obligations apply to ALL in-scope products placed on the market before 11 December 2027.

What counts as a "substantial modification" under the CRA?

Article 3, point 30 defines substantial modification as "a change to the product with digital elements following its placing on the market, which affects the compliance of the product with digital elements with the essential cybersecurity requirements set out in Part I of Annex I or which results in a modification to the intended purpose for which the product with digital elements has been assessed". A routine bug fix that does not change the cybersecurity posture is not substantial. A firmware update that removes a password requirement, adds a new wireless interface or pushes new categories of personal data through the cloud is — and triggers full CRA compliance for the modified product.

Do I have to apply CRA Article 14 24-hour reporting to legacy products?

Yes. Article 69(3) is explicit: "By way of derogation from paragraph 2 of this Article, the obligations laid down in Article 14 shall apply to all products with digital elements that fall within the scope of this Regulation that have been placed on the market before 11 December 2027." From 11 September 2026 — the Article 14 application date set in Article 71(2) — manufacturers must notify actively exploited vulnerabilities and severe incidents in their legacy fleet to ENISA, the relevant CSIRT and users.

Are existing notified body certificates still valid?

Article 69(1) provides that "EU type-examination certificates and approval decisions issued regarding cybersecurity requirements for products with digital elements that are subject to Union harmonisation legislation other than this Regulation shall remain valid until 11 June 2028, unless they expire before that date, or unless otherwise specified in such other Union harmonisation legislation, in which case they shall remain valid as referred to in that legislation." Translation: certificates issued under, for example, the Radio Equipment Directive remain valid until 11 June 2028, giving manufacturers a 6-month window between CRA general application (11 December 2027) and certificate sunset to plan transitions.

Can I keep selling a legacy product after 11 December 2027 without redoing conformity assessment?

Yes, provided two conditions hold: (a) every unit you sell was "placed on the market" before 11 December 2027 under Article 3(21) — i.e. first made available on the Union market — and (b) no substantial modification has occurred. Distributors can continue to make available units already placed on the market. Manufacturers can clear pre-2027 inventory. Once you ship a new unit into the EU after 11 December 2027 that was NOT placed on the market before that date, the CRA applies in full to that unit.

What about security updates — can I keep pushing them without triggering substantial modification?

Yes for genuine bug-fix and security updates that do not change the cybersecurity posture or intended purpose. The Article 3(30) test for substantial modification looks at whether the change affects compliance with Annex I Part I or modifies the intended purpose. A patch that closes a CVE without altering the trust model is a routine update and not substantial. A "security update" that, for example, removes mutual authentication for a new partner integration, or starts processing payment data on a device previously not assessed for Article 3(3)(f), is substantial and triggers full CRA compliance for the updated product.

Does Article 69 apply to free or open source software placed on the market before 11 December 2027?

Free and open source software placed on the market in the course of a commercial activity is in CRA scope from the general Article 71(2) application date. Article 69(2) treats free and open source products the same as any other product with digital elements — pre-11 December 2027 placements are grandfathered absent substantial modification, but the Article 14 reporting derogation in 69(3) also applies. Pure non-commercial open source contributions are addressed separately in the CRA's open-source provisions (notably the Article 24 "open-source software steward" role) and outside the scope of Article 69.

Related from the Library

  • CRA timeline and reporting obligations
  • CRA December 2027 readiness
  • CRA September 2026 reporting checklist
  • CRA ENISA 24-hour reporting
  • CRA Annex I explained
  • Updating a Declaration of Conformity after an amendment

Further reading

  • Regulation (EU) 2024/2847 — Cyber Resilience Act, EUR-Lex
  • CRA Article 69 — Transitional provisions
  • CRA Article 71 — Entry into force and application
  • CRA Article 14 — Reporting obligations of manufacturers
  • CRA Article 3 — Definitions
  • European Commission — Cyber Resilience Act policy page

Last reviewed: 5 July 2026. Cited regulations watched continuously by Cenitia — when one amends, this article is flagged for update.

FAQ

Frequently asked questions

  • Does the Cyber Resilience Act apply to products already on the EU market before 11 December 2027?+

    Article 69(2) of Regulation (EU) 2024/2847 provides the default rule: products placed on the market before 11 December 2027 fall under the CRA only if they are subject to a substantial modification from that date. The Annex I essential cybersecurity requirements, the Article 13 manufacturer obligations and conformity assessment do not retroactively bind every unit on store shelves. Article 69(3) creates one explicit exception — the Article 14 reporting obligations apply to ALL in-scope products placed on the market before 11 December 2027.

  • What counts as a 'substantial modification' under the CRA?+

    Article 3, point 30 defines substantial modification as 'a change to the product with digital elements following its placing on the market, which affects the compliance of the product with digital elements with the essential cybersecurity requirements set out in Part I of Annex I or which results in a modification to the intended purpose for which the product with digital elements has been assessed'. A routine bug fix that does not change the cybersecurity posture is not substantial. A firmware update that removes a password requirement, adds a new wireless interface or pushes new categories of personal data through the cloud is — and triggers full CRA compliance for the modified product.

  • Do I have to apply CRA Article 14 24-hour reporting to legacy products?+

    Yes. Article 69(3) is explicit: 'By way of derogation from paragraph 2 of this Article, the obligations laid down in Article 14 shall apply to all products with digital elements that fall within the scope of this Regulation that have been placed on the market before 11 December 2027.' From 11 September 2026 — the Article 14 application date set in Article 71(2) — manufacturers must notify actively exploited vulnerabilities and severe incidents in their legacy fleet to ENISA, the relevant CSIRT and users.

  • Are existing notified body certificates still valid?+

    Article 69(1) provides that 'EU type-examination certificates and approval decisions issued regarding cybersecurity requirements for products with digital elements that are subject to Union harmonisation legislation other than this Regulation shall remain valid until 11 June 2028, unless they expire before that date, or unless otherwise specified in such other Union harmonisation legislation, in which case they shall remain valid as referred to in that legislation.' Translation: certificates issued under, for example, the Radio Equipment Directive remain valid until 11 June 2028, giving manufacturers a 6-month window between CRA general application (11 December 2027) and certificate sunset to plan transitions.

  • Can I keep selling a legacy product after 11 December 2027 without redoing conformity assessment?+

    Yes, provided two conditions hold: (a) every unit you sell was 'placed on the market' before 11 December 2027 under Article 3(21) — i.e. first made available on the Union market — and (b) no substantial modification has occurred. Distributors can continue to make available units already placed on the market. Manufacturers can clear pre-2027 inventory. Once you ship a new unit into the EU after 11 December 2027 that was NOT placed on the market before that date, the CRA applies in full to that unit.

  • What about security updates — can I keep pushing them without triggering substantial modification?+

    Yes for genuine bug-fix and security updates that do not change the cybersecurity posture or intended purpose. The Article 3(30) test for substantial modification looks at whether the change affects compliance with Annex I Part I or modifies the intended purpose. A patch that closes a CVE without altering the trust model is a routine update and not substantial. A 'security update' that, for example, removes mutual authentication for a new partner integration, or starts processing payment data on a device previously not assessed for Article 3(3)(f), is substantial and triggers full CRA compliance for the updated product.

  • Does Article 69 apply to free or open source software placed on the market before 11 December 2027?+

    Free and open source software placed on the market in the course of a commercial activity is in CRA scope from the general Article 71(2) application date. Article 69(2) treats free and open source products the same as any other product with digital elements — pre-11 December 2027 placements are grandfathered absent substantial modification, but the Article 14 reporting derogation in 69(3) also applies. Pure non-commercial open source contributions are addressed separately in the CRA's open-source provisions (notably the Article 24 'open-source software steward' role) and outside the scope of Article 69.

Portrait of Vladimír Vician

Written by

Vladimír Vician

Founder, Cenitia · Founder & Managing Director, Inovasense s.r.o.

Founded Inovasense in Bratislava in 2016. Specialises in EU-sovereign hardware — FPGA and embedded systems design, embedded security, and regulatory compliance under the CRA, RED (EN 18031), and the harmonised standards each cites. Named signatory on every Declaration of Conformity Inovasense ships.

Best reached on LinkedIn. For longer enquiries, the Inovasense contact form.

Inovasense profile · More about Cenitia

Continue reading

Related guides

  • comparison

    ISO/IEC 27001 vs CRA — when to certify both

    ISO/IEC 27001:2022 is an organisational ISMS standard; the EU Cyber Resilience Act is a product-level regulation. Where they overlap, where they don't, and why you need both.

    8 min read

  • tutorial

    CRA December 2027 readiness — the 18-month roadmap to full conformity

    18-month preparation roadmap to 11 December 2027 CRA full application. Quarterly milestones for Annex I conformity, Technical File, DoC, and Notified Body engagement.

    10 min read

  • tutorial

    CRA ENISA 24-hour reporting — the early warning rule in operational detail

    Operational walkthrough of CRA Article 14 reporting: the 24-hour early warning content, the ENISA single reporting platform, CSIRT routing, and the three-tier cascade.

    9 min read

  • tutorial

    CRA September 2026 reporting checklist — preparation for the 24-hour rule

    Practical checklist for manufacturers preparing for 11 September 2026 — when CRA Article 14 reporting to ENISA becomes mandatory. Workflow, accounts, escalation, monitoring.

    9 min read

Put this into practice

Free tools & references

  • CRA Readiness CheckerScore your product against the Cyber Resilience Act essential requirements.Open tool →
  • EU Directive SelectorDescribe your product and find which EU directives and regulations apply.Open tool →

New to the terminology? Browse the compliance glossary — plain-English, citation-backed definitions of every term above.

Reserve your spot — launching September 2026

One email at launch · cancel any time

← Back to Library

Cenitia

The EU compliance engine for hardware manufacturers. Cited drafts, electronic signing, regulation watching — all in one place.

A product of Inovasense s.r.o., Bratislava, Slovakia · Data hosted in Stockholm, EU

Site

  • How it works
  • Library
  • Glossary
  • Regulations
  • By product type
  • Tools
  • About

Legal

  • Imprint
  • Privacy
  • Terms

© 2026 Inovasense s.r.o. · cenitia.com

EU sovereign · EU data residency by design · Customer data never trains models