TEC MTCTE (Telecom Equipment)

Introduction to TEC MTCTE

The Mandatory Testing and Certification of Telecommunication Equipment (MTCTE) is India's compulsory conformance-and-safety regime for telecom equipment sold, imported or used in the country. Administered by the Telecommunication Engineering Centre (TEC) under the Department of Telecommunications (DoT), Ministry of Communications, MTCTE requires that every notified category of telecommunication equipment be tested against the applicable Essential Requirements (ERs) in TEC-accredited/designated Conformity Assessment Bodies (CABs) and issued a certificate before it can be commercially deployed on Indian telecom networks. The scheme is anchored in the Indian Telegraph (Amendment) Rules, 2017 (Rule 528 series) and operationalised through the MTCTE Procedure and the TEC online portal (mtcte.tec.gov.in).

This deep-dive is written for two audiences at once: the assessor/auditor who must evaluate whether a manufacturer or importer's test artefacts and quality system satisfy the scheme, and the implementer/product team who must design test campaigns, assemble evidence and shepherd a device through the certification lifecycle. It enumerates the scheme's essential-requirement families, its certification routes and phases, the roles of TEC, CABs and applicants, and provides an auditor-grade master checklist mapping each requirement family to what to verify and the typical evidence that satisfies it.

What is TEC MTCTE

MTCTE makes conformity assessment and certification mandatory (not voluntary) for notified telecommunication equipment before it can be sold, imported or used in India. In practical terms, a manufacturer or its authorised Indian representative must obtain a Certificate of Conformance from TEC, based on test reports produced by CABs (test labs), for each Product Category / Equipment Type / Model. The certificate confirms that the equipment meets the Essential Requirements defined by TEC for that category, spanning safety, EMI/EMC, technical/functional performance, security and other domain-specific parameters.

The scheme rolled out in phases from 1 October 2019, progressively bringing more equipment categories under mandatory certification. Enforcement is coupled with the ComplianceTEC framework and, for security, with the Indian Telecom Security Assurance Requirements (ITSAR) and the National Security Directive on the Telecom Sector (Trusted Products / Trusted Sources) administered via the National Centre for Communication Security (NCCS). MTCTE therefore functions as a gate: without a valid TEC certificate for the applicable model, the product cannot lawfully be marketed or connected to Indian telecom networks.

Key characteristics of the scheme:

• Mandatory and pre-market: certification must precede sale, import or use, not follow it.
• Category-driven: TEC notifies Equipment Categories in phases; each category has one or more ER documents that enumerate the parameters to be tested.
• Test-report-based: certification decisions rest on test reports from TEC-designated Indian CABs (with limited MRA/foreign-lab and self-declaration routes for specific categories).
• Model-specific: certificates are issued per manufacturer, model and configuration; changes typically require re-assessment.
• Portal-mediated: applications, fees, reports, certificates, surveillance and renewals are transacted through the MTCTE online portal.
• Coupled to security assurance: for security-relevant categories, ITSAR testing at TEC-designated security labs is embedded in the ER set.

Who must comply

Compliance obligations attach to anyone placing notified telecom equipment on the Indian market or connecting it to Indian telecom networks. The scheme distinguishes the certificate holder (applicant) from the parties who rely on the certificate.

Not everything is in scope. Equipment not yet notified under MTCTE, purely internal/non-telecom devices, prototypes not offered for sale, and certain categories covered by separate regimes (for example, some radio equipment aspects under WPC/SACFA licensing) follow their own tracks, though overlaps must be resolved case by case with TEC guidance.

Structure of TEC MTCTE

MTCTE is structured as a hierarchy: the scheme (Procedure and Rules) sits at the top; below it are Equipment Categories notified in phases; each category maps to one or more Essential Requirement (ER) documents; each ER enumerates parameter groups/tests drawn from underlying test standards (Indian TEC GRs/IRs/SRs, ITU-T/ITU-R, IEC, ETSI, 3GPP, ISO/IEC, etc.). The certification decision aggregates conformity across all applicable ERs for the model.

Master assessment checklist

