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

Last reviewed 24 Aug 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 on developer forums and in dozens of compliance communities: 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.

Updated after the Commission’s July 2026 guidance. On 27 July 2026 the Commission approved the content of its guidance on applying the CRA, the Article 26 document that had been in draft since the spring consultation. It changes three things in this post, and one of them reverses a position we took.

The reversal is on software copies. This post previously said it was unsettled whether each download after 11 December 2027 counts as a new placing on the market, and advised planning as though it did. Section 2.1 of the guidance settles it the other way: all copies of a software version are placed on the market at the moment that version is first offered, and later downloads of it are merely making it available. If you built your 2028 plan on our earlier advice, you have more room than we told you.

The second change is to how substantial modification is assessed. We had a table sorted by type of change: auth flows in, security patches out. The guidance says explicitly that scale and complexity are not the test (point 107); what matters is whether the change introduces risk your assessment didn’t already cover. That cuts both ways: a small convenience feature can be substantial, and a significant security rearchitecture may not be. The table has been rewritten and a four-part test added.

The third is a softening. We had said a substantial modification to a pre-2027 product pulls the whole thing into scope. Point 124 limits the obligations to the modified parts unless the change degrades the product’s security as a whole, and existing test evidence can be reused for everything else.

Everything else in this post stands, including the part that matters most: Article 14 reporting still applies to every in-scope product from 11 September 2026, grandfathered or not.

The short answer

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

Units placed on the EU market before 11 December 2027 are not subject to most CRA requirements. They’re grandfathered. New units built to the same design and placed on the market on or after that date are not.
The grandfathering ends the moment such a unit 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 a unit already placed
The continuing presence of an already-placed unit on shelves or in app stores, including subsequent downloads of the same software version
An ongoing licence

A smart bulb manufacturer that placed 10,000 v1 units on the EU market in 2024 placed those 10,000 units once, under the pre-CRA regime, and they remain governed by it through 2030. Building another 5,000 units to the same design and placing them on the market on or after 11 December 2027 is a fresh placing, and those units have to be CRA-conformant. The design is not grandfathered. The units are. Commission FAQ 7.2 works this exact example for physical units, using routers, and section 2.2 of the Blue Guide is the underlying principle: Union harmonisation legislation applies to individual products, not product types.

Software copies are now settled, and in the developer’s favour. Section 2.1 of the July 2026 Commission guidance addresses standalone software directly: once the manufacturing phase is complete and the software is first supplied for distribution or use, the manufacturer is regarded as having placed multiple copies on the market at that moment (points 13–14). Every subsequent download of that version is making available, not a new placing. The guidance works the example: version 1.0.0 first offered on 1 January 2028 and bought by a second customer on 15 January, both copies are placed on the market on 1 January. Point 15 extends it to iterations: a 1.0.1 patch that is not a substantial modification does not change the date of placement.

So an app first offered before 11 December 2027 that ships only patches and bug fixes keeps its grandfathered status on those copies, however many people download it in 2028.

Two limits. First, point 14: variants that differ in included components, configurations or enabled functionality, such as separate OS builds or different feature bundles, are not copies of the same product. Each is a distinct product with its own placing date. Second, point 16: this reasoning applies only to standalone software. Where software is combined with hardware, section 2.4 folds the firmware and any companion app required to operate the device into the hardware product, placed when the hardware units are placed.

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

What Article 69 says

Three operative provisions, paraphrased:

The guidance cited throughout this post is the approved content of a draft Commission Communication dated 27 July 2026. It is explicitly non-binding (point 8) and only the Court of Justice can give an authoritative interpretation of the CRA, but it is the clearest signal available on how the Commission reads these provisions.

Paragraph 1. EU type-examination certificates and approval decisions issued under other Union harmonisation legislation covering cybersecurity remain valid until 11 June 2028, unless they expire earlier or the other legislation specifies otherwise. Two limits from points 248–249 of the guidance: validity extends only to the cybersecurity risks actually covered by the legislation the certificate was issued under, and even where the certificate’s own validity runs past 11 June 2028, it cannot be relied on for CRA purposes beyond that date. It is evidence for a subset of risks in your conformity assessment, not an exemption from the Article 13(2) risk assessment.

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?
Units first placed on the EU market on or after 11 December 2027	Yes, in full	Yes, from 11 September 2026
Units placed before 11 December 2027, no substantial modification afterwards	No	Yes, from 11 September 2026
Units placed before 11 December 2027, substantially modified after that date	Yes, but scoped (see below)	Yes
Units placed before 11 December 2027, only minor patches and bug fixes	No	Yes

Row three is narrower than it looks. Point 124 of the guidance: a substantial modification by the original manufacturer of a product placed on the market before 11 December 2027 does not in itself require bringing the entire product into full CRA compliance, unless the modification negatively affects the cybersecurity of the product as a whole. Where it doesn’t, obligations are limited to the substantially modified parts. Points 118–119 apply the same proportionality to third parties modifying someone else’s product under Article 22, and point 123 confirms that existing documentation and test results can be reused for the unaffected parts, including by a notified body, which should focus its assessment on what actually changed.

Notice the right-hand column: everyone has reporting obligations from September 2026, regardless of when the units were 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.

The July 2026 guidance reframes the test. Point 107 states explicitly that the assessment should not be based on the scale or complexity of the change, but on its impact on the product’s cybersecurity risk profile. Point 104 gives the operative question: does the change introduce new or increased cybersecurity risk that was not already addressed in the manufacturer’s risk assessment?

