The EU Cyber Resilience Act: Why Legacy Firmware, Locked Vendor Clouds, and “The OEM’s Problem” Are Now Your Liability — and What to Build Before the Deadlines

If you sell a connected product in the EU under your own brand, the Cyber Resilience Act makes you the manufacturer. It doesn’t care that your firmware was written a decade ago, that your devices have no update mechanism, or that an OEM in China runs the cloud they connect to. Vulnerability reporting obligations start on 11 September 2026 — and they cover products already in the field. Full requirements apply from 11 December 2027. Penalties reach €15 million or 2.5% of global turnover, whichever is higher.

This guide explains what that means for connected device manufacturers running on legacy stacks — and what to build about it.

Key takeaways:

• “Non-compliant legacy” has a concrete shape: no over-the-air updates, default or hardcoded credentials, unencrypted protocols, end-of-life components, and no software inventory.
• Under the CRA, whoever markets a product under their own name or trademark is the manufacturer — including brands rebranding OEM hardware.
• The cloud your devices depend on is inside your compliance scope, even if a vendor you don’t control operates it.
• Two dates matter: 11 September 2026 (reporting, including for products already on the market) and 11 December 2027 (full requirements for new products).
• The realistic modernization routes are a firmware/OTA retrofit, a secure gateway in front of legacy units, or a vendor-independent IoT platform — usually a combination. Which one fits vendor-locked hardware is a negotiation with your OEM as much as a technical choice.

The CRA Reality Check: You Are the Manufacturer, and Your Legacy Stack Is in Scope

Who counts as the manufacturer

The Cyber Resilience Act (Regulation (EU) 2024/2847) applies to all products with digital elements made available on the EU market — hardware and software that connects, directly or indirectly, to a device or network. Heat pumps with Wi-Fi modules. Boilers with a companion app. Industrial equipment reporting telemetry. All in scope.

The definition that surprises business owners sits in Article 3(13). A manufacturer is anyone who develops or manufactures such products — or has them developed or manufactured — and markets them under their own name or trademark. In plain terms: the logo on the casing decides. If your brand is on the product, the manufacturer obligations Article 13 sets out are yours: conformity assessment, technical documentation, CE marking cybersecurity requirements, vulnerability handling, incident reporting, and a security updates obligation across a declared device lifecycle support period — generally at least five years. Importers and distributors who sell under their own brand assume the same duties. This is the core of OEM rebranding liability: the CRA doesn’t recognize “we just put our logo on it” as a defense.

One more definition matters enormously for white label IoT products. A “product with digital elements” includes its remote data processing solutions — data processing at a distance without which the product can’t perform one of its functions. If your devices need a cloud to work, that cloud is part of your product under the CRA. The regulation doesn’t ask whether you control it.

The legacy compliance-gap checklist

What does “non-compliant” actually look like in a stack built before secure by design was a legal requirement? Run your product range against this list:

• No OTA update path. The product can’t receive security updates remotely — the single most common gap in legacy IoT devices.
• Default or hardcoded credentials. Same password on every unit, or credentials baked into firmware.
• Unencrypted communication. Plain Modbus TCP exposed to the network, HTTP instead of HTTPS, plaintext MQTT.
• No per-device identity or revocation. You can’t tell unit A from unit B cryptographically — and can’t cut off a compromised one.
• End-of-life components. The firmware runs on an OS or libraries that no longer receive security patches.
• No SBOM software bill of materials. Nobody can list what software is inside the product.
• No vulnerability-handling process. No disclosure contact, no triage procedure, no route for vulnerability reporting ENISA will expect from September 2026.
• Undeclared support period. Buyers aren’t told until when security updates are guaranteed.
• Telemetry outside the EU without control. Device data flows to infrastructure you can’t audit, complicating EU data residency and GDPR IoT devices obligations.

Any one of these is a gap. Most legacy fleets have most of them.

Close

×

Email*

The CRA is also not alone. A quick disambiguation, because these get mixed up in board discussions:

For a deeper look at how platform architecture underpins all of this, see our guide to IoT platform architecture and layers.

