Recently, TRAI released its recommendations on the “Revision of the National Numbering Plan“, highlighting a critical security issue in India’s telecom infrastructure which is reproduced below (clause 2.38, Page 27).
Currently, the Network-Network Interface (NNI) between telecom service providers (TSPs) is built on an assumption of trust, relying on commercial agreements rather than robust technology-based security measures. This outdated trust model, combined with the expansion of interfaces such as SIP trunks for non-TSP entities, third-party SMS gateways, and open 5G architecture, has created major security vulnerabilities. These gaps enable malicious activities like CLI spoofing, IMSI theft, and unauthorized surveillance, which threaten both network integrity and user data security. The risks are further amplified by AI-driven threats, such as voice cloning combined with CLI manipulation, making it easier for fraudsters to deceive users. Recognizing this, TRAI has recommended a transition to a more secure and trusted framework, modeled after successful internet security architectures like the X.509-based Public Key Infrastructure (PKI) framework or ITU-T standards (Q.3057 and Q.3062). These frameworks introduce certificate-based authentication, potentially through a National Certification Authority (CA) or multiple CAs, to enhance signaling security across telecom networks.
For a long time, I have emphasized in my writings and videos that the absence of such a trusted security framework is undermining initiatives like CNAP (Calling Name Presentation Service). Without verified caller authentication, CNAP risks displaying misleading or spoofed caller names, creating a false sense of trust rather than solving the problem of spam and call fraud. Instead of curbing scams and spoofing, it may end up being counterproductive, leading to reduced service quality, increased call setup times, and a worse user experience—without delivering any real value.
In this article, I will explain why this is the case in the simplest way possible, avoiding technical jargon, so that even a layperson can understand why a trusted framework is essential before implementing CNAP and similar services.
Purpose of CNAP (Calling Name Presentation Service)
The primary objective of CNAP is to enhance user awareness and call transparency by displaying the caller’s name, exactly as registered in the KYC (Know Your Customer) database, on the recipient’s phone screen.
By providing this additional context beyond just the phone number, CNAP empowers users to make informed decisions about whether to answer or reject a call, thereby:
✅ Reducing the risk of spam and fraudulent calls
✅ Saving time and resources by avoiding unnecessary interruptions
✅ Ensuring important calls are not missed
✅ Contributing to a safer and more secure telecom network
In essence, CNAP aims to strengthen trust in voice communication by helping users distinguish between genuine and potentially harmful calls, ultimately improving the overall security and reliability of the telecom ecosystem.
Why CNAP Without a Robust Trusted Framework is Ineffective
The Indian telecom network suffers from two critical trust issues. First, the KYC system is porous, with many SIMs issued under stolen or morphed identities. Once CNAP is implemented, it will display these fraudulent names, making the system ineffective. Just as fraudsters use rented or proxy bank accounts to launder stolen funds, they will exploit fake mobile identities, rendering CNAP useless.
Second, CNAP does not detect or block spoofed calls. Once a manipulated CLI enters the system, there is no way to verify its legitimacy, allowing fraudsters to exploit it freely. Without a real-time authentication mechanism, CNAP will display whatever name is linked to the number, whether real or spoofed.
Beyond security, CNAP relies on multiple databases for name retrieval, slowing down call setup and degrading user experience. Instead of solving fraud, a weakly implemented CNAP could introduce delays and create a false sense of trust, making the system worse rather than better.
How to Implement a Trusted Framework and Its Purpose
TRAI, in its latest recommendation (Feb 6, 2025), has proposed a secure caller authentication system that verifies both the caller and the entity initiating the call. The reason is simple—once a spoofed or morphed call enters the system, there is no way to verify its authenticity.
To prevent this, both the caller’s identity and the service provider feeding the call into the network must be verified. The originating entity must be a trusted, regulated provider, ensuring accountability in case of misuse. Once verified, this entity will cryptographically sign the caller’s identity, embedding it into the call setup. This signature remains intact throughout the call transit, preventing tampering.
At the receiving end, the terminating provider will decrypt the caller’s identity using its private key and verify it before displaying the name to the recipient. Additionally, it can cross-check the CLI with the Aadhaar database or a trusted identity source. If the caller fails verification, the call can be blocked before reaching the user—making the system truly effective rather than just displaying a potentially spoofed identity.
This approach aligns with systems already being implemented in the US and other advanced telecom markets. It not only secures calls within domestic networks but also enables trusted global interoperability. When international carriers adopt this system, they can hand over calls that are not just verified at the source but also authenticated by trusted entities, eliminating spoofing at its root.
Key Requirements for Implementing a Trusted System
The fundamental requirements for implementing a trusted call authentication system are the same as those needed for CNAP—a fully IP-based 4G and above network. It cannot be deployed on legacy 2G and 3G systems.
Since India is already testing and preparing for CNAP deployment, the groundwork for network readiness and integration modalities is likely underway. Extending this to include cryptographic verification of calls should not be a major challenge. However, without this trusted framework, CNAP will fail to deliver its intended results, as it will still display unverified and potentially spoofed caller identities.
Therefore, CNAP should only be implemented once the foundational security system is in place. Deploying it prematurely—without caller authentication—would achieve little and leave the telecom network vulnerable to the same frauds it aims to prevent.
How a Trusted System Helps in Dealing with Spoofed International Calls
India has implemented a system to combat spoofed calls originating from foreign countries, on 22nd Oct 2024, particularly from Southeast Asia. While the exact technical details are not public, it is unlikely that the system relies on a roamer database, as this would introduce high latency and risk false positives, leading to the blocking of genuine calls. Instead, it appears to be based on digit analysis and calling pattern detection, particularly identifying spoofed calls with a +91 CLI, which fraudulently appear as domestic calls.
This approach is relatively straightforward, as +91 should only be used for outgoing calls from India, not incoming ones. However, it does not fully prevent fraud, as spoofed roamers (with forged CLIs) can still bypass detection, allowing scammers to deceive Indian users.
This limitation is why countries like the U.S. do not rely on database-based systems—they are not real-time, can misidentify genuine calls, and lack scalability. The better solution is to implement a trusted authentication framework that verifies calls at the source. If verification is not possible, such calls should be marked as unverified, even if they carry an Indian CLI.
Simply tagging a call as “International” is not foolproof, as it also applies to genuine calls, creating unnecessary suspicion for legitimate communications. A trusted framework ensures real-time authentication, providing greater confidence in call validity rather than relying on assumptions based on numbering patterns.
Conclusion
The effectiveness of CNAP and other telecom security measures depends entirely on the presence of a trusted authentication framework. Without it, CNAP will merely display potentially spoofed or fraudulent caller names, creating a false sense of security rather than solving the problem. The absence of real-time caller authentication means that fraudsters can continue exploiting weaknesses in the system, whether through KYC loopholes, spoofed CLIs, or manipulated international routes.
TRAI’s proposal for cryptographic call authentication is the only scalable and effective solution to secure India’s telecom network. By verifying both the caller and the entity handling the call, this framework ensures that only legitimate, verifiable calls reach users, while unverified or fraudulent calls are flagged or blocked. Without this foundation, CNAP will not only fail to achieve its intended purpose but may also degrade service quality by introducing call setup delays and misleading users with incorrect caller identities.
The path forward is clear—India must prioritize the implementation of a trusted framework before deploying CNAP. A half-measured approach will do more harm than good, while a properly secured system will not only protect users from scams but also establish India as a global leader in telecom security.