Point 110 gives four criteria a manufacturer should work through. Does the update:

introduce new threat vectors, such as additional interfaces, communication channels, execution environments, or external dependencies?
enable new attack scenarios, meaning new routes to unauthorised access, manipulation, interference or misuse?
change the likelihood of previously identified attack scenarios, by lowering the effort or expertise needed, increasing exposure to untrusted actors, or weakening existing safeguards?
change the impact of previously identified attack scenarios, in the scope of affected data or functions, the severity of consequences, or the ability to detect, contain or recover?

Four “no”s and the update is very likely not a substantial modification (point 111). Any “yes” and you reassess (point 112).

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

Change	Substantial?
Security patch fixing a CVE, internal implementation only	No (point 108)
Bug fix in a non-security path	No
Refactor with no behavioural change	No
UI string translation	No
Tightening firewall rules, disabling unused ports, making already-available MFA mandatory	No (Example 47)
Disabling a deprecated crypto algorithm in favour of an already-supported alternative	No, where the risk assessment anticipated the deprecation (Example 48)
Enabling functionality that was present but disabled, and already risk-assessed	No (Example 43)
Adding group messaging where the original risk assessment covered it	No (Example 42)
Security update that replaces local processing with a remote service	Yes (Example 49)
Security update that introduces a third-party dependency and new data flows	Yes (Example 50)
A “remember me” persistent-login feature storing auth tokens locally	Yes (Example 44)
A logging feature that stores sensitive operational data unencrypted	Yes (Example 45)
Adding a new authentication flow not foreseen in the risk assessment	Yes
Changing the product’s core function (a fitness tracker that becomes a medical device)	Yes
A dashboard gaining the ability to control the machines it monitors	Yes (Example 40)

Note what the two halves of that table have in common. The dividing line is not how big the change is. A persistent-login checkbox is substantial, and a significant security rearchitecture may not be. It is whether the risk was in your assessment before you shipped. Which means the single highest-value thing you can do is write a risk assessment that anticipates your roadmap: functionality you foresaw, assessed and mitigated for does not trip the trigger when you later enable it.

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. The copies you offered before 11 December 2027 stay grandfathered through as many post-cutoff downloads as you get, provided you ship only patches and non-substantial iterations. What ends it is a substantial modification, and most apps ship a substantive feature update at least quarterly. In practice the trigger fires within one or two release cycles after December 2027, so plan to comply by mid-2028, but because the release is substantial, not because the downloads are.

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 stays grandfathered indefinitely as an installed unit. That is the audience for whom the carve-out genuinely matters. It does not extend to the production line: a manufacturer still shipping that same part number in 2029 is placing new units on the market, and those units have to be conformant.

Legacy desktop clients with no new features. The longest window of all. Copies first offered before 11 December 2027 remain grandfathered indefinitely while the product ships only patches and bug fixes, regardless of download volume after the cutoff. The window closes when the product is rewritten, substantially expanded, or a new variant is introduced.

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 the CSIRT designated as coordinator and ENISA simultaneously, 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 of a corrective or mitigating measure becoming available, for an actively exploited vulnerability (Article 14(2)(c))
Submit a final report within one month of the 72-hour notification, for a severe incident (Article 14(4)(c))

Two clarifications from the July 2026 guidance. First, point 210: the reporting obligation continues after a product’s support period ends, unlike the vulnerability-handling requirements. End-of-life is not an exit.

Second, point 217: there is no retroactive reporting. A vulnerability whose active exploitation you already knew about before 11 September 2026 does not need notifying. But if you knew of the vulnerability and not of any exploitation, and exploitation surfaces or comes to your attention after that date, it becomes reportable.

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 units 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. The CRA requires a coordinated vulnerability disclosure policy and a single point of contact under Annex I Part II, but those attach to products newly placed on the market from 11 December 2027. For units placed before that date they never apply at all: point 210 of the guidance confirms only Article 14 reporting reaches back. Commission FAQ 5.3 is explicit that for units placed on the market before 11 December 2027 manufacturers have to notify under Article 14 but “are not required by the CRA to comply with other obligations, e.g. in relation to vulnerability handling”. Publish one anyway: it is what makes the 24-hour clock survivable, because you cannot notify what nobody can report to you.
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 covers the units you placed on the market before 11 December 2027, not the product line, and 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 units are not retroactively in scope. Article 69 grandfathers units placed on the EU market before 11 December 2027, not the designs they were built to, and only until a substantial modification fires the trigger. For standalone software the July 2026 Commission guidance is better news than expected: all copies of a version count as placed when that version is first offered, so post-cutoff downloads of an unchanged release do not re-place it. What ends grandfathering is a substantial modification, and the test for that is whether the change introduces risk your assessment didn’t already cover, not how big the change is. Even then, the obligations scope to the modified parts unless the change degrades the product’s security as a whole. Article 14 reporting applies to everyone from 11 September 2026 regardless, and keeps applying after support ends. That’s the universal floor.

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.

Sources

Not sure where your product actually stands?

Reading about the CRA and knowing how it applies to your product are different problems. Book a short call and we will go through your product, your release cadence and your security programme, and tell you what the conformity route really looks like.

This article is general information about the EU Cyber Resilience Act, not legal advice, and reading it creates no advisory relationship. It reflects our reading of the regulation and the guidance available on the date shown above, both of which change. Classification, deadlines and obligations turn on the specific facts of your product. Verify against the primary sources before you rely on any of it, and take professional advice for decisions that carry legal or financial consequences. See our terms.