For makers of IP cameras, NVRs, routers, gateways and doorbells

Find firmware security problems before the test lab

The problems that fail cameras and routers at the test lab often sit in code you never wrote: an old OpenSSL, telnet left on, a default password in the chip vendor's SDK. See each one in your firmware before you submit.

Request access
  • See what the chip vendor's SDK put in your firmware
  • Answer "are we affected?" when a flaw makes the news
  • Prove each update fixed what it promised
The FDIE by Magdox home dashboard: tiles for releases ready to ship, blocked releases, open critical findings, known exploited vulnerabilities, overdue risks and the next report due, a table of releases needing a decision, and an Article 14 early warning deadline with its notification clock.The same screen in the light theme.
The home dashboard, shown with the app's sample organisation.

In numbers

frameworks for India, the EU, the US and international standards
14
device checks in 9 groups
64
code rules, firmware source first
1,774
instruction sets disassembled
22

Vulnerability data from NVD, OSV, the CISA Known Exploited Vulnerabilities catalogue and FIRST EPSS.

How it works

  1. Upload the firmware you plan to ship

    An image of up to 8 GiB, or imported from GitHub or GitLab. Connect its source code if you have it; you do not need it.

  2. We read everything inside it

    Our own readers unpack the image and disassemble its programs; the code engine scans the source. Nothing in the image is run.

  3. Fix what would fail, then ship

    A ship or hold decision with its reasons, findings with owners, and reports for your lab, your buyers and tenders.

Before the lab, the tender and the news

Screens from the app, shown with its sample organisation.

See the product

Stop finding failures at the lab

Every release is checked against your release rules before it leaves your team, with the reasons it would fail. What the analysis could not check is named, never counted as a pass.

A firmware release overview for camera firmware v4.2.1: the release gate blocked on four rules, among them one known exploited vulnerability and critical findings, severity counts compared with the previous release, what is inside the image (components, binaries, file systems, kernel version) and the coverage gaps the analysis could not check.The same screen in the light theme.

Know the day a flaw affects you

Components are matched to known vulnerabilities from NVD and OSV, the ones attackers already use first (CISA KEV), then by how likely they are to be exploited (EPSS), with whether your programs call the vulnerable code. Shipped releases are checked again every day.

The vulnerabilities list: one row per CVE with the affected component, where it was found in firmware and code repositories, severity, EPSS probability, whether the product calls the vulnerable function, applicability, VEX status and the version that fixes it, with known exploited entries from CISA KEV marked.The same screen in the light theme.

Prove an update fixed what it promised

Compare two releases: what was added, removed or upgraded, and whether each vulnerability is fixed in the code itself, even when the version string did not change. Share it as a delta report.

Delta for the sample camera, comparing firmware v4.1.9 with v4.2.1: a note that coverage gaps limit the comparison, counts of components added, removed, upgraded and downgraded, new and no longer matched vulnerabilities, patch states (fix verified, patch candidate, still vulnerable), and the start of the component changes table.The same screen in the light theme.

Evidence ready for the lab, the tender and the buyer

Each requirement of India's CCTV and router security rules, and of the other markets you sell in, with its status and the evidence behind it, for each analysed release.

Compliance by market

  • India

    • TEC 31318:2025
    • MeitY ER-01
    • NCCS ITSAR for IP routers
    • NCCS ITSAR for Wi-Fi CPE

  • European Union

    • EU Cyber Resilience Act, Annex I
    • EN 18031-1
    • EN 18031-2
    • EN 18031-3
    • prEN 40000 drafts

  • United States

    • NIST IR 8425
    • NIST IR 8259A

  • International

    • ETSI EN 303 645
    • IEC 62443-4-2
    • OWASP FSTM

Fix faster with AI on your own key

Connect your own AI provider to explain findings, propose triage and suggest code fixes that a person opens as pull requests. Without a key, every result still comes from our rules and engines.

AI in detail

People decide

AI explains and proposes. It never changes evidence, and a person accepts or rejects every proposal.

Never trained on your data

Not by us, and not by anyone else.

How we work

Gaps named, never hidden

Formats we cannot read and programs past the time budget are listed as coverage gaps.

Two-step sign-in for everyone

Each organisation is kept apart in the database, and the audit log cannot be changed by the app.

An Indian company

MAGDOX Private Limited, founded in 2025 and led by Manish Sharma, Chief Executive Officer.

Find out what the lab would flag in your firmware

A 45-minute call with our team. Bring one firmware image.

Request access