This is the operative section. It enumerates every essential-requirement family that recurs across MTCTE ER documents. For each family, an auditor should verify the specific clauses invoked by the applicable ER version for the equipment category, confirm the test was performed at an appropriately accredited/designated lab, and confirm the sample/configuration tested matches the model being certified. The tables below give, for each requirement family, what to verify and the typical evidence that closes it out. Not every family applies to every category; scope each family against the ER document(s) notified for the specific product.

1. Electrical / product safety

Safety requirements protect users and installers from electric shock, energy hazards, fire and mechanical injury. MTCTE ERs typically invoke IEC/IS 60950-1 (legacy) or IEC/IS 62368-1 (audio/video, ICT equipment) as the controlling safety standard, plus specific TEC GR safety clauses.

2. EMI / EMC (electromagnetic compatibility)

EMC requirements ensure the equipment neither emits excessive interference (emissions) nor malfunctions in the presence of interference (immunity). ERs invoke CISPR/IEC 61000 series and, for radio, ETSI EN 301 489.

3. Technical / functional performance

This family covers the equipment's core telecom functionality: interface conformance, throughput, protocol behaviour and category-specific parameters drawn from TEC Generic/Interface/Specific Requirements (GR/IR/SR) and international standards (ITU-T, IEEE, 3GPP).

4. Security assurance (ITSAR)

For security-relevant categories, MTCTE incorporates the Indian Telecom Security Assurance Requirements (ITSAR), administered by NCCS and tested at TEC-designated security-test labs under the Comprehensive Security Testing framework. ITSAR requirements are grouped into security functional domains derived from 3GPP SCAS / GSMA NESAS and hardened for Indian requirements.

5. RF / radio and spectrum parameters

For equipment with radio interfaces (Wi-Fi CPE, cellular devices, IoT radios), ERs invoke radio-parameter standards (ETSI EN 300 328/301 893 for 2.4/5 GHz, 3GPP for cellular) and coordinate with WPC/SACFA spectrum requirements.

6. SAR (specific absorption rate) / RF exposure

For body-worn or near-body equipment (mobile handsets, wearables, some CPE), ERs require RF-exposure/SAR compliance per IEC 62209 / IEC 62311 against DoT-adopted exposure limits.

7. Environmental / climatic and reliability

Where the ER category demands it (notably transmission and outdoor/network equipment), environmental parameters ensure the equipment survives its operating and storage environment per TEC/IEC climatic and mechanical test schedules (IEC 60068 series, TEC QM).

8. Documentation, marking and traceability

Beyond the physical tests, MTCTE requires a coherent documentation trail that links the certified model to its samples, firmware, BOM and manufacturing origin, and correct labelling/marking for the market.

9. Production consistency / quality management

Certification is only meaningful if mass production stays consistent with the certified sample. The scheme relies on manufacturer quality systems and surveillance to maintain conformity over the certificate's validity.

Scoping

Correct scoping determines which ERs apply, how many tests are needed, and how much evidence must be assembled. Getting scope wrong is the single biggest cause of rejected or delayed MTCTE applications.

1. Confirm whether the equipment falls within a currently notified MTCTE Equipment Category and phase; if not yet notified, MTCTE does not (yet) apply but monitor upcoming phases.
2. Identify every applicable ER document and its current version for the category; a single product may map to multiple ERs (e.g. safety + EMC + technical + security).
3. Define the certification unit: manufacturer + model + hardware variant + firmware baseline + configuration. Bundle only variants that are genuinely covered by the same test evidence (family/series certification).
4. Determine the certification route (see implementation approach): General Certification (GCR), Simplified Certification (SCR), or Self-Declaration of Conformity (SDoC) as permitted for the category.
5. Establish which requirement families are in scope: some categories require security (ITSAR) and SAR; others do not.
6. Identify designated CABs (test labs) whose scope covers each requirement family; confirm security testing is booked at a TEC-designated security lab.
7. Freeze the sample configuration and firmware to be submitted, and document the boundary of what is and is not covered by the certificate.

Implementation approach

A disciplined, phased approach shortens the path to certification and reduces re-test cost. The scheme offers different routes depending on category and risk: General Certification Route (full third-party CAB testing), Simplified Certification Route (leveraging existing acceptable reports for lower-risk categories), and Self-Declaration of Conformity (manufacturer declaration where TEC permits). Choose the route first, then execute the phases below.

Phase 1 - Scoping and route selection

