If you manufacture, supply, or import telecom equipment into India, ITSAR is the security framework you need to understand. It defines what your devices must be able to withstand, how they will be tested, and what certification you need before your products can enter the Indian market. It is not optional. It is a market access requirement.
ITSAR stands for Indian Telecom Security Assurance Requirements. It is developed and maintained by the National Centre for Communication Security (NCCS), which sits under India’s Department of Telecommunications (DoT). The framework establishes security standards for every category of telecom equipment deployed in India, from optical network terminals and routers to base stations, SIM modules, and 5G Open RAN components. Each equipment category has its own ITSAR document, with requirements tailored to the specific security risks of that device type.
This guide explains what ITSAR covers, who it applies to, how the certification process works, and what the requirements mean in practical terms for OEMs and vendors targeting the Indian telecom market.
In This Guide
- What ITSAR Is and Where It Comes From
- MTCTE and ComSeC: The Regulatory Framework Around ITSAR
- Who ITSAR Applies To
- What the Security Requirements Actually Cover
- Equipment Categories and Device-Specific ITSARs
- How the NCCS Certification Process Works
- Why Vulnerability Testing Is Central to ITSAR
- How ProtoCrawler Supports ITSAR Compliance
- Common Questions About ITSAR
What ITSAR Is and Where It Comes From
ITSAR is a set of security standards created by the NCCS to govern the security of telecom equipment used in India. The acronym stands for Indian Telecom Security Assurance Requirements. Each ITSAR document defines the security requirements that a specific category of telecom equipment must meet before it can be certified for deployment in Indian networks.
The NCCS is a specialised unit within the Department of Telecommunications, the government body responsible for telecom policy and regulation in India. The NCCS was established specifically to build a national capability for evaluating the security of telecom equipment. It develops the ITSAR standards, designates the test laboratories that carry out security testing, and issues the security certificates that confirm a product has passed.
The standards themselves draw on international references. ITSAR documents reference 3GPP specifications, TSDSI (Telecommunications Standards Development Society, India) standards, ETSI EN 303 645, OWASP Top 10, CWE Top 25, and NIST SP 800-115 among others. They are not purely Indian inventions. They take established international security requirements and apply them within an India-specific regulatory and certification framework, with additional India-specific controls where the NCCS has determined they are necessary.
The practical effect is that ITSAR creates a mandatory security baseline for telecom equipment entering the Indian market. It is not guidance. It is not a recommendation. It is a prerequisite for market access.
MTCTE and ComSeC: The Regulatory Framework Around ITSAR
ITSAR does not exist in isolation. It sits within a broader regulatory framework that includes MTCTE and ComSeC.
MTCTE stands for Mandatory Testing and Certification of Telecommunication Equipment. It is the overarching regulation that requires all telecom equipment sold, imported, or used in India to be tested and certified against applicable standards before deployment. MTCTE covers both safety and security testing. The security testing component is where ITSAR applies.
ComSeC stands for Communications Security Certification Scheme. It is the specific certification scheme operated by the NCCS for security evaluation and certification of telecom equipment. Under ComSeC, products are tested against the applicable ITSAR by designated test laboratories, and certification is issued by the NCCS upon successful completion.
The relationship between the three is straightforward. MTCTE is the regulation that makes testing mandatory. ComSeC is the certification scheme that manages the security evaluation process. ITSAR is the set of technical requirements that products are tested against. If you are an OEM preparing a product for the Indian market, MTCTE is the legal obligation, ComSeC is the process, and ITSAR is the standard your device must meet.
The enforcement timeline has been phased. Different equipment categories have been brought into scope at different dates. ONTs and OLTs, for example, became mandatory for certification from April 2025. New categories continue to be added, and new ITSARs continue to be published. The NCCS published an ITSAR for 5G Open RAN components in January 2026, covering O-RU, O-DU, O-CU, and O-Cloud infrastructure. The scope is expanding steadily.
Who ITSAR Applies To
ITSAR applies to any organisation that manufactures, supplies, or imports telecom equipment for use in Indian networks. That includes OEMs who build the equipment, importers who bring foreign-manufactured equipment into India, and telecom service providers who deploy the equipment in their networks.
The primary compliance obligation sits with the OEM or importer. They are responsible for submitting their equipment for testing, providing the required technical documentation and declarations, and obtaining certification before the product can be sold or deployed. Telecom operators also have a responsibility to ensure they are deploying only certified equipment, but the certification burden falls on the vendor.
The scope of equipment is broad. ITSAR documents have been published or are in development for routers, switches, base stations (including 4G and 5G), optical network terminals (ONTs), optical line terminals (OLTs), firewalls, IPSec gateways, SIM and eUICC modules, Wi-Fi access points, and 5G Open RAN components among others. If it connects to a telecom network in India and processes, routes, or secures traffic, it is likely to fall within scope.
For international OEMs, this is a significant market access consideration. India is one of the largest telecom markets in the world. Products that cannot demonstrate ITSAR compliance cannot enter that market. The incentive to treat ITSAR as a core product compliance requirement rather than a last-minute regulatory hurdle is considerable.
What the Security Requirements Actually Cover
Each ITSAR document is structured around a set of common security requirements that apply across equipment categories, plus specific requirements tailored to the particular device type. The common requirements cover the security fundamentals that the NCCS expects every piece of telecom equipment to address.
Authentication and access control requirements define how the device manages user and machine accounts, enforces role-based access, handles password management, and prevents unauthorised access. Devices must implement multi-factor authentication where applicable, enforce password complexity and expiration policies, and ensure that default or predefined accounts are disabled or removed before deployment.
Secure software requirements cover the integrity of the device’s firmware and software. OEMs must demonstrate that secure coding practices were followed throughout development. The device must verify the authenticity and integrity of software updates before installing them, using cryptographic controls prescribed by the NCCS. Tampered software must not be executed or installed.
Cryptographic controls are specified in a separate NCCS document that accompanies the ITSAR. This prescribes which cryptographic algorithms and key lengths are acceptable for data protection, communications security, and software integrity verification. OEMs do not get to choose their own cryptographic approach freely. The NCCS prescribes what is acceptable.
Data protection requirements cover both data in transit and data at rest. Sensitive operational and user data must be encrypted using approved cryptographic controls. Audit logging requirements mandate that the device generates and retains logs for security-relevant events, including access attempts, configuration changes, and time synchronisation events.
Network security requirements address interface separation (management traffic must be separated from user traffic), port management, and protection against denial-of-service conditions. Devices must not contain undeclared wireless, optical, or magnetic access mechanisms. OEMs must provide a written declaration confirming this.
Vulnerability and robustness testing requirements are where protocol-level security enters the picture. Devices must be tested to confirm they handle malformed, unexpected, or deliberately hostile inputs safely. This is not a documentation exercise. It requires actual testing, with evidence, demonstrating that the device does not crash, leak information, or enter an insecure state when subjected to invalid protocol messages.
Equipment Categories and Device-Specific ITSARs
Each equipment category has its own ITSAR document, identified by a unique reference number. The common security requirements apply across all categories, but each document adds device-specific requirements that reflect the particular security risks and operational context of that equipment type.
For example, the ITSAR for optical line terminals (OLTs) includes requirements specific to passive optical network architectures, including mutual authentication between OLT and ONT, secure management of optical distribution networks, and protection of downstream traffic. The ITSAR for SIM and eUICC modules includes requirements for secure operating system integrity, protection against physical manipulation and probing attacks, and restrictions on modifying security algorithms.
The ITSAR for 5G Open RAN components, published in January 2026, introduces requirements specific to the O-RAN architecture. The O-RU must protect control and user plane traffic between the radio unit and user equipment. The O-DU must secure the F1 and eCPRI interfaces. The O-CU must safeguard RRC signalling, key refresh mechanisms, and inter-component confidentiality. The O-Cloud component must protect virtualised infrastructure, secure storage, and cryptographic key handling.
The NCCS publishes the full list of approved and draft ITSARs on its website. OEMs should identify which ITSAR applies to their product early in the development cycle, not after the product is finished. The requirements should inform design decisions, not force retrospective changes.
How the NCCS Certification Process Works
The ITSAR certification process has four main stages.
First, the OEM or importer submits an application to the NCCS. This includes technical documentation describing the product, its interfaces, its software components, and the applicable ITSAR. The OEM must also provide a series of declarations covering secure coding practices, the absence of known vulnerabilities, the absence of undeclared access mechanisms, and the use of approved cryptographic controls.
Second, upon successful evaluation of the application, the applicant selects a designated Telecom Security Test Laboratory (TSTL) to carry out the testing. TSTLs are third-party laboratories that have been accredited by the NCCS to conduct security testing against ITSAR requirements. Testing is carried out under the supervision of a validator appointed by the NCCS.
Third, the TSTL conducts the security testing against the applicable ITSAR. This includes the vulnerability and robustness testing, the authentication and access control tests, the cryptographic validation, and the device-specific security tests. The testing produces a detailed set of test reports documenting what was tested, how it was tested, and what the results were.
Fourth, the test reports are submitted by the TSTL to the NCCS for evaluation. If the NCCS is satisfied that the product meets the applicable ITSAR requirements, it issues a security certificate. The product can then be deployed in Indian telecom networks.
The process is not fast. OEMs should allow for months of preparation and testing, particularly if the product has not been designed with ITSAR requirements in mind from the outset. Products that fail testing must remediate the identified issues and retest. Building compliance into the development cycle rather than treating it as a post-development activity reduces both time and cost significantly.
Why Vulnerability Testing Is Central to ITSAR
Of all the ITSAR requirements, vulnerability and robustness testing is the one that creates the most practical difficulty for OEMs. The requirement is clear: devices must safely handle malformed or invalid inputs at the protocol level. The testing must demonstrate this empirically, with evidence, not through documentation or assertion.
This means protocol-level fuzz testing. Sending structurally varied, semantically malformed, and deliberately hostile messages through every external interface the device exposes, and recording exactly how the device responds. Does it reject the malformed message cleanly? Does it crash? Does it enter an undefined state? Does it leak information in its error response? Does it continue operating normally after receiving thousands of invalid inputs in sequence?
These are the questions the TSTL is answering during the vulnerability testing phase. Generic functional testing does not cover this ground. Functional testing confirms the device works correctly when it receives valid inputs. Vulnerability testing confirms the device behaves safely when it receives inputs it was never designed to handle. That is a fundamentally different discipline.
The NCCS requires comprehensive test evidence for this phase. Logs, coverage data, crash traces, and structured records of what was tested and what happened. The evidence must be reproducible. If a vulnerability is found and remediated, the OEM must demonstrate through regression testing that the fix holds and that previously resolved issues have not reappeared.
Manual vulnerability testing cannot achieve the scale or repeatability that ITSAR demands. The number of protocol fields, message variants, and input combinations involved in a thorough robustness test is too large for manual methods. Automated, protocol-aware fuzz testing is the practical way to meet this requirement at scale.
How ProtoCrawler Supports ITSAR Compliance
ProtoCrawler (link to: https://cytal.co.uk/products/protocrawler/) is CyTAL’s automated protocol fuzz testing platform, built for security-critical environments including telecom. It directly addresses the vulnerability and robustness testing requirements that sit at the heart of ITSAR.
ProtoCrawler understands protocol structure. It generates test cases that are structurally valid but semantically malformed, targeting specific protocol fields and message sequences rather than sending random data. This means the testing exercises real protocol handling logic in the device firmware, reaching the code paths where implementation vulnerabilities actually live.
For ITSAR compliance specifically, ProtoCrawler provides automated generation and execution of thousands of protocol-specific test cases, structured test evidence including logs, coverage data, and anomaly records in the format TSTLs and the NCCS expect, repeatable test configurations that support regression testing after firmware updates, and a broad protocol library that covers the telecom and networking protocols relevant to ITSAR-scoped equipment (link to: https://cytal.co.uk/protocols/).
ProtoCrawler’s capabilities extend beyond ITSAR. The same platform supports compliance testing against IEC 62443 (link to: https://cytal.co.uk/iec-62443/), ETSI EN 303 645, and other international security frameworks. For OEMs selling into multiple markets, this means a single testing platform can serve multiple compliance programmes, reducing duplication and accelerating certification across regions.
For a detailed walkthrough of how ProtoCrawler maps to ITSAR’s testing requirements, see the CyTAL guide to ITSAR compliance with ProtoCrawler (link to: https://cytal.co.uk/blog/understanding-itsar-a-foundation-for-secure-telecom/).
Ready to prepare your telecom products for ITSAR certification? Get in touch (link to: https://cytal.co.uk/contact/) or book a ProtoCrawler demo (link to: https://cytal.co.uk/book-a-demo/).
Common Questions About ITSAR
What does ITSAR stand for? Indian Telecom Security Assurance Requirements. It is the set of security standards developed by the NCCS that defines what telecom equipment must meet to be certified for use in India.
Is ITSAR certification mandatory? Yes. Under the MTCTE regulation, telecom equipment must be tested and certified before it can be sold, imported, or deployed in India. The security testing component of MTCTE is conducted against the applicable ITSAR. Non-compliant products cannot access the Indian market.
Who is responsible for ITSAR certification? The OEM or importer of the telecom equipment. They must submit the product for testing, provide required documentation and declarations, and obtain certification from the NCCS through a designated TSTL.
What equipment types does ITSAR cover? The scope is broad and expanding. ITSARs have been published for routers, switches, base stations, ONTs, OLTs, firewalls, IPSec gateways, SIM and eUICC modules, Wi-Fi access points, 5G Open RAN components, and other categories. New ITSARs continue to be published as additional equipment types are brought into scope.
How long does ITSAR certification take? It varies depending on the complexity of the product and how well prepared the OEM is. Products that have been developed with ITSAR requirements in mind and have existing vulnerability testing evidence can move through the process faster. Products that need significant remediation work after initial testing will take longer. OEMs should allow months, not weeks.
Does ITSAR require fuzz testing? ITSAR requires vulnerability and robustness testing that demonstrates devices can safely handle malformed and unexpected inputs. Protocol-level fuzz testing is the established method for meeting this requirement at the scale and with the evidence quality that TSTLs and the NCCS expect.
How does ITSAR relate to IEC 62443? They are different frameworks with different scopes. ITSAR is specific to the Indian telecom market and covers telecom equipment security. IEC 62443 is an international standard for industrial automation and control systems. There is overlap in the types of security testing they require, particularly around protocol robustness and vulnerability testing. OEMs whose products serve both telecom and industrial markets may need to comply with both. ProtoCrawler supports both frameworks from a single testing platform.
What is a TSTL? A Telecom Security Test Laboratory. TSTLs are third-party laboratories designated by the NCCS to conduct security testing of telecom equipment against ITSAR requirements. Testing is carried out under the supervision of an NCCS-appointed validator. For an explanation of what TSTL testing involves, see the CyTAL guide to Telecom Security Test Labs (link to: https://cytal.co.uk/blog/). [Note: update this link when Blog 14 on TSTLs is published.]