DE Contact
Menu

For device manufacturers

Security maintenance for shipped embedded Linux products. CVE applicability assessment, patch adaptation, firmware builds, and regression evidence, delivered in your engineering environment.

Built for industrial gateways, routers, controllers, and connected equipment on Yocto, Buildroot, OpenWrt, and Debian/CIP, with EU CRA reporting coordinated alongside the fix.

Contact us View services

The engineering gap

An upstream fix or scanner alert is not an update your device can ship.

  • Version numbers do not establish exposure

    Impact depends on compile flags (PACKAGECONFIG, BR2_PACKAGE_*), kernel Kconfig, C library choice, and whether the vulnerable code path is reachable.

  • Mainline patches rarely fit maintained branches

    Pinned releases carry older APIs, BSP modifications, and missing prerequisites that require semantic backporting rather than blind cherry-picks.

  • Full upgrades risk regressions and requalification

    Targeted backports preserve ABI stability, saved device configurations, and hardware certifications without forcing OS migrations.

  • A clean compile does not prove the image works

    Candidate firmware has to be rebuilt and exercised against a known functional baseline before entering release review.

Repeats across every supported branch and board revision for 5 to 10 years.

References: Linux kernel backporting guide · Yocto CVE guidance

Services

Completed maintenance work in your repository, not another alert feed.

Platform coverage & ARM case study
When firmware is affected

Verified merge request

Compatible version updates or adapted .patch backports in your build system, delivered with rebuilt packages or images, baseline-vs-candidate regression logs, and a hardware sign-off checklist.

When a finding does not apply

Auditable CVE disposition

Source and compile-flag proof of disabled features, prior patches, or unreachable paths, committed as VEX records or build metadata (CVE_STATUS, IGNORE_CVES) aligned with EU CRA guidance.

When an event is reportable

CRA Article 14 dossier

Joint evaluation of active exploitation or severe impact, staged 24h and 72h draft notifications formatted for ENISA's Single Reporting Platform, and deadline tracking alongside remediation.

Operating boundaries

Executed in your environment. Signed by your team.

Full workflow & security matrix

  • Your runners and source rules

    Confidentiality and branch scope are signed in writing up front; builds and regression suites run in infrastructure you control or approve.

  • Standard Git commits, zero agents

    Deliverables are plain build definitions, patches, and VEX records in your repository, with no proprietary binaries added to your image.

  • Keys and deployment stay with you

    Your engineers review and merge changes. Cryptographic signing keys, PKI, hardware sign-off, and OTA rollout never leave your control.

EU Cyber Resilience Act

Statutory reporting handled alongside the firmware fix.

Under Regulation (EU) 2024/2847, reporting deadlines start on awareness of an actively exploited vulnerability or severe incident, before a patch is finished. Firmdura verifies exposure against your shipped configuration and prepares staged ENISA submissions in parallel with remediation.

Mandatory reporting covers actively exploited vulnerabilities and severe incidents, not every CVE. You retain product decisions and legal responsibility as manufacturer.

Article 14 workflow & timelines

  • 11 September 2026

    In effect

    Article 14 reporting applies across the EU (24h early warning, 72h notification) through ENISA's Single Reporting Platform.

  • 11 December 2027

    Full obligation

    Main CRA requirements apply, including security updates across a support period of in general at least five years (Article 13(8)).

  • Article 64

    Enforcement

    Non-compliance carries administrative fines up to EUR 15 million or 2.5% of worldwide annual turnover, whichever is higher.

Primary sources: Regulation (EU) 2024/2847 · European Commission CRA · CRA reporting

Insights

Primary-source analysis on firmware security and regulation.

All insights

Engagement & contact

Start with a fixed-fee baseline. Continue per configuration.

Scope & pricing details
Stage 01 · Fixed fee

Baseline & initial maintenance scope

Three upstream-backed user-space CVE cases on one pinned firmware configuration (Yocto, Buildroot, OpenWrt, or Debian/CIP), with deliverables, tests, and fixed price agreed in writing before access.

Stage 02 · Per configuration

Ongoing lifecycle maintenance & reporting

Predictable fixed-fee CVE triage, patch backporting, candidate builds, regression evidence, and CRA Article 14 reporting per supported product configuration, never open-ended hourly billing.

Discuss a firmware configuration.

Share your target stack, firmware branch, and whether your priority is open backlog fixes, ongoing maintenance, or CRA reporting, or request a 20-minute technical call.

Contact us Or email info@firmdura.com