Smart plugs, sensors, hubs and video doorbells are consumer products sold in many markets, and many run on a microcontroller rather than Linux. Every market's rules start with passwords, then ask for a way to report vulnerabilities and a stated period of updates. FDIE checks the firmware and prepares that evidence.
The challenge
Devices pair with an app and talk to a cloud service. A key or token that every unit shares means one extracted device exposes them all.
Setup modes with open access points, static WPS PINs or Wi-Fi passwords in the image are easy to ship and hard to recall from customers' homes.
UK PSTI, EN 18031 for radio equipment in the EU and ETSI EN 303 645 expect no universal default passwords, a published way to report vulnerabilities and a stated update period.
How FDIE helps
Bare-metal images for ESP32 and Cortex-M are read from Intel HEX, S-record, UF2 and DfuSe files and laid out as one image with its entry point and interrupt handlers. ESP images give the ESP-IDF version and the application's name, and Linux hubs and doorbells are read like any embedded Linux image.
Hard-coded passwords, default accounts, private keys, API keys and tokens are found in the image and shown masked. Anything in the image ships on every unit, so a shared private key or cloud token is flagged before one extracted device gives it away.
Device checks look at the update path: signed updates, an encrypted download channel, rollback protection and unsigned updates rejected. With the source connected, rules read ESP-IDF and Zephyr build settings for secure boot and flash encryption, and device settings for Wi-Fi with WEP, WPA1, TKIP or a static WPS PIN.
For UK PSTI, the checks give evidence for no universal default passwords, and the disclosure policy and support period you record for the product cover the other two requirements. The same records feed ETSI EN 303 645, EN 18031 and, for products sold in the EU, the EU CRA.
How it works
A Linux image or a microcontroller file such as Intel HEX, UF2 or an ESP image.
FDIE lays out the image, identifies its components and runs the device checks. With runtime evidence on, programs from the image also run under emulation in a separate isolated job.
Add the product's disclosure policy and support period once; they feed every market's evidence.
Export the evidence and reports, and get alerts for new flaws for as long as the product is supported.
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
UK PSTI has applied to consumer connectable products sold in the UK since 29 April 2024. EN 18031 applies to radio equipment in the EU until the EU CRA applies in full on 11 December 2027. California and Oregon require reasonable security and unique passwords.
Voluntary code for consumer IoT, Release 2.0 of November 2025
Article 14 reporting since 11 September 2026; the rest from 11 December 2027
Applies since 1 August 2025
In force since 29 April 2024
Since 1 January 2020
Voluntary consumer IoT baseline, September 2022
Version 3.1.3 of September 2024
Evidence and gap finding, not certification: the lab or certification body decides.
Deliverables
The three requirements, from the image and from what you record for the product.
A signed PDF of checks, findings and fixes for the release.
Linux and microcontroller components in CycloneDX 1.6 or SPDX 2.3.
Your answer when a vulnerability does not affect the device.
New flaws in the product's components, for as long as you support it.
Accepted risks with owners and due dates, each approved by a second person.
Yes. ESP32, ESP32-S2, ESP32-S3 and ESP8266 images on Xtensa, ESP32-C and ESP32-H images on RISC-V, and Cortex-M and other microcontrollers in Intel HEX, S-record, UF2 and DfuSe files.
It gives evidence for PSTI's requirements from the image and from what you record for the product, such as its disclosure policy and support period.
Yes. When a doorbell's image carries stream or ONVIF software or a cloud P2P SDK, the camera checks apply, as they do for IP cameras.
No. FDIE analyses the firmware and, if you connect it, the source code. Pairing, radio and the running device stay with your testers.
Connect their repositories and the code engine reads them too, with their findings beside the device's in the same product.
A 45-minute call with our team. Bring one firmware image.