Country

India ITSAR Device Hardening Updates

Back

India’s telecom security landscape is evolving with new ITSAR device hardening requirements and updated testing flexibility. These Regulatory Updates introduce structured obligations for OEMs while also enabling controlled software modifications during testing. As a result, manufacturers must align their processes with stricter documentation and compliance expectations to ensure successful certification.

Mandatory ITSAR Device Hardening Requirements

The National Centre for Communication Security (NCCS) has formalized strict procedures for ITSAR device hardening prior to security evaluations. Notably, OEMs must submit a dedicated hardening guide to the Telecommunication Security Testing Laboratory (TSTL) before testing begins. This guide must include precise configuration commands and steps, rather than general user advisories.

Moreover, the applied hardening configurations must persist after device reboot, ensuring consistent security posture throughout testing. The TSTL is responsible for implementing the complete hardening process before evaluations, and all tests are conducted on a fully hardened device.

Another key requirement is transparency in compliance reporting. The TSTL must clearly indicate whether compliance with each ITSAR clause is achieved by default or through applied hardening. Additionally, any modifications to the hardening guide must undergo validation, and OEMs are required to provide a public, digitally signed version of the final guide prior to certification.

Permitted Software Changes During Testing

In parallel, India has introduced flexibility by allowing OEMs to modify device software during active testing. This change enables faster alignment with ITSAR requirements without restarting the certification process.

However, this flexibility comes with clear documentation obligations. When substantive software modifications are made, OEMs must submit Annexure-I and Annexure-II declarations, including details such as software versions, hashes, and an Impact Assessment Document (IAD). This ensures that updates do not negatively affect previously achieved compliance.

On the other hand, for minor corrections—such as typographical errors in the ITSAR Bill of Materials (BOM)—only Annexure-II is required. This simplified pathway significantly reduces administrative burden when no actual software change is involved.

Implications for OEMs and Compliance Strategy

These updates reinforce India’s focus on robust telecom security validation. On one hand, mandatory ITSAR device hardening ensures that devices are tested under realistic and secure configurations. On the other, the allowance for software changes introduces operational flexibility, helping OEMs address compliance gaps more efficiently.

Additionally, the emphasis on detailed documentation, traceability, and public availability of hardening guides reflects a move toward greater transparency and accountability in certification processes.

Impact Assessment

Technical Standards? ❌ No

Type Approval & Market Access? ✅ Yes

Imports, Customs, Trade, or Market Surveillance? ✅ Yes

Spectrum Management? ❌ No


Sources & Documents

Related articles

No hay artículos relacionados disponibles en este momento.

View All