What This Looks Like in Practice

Consider a real situation we encountered: a Western European air-treatment brand with 20+ years in the market. It sells pool heat pumps, dehumidifiers, and ventilation units — solid products, manufactured by Asian OEM partners, with a steady volume of connected units shipping every year.

The connected part is where it gets uncomfortable. The units ship with onboard Wi-Fi and 4G modules hard-locked to the OEM’s cloud. End customers control their equipment through the OEM’s app. When the brand examined its position, it found that it owned neither the data nor the platform. In this case the OEM neither owned the underlying module stack outright nor was willing to change it — so the modules couldn’t be re-flashed or re-pointed to another backend. Vendor cloud lock-in, at the hardware level. The “just integrate cloud-to-cloud” option kept them dependent on the vendor’s API and the vendor’s security posture: a temporary bridge, not a compliance strategy. Meanwhile, new product launches were waiting on the platform decision. The CRA turned a platform that had been “nice to have” into a launch blocker.

Here’s the general lesson. This is the white-label variant of a disease that affects manufacturers with their own in-house stacks just as much. If your company built its own firmware and connectivity a decade ago — no update path, shared credentials, unencrypted protocols — you’re in the equivalent position. The gap simply sits inside your four walls instead of a vendor’s.

From Legacy Stack to Compliant Product: The Paths That Work (and the Two That Don’t)

EU Cyber Resilience Act compliance is not one project. The right route depends on where your gap lives.

Route A: you own the firmware

If the legacy stack is yours, the answer is targeted IoT firmware modernization: adding OTA firmware updates, encrypted transport, per-device identity, and secure boot where the hardware allows it. Our IoT firmware development services team typically starts a firmware retrofit with an audit of what the installed hardware can realistically support. We did exactly this for an industrial heat pump manufacturer — reflashing the controller firmware to connect it securely to a cloud platform for remote control and diagnostics; see the SmartHeat heat-pump firmware case study. Where the installed base can’t be retrofitted, a gateway placed in front of legacy units carries the secure layer instead — see Route B. And an honest note: some legacy hardware can’t be economically retrofitted at all. For those products, the CRA-relevant question becomes support-period planning and getting the next generation designed right. Our guide on how to update IoT devices (OTA) covers the mechanics.

Route B: vendor-locked OEM hardware

If the compliance-critical layers sit with an OEM vendor, there is no universal “best” option — and any table that declares one hasn’t seen your supplier contract. Which route is even available to you turns on two questions you have to answer first:

• Does your OEM actually own the controller and connectivity? The firmware, the module, the cloud — or are they simply assembling modules bought from a third-party supplier? An OEM that owns the stack can change it. One that’s reselling someone else’s modules often can’t, no matter what they promise.
• How willing is the OEM to make changes for you? That’s a commercial conversation as much as a technical one — your volume, your contract, and your leverage decide what’s actually on the table.

So Route B is a negotiation before it’s an architecture. Here are the five options and how they usually play out — but the verdict for your product depends on those two answers:

Two of these are the ones that actually get chosen. If your OEM is cooperative — or genuinely owns the controller and connectivity — re-pointing the module by configuration (Option 2) is almost always the least time- and budget-consuming route. You’re not touching hardware or rewriting firmware; you’re getting the device to report to your endpoint instead of theirs. The whole question is commercial: will the vendor do it, and on what terms? That’s exactly why Route B starts at the negotiating table, not the architecture diagram.

If the OEM won’t cooperate — or is only reselling modules it can’t change — the off-the-shelf industrial gateway (Option 4) is the pragmatic fallback. An industrial gateway from an established EU vendor reads the equipment’s standard Modbus interface and forwards encrypted MQTT telemetry to your platform. It needs configuration, not firmware development, and the gateway vendor carries the device-layer obligations for its own product — so it’s the easiest and fastest route that doesn’t depend on anyone’s goodwill. The honest trade-off: a gateway is another component in the bill of materials, so it raises the per-unit cost of every connected device. On premium equipment that’s absorbable; on a low-margin product in a price-sensitive market it can tip the unit economics — and occasionally rules the option out altogether.

