For engineers
Routers in India: preparing firmware for NCCS ITSAR
By Manish SharmaPublished 8 min read
Router and Wi-Fi CPE makers cannot sell in India without NCCS security certification. IP routers and Wi-Fi CPE sold in India need NCCS security certification under the ComSec scheme of MTCTE, tested against ITSAR by a designated laboratory. Version 2.0.0 of the two documents has 179 and 133 clauses. Firmware evidence helps with 39 clauses in each, and the rest needs the lab's tests on the device or the maker's documents and undertakings. TEC 31318:2025 is a voluntary 21-provision code that follows ETSI EN 303 645, so work done for it carries over.
In short
- IP routers and Wi-Fi CPE (home routers, modems and access points) sold in India need NCCS security certification, tested against ITSAR by a designated lab.
- Firmware evidence helps with 39 clauses in each ITSAR document, while the lab's device tests and your documents settle the rest.
- TEC 31318 is voluntary, but it follows ETSI EN 303 645, so the work also counts for buyers abroad.
How ITSAR certification works
NCCS writes the requirements, a designated Telecom Security Testing Laboratory (TSTL) tests the product, and NCCS certifies it. This is the ComSec scheme of MTCTE, separate from TEC's certification of technical parameters.
NCCS's notification of 16 April 2024 set the dates. Models not yet certified by TEC under MTCTE needed security certification from 1 July 2024. TEC-certified models already in an operator's network needed it from 1 October 2024 if their hardware or software changed. Until then, products could use Voluntary Security Certification.
| Document | Number | Version | Released | Clauses | Scope |
|---|---|---|---|---|---|
| ITSAR for IP routers | ITSAR201012512 | 2.0.0 | 1 December 2025 | 179 | Core, edge and other IP routers |
| ITSAR for Wi-Fi CPE | ITSAR402122512 | 2.0.0 | 1 December 2025 | 133 | Wi-Fi routers and modems, broadband and cable modems with Wi-Fi, access points and controllers |
When we read both documents, their enforcement dates were blank. Version 1.0.1 of each, from January 2024, applied when certification became mandatory. Ask your TSTL which version your test follows.
What the clauses test
Chapter 2 holds the common requirements and chapter 3 the product-specific ones. The router document has 90 common clauses and 89 specific ones, while the Wi-Fi CPE document has 80 and 53.
| Section (router numbering) | What it asks | Can firmware show it? |
|---|---|---|
| 2.1 Access and authorisation | Authenticated management interfaces, protected management traffic, role-based access | Partly: credential checks, HTTPS on the management interface |
| 2.2 Authentication attributes | Brute-force protection, strong passwords, default attributes removed, session timeouts | Partly: default and hard-coded credentials, password hashes, brute-force protection |
| 2.3 Software security | Secure update and upgrade, source code assurance, malware check, no unused software or services | Partly: update signatures, known malware, the SBOM, network services |
| 2.4 Secure execution environment | No unused functions, no unsupported components | Partly: end-of-life components |
| 2.5 User audit | Audit trail, event generation, log export | Partly: security events logged |
| 2.6 Data protection | Cryptography as NCCS prescribes, protected storage | Partly: TLS versions, ciphers, key sizes, clear text credentials |
| 2.7 and 2.8 Network services and attack prevention | Traffic filtering, anti-spoofing, DDoS and overload protection | No: tested on the device |
| 2.9 Vulnerability testing | Fuzzing, port scanning, vulnerability scanning | Partly: known vulnerabilities in the components |
| 2.10 Operating system | Privilege escalation, account identification, buffer overflow protection | Partly: binary hardening, only root with user id 0 |
| 2.11 Web servers | HTTPS, input validation, no system privileges, no default content | Partly: web server user, HTTPS, injection checks on scripts |
| 2.12 Other | Integrity checks at installation and boot, unused interfaces, predefined accounts | Partly: boot and update integrity, accounts |
Chapter 3 of the router document covers routing, APIs, SDN, orchestration, virtual and container network functions, and Wi-Fi access. Sections 3.3 to 3.9 hold 57 clauses that apply only to routers with SDN or virtualised parts. In the Wi-Fi CPE document, 28 clauses in sections 3.4 and 3.5 work the same way.
Four clauses to read closely
These four clauses decide a lot of the lab's work, and three of them touch the firmware directly.
2.9.3 Vulnerability scanning. The lab scans for known vulnerabilities, and the document sets fix deadlines by CVSS score.
| Severity | CVSS | Deadline in ITSAR |
|---|---|---|
| Critical | 9.0 to 10.0 | Patched immediately |
| High | 7.0 to 8.9 | Within a month |
| Medium | 4.0 to 6.9 | Within three months |
| Low | 0.1 to 3.9 | Within a year |
Zero-day vulnerabilities are to be fixed immediately or as soon as possible, and the maker gives a remediation plan for the rest. Matching your SBOM against vulnerability data before submission shows what the lab is likely to find.
2.2.8 Removal of default authentication attributes (2.2.7 for Wi-Fi CPE). Default passwords and keys must be deleted or disabled, by forcing a change at first login or with clear instructions. Firmware shows published default credentials and hard-coded ones, while the lab checks the first-login flow.
2.3.3 and 2.3.4 Source code and malware. The maker makes source code available for review by the TSTL and signs undertakings on secure coding. For Wi-Fi CPE, that covers the CWE Top 25, the OWASP Top 10 and the OWASP API Top 10. A malware undertaking and an internal Malware Test Document go with it.
2.4.3 No known vulnerabilities in the system on chip (Wi-Fi CPE only). The maker gives a self-test, third-party or chip vendor report that the SoC is free from malware and known vulnerabilities. Older products may instead show a listing on the Trusted Telecom Portal. A firmware analysis sees the software on the chip, not the silicon, so the chip vendor's report is still needed.
What firmware evidence covers, in numbers
Of the 312 clauses in the two documents, device checks decide 5 on their own and help with 73. The other 234 need the lab's tests or your documents.
| Document | Clauses | Decided by device checks | Checks help | Lab tests or your evidence |
|---|---|---|---|---|
| ITSAR for IP routers | 179 | 3 | 36 | 140 |
| ITSAR for Wi-Fi CPE | 133 | 2 | 37 | 94 |
The automatic clauses are the web server running without system privileges (2.11.4) and software integrity checks. For routers, those checks are clause 2.12.4 at installation and 2.12.5 at boot; for Wi-Fi CPE, clause 2.12.4 at boot.
A firmware check before you submit
Run these checks on the exact build you will hand to the TSTL, because each maps to a clause the lab will test.
- Default credentials (2.2.8): no published default password, no hard-coded credential and no account without a password in the image.
- Updates (2.3.1 and 2.3.2): the update code verifies a signature and refuses unsigned or tampered packages.
- Services (2.3.5 and 2.3.6): telnet and FTP are off, and every listening service appears in your list of needed software.
- Known vulnerabilities (2.9.3): no critical or high item past its deadline, and a written plan for the medium and low ones.
- Cryptography (2.6.1): only what NCCS's ITSAR for Cryptographic Controls allows; the image shows TLS versions, weak ciphers and key sizes.
- Web interface (2.11): the web server does not run as root, HTTPS is on, and the scripts show no command or path injection.
- Hardening (2.10.7): programs built with stack protection and a non-executable stack, which the OEM must also document for the lab.
A clean result here does not mean the lab will pass the product. It means the lab is less likely to find something you could have fixed at your desk.
TEC 31318: the voluntary code
TEC 31318:2025 is a short, free code for consumer IoT. Release 2.0, from November 2025, revises the 2021 release to follow ETSI EN 303 645 V3.1.3.
It has 13 security guidelines and 8 data protection provisions. Its data section points makers to the Digital Personal Data Protection Rules, 2025, under the DPDP Act, 2023. Its executive summary also says that IoT devices must go through MTCTE testing and certification before sale, import or use in India.
| TEC 31318 | ETSI clause | How FDIE decides it |
|---|---|---|
| 3.1 No universal default passwords | 5.1 | Partly automatic |
| 3.2 Manage reports of vulnerabilities | 5.2 | Automatic, with your disclosure policy |
| 3.3 Keep software updated | 5.3 | Partly automatic |
| 3.4 Store security parameters securely | 5.4 | Automatic |
| 3.5 Communicate securely | 5.5 | Automatic |
| 3.6 Minimise exposed attack surfaces | 5.6 | Automatic |
| 3.7 Ensure software integrity | 5.7 | Automatic |
| 3.8 Personal data secure | 5.8 | Needs evidence |
| 3.9 Resilient to outages | 5.9 | Partly automatic |
| 3.10 Examine telemetry | 5.10 | Partly automatic |
| 3.11 Easy deletion of user data | 5.11 | Needs evidence |
| 3.12 Easy installation and maintenance | 5.12 | Needs evidence |
| 3.13 Validate input data | 5.13 | Automatic |
| 4(i) to 4(viii) Data protection | 6 | Needs evidence |
How the two relate
ITSAR is a certification gate for telecom equipment, while TEC 31318 is a voluntary baseline for consumer devices. A home Wi-Fi router can meet both: ITSAR before sale, and TEC 31318 because buyers know it.
They overlap on the same firmware facts, so one analysis answers both.
| Topic | ITSAR (router) | TEC 31318 |
|---|---|---|
| Default passwords | 2.2.8 | 3.1 |
| Secure updates | 2.3.1, 2.3.2 | 3.3 |
| Cryptography in transit | 2.6.1 | 3.5 |
| Unneeded services | 2.3.6 | 3.6 |
| Integrity at boot | 2.12.5 | 3.7 |
| Input validation | 2.11.3 | 3.13 |
The difference is the method. ITSAR is test-centred, with lab test cases, undertakings and source review, while TEC 31318 states outcomes.
How FDIE helps, and where it stops
A product of device type Router gets both ITSAR documents, and a gateway gets the Wi-Fi CPE one. Each clause shows the device checks and findings behind it, and your team attaches test reports, documents and undertakings.
- Before the lab: analyse the exact build you will submit, and fix critical and high vulnerabilities against the 2.9.3 deadlines.
- Between versions: compare each release with the one before, since a new component can reopen a clause you had closed.
- At submission: export the SBOM and the evidence pack with your documents.
The app follows version 2.0.0 of both documents, so check the version with your lab first. Our evidence is not a TSTL report: the lab still tests the device, and NCCS issues the certificate. For every Indian rule by product, see device security rules in India.
Questions
Is NCCS security certification mandatory for Wi-Fi routers in India?
Yes. NCCS's notification of 16 April 2024 made it mandatory from 1 July 2024 for IP router and Wi-Fi CPE models not yet certified by TEC under MTCTE. It also applies from 1 October 2024 to certified models in an operator's network that change hardware or software.
Which ITSAR version applies to my router?
Version 2.0.0 of both documents was released on 1 December 2025, and its enforcement date was blank when we read it. Version 1.0.1 applied when certification became mandatory, so confirm with your lab which version your test follows.
Is TEC 31318 mandatory?
No. It is a voluntary code of practice published as a TEC technical report. Release 2.0, TEC 31318:2025, follows ETSI EN 303 645 V3.1.3.
Can a firmware analysis replace testing by a TSTL?
No. A designated lab tests the device and reviews your documents and source code. A firmware analysis helps you find and fix problems before you submit, and gives evidence for the clauses it can see.
Sources
- NCCS notification on security certification of IP Router and Wi-Fi CPE under the ComSec scheme of MTCTE, 16 April 2024 (PDF) nccs.gov.in
- NCCS ITSAR for IP routers, ITSAR201012512, version 2.0.0, released 1 December 2025 (PDF) nccs.gov.in
- NCCS ITSAR for Wi-Fi CPE, ITSAR402122512, version 2.0.0, released 1 December 2025 (PDF) nccs.gov.in
- NCCS ITSAR for Wi-Fi CPE, ITSAR402122401, version 1.0.1 (PDF) nccs.gov.in
- National Centre for Communication Security (NCCS) nccs.gov.in
- TEC MTCTE portal mtcte.tec.gov.in
- TEC 31318:2025, Code of Practice for Securing Consumer IoT, Release 2.0 (PDF) tec.gov.in
- ETSI EN 303 645 V3.1.3, Cyber Security for Consumer Internet of Things (PDF) etsi.org
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.