The Telecommunications (Telecom Cyber Security) Rules, 2024, notified by the Department of Telecommunications (DoT) under the Telecommunications Act, 2023, require telecom entities — licensees, service providers, and infrastructure providers — to adopt a formal cybersecurity policy, report security incidents to the government, and get network equipment tested for cyber vulnerabilities before deployment. Indirectly, they matter to every business that depends on telecom networks for connectivity, SMS delivery, or OTP-based login, because the security posture of the carrier layer now shapes the reliability of authentication flows businesses build on top of it.
If your product sends OTPs, relies on call-based verification, or simply assumes "the network will always deliver," this framework is the reason that assumption is getting stress-tested through 2025 and 2026.
What the Telecommunications (Telecom Cyber Security) Rules, 2024 Actually Are
India replaced its colonial-era telegraph law with the Telecommunications Act, 2023, which received presidential assent in December 2023 and consolidated licensing, spectrum, and security powers under one statute. Using rule-making powers under that Act, the DoT notified the Telecommunications (Telecom Cyber Security) Rules, 2024, in late 2024. The rules give statutory shape to something DoT had been doing informally for years through licence conditions and equipment-testing mandates — except now it sits inside a dedicated cybersecurity framework rather than scattered across licence clauses.
The stated intent, as published on dot.gov.in, is to protect telecommunication networks from unauthorised access, security threats, and disruption, and to give the Central Government visibility into and control over cybersecurity risk across the telecom sector — the layer almost every other digital service in India ultimately depends on.
Who the Rules Apply To
The rules bind "telecommunication entities" as defined under the Act — a category that covers telecom licensees, registered entities, and infrastructure providers operating networks, equipment, or services covered by the Act. That is the direct compliance population: telcos, ISPs, and infrastructure players.
But the practical reach is wider. Two groups of businesses feel these rules even though they never sign a compliance form with DoT:
- Businesses whose product or workflow depends on telecom rails — SMS-OTP login, voice-call verification, IVR-based authentication, missed-call marketing, or any flow that assumes a message reaches a phone number reliably and quickly.
- Enterprises procuring telecom-adjacent equipment or services — organisations that buy network gear, private 5G, or leased-line infrastructure increasingly find vendors citing DoT security-testing and certification requirements as part of procurement and onboarding.
The Core Obligations, Category by Category
The rules organise obligations around a few consistent themes: governance, incident reporting, equipment security, and traceability of communications. The table below summarises what each category requires in practice and who inside a telecom entity typically owns it.
| Obligation Category | What It Requires | Typical Internal Owner |
|---|---|---|
| Governance & Policy | Formal, documented cybersecurity policy covering risk identification, security safeguards, and a designated senior security point of contact for the government | CISO / designated security officer |
| Incident Reporting | Timely reporting of cybersecurity incidents affecting the network to the Central Government or its designated agency | Security operations / compliance team |
| Equipment Security Testing | Network equipment tested and certified for cyber vulnerabilities before induction into the network | Network engineering / procurement |
| Traceability | Measures to prevent spoofed or unauthorised telecom identifiers and to support tracing the origin of communications when legally required | Network operations / fraud teams |
| Audit & Records | Maintaining security logs, audit trails, and evidence of compliance for government review | Compliance / internal audit |
1. Cybersecurity Policy and Governance
Telecom entities are expected to put a written cybersecurity policy in place and designate a senior officer responsible for it — reporting is widely described as requiring a Chief Telecommunication Security Officer, an Indian citizen, who acts as the coordination point with the government on security matters. Whether every entity uses that exact title or an equivalent role, the underlying requirement is the same: cybersecurity ownership can no longer be informal or diffuse inside a telecom organisation.
2. Incident Reporting to the Government
The rules require telecom entities to report cybersecurity incidents affecting their networks to the Central Government or its designated agency. This sits alongside, and is conceptually aligned with, the incident-reporting regime CERT-In has run since its 2022 directions, which set a well-documented six-hour reporting window for a broad category of cyber incidents across regulated sectors. Exact reporting timelines and formats specific to the telecom rules are best confirmed on dot.gov.in rather than assumed from the CERT-In precedent, but the direction of travel — faster, mandatory, government-visible incident reporting — is consistent across both frameworks.
3. Security Testing and Certification of Network Equipment
Before network equipment goes live, it is expected to be tested and certified for cybersecurity — building on DoT's existing equipment-testing apparatus, run through the National Centre for Communication Security, which has for years certified telecom gear against defined security requirements before induction into Indian networks. The 2024 rules reinforce this as an explicit cybersecurity obligation rather than a general quality-and-compliance formality, pushing telecom entities and their equipment vendors toward documented, auditable security testing rather than self-attestation.
4. Traceability of Telecom Identifiers
The Telecommunications Act and its associated DoT rules give the government mechanisms to require traceability of telecom identifiers (such as mobile numbers and device IDs) and to restrict their unauthorised or spoofed use. That is a separate but related track from the 2024 crackdown many Indian businesses have already felt directly: TRAI — a different regulator, acting under its own commercial-communication rules — tightened enforcement of message-traceability and sender-registration requirements for commercial SMS, which led to disruptions for SMS-OTP and commercial-SMS senders who had not registered their templates and delivery chains correctly. The two frameworks are distinct, but both reflect the same 2024-2025 direction in Indian telecom policy: less anonymity, more mandatory traceability. Any business sending OTPs or transactional SMS at scale has likely already felt one or both of them, even without reading a single line of either rulebook.
Know your vulnerabilities before attackers do
Run a free VAPT scan — takes 5 minutes, no signup required.
Book Your Free ScanHow Compliance Flows in Practice
The diagram below shows the general shape of how a telecom entity — or an enterprise relying heavily on telecom infrastructure — typically works through these obligations, from policy to ongoing incident response.
The illustrative chart below groups the rules' obligations into broad focus areas — not an official DoT weighting, but a useful mental model for where compliance effort typically concentrates.
What This Means for Businesses Beyond Telecom
Most Indian SMBs and enterprises are not "telecommunication entities" under the Act and will never file a report directly with DoT. But three practical consequences reach them anyway.
First, authentication reliability is now a compliance-adjacent risk, not just an engineering one. If OTP delivery gets delayed or blocked because a sender ID or template didn't meet traceability requirements, that's a business continuity problem masquerading as a support ticket. Teams that treat SMS-OTP as a black box are the ones most exposed.
Second, vendor due diligence just got a new question to ask. Any organisation procuring network equipment, private connectivity, or telecom-adjacent infrastructure should be asking suppliers whether their equipment has gone through the applicable security testing and certification process, the same way procurement teams already ask about ISO 27001 or SOC 2.
Third, the direction of Indian regulation is now unmistakably aligned across sectors. CERT-In's incident-reporting mandates, the Digital Personal Data Protection Act's obligations around breach notification (see our DPDP compliance guide for the data-protection side of this), and now DoT's telecom-specific rules are converging on the same expectation: formal policy, fast incident reporting, and demonstrable security testing, not informal best-effort security.
A Practical Starting Checklist
Even if you are not directly regulated, this checklist reflects the questions worth answering internally.
| Area | Question to Answer |
|---|---|
| Authentication dependency | Which of our critical flows (login, payments, password reset) depend solely on SMS-OTP or voice-call delivery? |
| Vendor posture | Have we asked our telecom, SMS-gateway, and network-equipment vendors about their DoT compliance and equipment certification status? |
| Incident response | Does our incident response plan account for a telecom-layer disruption (delayed OTPs, blocked sender IDs) as a distinct scenario? |
| Fallback channels | Do we have a non-SMS fallback (email OTP, authenticator app, push notification) for critical authentication flows? |
| Data protection overlap | Have we mapped where telecom-layer incident reporting overlaps with our DPDP Act breach-notification obligations? |
Security testing under this framework is about network equipment and telecom infrastructure specifically — it doesn't replace the application-layer security testing your own web and mobile products still need. Bachao.AI, built by Dhisattva AI Pvt Ltd, runs automated vulnerability assessment and penetration testing for Indian businesses, and for engagements that require CERT-In empanelled sign-off, that work is delivered with a CERT-In empanelled partner. If you want a clear picture of where your own applications and APIs stand, start with a free VAPT scan. For more on the compliance landscape shaping Indian businesses, browse the Bachao.AI blog.