Both routes converge on the same destination: your own EU-hosted platform with an adapter layer that supports several connection paths at once. Gateways for one product line, a vendor-cloud adapter as a transition bridge for another, native connectivity for the next generation. A new product line becomes a new adapter — not a platform rebuild.

The key insight for CRA compliance for manufacturers: your architecture choice determines how much of the CRA burden you carry — not whether it applies. That part was decided the moment your logo went on the product.

The Platform Side of Compliance — In Plain Terms

So what do the CRA requirements for connected products mean for the platform you’d own? Translated out of regulation language:

• Secure by default. Encrypted connections everywhere; no default passwords anywhere.
• Per-device identity with revocation. Every unit is individually known to the platform — with a “kill switch” for compromised devices.
• Role-based, multi-tenant access. End users see their unit. Installers see their fleet. Your service team sees everything. That’s a multi-tenant IoT platform, and it’s also simply good product design.
• Audit logging and security monitoring. You can answer “what happened, when, on which device.”
• Fleet-wide software visibility. The platform tracks firmware versions across the fleet and notifies about updates. The actual OTA delivery is handled by the equipment or gateway vendors — your platform gives you the visibility the regulation assumes you have.
• Reporting readiness. An SBOM, a coordinated disclosure contact, and data export built for the 24-hour early warning, 72-hour notification, and 14-day final report cascade that ENISA’s single reporting platform expects.
• User data rights. Data export, deletion, and EU hosting — covering the GDPR and Data Act side of the same coin.

None of this requires a moonshot. The consultative path we recommend is staged: start with a web-only MVP that serves all four roles, add mobile apps next, then scale and harden — predictive maintenance, full product-range coverage. The first investment stays lean while the compliance foundation gets established. For a sense of what the predictive-maintenance layer can add commercially, see our AI-powered HVAC predictive-maintenance platform case study.

One more point that matters at the ownership level: a bought SaaS subscription doesn’t transfer your manufacturer obligations, and it never becomes your asset. A custom-built platform with full source code and IP transfer does — your data on EU infrastructure, and the freedom to change hardware vendors or support teams later. This is the kind of build our enterprise IoT solutions practice delivers.

→ See a vendor-independent fleet platform we built and operate: the fleet IoT management platform case study.

Your CRA Countdown

• 10 December 2024 — CRA in force. Done.
• 11 June 2026 — conformity assessment body provisions apply. Done.
• 11 September 2026 — reporting obligations go live. You need a vulnerability-handling process, a reporting route to ENISA and your national CSIRT, and enough visibility into your products — including vendor clouds — to know when something is being exploited. Per the European Commission’s summary, reporting obligations apply to all products already made available on the EU market. Legacy fleets included.
• 11 December 2027 — full requirements apply to products placed on the market from that date. Note the substantial-modification trap: products placed on the market earlier come into full scope if they undergo a substantial modification from that date — a major firmware overhaul can qualify. Confirm your specific case with legal counsel; this article informs, it isn’t legal advice.

Now the build math. A structured Discovery plus a staged platform build or firmware modernization takes months, not weeks — and if your route runs through the OEM, add time for the negotiation itself. Manufacturers starting in late 2026 are cutting it close for December 2027 — and those who haven’t started have no answer for September 2026 at all. We covered how connectivity choices affect this timeline in our IoT connectivity guide; the strategic build-vs-OEM trade-offs are in launching consumer IoT devices, and the commercial upside of owning the platform in IoT energy management for HVAC manufacturers.

The deadline pressure is real. But the right response is a structured Discovery of your product range and regulatory position — not a panic purchase of a SaaS badge.

The Window Is Now

The months between now and September 2026 are when the difference between prepared and exposed manufacturers gets locked in — whether your gap is legacy firmware in your own products or a vendor cloud you don’t control. WebbyLab starts with a structured Discovery: your product range, your current stack, your regulatory position — mapped to a staged modernization and platform plan with full IP ownership, backed by our IoT consulting services and enterprise IoT solutions practice.