For engineers
One firmware analysis for India, the EU and the US
By Manish SharmaPublished Reviewed 6 min read
Founder and CEO, MAGDOX. Writes on firmware security and device regulation.
India, the EU and the US ask device makers the same technical questions in different words: no default passwords, signed updates, encrypted traffic, only the services the device needs, and no known exploitable vulnerabilities. One firmware analysis can answer those questions once and map each answer to the provision that asks it, from MeitY ER: 01 and NCCS ITSAR to the EU Cyber Resilience Act for products sold in the EU, EN 18031-1, NIST IR 8425 and the California and Oregon laws. Lab tests, procedures and policy documents still come from you.
In short
- India, the EU and the US ask the same technical questions of a device's firmware, each in its own words.
- One analysis of the image answers each question once; the answer then maps to every provision that asks it.
- What the image cannot show (lab tests, procedures, policies, supplier statements) still comes from you, and each framework says which.
The same questions, in different words
A Wi-Fi camera sold in India, the EU and the US meets at least five documents: MeitY's ER: 01, the EU Cyber Resilience Act for products sold in the EU, EN 18031-1 under the Radio Equipment Directive, NIST IR 8425 and the California and Oregon connected device laws. A router adds NCCS ITSAR. Read side by side, they keep asking the same things:
- Is there a default or hard-coded password?
- Are updates signed, and checked before they are installed?
- Is traffic encrypted with current TLS?
- Are only the needed network services running?
- Does the image ship known exploitable vulnerabilities?
A published default password in the image is the same fault under ER: 01 clause 2.6, CRA Annex I Part I (2)(b), EN 18031-1 AUM-5 and California Civil Code 1798.91.04(b). Finding it once, and recording which provisions it touches, saves the same work three or four times over.
The frameworks in this crosswalk
| Market | Framework | Status | Applies to |
|---|---|---|---|
| India | MeitY ER: 01 | Mandatory since 9 April 2025 | CCTV cameras registered with BIS, tested by STQC recognised labs |
| India | NCCS ITSAR, version 2.0.0 | Mandatory under MTCTE | IP routers and Wi-Fi CPE, tested by NCCS designated labs |
| India | TEC 31318:2025 | Voluntary code of practice | Consumer IoT; it follows ETSI EN 303 645 V3.1.3 |
| EU | Cyber Resilience Act, Annex I | Article 14 reporting from 11 September 2026; Annex I from 11 December 2027 | Products with digital elements sold in the EU |
| EU | EN 18031-1 | Mandatory under the Radio Equipment Directive since 1 August 2025 | Internet-connected radio equipment |
| US | NIST IR 8425 | Voluntary | Consumer IoT; the criteria behind the US Cyber Trust Mark |
| US | The California and Oregon laws: Cal. Civ. Code 1798.91.04 and ORS 646A.813 | Mandatory | Connected devices sold in California, consumer connected devices sold in Oregon |
| US | NDAA section 889 and FAR 52.204-25 | Mandatory in federal procurement | Equipment sold to US federal agencies and their contractors |
The crosswalk, check by check
Each row is a group of device checks that FDIE decides from the firmware image. The cells name the provisions each group gives evidence for. A blank cell means that framework has no provision for it, not that the fault is acceptable there.
| What the image shows | India | EU (products sold in the EU) | US |
|---|---|---|---|
| No hard-coded, default or empty passwords | ER: 01 2.6; ITSAR 2.2.8; TEC 31318 3.1 | CRA Part I (2)(b) and (d); EN 18031-1 AUM-5 | NIST IR 8425 Interface Access Control 1(b); Cal. Civ. Code 1798.91.04(b); ORS 646A.813(2) |
| Updates signed and checked before install | ER: 01 2.10; ITSAR 2.3.1 and 2.3.2; TEC 31318 3.3 | CRA Part II (7); EN 18031-1 SUM-2 | NIST IR 8425 Software Update 1 |
| No downgrade to older firmware | ER: 01 2.11; ITSAR 2.12.3 | CRA Part I (2)(f) | |
| Boot image signature and integrity checked | ER: 01 1.8; ITSAR 2.12.5; TEC 31318 3.7 | CRA Part I (2)(f); EN 18031-1 SSM-2 | |
| TLS 1.2 or later, no SSL, management over HTTPS | ER: 01 2.2; ITSAR 2.6.1; TEC 31318 3.5 | CRA Part I (2)(e); EN 18031-1 SCM-1 to SCM-3 | NIST IR 8425 Data Protection 3 |
| No weak hashes or ciphers (MD5, SHA-1, DES, RC4, ECB) | ITSAR 2.6.1 and 2.6.3; TEC 31318 3.5 | CRA Part I (2)(e) and (f); EN 18031-1 CRY-1 | NIST IR 8425 Data Protection 3 |
| Telnet and FTP off, only needed services | ITSAR 2.3.6; TEC 31318 3.6 | CRA Part I (2)(j); EN 18031-1 GEC-2 | NIST IR 8425 Interface Access Control 1(a) |
| No shell on the serial console | ER: 01 1.1; ITSAR 2.12.6; TEC 31318 3.6 | CRA Part I (2)(j); EN 18031-1 GEC-5 | NIST IR 8425 Interface Access Control 1(a) |
| No high, critical or known exploited vulnerability | ITSAR 2.9.3; TEC 31318 3.3 | CRA Part I (2)(a); EN 18031-1 GEC-1 | |
| No known malware | ER: 01 4.3; ITSAR 2.3.4; TEC 31318 3.3 | CRA Part I (2)(a) | |
| A software bill of materials | TEC 31318 3.3 | CRA Part II (1) | |
| Disclosure policy referenced in the firmware | TEC 31318 3.2 | CRA Part II (5) | |
| Software from the companies section 889 names | Evidence for NDAA 889(f)(3)(A) and (B) |
The last row is evidence, not a verdict. FDIE shows software from Huawei (including HiSilicon), ZTE, Hytera, Hikvision or Dahua found in the firmware, for your legal review. Whether a product is covered equipment is a legal question.
What the image cannot show
Every framework also asks for things that live outside the firmware. Of their provisions, these have at least one automated check today; the rest need a lab test, a procedure, a document or a link:
| Framework | Provisions | With an automated check |
|---|---|---|
| ER: 01 | 30 | 12 |
| NCCS ITSAR for IP routers | 179 | 39 |
| TEC 31318:2025 | 21 | 10 |
| CRA Annex I | 22 | 13 |
| EN 18031-1 | 31 | 22 |
| NIST IR 8425 | 33 | 8 |
| California and Oregon laws | 3 | 2 |
| NDAA 889 | 3 | 0 |
The gaps are predictable. ITSAR leans on lab test reports, because NCCS designated labs test the running router. NIST IR 8425 asks mostly for documentation and for how you receive and share security information. The CRA asks for processes, such as remediating vulnerabilities without delay, alongside the technical requirements. ER: 01 asks for a malware scanning procedure during development, not only a clean image. California's "reasonable security features" is a judgement a document has to argue.
FDIE marks each of these provisions as needing evidence and names the kind (a test report, a procedure or a document), so the open items form a list your team can work through rather than a surprise from the lab.
How to run it, release by release
- Analyse each firmware release as you build it, not the week before submission.
- Fix what the checks find, and record a VEX statement for each vulnerability that does not affect the product, with the reason.
- Compare each release with the one before, so a new vulnerability or a reopened service is caught when it is introduced.
- Export the evidence for each market from the same analysis, and add your documents, procedures and lab reports where the framework asks for them.
The lab still decides. What changes is that you arrive knowing what it will find.
Questions
Can one firmware analysis cover several markets?
For the technical facts in the image, yes: a default password, an unsigned update or an outdated TLS library is the same fault under every market's rules. Each framework also asks for documents, procedures and lab tests that no analysis of the image can produce.
Does passing these checks mean a device passes ER: 01 or NCCS ITSAR?
No. STQC recognised labs test cameras for ER: 01 and NCCS designated labs test routers and Wi-Fi CPE for ITSAR. The checks find gaps before you submit and prepare the evidence; the lab makes the final call.
Which US rules apply to connected devices?
The California and Oregon laws (California Civil Code 1798.91.04 and ORS 646A.813) apply to connected devices sold there and require a unique password or new credentials at first use. NIST IR 8425 is a voluntary baseline, the criteria behind the US Cyber Trust Mark. Section 889 of the FY2019 NDAA bars covered equipment from five named companies in US federal procurement.
When does the EU Cyber Resilience Act apply?
For products with digital elements sold in the EU, reporting under Article 14 applies from 11 September 2026 and the essential requirements of Annex I from 11 December 2027. Radio equipment must already meet EN 18031 under the Radio Equipment Directive since 1 August 2025.
Can a firmware analysis prove NDAA 889 compliance?
No. It can show software from the named companies found in the firmware, which is evidence for your legal review. Whether a product is covered equipment is a legal question, and your suppliers' representations under FAR 52.204-24 and 52.204-26 are documents only they can give.
Sources
- BIS, Guidelines for implementation of Essential Requirement(s) for Security of CCTV, 22 October 2024 (PDF) crsbis.in
- NCCS ITSAR for IP routers, ITSAR201012512, version 2.0.0, released 1 December 2025 (PDF) nccs.gov.in
- TEC 31318:2025, Code of Practice for Securing Consumer IoT, Release 2.0 (PDF) tec.gov.in
- Regulation (EU) 2024/2847, the Cyber Resilience Act (EUR-Lex) eur-lex.europa.eu
- Commission Delegated Regulation (EU) 2022/30 (EUR-Lex) eur-lex.europa.eu
- Commission Implementing Decision (EU) 2025/138 citing EN 18031-1, -2 and -3 with restrictions (EUR-Lex) eur-lex.europa.eu
- NIST IR 8425, Profile of the IoT Core Baseline for Consumer IoT Products csrc.nist.gov
- California Civil Code section 1798.91.04 (California Legislative Information) leginfo.legislature.ca.gov
- Oregon Revised Statutes 646A.813 oregon.public.law
- FAR 52.204-25, implementing section 889 of the FY2019 NDAA (Acquisition.gov) acquisition.gov
Product and project names are trademarks of their owners, used only to identify the public firmware, software and standards discussed. MAGDOX is not affiliated with or endorsed by them.