Placed on the Market: How the CRA's Transition Rules Apply to Products You Already Sell

Every manufacturer knows the headline date by now: the Cyber Resilience Act applies in full from 11 December 2027. The question we hear far more often is the one the headline does not answer: what about everything we already sell?

The regulation resolves that question with three moving parts: a staggered application calendar (Article 71), a definition of "placing on the market" (Article 3), and a transition rule for existing products (Article 69). Read together, they produce answers that surprise people in both directions — some products you assumed were grandfathered are not, and some obligations arrive more than a year before December 2027.

The Calendar First

Article 71(2) sets three dates:

11 June 2026 — Chapter IV (Articles 35 to 51) applies: the machinery for notifying conformity assessment bodies. This one matters to you only indirectly; it exists so that notified bodies can be accredited and designated in time to actually assess products before the main deadline.
11 September 2026 — Article 14 applies: mandatory reporting of actively exploited vulnerabilities and severe incidents, on the 24-hour / 72-hour / final-report cadence.
11 December 2027 — everything else: the essential requirements of Annex I, the conformity assessment, the CE marking, the Declaration of Conformity, the Annex II user information, the support-period obligations.

What "Placed on the Market" Actually Means

Article 3(21) defines placing on the market as "the first making available of a product with digital elements on the Union market", and Article 3(22) defines making available as any supply for distribution or use in the course of a commercial activity, paid or free.

The CRA borrows these concepts from the EU's New Legislative Framework, and they come with an established reading (set out in the Commission's Blue Guide) that does a lot of work here: placing on the market is assessed per individual unit, not per model or product line. A product model is not "placed on the market" once in 2025 and grandfathered forever; each unit is placed on the market when that unit first changes hands in the EU.

The consequence is the one manufacturers most often miss: from 11 December 2027, every unit you supply must comply — even if the model has been on sale unchanged for years. The device sold on 10 December 2027 is out of scope (until modified, see below); the physically identical device sold on 12 December 2027 must have its CE marking, DoC, and technical file in order. There is no model-level grandfathering for continued sales.

For software, the same logic applies to versions: a new version that amounts to a substantial modification and is made available on the market is treated as a new product being placed on the market.

Article 69(2): The Rule for Products Already Out There

For units placed on the market before 11 December 2027, Article 69(2) provides the actual grandfathering: those products "shall be subject to the requirements set out in this Regulation only if, from that date, those products are subject to a substantial modification."

So your installed base — the devices already sold, the licences already delivered — does not retroactively need a conformity assessment or a CE marking. It stays outside the regulation's product requirements unless and until you substantially modify it.

Article 69(3): The Exception That Starts This September

Before you relax about the installed base, read the next paragraph. Article 69(3) carves out one obligation from the grandfathering: Article 14 reporting applies to all in-scope products placed on the market before 11 December 2027.

Combine that with the calendar and you get the sentence every product organisation should have circulated internally this year: from 11 September 2026, an actively exploited vulnerability in any in-scope product you have ever placed on the EU market — including products shipped years before the CRA existed — must be reported to your CSIRT coordinator and ENISA within 24 hours of your becoming aware of it.

There is no "legacy product" exemption from reporting. If you still have products in the field, your September 2026 preparation has to cover the back catalogue, not just the current price list.

Substantial Modification: The Concept That Decides Everything

Since Article 69(2) hangs the installed base's status on it, and every future software release potentially triggers it, "substantial modification" deserves precision. Article 3(30) defines it as a change after placing on the market that either:

affects the product's compliance with the essential cybersecurity requirements of Annex I, Part I, or
modifies the intended purpose for which the product was assessed.

The recitals flesh out how this applies to software updates, and the guidance is more manufacturer-friendly than many expect:

Security updates are generally not substantial modifications. An update designed to decrease cybersecurity risk without changing the intended purpose — patching a vulnerability, hardening a function — does not trigger the rule. The regulation explicitly wants you to keep patching legacy products without fear of dragging them into scope.
Minor functionality updates are generally fine too. Visual tweaks, new UI languages, small enhancements that leave functions, type, and performance as assessed.
Feature updates can be substantial modifications. Where an update changes the intended functions or the type or performance of the product — a new input surface, a new networked capability, a changed risk profile not foreseen in the original risk assessment — the updated version, once made available on the market, is a substantially modified product. Whether the feature ships bundled with a security update is irrelevant.

The Commission is tasked with issuing guidance on the concept (Article 26 covers guidance generally, and the recitals single out substantial modification as a topic for it) — worth tracking, because edge cases abound. But the operating rule for planning is clear enough: patch freely; add features deliberately.

What Happens When You Do Substantially Modify

A substantial modification has cascading consequences:

A grandfathered product loses its grandfathering. Under Article 69(2), a pre-2027 product that is substantially modified after 11 December 2027 becomes subject to the full regulation — essential requirements, conformity assessment, CE marking, DoC, support period.
An in-scope product needs its conformity re-verified. In line with the established NLF approach, a substantial modification requires compliance to be verified and, where applicable, a new conformity assessment — with the notified body informed if one was involved.
Someone else's modification can make you the manufacturer. If an importer or distributor substantially modifies a product already on the market, Article 21 shifts the manufacturer obligations onto them; if any other party does so and makes the product available, Article 22 does the same. Integrators who re-flash, re-configure at depth, or re-brand should read our post on who counts as the manufacturer.

One pragmatic relief for software vendors: where you have placed successive substantially modified versions on the market, Article 13(10) lets you concentrate the "address and remediate vulnerabilities" obligation (Annex I, Part II(2)) on the latest version — provided users of earlier versions can move to it free of charge and without hardware or software environment costs.

A Note on Certificates

Article 69(1) handles a narrower transition: EU type-examination certificates and approval decisions issued for cybersecurity requirements under other Union harmonisation legislation (think of the Radio Equipment Directive's cybersecurity delegated regulation, whose ground the CRA takes over) remain valid until 11 June 2028, unless they expire earlier. If your product's cybersecurity conformity currently rides on such a certificate, diarise that date alongside December 2027.

The 2026 Playbook

Translating the rules into this year's to-do list:

Inventory what is in the field. Every product and version placed on the EU market and still in use is reportable under Article 14 from 11 September 2026. You cannot report against an inventory you do not have.
Classify the roadmap, not just the products. For each planned release between now and December 2027, decide: security update, minor update, or substantial modification? The third category needs a conformity plan behind it.
Decide the fate of each legacy line. For products you intend to keep selling after 11 December 2027: full compliance programme now. For products you will stop supplying: plan the last placing on the market, remembering that post-2027 units need compliance even if the model predates the CRA.
Guard the substantial-modification boundary. Make "does this change the intended purpose or affect Annex I compliance?" a standing question in release planning — and document the answer each time. The assessment you cannot show is the assessment an authority assumes you never did.

How Seentrix Fits In

Seentrix tracks each product's placing-on-the-market status, its classification, and its release history in one place, so the questions in this post stop being archaeology: which versions are in the field, which ones the reporting obligation covers from 11 September 2026, and which planned changes have been flagged as potential substantial modifications requiring a conformity decision before release.

The judgment calls — is this release a new feature surface or a hardening patch? — stay with your engineers. The platform's contribution is that every one of those calls is recorded, dated, and attached to the product it concerns, which is exactly what you will want in hand if a market-surveillance authority ever asks why version 12 did not get a new assessment.