For manufacturers of embedded Linux devices
From upstream fix to an update you can ship.Security maintenance for your supported Yocto configuration.
A published fix is not yet a change your product can ship. Firmdura does the engineering in between: applicability, adaptation, rebuild, regression tests, and the regulatory reporting that runs alongside. You review and release; your platform engineers stay on the roadmap.
- Vendor neutral
- Your Yocto branch and BSP
- Builds and tests in your environment
- Your review, your release
The problem
A fix upstream is not a fix in your product.
An upstream project repairs its own source. Your firmware ships particular versions of that source, local modifications, a selected configuration and your board support package. Between the two sits engineering work that cannot be skipped.
Applicability is a product decision
A component name and version do not decide whether a finding matters. An existing patch, a disabled feature or a different platform can change the answer. A scanner supplies information; it does not make this call.
Patches rarely fit maintained branches
Your branch may use different APIs, carry local modifications or lack changes the fix depends on. The repair has to preserve the fix's meaning, not merely apply without conflicts.
Updates can break working behavior
Devices in the field must keep communicating, hold their configuration and operate their interfaces after the change. A fix that disturbs any of this creates a second problem.
Compiling is not validating
A patch can apply, build and boot while still missing a dependency. What matters is the rebuilt firmware's behavior on your product, not a successful build of the upstream project.
This work repeats for every supported product, branch and hardware revision, for as long as the product is supported. That recurring load is what Firmdura takes on.
The approach is established engineering practice: Yocto's stable-branch guidance prefers compatible updates and backports to preserve API and ABI stability, and the Linux kernel backporting guide documents why adapted patches need review and testing.
What you receive
A change to review, not a report to triage.
The unit of delivery is a merge request against your repository: the fix, its evidence and its documentation, assembled for engineering review. What that changes for your team:
Review instead of reconstruct
Your engineers assess a prepared change with its evidence, instead of integrating an upstream patch from scratch. Findings that do not apply are dispositioned with reasons you can show an auditor.
Your roadmap keeps its engineers
Recurring patch adaptation, rebuilds and regression runs stop competing with new product development for your most constrained platform capacity.
Your platform stays in place
Targeted, minimal changes preserve the platform your product was qualified on: no forced version jumps, no avoidable requalification.
Your compliance record builds itself
Every delivery documents the decision, the change and its validation, ready for your security reviews and CRA obligations.
How it works
A defined path from finding to release.
Five steps, the same for every case, on a baseline agreed before work begins.
Agree the baseline
One supported branch, configuration and board revision, plus the findings, tests and acceptance criteria in scope. Source handling is agreed in writing before any access.
Assess applicability
Each finding is investigated against your actual source and configuration, and recorded as affected, already addressed or not applicable.
Prepare the repair
A compatible update where it fits, a backport where it does not. Changes are prepared for your source and build system, with upstream references.
Rebuild and test
Your firmware is rebuilt and the agreed component and product checks run, in an environment your team controls or approves.
You review and release
The merge request and its evidence land in your review queue. Your engineers approve the change; hardware acceptance, signing and deployment stay in your process. Firmdura does not release firmware; you do.
EU Cyber Resilience Act
Regulatory reporting, handled alongside the fix.
We assess reportability with you, prepare notifications, coordinate authorized submissions and follow-ups, and manage the deadlines. Initial notifications do not wait for a completed fix.
Mandatory reporting covers actively exploited vulnerabilities and severe incidents, not every CVE. You retain product decisions and legal responsibility: the service covers maintenance and reporting, not complete regulatory compliance.
11 September 2026 In effect
Reporting obligations apply for actively exploited vulnerabilities and severe incidents affecting product security.
11 December 2027 Upcoming
The main obligations apply, including vulnerability handling for a support period that is in general at least five years.
Article 64 Penalties
Administrative fines of up to EUR 15 million or 2.5% of worldwide annual turnover, whichever is higher.
Sources: Regulation (EU) 2024/2847 and the European Commission's reporting guidance.
Latest analysis
Current developments, read by engineers.
Researched briefings on the vulnerabilities, platform releases and regulation that shape embedded Linux maintenance. Primary sources linked; reported facts kept separate from our interpretation.
Company
An engineering company in Hamburg.
Firmdura is an engineering company in Hamburg, Germany, built for one job: keeping shipped embedded Linux products secure without consuming the teams that build them. The team's background spans security, cloud infrastructure and distributed systems.
We work as an extension of your platform team, inside boundaries you set. Our analysis is published openly with named sources, and our claims stay within what we can demonstrate on your firmware.
- Hamburg, Germany
- Engineering-led
- Independent and vendor neutral
Getting started
Every engagement starts on your baseline.
The first engagement is a bounded scope: three userspace cases on one supported configuration, with deliverables, acceptance criteria, rework boundaries and price fixed before work begins. It establishes the baseline, test set and acceptance workflow that continuous maintenance then runs on, and ends at a defined decision point.
- Cases chosen from your actual maintenance backlog.
- Deliverables, acceptance and price fixed up front.
- A defined decision point before continuous maintenance.
Kernel and platform-wide changes are scoped as separate engagements: they carry their own feasibility and validation requirements.
What is holding up your next maintenance release?
Tell us which product and Yocto branch you support, and what work remains open. We can discuss where preparation or validation support would help.
Talk to an engineerStart with a short email or a 20-minute discussion.
How pricing works
A fixed fee for the first engagement
One price for the full first scope, agreed before work begins. Not open-ended time and materials.
A defined scope per configuration
Continuous maintenance is priced per supported configuration, so it can stand in your budget as a known line item.
What moves the price
Configurations and branches in scope, case volume, test depth and reporting scope. You see the full price before you commit.