Activities: confirm notified category/phase; enumerate applicable ERs and versions; select certification route (GCR/SCR/SDoC); define model/variant family; identify requirement families in scope; shortlist designated CABs; register the applicant/AIR on the MTCTE portal.

Deliverables: scope statement; ER applicability matrix; route decision record; portal registration; draft variant-grouping justification.

Phase 2 - Design review and gap assessment

Activities: pre-scan the product against each ER family (safety, EMC, technical, ITSAR security, SAR, environmental); run internal/pre-compliance tests; harden security configuration to ITSAR; freeze firmware and BOM; remediate obvious gaps before formal testing.

Deliverables: gap-assessment report; pre-compliance results; hardening/remediation log; frozen firmware baseline and BOM.

Phase 3 - Sample preparation and lab booking

Activities: manufacture representative production-equivalent samples; label and serialise; prepare technical documentation pack (manuals, DoC, BOM, block diagrams, critical-component list); book test slots at designated CABs including the security lab; raise the portal application and pay fees.

Deliverables: sample chain-of-custody records; technical documentation pack; CAB booking confirmations; portal application reference and fee receipts.

Phase 4 - Formal testing

Activities: execute safety, EMC, technical/functional, radio/SAR (as applicable) and ITSAR security tests at designated CABs; manage any test failures with root-cause analysis and controlled re-test; keep firmware/hardware frozen throughout.

Deliverables: CAB test reports per requirement family with pass verdicts; non-conformity/CAPA records for any failures; consolidated evidence set.

Phase 5 - Application, assessment and certificate grant

Activities: upload all test reports and documentation to the MTCTE portal; respond to TEC assessment queries and clarifications; resolve any deficiencies; obtain the Certificate of Conformance.

Deliverables: complete portal submission; query-response log; granted TEC MTCTE certificate with validity period and scope.

Phase 6 - Surveillance, change management and renewal

Activities: maintain production consistency; respond to market surveillance/drawn-sample testing; notify TEC of significant design/firmware/component changes and re-certify where required; track certificate validity and renew before expiry.

Deliverables: change-notification records; surveillance test outcomes; renewal application and renewed certificate.

Maturity / capability model

MTCTE itself is a binary conformance decision (certified / not certified) rather than a graded maturity scheme. However, organisations that certify many products benefit from a capability model to gauge how repeatably and cheaply they can achieve and sustain certification. The levels below are an implementation-maturity construct for internal use, not an official TEC grading.

Assessment and audit approach

An assessor (whether TEC, an internal compliance auditor, or a consultant preparing a client for submission) should work through the following steps to judge whether a product is genuinely ready for and worthy of certification.

1. Confirm scope: verify the equipment category is notified and identify every applicable ER document and its current version.
2. Verify the certification unit: check that the model, hardware variant, firmware version and configuration are unambiguously defined and consistent across the application and all reports.
3. Check lab designation: confirm each test report comes from a CAB whose TEC designation/accreditation scope covers that requirement family, with valid accreditation dates.
4. Map clause-by-clause: for each ER, confirm every mandatory clause/parameter has a corresponding tested result with a pass verdict, and flag any not-applicable justifications.
5. Verify sample identity: confirm the tested EUT (serial, photos, firmware hash) matches the model being certified and that samples are production-representative.
6. Assess security (ITSAR): confirm security testing was performed at a designated security lab and that every ITSAR requirement is addressed, including no default credentials, approved crypto, secure update and vulnerability status.
7. Review documentation: check manuals, marking, DoC/undertaking, BOM, critical-component list and quality-system evidence for completeness and consistency.
8. Evaluate non-conformities: review any test failures, their root-cause analysis, corrective actions and the validity of re-test evidence.
9. Confirm production consistency controls: assess change-management, QMS and the manufacturer's ability to keep production units identical to the certified sample.
10. Render the decision: grant, grant-with-conditions, or reject with a documented deficiency list; set validity period and surveillance obligations.

Evidence request list

The following categorised evidence list is what an assessor will request and what an implementer should assemble before submission.

