Why we are building FDIE for device makers

The problem we keep hearing

A camera maker submits a model to the lab and learns, weeks later, that the firmware fails. A router maker answers a tender and is asked for a software bill of materials it has never produced. An exporter is asked by a distributor in Europe how it handles vulnerabilities, and nobody in the company owns the answer.

The thread through all three: device makers learn about security problems in their firmware late, from someone else, and often in code they never wrote. A camera or router image carries the chip vendor's SDK, a Linux kernel, a web server, a TLS library and dozens of other components. Most of it arrived with the board support package. Very little of it was reviewed by the team that ships the product.

Why it matters more now

For years firmware security was optional for many device makers. That has changed, market by market:

• In India, CCTV cameras registered with BIS have needed an ER: 01 security test report since 9 April 2025, and IP routers and Wi-Fi CPE have needed NCCS security certification since 1 July 2024.
• CERT-In's SBOM guidelines of 9 July 2025 recommend that buyers in government and essential services ask for SBOMs, and device buyers have started asking too.
• In the United Kingdom, the PSTI rules have banned universal default passwords and required a way to report security issues and a stated support period since 29 April 2024.
• For products sold in the EU, the Cyber Resilience Act makes manufacturers report actively exploited vulnerabilities from 11 September 2026, with its other obligations from 11 December 2027.

Each rule asks the same question in its own words: for this release, can you show what is inside and what you did about it?

What we are building

FDIE, the Firmware Delta Intelligence Engine, is our answer. It is a hosted service that starts from the firmware image itself, the file you actually ship:

• It unpacks the image and lists the components it finds, as an SBOM in CycloneDX and SPDX.
• It matches those components against public vulnerability data, with known exploited vulnerabilities first.
• It checks the image for what labs and buyers look for: default credentials, hard-coded secrets, weak cryptography and exposed network services.
• It compares each release with the one before, so you can see what an update fixed and what it brought in.
• It maps what it finds to the rules of each market you sell in, and prepares the evidence.

We start from the image because it is what ships. Source code tells you what your team wrote; the image also shows what the chip vendor's SDK and every bundled library put on the device.

What it will not do

FDIE will not certify a device. A test lab or a certification body makes the final call, and our reports will say so. What we can do is help you find the gaps before you submit, and arrive with evidence rather than guesses.

We will also claim only what the product does today. When something is still in development, we will say that too.

Who it is for

We are building FDIE for makers of IP cameras, NVRs, routers, gateways, doorbells and similar connected devices. We are starting in India, with data hosted in India, and with Indian makers who export to Europe and the United Kingdom.

If your team answers labs, tenders or buyers about firmware security, we would like to hear what slows you down. Write to us through the contact page.

Update, October 2026

Since this post, FDIE by Magdox has opened to device makers by invitation, and each organisation now chooses where its data is hosted: India, the European Union or the United States. Later posts on this blog go deeper into each market's rules and into how FDIE analyses an image.