Camera and NVR firmware is built on a chip vendor's SDK, with a web interface, RTSP streams, ONVIF and often a cloud P2P SDK. That is where labs and attackers look first. FDIE finds default accounts, open streams, debug shells and old components in the image, and prepares the evidence for ER-01 in India and for the other markets you sell in.
The challenge
Admin, stream and ONVIF accounts shipped with one password on every camera are still a common way in. Every market's rules now start there.
RTSP without authentication, ONVIF discovery at boot, telnet and serial shells left in by the SDK. Each one widens what an attacker on the network can reach.
P2P relay SDKs make a camera reachable from the internet through a vendor's cloud. Some of these SDKs have had serious published flaws, and many teams do not know which one their image carries.
How FDIE helps
Hard-coded and default accounts for the web interface, the streams and ONVIF are found in binaries, scripts and configuration, along with private keys, tokens, empty passwords and weak password hashes. Evidence is masked, so a password never shows in full.
Device checks read the image's streamer and ONVIF configuration, its init scripts and the programs present: streams without authentication, ONVIF services started at boot, shells on UART, ADB or USB serial, telnet and FTP, and cloud P2P relay SDKs. It reads the image; it is not a network scan of your device.
Embedded Linux file systems such as SquashFS and UBIFS and vendor wrappers such as uImage are unpacked, and programs for ARM, AArch64 and MIPS are disassembled. Components from the SDK and open source come with their versions, licences and known vulnerabilities, exploited ones first.
The device checks decide several ER-01 provisions on their own, such as a checked boot image signature, signed updates with no downgrade, no hard-coded credentials and exploit mitigations. They give part of the evidence for closed debug interfaces, keys unique to each device and TLS. Where the image cannot decide, the app says what the lab will ask for.
How it works
Upload the image, import it from a GitHub or GitLab release, or let CI send every build.
FDIE unpacks the SDK image, disassembles the programs and runs the device checks, camera checks included.
Start with default accounts, open streams and known exploited flaws, then the checks ER-01 decides.
Export the pre-certification report, the ER-01 evidence and the SBOM for the lab, and keep watching the model once it ships.
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
Since 9 April 2025, BIS grants no new CCTV camera registration in India without ER-01; analog cameras are not covered. Section 889 evidence shows components from covered vendors' software for your counsel, never as a legal verdict.
Needed for new BIS registrations since 9 April 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
Component evidence for federal buyers, not a legal verdict
Version 3.1.3 of September 2024
Evidence and gap finding, not certification: the lab or certification body decides.
Deliverables
A signed PDF of the camera release's checks, findings and fixes.
Provisions decided, helped and left to you, with the evidence behind each.
The SDK and open-source components, in CycloneDX 1.6 or SPDX 2.3.
Your team's reasons a vulnerability does not affect the camera.
New flaws in a supported camera's components, by email, chat or webhook.
Accepted risks with owners and due dates, each approved by a second person.
No. It analyses the firmware image. For ER-01, the lab still tests the camera and audits manufacturing.
Embedded Linux images with SquashFS, UBIFS and other file systems, vendor wrappers such as uImage, and programs for ARM, AArch64 and MIPS. What it cannot read is listed as a coverage gap, never counted as a pass.
Yes. NVR firmware is analysed like camera firmware, x86 appliances included, and the camera checks apply wherever stream or ONVIF software is present.
When a known cloud P2P relay SDK is in the image, FDIE names it in a finding that says why it matters, so you can ask your ODM which release it is and how it is set up.
No. It shows components from covered vendors' software as evidence for counsel, never as a legal verdict.
A 45-minute call with our team. Bring one firmware image.