“If it ain’t broke, don’t fix it.” For decades, this was the golden rule of embedded engineering. This philosophy made perfect sense in a disconnected world. If a PID controller on a hydraulic press has been running stably since 2012, touching the firmware introduces unnecessary risk. Stability was the primary metric of success.
In 2026, that rule is effectively illegal. The EU Cyber Resilience Act (CRA) has flipped the script. While many are focused on the 2027 full compliance deadline, a much closer date is about to catch the industry off guard. On September 11, 2026, the reporting obligations kick in.
If you have industrial devices in the field that you cannot patch, monitor, or explain (via an SBOM), you are walking into a minefield of fines (up to €15M or 2.5% of global turnover) and potential market withdrawal orders.
This guide is for the CTOs and Product Owners looking at a fleet of “Zombie Firmware” and wondering how to survive the next 18 months without bricking their hardware or their budget.
The “Zombie Firmware” Trap
We define Zombie Firmware as code that is technically running in the field, but operationally dead in the lab. It generates revenue, but you have lost the ability to maintain it.
How do you know if you are managing Zombie Firmware? Here are the four most common indicators we see:
- The “Bus Factor” is Zero: Ideally, multiple engineers should understand your core code. In a Zombie scenario, the only engineer who understood the complex interrupt service routines or the custom scheduler retired years ago. The code has become “magic”, everyone is afraid to touch it because no one truly understands how it works.
- The Toolchain is Obsolete: Modern software requires modern tools. If your team needs to spin up a Virtual Machine running Windows XP just to compile the source code because the compiler license server was decommissioned in 2019, you have a toolchain problem. This fragility makes rapid patching nearly impossible.
- Deployments are Purely Physical: If updating a device requires a technician to drive to a site, climb a ladder, and plug in a USB cable, your ability to respond to a cyber threat is limited by physical logistics.
- Security via Obscurity: The security model relies on the hope that no one will look closely. This often manifests as a lack of encryption, no secure boot verification, and hardcoded credentials (like admin/1234) baked directly into the binary.
In the past, these issues were merely technical debt, annoying, but manageable. Under the CRA, they represent a direct violation of the requirement to maintain a secure product throughout its lifecycle.
The Hidden Financial Risks of Stagnation
The most common objection to modernizing legacy code is cost. “Rewriting is too expensive,” is a sentiment we hear often. However, this view often misses the Hidden Costs that the CRA brings to light:
- The Archaeology Tax: Every time a bug is reported, your team spends 40 hours just understanding how the code works before they spend 1 hour fixing it.
- The Compliance Panic: When a vulnerability like Log4j (or a microcontroller equivalent like Ripple20) hits, you cannot scan your fleet because you don’t have a Software Bill of Materials (SBOM).
- The “Truck Roll” Premium: Without Over-the-Air (FOTA) updates, a critical patch costs $500 per device (the cost of sending a technician). For a 5,000-unit fleet, that’s $2.5M—often more than the profit margin of the contract.
The Critical Date: September 11, 2026
Do not wait for December 2027. There is a misconception that manufacturers have until late 2027 to worry about compliance. While the requirement for the CE marking comes later, a crucial deadline arrives much sooner.
On September 11, 2026, Article 11 (Reporting Obligations) enters into force. Manufacturers must report actively exploited vulnerabilities to ENISA (the EU cybersecurity agency) within 24 hours of becoming aware of them.
You cannot report what you cannot see. If your legacy devices are “dumb boxes” with no logging, no connectivity, and no vulnerability management process, you are effectively flying blind.
- Scenario: A security researcher finds a buffer overflow in your 8-year-old smart meter. They publish it.
- Result: ENISA knows. The public knows. You don’t. You miss the 24-hour window. You are now non-compliant and facing fines.
2026 CRA Compliance Audit Tool
To help you assess your current standing, we have developed a brief audit. We encourage you to review your legacy products against these six criteria.
| Requirement | The Question | Pass/Fail |
| 1. SBOM Readiness | Can you generate a machine-readable Software Bill of Materials (SBOM) for the current firmware in under 1 hour? | ☐ |
| 2. Vulnerability Intake | Do you have a public channel (e.g., security.txt or web form) for researchers to report bugs? | ☐ |
| 3. 24-Hour Awareness | If a device is compromised, do you have the telemetry to know about it within 24 hours? | ☐ |
| 4. Remediation Speed | Can you deploy a patch to 90% of your fleet within 72 hours of a fix being available? | ☐ |
| 5. Crypto Agility | Are your encryption keys/certs capable of being rotated without a truck roll? | ☐ |
| 6. Build Reproducibility | Can a new hire set up the build environment and compile a byte-exact binary in < 4 hours? | ☐ |
Score:
- 0-2 Checks (Critical Risk): Your product is a prime candidate for mandatory market withdrawal.
- 3-5 Checks (High Risk): You are vulnerable to fines and operational chaos.
- 6 Checks (Compliant): You are ready for 2026.
The “Rescue” Strategy: Modernization Without a Full Rewrite
If your audit revealed significant gaps, do not panic. The solution does not necessarily require throwing away ten years of code and starting from scratch. Rewriting legacy C/C++ is risky, slow, and prone to introducing new bugs.
We use a “Wrap & Adapt” strategy to bring Zombie Firmware back to life:
Phase 1: Containerize the Toolchain
The first step is to secure your ability to compile code. We stop relying on fragile setups like “Dave’s old laptop.” We take your ancient compilers, specific library versions, and build scripts, and we wrap them into a Docker container.
- Think of this as creating a perfectly preserved “time capsule” of your development environment. It ensures that running a build command in 2026 produces the exact same binary as it did in 2016. This removes the “it works on my machine” variable and allows us to plug your legacy code into modern automated testing pipelines.
Phase 2: The “Ambassador” Pattern
If your legacy MCU (e.g., an old 8-bit PIC or AVR) is too weak to handle TLS 1.3 encryption or complex FOTA logic, don’t force it.
- The Fix: Add a small, modern “Sidecar” module (e.g., an ESP32 or a Linux gateway) that acts as a secure gateway.
- How it works: The Sidecar handles the heavy lifting—TLS, MQTT, authentication, and FOTA verification. It then speaks a simple, local protocol (UART/SPI) to the legacy MCU.
- Result: You get military-grade security and connectivity without touching the fragile control logic of the legacy system.
Phase 3: Binary Patching (Bandwidth Saver)
For devices on expensive or slow networks (NB-IoT, LoRaWAN, Satellite networks), sending a full 500KB firmware image is impossible.
- The Fix: We implement binary diffing algorithms (like BSDiff).
- How it works: The build server compares the old firmware with the new firmware and generates a tiny “patch file” (often < 5KB) containing only the changed bytes. The device downloads this patch and reconstructs the new firmware locally.
- Result: You can patch vulnerabilities over almost any network connection, drastically reducing the “unpatchable” fleet.
The “Do Nothing” Calculation
As a business leader, you must weigh the investment. Is a legacy rescue project expensive? It certainly requires a budget. But it must be compared against the alternative.
Option A: The Rescue Project
- Estimated Investment: €50k – €150k (depending on complexity).
- Outcome: A maintainable, fully compliant fleet that extends the product’s revenue-generating life by another 5-7 years.
Option B: The “Do Nothing” Gamble
- Potential Cost: Up to €15,000,000 (The maximum CRA Fine) OR a forced Market Withdrawal (Total revenue loss for the product line).
- Outcome: Reputational damage, emergency engineering costs (often at 3x normal rates), and significant legal fees.
Conclusion
The Cyber Resilience Act is not asking you to make your devices perfect. Software will always have bugs. What the regulation requires is that your devices be maintainable and transparent.
You cannot afford to have “black boxes” in your product portfolio anymore. The cost of “rescuing” your legacy firmware is a fraction of the potential fines and business risk.
Don’t let Zombie Firmware jeopardize your business continuity. Contact Better Devices to assess your legacy fleet today
