Embedded firmware that's documented, maintainable, and built to live for ten years.
Industrial firmware isn't a script that works on delivery day. It's a system that has to keep running after ten years of series production, support secure OTA updates, and withstand a regulatory environment that keeps moving (CRA, IEC 62443).
- IEC 62304
- IEC 62443
- ETSI EN 303 645
- Cyber Resilience Act (CRA)
- MCUboot
- RAUC
Industrial firmware has to outlive its team
An industrial product stays in series production 5 to 15 years. During that period the team that designed it can change three times over. Firmware that can only be maintained by its original author is hidden technical debt — and it surfaces at the worst possible moment, when a critical customer asks for an urgent fix.
We write firmware that's documented in intent: why this architecture choice, why this timing, why this interrupt priority. The code itself stays conventional and readable. A successor team can take over in a few weeks, not six months.
Secure OTA: not optional, mandatory
From 2027, the Cyber Resilience Act (CRA) requires every connected product to support security updates for the expected product lifetime. Without secure OTA, no industrial IoT product will be sellable in Europe.
We systematically integrate: secure boot anchored in hardware (chain of trust verified at every startup), ECDSA signature on every OTA image (MCUboot for MCU, RAUC for Linux), encrypted storage for secrets, TLS 1.3 for all network communication, and IEC 62443 alignment for industrial products.
Handling the CVEs raised by the SBOM requires an operational prioritization layer — a point validated by Thierry Durand of Embedded Expertise, our independent peer in embedded cybersecurity: scanning with Grype or Trivy is only the first step; the real engineering work is prioritization and remediation steering in the product's operational context.
RTOS choice: Zephyr, FreeRTOS, NuttX, Linux
Picking an RTOS or embedded operating system isn't ideological — it follows from the product's constraints: memory footprint, target certification, driver ecosystem, real-time requirements.
On constrained MCUs (Cortex-M0/M4 with 64-256 KB of RAM), Zephyr offers the most modern ecosystem and the best long-term maintainability. FreeRTOS is still relevant for simple projects or existing teams. For embedded Linux (Cortex-A, MPSoC), Yocto with a clean BSP and an SBOM (CycloneDX, SPDX) is our default choice on any product expected to clear CRA compliance.
IEC 62304 compliance — for medical
When firmware ships inside a medical device, IEC 62304 adds strict documentation discipline: software classification (A, B, C by patient impact), requirements ↔ code traceability, SOUP management (Software of Unknown Provenance, i.e. third-party libraries), validated update process.
Our approach: structure the firmware in components with clear criticality, isolate Class C functions in a dedicated module (qualified under IEC 62304), handle the rest as Class A/B with ISO 13485-grade rigour. This keeps the qualification effort to the strict regulatory minimum.
FAQ
- Embedded Linux or RTOS? How do you decide?
The simple rule: if the product needs a complete network stack (TCP/IP, TLS, multitasking), a rich graphical UI, or a file system — Linux. If the product is hard real-time (latency < 1 ms), low-power (sub-mA on average), or safety-critical — RTOS. Many industrial projects combine both: an MPSoC with Linux on the application side and a companion MCU (Zephyr or FreeRTOS) for real-time functions.
- How do you handle CVEs that surface after deployment?
Automatic SBOM generation (CycloneDX) at every build, continuous scanning (Grype, Trivy), and — this is the key work — prioritization by operational context: what's the real attack surface of this CVE on this product deployed at this customer? Most CVEs raised by a raw scan aren't exploitable in the product's context, but they clutter reports. We work with Thierry Durand (Embedded Expertise) on this prioritization discipline.
- Can you take over an existing firmware that needs fixing?
Yes. Taking over a failing or drifting electronics project is one of our typical cases. We start with a structured technical diagnostic (architecture, code quality, technical debt, observed failure modes), then propose a costed stabilization plan before any long-term commitment. See our article: Taking over a failing electronics project.
Medical
Designing a medical device isn't about retrofitting an industrial board. It's about embedding patient safety, software traceability and risk management into every architectural decision, from specification to MDR technical file.
Hardware
A PCB we deliver is a PCB you can manufacture in series, certify without rework, and assemble in the factory without surprises. EMC, IPC standards and DFM are baked into the schematic — not bolted on after the prototype goes up in smoke.
Industrialization
The classic trap: a working prototype that needs six months and a re-spin to hold up in series production. Our technical signature is the opposite — DFM, IPC standards and testability are integrated into the initial schematic. The prototype is already a manufacturable board.