Industrial gateways, controllers and industrial PCs stay in service for many years, on PowerPC, ARM or x86, with an embedded Linux or an RTOS. Buyers increasingly ask for IEC 62443-4-2 evidence before they buy. FDIE reads the firmware you ship, finds what an assessor would question and shows which requirements the image can answer and which need your evidence.
The challenge
Industrial devices stay in the field far longer than consumer ones, and their Linux, OpenSSL and BusyBox versions age with them. Every year adds known vulnerabilities to a release nobody rebuilt.
Telnet, FTP, serial consoles and shared service accounts make field maintenance easy. They give an attacker on the plant network the same access.
Operators and integrators ask component makers for evidence against IEC 62443-4-2 at a security level. Assembling it by hand for every release takes weeks.
How FDIE helps
FDIE unpacks embedded Linux images such as SquashFS, UBIFS and ext4, and disassembles ELF programs for PowerPC, ARM, AArch64, MIPS and x86. Raw MIPS builds of eCos, VxWorks and other RTOSes are read too, and whatever cannot be read is listed as a coverage gap.
Device checks look for hard-coded and default accounts, accounts without a password, extra root accounts, telnet and FTP left on, services the product does not need, shells on the serial console and a web server running as root. Evidence is masked, so a password never shows in full.
Checks read the update path and the boot chain: signed updates, encrypted downloads, rollback protection, signature checks in the boot loader and integrity checks at boot. With the source connected, rules read Yocto and BitBake recipes, Kconfig and build flags for telnet servers, root without a password and hardening turned off.
The app holds IEC 62443-4-2 as a framework. Device checks give part of the evidence for requirements such as human user identification and authentication, authenticator management, unsuccessful login attempts, software and information integrity and input validation. The others, such as session control, timestamps and backup, are marked for your evidence at the security level you claim.
How it works
Upload the firmware image, import it from a GitHub or GitLab release, or let CI send each build.
FDIE unpacks the image, disassembles the programs and runs the device checks. Nothing touches your plant: with runtime evidence on, programs from the image run only under emulation in a separate isolated job.
Fix default accounts, open services and exploited flaws first, and attach evidence for the requirements the image cannot answer.
Export the SBOM, the evidence pack and signed reports, and keep the release monitored for as long as you support it.
Know the split
FDIE analyses the firmware, not the device. Knowing the split tells you what to fix before the lab and what to prepare for it.
Rules by market
IEC 62443-4-2 is voluntary, and buyers of industrial gateways and controllers often ask for it. For products sold in the EU, the EU CRA covers industrial products with digital elements too, and EN 18031 applies to internet-connected radio equipment.
Article 14 reporting since 11 September 2026; the rest from 11 December 2027
Applies since 1 August 2025
Voluntary IoT device baseline, May 2020
For industrial components such as gateways
Evidence and gap finding, not certification: the lab or certification body decides.
Deliverables
Requirements helped by the checks, and those left to you, with the evidence behind each.
Every component in CycloneDX 1.6 or SPDX 2.3, for operators and integrators.
A signed PDF of checks, findings and fixes for the release.
Your team's reasons a vulnerability does not affect the device.
New flaws in a supported product's components, for as long as its support period runs.
Accepted risks with owners and due dates, each approved by a second person.
No. It analyses the firmware image you upload. Nothing is scanned on your network, and with runtime evidence on, programs from the image run only under emulation in a separate isolated job, with the firmware's own network refused.
ELF programs for PowerPC, ARM, AArch64, MIPS and x86, raw MIPS builds of RTOSes such as eCos and VxWorks, and microcontroller images in Intel HEX and S-record files. What it cannot read is listed as a coverage gap.
No. The device checks give part of the evidence for some requirements; the security level and most requirements need your evidence and an assessor.
UEFI firmware volumes and capsules are read too, with Secure Boot checks for test keys and the revocation list. The PCs and servers page has the detail.
Yes, when you connect the repository. Rules read BitBake recipes, layers and image configuration for checksums not enforced, unverified fetches, telnet or rsh servers, remote debugging agents and root without a password.
A 45-minute call with our team. Bring one firmware image.