Already shipped doesn’t mean regulatory-safe: the retroactive impact of the EU CRA

From 11 September 2026, a connected product you shipped years ago could carry new legal obligations, even if you never change a line of its code.

That’s when the mandatory vulnerability and incident reporting requirements under Article 14 of the EU Cyber Resilience Act (CRA) become legally enforceable. Miss the deadlines, and you could face fines of up to €15 million or 2.5% of total worldwide annual turnover — whichever is higher.

If you have a connected product still on the EU market, you need to be aware of your obligations under CRA.

What does “retroactive” mean here?

No matter how long ago your products were placed on the EU market, the September 2026 reporting requirements still apply. That reach comes from Article 69(3), which states that every product with digital elements placed on the EU market before 11 December 2027 is in scope for reporting. A connected sensor shipped in 2018 that is still in service carries the same reporting obligations as a product launched next year.

Where Article 69 catches people out is modification. Paragraph 2 says pre-2027 products only face the full CRA requirements if they undergo a substantial modification after that date — which sounds like an untouched product is mostly off the hook. It isn’t. That threshold governs only the Phase 2 conformity obligations: CE marking and the Annex I security requirements. Reporting is deliberately separate. Whether you’ve modified the product or not has no bearing on your Article 14 reporting duty.

This also applies to severe security incidents. If the availability, authenticity, integrity, or confidentiality of sensitive or important data or functions is compromised, it must be reported. An incident must also be reported if it leads to malicious code being introduced or run in your product or in a user’s systems.

So, from September 2026, if an actively exploited vulnerability or severe security incident turns up in any of your live products, you’ll need to:

There are no exceptions due to industry regulations

Medical device and aerospace teams might think that they’re off the hook because MDR/IVDR and aviation safety regulations (EU 2018/1139) govern their core products under sector-specific rules, exempting them from the CRA directly.

While that’s technically correct for most certified devices, it overlooks two things. First, body-worn medical device wearables must fulfil CRA requirements regardless of the MDR/IVDR exemption. Second, it completely ignores the rest of the ecosystem. Manufacturer-developed companion apps, cloud-based telemetry dashboards, remote update servers, and other connected infrastructure surrounding those devices aren’t exempt. They fall squarely under the CRA.

A December 2025 European Commission proposal seeks to integrate CRA-aligned vulnerability reporting obligations directly into MDR and IVDR — requiring manufacturers to route actively exploited vulnerabilities and severe incidents to CSIRTs and ENISA via EUDAMED, in addition to existing MDR/IVDR vigilance reporting. These discussions are still ongoing at the time of this article’s publication, but it’s clear the picture for medical device manufacturers is shifting regardless. For industrial embedded systems, there are no exemptions; the September 2026 reporting deadline applies in full.

Under the CRA, technical debt is now a legal liability

The legislation places full responsibility for remediation on the manufacturer placing the product on the EU market. If an EOL open-source component in your firmware is actively exploited, you have three options: patch it yourself, migrate the product to a supported framework, or face market exclusion and fines.

Framework migrations in embedded systems aren’t quick work, either. In our experience, depending on the depth of integration, moving a product from a legacy runtime or library to a modern, maintained equivalent can take anywhere from 12 to 24 months. It’s one of the reasons we place such emphasis on building habitable, maintainable codebases from the outset, because the cost of refactoring rises sharply when a regulatory deadline is involved. Attempting a migration in response to a live exploit, while simultaneously trying to hit a 24-hour reporting window, isn’t a position you want to be in.

And that raises a practical question: how do you know what’s in your products before something goes wrong? A Software Bill of Materials (SBOM) is the primary mechanism that enables the 24-hour reporting window. Without one, triage at that speed is not realistic across a fleet of products.

How a Software Bill of Materials enables the CRA 24-hour reporting window

The three-phase CRA compliance timeline

The CRA’s requirements don’t all take effect at once. Instead, they arrive in waves, each with its own deadline and its own engineering demands. Grouping them into three phases makes that sequence easier to plan around.

The September 2026 deadline is the first of the three phases, but it’s also the most significant deadline for teams who aren’t ready. Phases 2 and 3 require deeper architectural work, but you can’t reach them credibly if you are unable to meet the reporting obligations first. Security cannot be retrofitted late in development, and the CRA makes that plain by applying its heaviest penalties from the earliest deadline, not reserving them for the later conformity stages.

Phase 2 is where the larger engineering challenge sits. Meeting the Annex I security requirements and achieving CE marking will mean significant technical groundwork for most teams, and December 2027 is closer than it looks.

What this means in practice

Most of what the CRA requires sits in three areas of engineering work:

• 
  Legacy codebase audit

  If you’ve got products in the field that haven’t been significantly touched in a few years, you need to know what’s in them. A systematic gap analysis of open-source components and their support status will surface anything already EOL or heading that way, and will often turn up broader maintainability issues at the same time.

• 
  Patch validation pipelines

  Getting a fix out quickly is only half the problem. You also need to know that fixes haven’t introduced new errors, especially in safety-critical systems, where a bad patch can carry real physical risk. This is where Test-Driven Development (TDD) and Behaviour-Driven Development (BDD) pay off. An automated test suite built around your codebase can verify a firmware change in minutes rather than weeks, giving you the confidence to move within the reporting window without cutting corners on safety. In regulated products, that validation also carries compliance weight under standards like IEC 62304 or IEC 61508.

• 
  Secure Over-the-Air (OTA) update mechanisms

  If your products can’t be updated remotely, your ability to respond to a field vulnerability is seriously limited. The CRA’s Phase 3 requirements include a five-year security update commitment. Delivering that at scale requires a secure, reliable OTA mechanism with rollback capability in case something goes wrong.

Most of this is just good embedded engineering

At Bluefruit Software, we don’t see the CRA introducing anything new to good engineering practice. It’s asking for what high-quality embedded engineering teams should implement as standard: structured dependency management, automated testing, clean and maintainable codebases, and security built into the development process rather than added at the end. The legislation is just making the cost of ignoring those things explicit.

The teams best placed to meet the technical specification deadlines are the ones already making CRA part of their design process from day one. For everyone else, now is the time to get an honest picture of where you stand, before the deadline forces that conversation. Our readiness quiz is a great place to start. It takes a few minutes, and if what it surfaces suggests you need to move quickly, at least you’ll know before September makes that decision for you.