• Product identification: make/model/variant list, hardware and firmware version strings, block diagrams, photographs, rating/marking label artwork.
• Applicability: ER applicability matrix mapping the product to every relevant ER and version; certification-route decision record.
• Safety evidence: safety test report (IEC 62368-1/60950-1 or IS equivalent), CB certificate/report where accepted, critical-component list, adapter safety certificate.
• EMC evidence: emissions and immunity test reports, harmonics/flicker results, EUT configuration description, lab accreditation and calibration certificates.
• Technical/functional evidence: functional test reports mapping each ER clause to a result, test-bench topology, performance measurement data.
• Security (ITSAR) evidence: security test report from designated lab, crypto/TLS configuration, secure-boot and signed-update evidence, port/service scan, vulnerability/CVE status, SBOM, hardening guide.
• Radio/SAR evidence (where applicable): radio parameter test report, SAR/RF-exposure report, WPC/ETA references, EIRP/antenna documentation.
• Environmental evidence (where applicable): climatic, mechanical and IP-rating test reports.
• Documentation: user/installation manuals, declaration of conformity/undertaking, BOM, sample chain-of-custody records.
• Quality and production: ISO 9001 certificate, change-control procedure and log, factory/production audit records where required.
• Portal artefacts: application reference, fee receipts, previous certificates (for renewal), and query-response correspondence.

Roles and responsibilities

KPIs to track

• First-pass test rate (percentage of tests passed without re-test) per requirement family.
• Certification cycle time (application-to-certificate) per product and trend over time.
• Cost per certificate (test fees + lab + internal effort), including re-test cost avoided.
• Number of open non-conformities / CAPAs across in-flight certifications.
• Coverage: percentage of the in-scope product portfolio holding valid, in-date certificates.
• Certificate expiry runway (products with certificates expiring within 90/180 days).
• ITSAR security-test pass rate and count of critical findings at first submission.
• Change-to-recertification lead time for firmware/hardware changes.
• Surveillance/drawn-sample outcomes (pass rate on market-drawn units).
• Query-response turnaround time on TEC portal assessment queries.

Readiness checklist

• Equipment category confirmed as notified under MTCTE and correct phase identified.
• All applicable ER documents and current versions identified and mapped in an applicability matrix.
• Certification route (GCR / SCR / SDoC) selected and justified.
• Model, hardware variant and firmware baseline frozen and documented.
• Designated CABs (including security lab for ITSAR) shortlisted and booked.
• Pre-compliance testing completed and major gaps remediated.
• ITSAR security hardening applied: no default credentials, approved crypto, secure boot/update, ports minimised.
• Production-representative samples serialised with chain-of-custody records.
• Technical documentation pack assembled (manuals, DoC, BOM, critical-component list, block diagrams).
• Applicant/AIR registered on the MTCTE portal and fees arranged.
• All test reports obtained with pass verdicts and mapped clause-by-clause to the ERs.
• Change-management and QMS controls in place to sustain production consistency.
• Certificate validity and renewal tracking process established.

Common gaps

• Wrong or incomplete ER scoping - missing an applicable ER (commonly the security/ITSAR ER) until late in the programme.
• Firmware or hardware drift between the tested sample and production units, invalidating the certificate.
• Attempting to shelter too many hardware/firmware variants under one certificate without adequate justification.
• Test reports from labs whose designated scope does not actually cover the requirement family.
• ITSAR failures: default/hardcoded credentials, weak/deprecated ciphers, unsigned updates, open unnecessary ports, unpatched critical CVEs.
• Inconsistent model/version identifiers across safety, EMC, technical and security reports.
• External power adapter not separately safety-certified or not cross-referenced.
• Missing or incorrect marking, manuals or declaration of conformity.
• No change-notification process, so significant changes are made without re-certification.
• Certificate allowed to lapse; renewal not initiated before expiry, halting sales/imports.
• Underestimating environmental/climatic requirements for outdoor or transmission equipment.

TEC MTCTE mapped to other frameworks

MTCTE overlaps with several international conformity and security schemes. Understanding the mapping helps teams reuse evidence and set expectations. Note that acceptance of foreign evidence is limited and governed by MRAs and TEC's route rules; the table indicates conceptual correspondence, not automatic acceptance.

Frequently asked questions

Need help with TEC MTCTE?

CERT-In empanelled, PCI QSA senior auditors can take you from reading about it to compliant — with a scoped, guided programme.