Your firmware changes.
Keep the evidence connected.

FDIE (Firmware Delta Intelligence Engine) helps connected-device teams maintain technical evidence between firmware releases. It analyses supported images, compares identified components and functions, and offers earlier vulnerability decisions for analyst review. SBOM, VEX and evidence exports support release documentation and CRA preparation where applicable.

The core analysis is built in-house: the extraction engine, FirmBin (disassembly, control-flow and reachability analysis across 19 architectures), the ELF/PE binary parser, component identification and CVE matching. None of it wraps Ghidra, Capstone, radare2, angr or binwalk. Three well-known open-source components run alongside it, bundled inside the platform: QEMU for per-binary emulation and full-system boot, Unicorn as a fallback CPU emulator, and YARA for malware-rule scanning, plus standard libraries for PDF rendering, compression and cryptography. The full list is on the Security page and an SBOM of FDIE itself is available on request.

Yes. The Enterprise plan is available to smaller manufacturers and midsize teams as well as larger organisations. Start with a call covering one product, an authorised image pair, compatibility, hosting and budget. A team-arranged 21-day full-platform trial has no card requirement or automatic paid conversion; dedicated or on-premise evaluations have separately scoped terms.

No. Everything FDIE uses, including the in-house engines and the bundled open-source components (QEMU, Unicorn, YARA), ships inside the platform. Nothing needs to be installed on your side, and nothing is fetched from the customer environment at analysis time.

FDIE extracts the filesystem and binaries from an uploaded firmware image, identifies software components and library versions from the metadata it can recover (dynamic-linking data, version banners, strings and component signatures), and matches each identified component against its NVD mirror with CVSS scoring. Components without recoverable identifiers are reported as unidentified, not omitted silently. It then runs a 60-point security test suite across 9 categories: credential security, firmware update, cryptography, binary hardening, attack surface, known vulnerabilities, secure boot, runtime behaviour, and code security. These surface misconfigurations that CVE matching alone would miss.

FDIE extracts and analyzes 35 firmware and filesystem formats, including common embedded Linux images, filesystem archives, and bootloader/update package formats. Nested archives and vendor wrappers are unpacked automatically, so a single upload is usually enough to reach the binaries inside. Encrypted images are decrypted only where the vendor key is published (today: D-Link SHRS images); any other encrypted or opaque region is reported as unreadable, with its offset and size, rather than guessed at. Bring the key material or a decrypted image for those.

FDIE emulates supported firmware binaries in resource-limited sandboxes, records process and library observations, and checks behavior and crashes. Available methods depend on the image and architecture. A loaded component does not prove a CVE is exploitable; non-observation does not justify a not-affected verdict. Dynamic analysis is included in the Enterprise contract.

FDIE applies YARA content rules to extracted files and presents matching indicators alongside vulnerability candidates. Rule matches need investigation and do not guarantee identification of every implant. No match does not establish that the image is malware-free.

FDIE automates supported extraction, component identification, vulnerability matching and evidence generation. Opaque images, missing metadata or unsupported hardware can require additional preparation or investigation. Your team reviews applicability, carry-forward suggestions, patch evidence, reportability and the product assessment.

FDIE uses deterministic rules and templates for vulnerability matching, scoring and Delta Intelligence narratives, rather than language models. Results still depend on identification accuracy, coverage, configuration, engine version and vulnerability-feed context, and need review. Determinism is not a guarantee that a finding is correct.

We do not publish a validated false-positive rate. Evaluate candidate findings against your own firmware and known evidence. Review component identification, matching rules, engine version, feed context and coverage when assessing a result. A changed vulnerability feed can add or retire matches even when firmware bytes are unchanged.

FunctionDiff compares releases at the function level and highlights changed bytes for patch review. Changes identify candidates, not proven remediation. Confirming a fix requires evidence tied to the vulnerability, with review of backports, rebuilds and unchanged version strings.

Compare two analysed releases to review identified component changes, known dependencies and function changes. Earlier triage decisions are offered as suggestions with their context. An analyst decides whether they still apply, especially when component versions, coverage or vulnerability intelligence have changed. Nothing is re-applied automatically.

FDIE maps assessed firmware evidence to eleven frameworks: ETSI EN 303 645, EN 18031-1, EN 18031-2 and EN 18031-3, OWASP FSTM, NIST SP 800-193, NIST IR 8259A, IEC 62443-4-2, IEC 81001-5-1, FDA premarket cybersecurity (FD&C Act 524B) and India's TEC 31318. Grades cover assessed controls; missing evidence stays unassessed. CRA disclosure review is separate, and automated CRA conformity grading is not currently offered.

The CRA sets cybersecurity requirements for products with digital elements placed on the EU market, subject to product-specific scope and exclusions. Article 14 reporting began on 11 September 2026; the main obligations apply from 11 December 2027. FDIE supports technical evidence and disclosure review. A CVE match alone does not establish reportability, and FDIE does not certify conformity.

An SBOM (Software Bill of Materials) records identified software components, libraries and dependencies. FDIE exports CycloneDX and SPDX inventories, with coverage dependent on recovered metadata and supported formats. VEX documents record vulnerability assessments, uncertainty and reviewed analyst decisions.

TARA (Threat Analysis and Risk Assessment) and EMB3D (MITRE's threat model for embedded devices) are structured methods for describing what an attacker could do to a device, rather than listing individual vulnerabilities. FDIE builds both automatically from what it found in your firmware: the components, the exposed network services, the boot chain, and the observed runtime behaviour. It produces a TARA report, an EMB3D mapping, and a combined hybrid view. Both are generated automatically on every contract.