MTCTE certification is a market access requirement, not a quality mark. Wi-Fi access points, routers, and customer premises equipment that have not been certified cannot be legally imported, sold, or deployed in India. The scheme has been in force since 2021 and the product categories in scope have expanded consistently since launch.
For OEMs in the Wi-Fi and router space, the practical question is not whether MTCTE applies. It almost certainly does. The question is what the certification process involves, which CAB will assess the product, and how to arrive at that assessment prepared rather than surprised.
This guide answers those questions specifically for Wi-Fi and router OEMs.
In This Guide
Which Wi-Fi and Router Products Need MTCTE Certification
The MTCTE scheme covers equipment categories defined by the Department of Telecommunications. For Wi-Fi and router OEMs, the relevant categories include Wi-Fi Access Points, Customer Premises Equipment, WLAN Controller Equipment, and network routing equipment across both enterprise and carrier product lines.
Wi-Fi Access Points covers indoor and outdoor access points across the current Wi-Fi generations. This includes standalone access points and those designed to operate as part of a managed WLAN infrastructure. The category applies regardless of whether the access point is sold for enterprise, residential, or carrier deployment.
Customer Premises Equipment covers the broadband routers and residential gateways that operators deploy at subscriber premises. This is one of the largest categories by volume in the Indian market given the scale of broadband infrastructure investment across the country. CPE that combines routing, wireless, and voice functions is assessed as a single product across all its implemented functions.
WLAN Controller Equipment covers the management and control plane infrastructure that manages large-scale Wi-Fi deployments. Controllers that manage access point configuration, firmware distribution, and network policy are within scope.
Network routing equipment covers routers deployed in carrier, enterprise, and small business environments. The product categories are defined by the TEC and OEMs should verify the current category definitions before planning a certification programme, as the scheme continues to expand.
The safe working assumption for any OEM with products that connect to or operate within Indian telecommunications networks is that MTCTE certification is required unless a specific product category has been confirmed as out of scope. The cost of that assumption being wrong after products have entered the market is considerably higher than the cost of confirming scope before it.
How the CAB Assessment Process Works
The MTCTE certification process runs through TEC-designated Conformity Assessment Bodies. The OEM selects a CAB designated for their equipment category, submits the product with a complete technical file, and the CAB conducts the assessment against the applicable standards. Certification is issued by the TEC on the basis of the CAB’s assessment report.
The CAB selection matters more than it might appear. Not all CABs are designated for all equipment categories, and CABs differ in their technical capability, testing throughput, experience with international OEM submissions, and the specific test infrastructure they operate. For Wi-Fi and router equipment in particular, the range and depth of protocol testing capability across designated CABs varies. Selecting a CAB with strong protocol testing infrastructure for Wi-Fi and router products avoids the mismatch of discovering mid-assessment that the lab lacks a specific test capability.
The technical file submitted with the product needs to be complete before the assessment begins. This includes the product specification, a description of all implemented protocols and their version details, the applicable standards the product is being assessed against, and the software and firmware version under test. Incomplete technical files are a common cause of assessment delays that have nothing to do with the product itself.
Timeline expectations need to be realistic. For Wi-Fi and router equipment with security testing requirements, the process from initial application to certification mark typically runs to several months. OEMs that treat MTCTE as a final step before launch rather than a planned stage in the market entry timeline create schedule pressure that consistently produces worse outcomes than planned programmes.
What CAB Testing Covers for Wi-Fi and Router Equipment
CAB testing for Wi-Fi and router equipment covers several categories of requirement. Understanding each helps OEMs identify where preparation effort is best spent.
Electromagnetic compatibility and radio frequency testing covers the RF characteristics of the product: transmit power, frequency accuracy, occupied bandwidth, and the emission characteristics that determine whether the product interferes with other equipment. This is the most technically specialised part of the assessment and the part where OEMs typically have the most preparation experience from certifications in other markets.
Protocol conformance testing covers whether the device correctly implements the communication protocols it claims to support. For Wi-Fi equipment this includes the 802.11 protocol family. For routing equipment it includes the routing protocols the device implements. Conformance testing checks correct behaviour for valid inputs and is well understood by most OEM test programmes.
Security testing is the component where OEM preparation is most consistently inadequate and where the most significant assessment findings emerge. It is covered separately in the next section.
Interoperability testing in some equipment categories verifies that the device works correctly with other equipment it is expected to connect with. This is most relevant for CPE that must interoperate with operator infrastructure.
The Security Testing Component
Security testing in MTCTE assessments for Wi-Fi and router equipment covers how the device behaves under security-relevant conditions. This is categorically different from conformance testing and requires different preparation.
The security testing scope for Wi-Fi and router equipment covers the protocol surfaces that the device exposes across its interfaces. For management plane protocols, this includes CWMP TR-069, NETCONF, SNMPv3, and SSHv2. For network layer protocols, it includes DHCP, ARP, and DNS handling. For routing equipment, it extends to BGP and OSPF. For wireless infrastructure, it covers WPA2 and WPA3 implementation robustness.
For each of these protocol surfaces, security testing assesses how the device handles traffic that deviates from the specification: malformed messages, out-of-range field values, unexpected sequences, and inputs the implementation was never designed to receive. A device that crashes, hangs, exposes internal state information, or accepts and incorrectly processes malformed input has a security finding that will appear in the CAB assessment report.
The finding categories that appear most consistently in Wi-Fi and router security assessments include buffer overflows in DHCP option handling, input validation failures in CWMP TR-069 parameter processing, denial-of-service conditions triggered by malformed management plane requests, and authentication handling failures in WPA2 and WPA3 implementations.
None of these are obscure or unusual. They are the vulnerability classes that systematic security testing reliably surfaces in equipment that has been conformance tested but not security tested. OEMs that pre-test their protocol implementations before CAB submission find these themselves. OEMs that do not find them in the assessment report.
- CWMP TR-069 → https://cytal.co.uk/protocols/cwmp-tr-069-cpe-protocol/
- DHCP → https://cytal.co.uk/protocols/dhcp-protocol/
- ARP → https://cytal.co.uk/protocols/arp/
- BGP → https://cytal.co.uk/protocols/bgp-protocol/
How OEMs Should Prepare
The preparation that makes the most consistent difference to MTCTE assessment outcomes for Wi-Fi and router OEMs comes down to three things done before submission rather than during it.
The first is a complete protocol surface inventory. Every protocol the device implements across every interface needs to be identified and documented. This includes the obvious management interfaces, the wireless security protocols, and the less-prominent surfaces that are easy to overlook: the NTP client, the DNS resolver, the IGMP implementation in a device primarily assessed for its routing capability. Incomplete protocol inventory at this stage means incomplete preparation and incomplete testing.
The second is systematic internal security testing of each protocol surface before submission. This is the step most consistently absent from OEM preparation programmes and the one that most consistently determines whether an assessment produces expected outcomes or unexpected ones. Internal protocol security testing using the same methods a CAB security assessment applies surfaces the vulnerabilities that can be resolved before they appear in the official assessment report.
The third is complete technical documentation prepared before engagement. The technical file needs to be ready before the CAB assessment begins. Product specification, protocol implementation details, firmware version, and applicable standards all need to be accurate and current. Assembling this documentation under time pressure after submission delays the start of the assessment and creates errors that require correction.
How ProtoCrawler Supports MTCTE Preparation
ProtoCrawler is directly applicable to the internal security testing that Wi-Fi and router OEMs need to conduct before MTCTE CAB submission.
For the protocol surfaces covered by MTCTE security testing for Wi-Fi and router equipment, ProtoCrawler generates protocol-aware test cases that exercise the implementation logic rather than being rejected at the framing layer. The supported protocols relevant to this equipment category include DHCP, ARP, BGP, and CWMP TR-069.
The output gives OEMs exactly what pre-certification testing needs to produce: specific findings with the exact inputs that triggered them, observed behaviour, and severity classification. Findings resolved before CAB submission do not appear in the assessment report. That is the entire value proposition of pre-testing, and it is consistent: the OEM controls the finding, the fix, and the timeline rather than having all three determined by the assessment process.
For OEMs with compliance obligations across both MTCTE and IEC 62443, the same ProtoCrawler test programme produces evidence relevant to both frameworks. The protocol robustness testing that MTCTE security assessment requires and the IEC 62443-4-1 Practice 5 SVV-3 vulnerability testing requirement address the same question through the same methodology.
For the full list of protocols supported, see the protocol models page.
- DHCP → https://cytal.co.uk/protocols/dhcp-protocol/
- ARP → https://cytal.co.uk/protocols/arp/
- BGP → https://cytal.co.uk/protocols/bgp-protocol/
- CWMP TR-069 → https://cytal.co.uk/protocols/cwmp-tr-069-cpe-protocol/
- protocol models page → https://cytal.co.uk/protocols/
Common Questions
Does MTCTE certification from one CAB apply across all Indian operators?
Yes. MTCTE certification is issued by the TEC and applies nationally. It is not operator-specific. A product certified through one designated CAB can be sold and deployed across the Indian market regardless of which operator deploys it.
Can the same product be assessed by multiple CABs simultaneously?
No. An OEM submits a specific product version to a single designated CAB for assessment. If the product needs to be retested after modifications, the retesting is typically handled by the same CAB that conducted the original assessment, focusing on the areas that changed.
Does MTCTE certification expire?
MTCTE certification applies to a specific product version. It does not have a fixed expiry date, but material changes to the product, particularly changes to the software, firmware, or protocol implementations that were assessed, may require reassessment. OEMs should treat certification as version-specific rather than as a perpetual approval for the product line.
How does MTCTE interact with ITSAR for security-relevant equipment?
MTCTE covers the broad range of market access requirements including conformance, RF, and security. ITSAR is a separate security-specific framework administered by NCCS through designated Telecom Security Test Labs. For some equipment categories and deployments, both apply. OEMs should confirm which frameworks are relevant to their specific product and customer requirements rather than assuming MTCTE alone is sufficient.
Ready to pre-test your Wi-Fi and router protocol implementations before MTCTE CAB submission? Book a demo to see how ProtoCrawler finds the protocol security failures before your CAB assessment does.