Explainer · By Chris · 27 Apr 2026 · 8 min read

Last reviewed 07 May 2026

Are products built before 2027 grandfathered under the CRA?

Article 69 of the EU Cyber Resilience Act creates a real but narrow grandfathering carve-out for products placed on the market before 11 December 2027, until a substantial modification trips the trigger. Here's what that means in practice.

A common question, asked recently in r/cybersecurity and dozens of compliance forums: if a product was designed years before the EU Cyber Resilience Act came into force, but is still being sold after the full-compliance date in December 2027, does it have to comply retroactively?

The intuitive answer is “yes, of course”. The actual answer is “no, with an important exception, and that exception catches more people than the rule does.”

This post explains Article 69 of the CRA (the transitional provisions) and the concept of “substantial modification” that does most of the real work.

The short answer

Three things hold simultaneously, and they sit awkwardly with each other:

Products placed on the EU market before 11 December 2027 are not subject to most CRA requirements. They’re grandfathered.
The grandfathering ends the moment a product undergoes a substantial modification on or after that date.
Vulnerability reporting under Article 14 applies to all in-scope products from 11 September 2026 anyway, including grandfathered ones.

So the Reddit interpretation, “any product still being sold after late 2027 must comply retroactively”, is wrong on point one and right on point three. Most of the friction comes from misunderstanding what “placed on the market” means in EU law.

What “placed on the market” actually means

In EU product regulation, “placing on the market” is a one-time legal event, not an ongoing one. It refers to the first time a product unit is made available for distribution or use on the EU market.

It is not:

Every individual sale of every unit
The continuing presence of the product on shelves or in app stores
An ongoing licence

A smart bulb manufacturer who first shipped the v1 model in 2024 and continues selling those exact same units through 2030 is not repeatedly placing them on the market. Those units were placed once, in 2024, under the pre-CRA regime, and remain governed by it.

This distinction is foundational. Once you grasp it, Article 69 becomes much clearer.

What Article 69 says

Three operative provisions, paraphrased:

Paragraph 1. EU type-examination certificates and approval decisions issued under other Union harmonisation legislation that touch cybersecurity remain valid until 11 June 2028, unless they expire earlier.

Paragraph 2. Products with digital elements placed on the market before 11 December 2027 are subject to the CRA only if, from that date, they undergo a substantial modification.

Paragraph 3. As a derogation from paragraph 2, the reporting obligations of Article 14 apply to all in-scope products that have been placed on the EU market, including the grandfathered ones, from 11 September 2026.

The full text is available in the official Regulation 2024/2847 and on the European Commission’s CRA page.

The four scenarios

Scenario	Full CRA compliance?	Vulnerability reporting?
First placed on the EU market on or after 11 December 2027	Yes, in full	Yes, from 11 September 2026
Placed before 11 December 2027, no substantial modification afterwards	No	Yes, from 11 September 2026
Placed before 11 December 2027, substantially modified after that date	Yes, for the modified version	Yes
Placed before 11 December 2027, only minor patches and bug fixes	No	Yes

Notice the right-hand column: everyone has reporting obligations from September 2026, regardless of when their product was first placed on the market. That’s the bite that catches even the most thoroughly grandfathered legacy product.

What is a “substantial modification”?

The CRA’s definition (paraphrased from Article 3): a substantial modification is a change to a product with digital elements that affects compliance with the essential cybersecurity requirements, or results in a change to the intended purpose for which the product has been assessed.

What counts and what doesn’t, with a working developer’s view:

Change	Substantial?
Security patch fixing a CVE	No
Bug fix in a non-security path	No
Refactor with no behavioural change	No
Translating UI strings into a new language	No
Adding a new authentication flow (e.g. SSO, biometric)	Yes
Adding a new network endpoint that processes user data	Yes
Changing the product’s core function (a fitness tracker that becomes a medical device)	Yes
Adding a major feature that changes the threat model	Yes
Major version upgrade with new architecture	Almost certainly yes

Note the asymmetry: routine maintenance is safe, but anything that meaningfully changes the security posture or the product’s purpose flips you into full CRA scope.

Why this matters less than it looks for software

The grandfathering carve-out has a different real-world impact depending on what kind of product you ship:

Mobile apps and SaaS clients. Most ship a substantive feature update at least quarterly. In practice the substantial-modification trigger fires within one or two release cycles after December 2027, so the grandfathering window is narrow. The honest answer for an app developer is: assume you’ll need to comply by mid-2028, even on products built years earlier.

Connected consumer hardware. Smart bulbs, thermostats, fitness trackers typically push firmware that adds features (new automations, new integrations, new cloud endpoints). The trigger fires whenever a meaningful firmware update lands. Maybe 12 to 24 months of grandfathering in practice.

Industrial and embedded devices. A sensor placed in a factory in 2025 and never updated except for security patches can stay grandfathered indefinitely. This is the audience for whom the carve-out genuinely matters.

Legacy SaaS desktop clients with no new features. Long grandfathering window, until the product is rewritten, retired, or substantially expanded.

What about the reporting obligation that catches everyone?

From 11 September 2026, every manufacturer of an in-scope product placed on the EU market (including legacy products predating CRA) has to:

Register a manufacturer profile on the ENISA Single Reporting Platform
Notify ENISA within 24 hours of becoming aware of an actively exploited vulnerability or severe incident
Submit a more detailed notification within 72 hours
Submit a final report within 14 days

This applies even if you’re invoking Article 69 grandfathering for everything else. There is no opt-out for legacy products on the reporting side.

So if you’re shipping a product that’s grandfathered for compliance purposes but you have no vulnerability disclosure channel, you have one obligation that genuinely matters from September 2026 onwards.

What to do if you ship a product placed before December 2027

A pragmatic three-step approach:

Publish a vulnerability disclosure policy now. A /.well-known/security.txt and a triage email is the bare minimum. This is required by September 2026 regardless of grandfathering status.
Decide your substantial-modification policy. When does your product team consider a change “substantial”? Document the threshold internally so the legal team isn’t reverse-engineering it after a release.
Assume future major releases trigger full compliance. Plan the SBOM, gap analysis, and Declaration of Conformity work into the next planned major release. Don’t try to retrofit it later.

For most software companies, the practical effect is this: grandfathering buys you 12 to 18 months on the legacy SKUs, but every meaningful release after December 2027 needs the full pack. For hardware companies with long-lived embedded products, the calculus is genuinely different.

TL;DR

Pre-existing products are not retroactively in scope under the CRA. Article 69 grandfathers anything placed on the EU market before 11 December 2027, until a substantial modification fires the trigger. Vulnerability reporting under Article 14 still applies to everyone from 11 September 2026, that’s the universal floor. For fast-moving software the grandfathering is narrow; for slow-moving hardware it’s broad.

If you’re unsure where your product sits, our free compliance assessment walks through the questions the CRA actually cares about and tells you whether you’re already in scope, grandfathered, or about to flip.