As reported by The Hacker News, India's Department of Telecommunications has issued a directive requiring all telecom service providers to implement Calling Name Presentation (CNAP) on 4G and newer networks beginning November 1, 2026. While the policy intention — curbing spam and fraudulent calls — is sound, the execution introduces a complex threat surface that demands careful scrutiny from a security standpoint.

Key Takeaway: While the policy intention — curbing spam and fraudulent calls — is sound, the execution introduces a complex threat surface that demands careful scrutiny from a security standpoint.

The Security Promise: Friction for Fraudsters

India has long been a battleground for telecom fraud. Vishing campaigns, SIM-swap attacks, and impersonation scams have exploited the anonymity of caller ID for years. By forcing originating TSPs to transmit a verified name from their subscriber database, CNAP creates a trust signal that didn't previously exist. A call claiming to be from a bank but displaying a random individual's name immediately raises suspicion.

This is a meaningful deterrent. Fraud operations that rely on disposable SIMs and number spoofing will face a new obstacle: their registered names will be visible, creating a paper trail that law enforcement can follow. The mandate also aligns with broader global trends — the U.S. has STIR/SHAKEN for caller ID authentication, and the EU has similar initiatives under its electronic communications framework.

The Privacy Paradox

The core tension: CNAP trades caller anonymity for callee security. That trade-off deserves rigorous examination.

Every subscriber's legal name will now be transmitted with every call and momentarily displayed on the recipient's device. For individuals calling businesses, delivery services, or strangers, this means their full registered name is exposed to people they have no relationship with. The Ministry's circular wisely includes a CLIR provision allowing users to hide their identity, but questions remain about how accessible this opt-out will be and whether it fully mitigates the privacy exposure.

More critically, the architecture described — where the receiving operator queries the originating operator's database — creates a massive, cross-carrier data exchange infrastructure. Each of India's major TSPs maintains subscriber databases with tens of millions of records. The querying mechanism between operators becomes a high-value target. If that lookup protocol is compromised or if a TSP's subscriber database is breached, attackers gain access to name-to-number mappings for entire carrier populations — a goldmine for social engineering, doxxing, and targeted phishing campaigns.

Key Risk Areas Shield53 Identifies

  • Database exposure: Subscriber name-to-number mapping databases become critical infrastructure. A single breach at any TSP could expose millions of records.
  • Lookup protocol abuse: The inter-carrier query mechanism could be abused for enumeration attacks if rate limiting and authentication aren't properly implemented.
  • Metadata retention concerns: The circular states calling name identity should not be retained after call completion, but enforcement and audit mechanisms are unclear.
  • Spoofing at scale: CNAP doesn't inherently prevent SIP-based spoofing if the originating network doesn't properly validate identity before transmission.
  • International call blind spot: Calls labeled simply as 'International Call' create a new social engineering vector — attackers could route calls through international gateways to bypass name display entirely.

What You Should Do

For Telecom Service Providers

What You Should Do
Implement zero-trust architecture for all inter-carrier CNAP lookup APIs — mutual TLS, signed JWTs, strict rate limiting, and IP allowlisting for partner endpoints.
Encrypt subscriber databases at rest with hardware security modules (HSMs) and enforce field-level encryption for PII columns.
Deploy behavioral anomaly detection on lookup traffic — sudden spikes in query volume from any partner endpoint should trigger automated throttling and alerting.
Establish audit logs for every CNAP query with immutable storage, enabling forensic investigation if a breach occurs.
Conduct third-party penetration testing of the CNAP infrastructure before the November 1 deadline and quarterly thereafter.

For Enterprises and Security Teams

  • Update anti-vishing training to account for CNAP — employees should still verify identity through independent channels, as CNAP names can be manipulated through SIM registration fraud.
  • Monitor for international call labeling abuse — if your fraud detection relies on caller ID metadata, 'International Call' labels may mask domestic-origin attacks routed through foreign gateways.
  • Review corporate SIM policies — ensure employee mobile numbers registered with TSPs use appropriate corporate names, not individual employee names, to limit PII exposure.

For Regulators

  • Mandate independent security audits of each TSP's CNAP infrastructure before go-live, with results submitted to the Department of Telecommunications.
  • Publish binding technical standards for the inter-carrier lookup protocol — voluntary 'secure-by-design' language is insufficient for infrastructure of this scale.
  • Define breach notification timelines specific to CNAP databases, given the heightened sensitivity of name-to-number mappings.

India's CNAP mandate is a step in the right direction for consumer protection, but its success hinges on implementation security. A breach of any single carrier's subscriber database — or the inter-carrier lookup protocol — would not only undermine the initiative's trust-building purpose but could expose hundreds of millions of Indians to targeted social engineering campaigns. The November 1 deadline leaves little time for TSPs to build this securely. Regulators and operators must prioritize security architecture alongside functional delivery.