India’s new telecom authorisation framework changes the regulatory landscape for cloud communication businesses. CPaaS, UCaaS, cloud telephony and enterprise communication providers should now examine whether their existing business and network architecture falls within an authorised telecommunication service.

The Indian telecom ecosystem is undergoing one of its most important regulatory transitions in decades.

With the implementation of the Telecommunications Act, 2023 and the notification of the new Telecommunications Authorisation Rules, 2026, the earlier licence-based framework is being replaced by a new authorisation regime. The Department of Telecommunications has also operationalised an Authorisation Portal for new applications and migration of existing licences.

For traditional telecom operators, this transition is clearly significant. But the implications extend well beyond mobile and broadband companies.

They are particularly relevant for businesses operating in:

CPaaS – Communications Platform as a Service, UCaaS – Unified Communications as a Service, CCaaS – Contact Centre as a Service, cloud telephony, hosted PBX, enterprise voice platforms, automated calling solutions, conferencing platforms and other enterprise communication services.

For these companies, the central question in 2026 is no longer simply:

“Are we a software company or a telecom company?”

The more relevant question is:

What telecom functionality are we actually providing, how is the service connected to the public telecom network, whose numbering resources are being used, and under whose authorisation is the telecom service being delivered?

CPaaS Is Moving Closer to the Telecom Regulatory Framework

Historically, many cloud communication businesses positioned themselves primarily as technology or software platforms.

A CPaaS company might provide enterprises with APIs for voice calls, messaging, virtual numbers, IVR, call routing, click-to-call, conferencing, contact-centre integration and other communication capabilities.

However, underneath these software interfaces there is almost always a telecom network.

The service may ultimately depend on:

• telephone numbers or other telecom identifiers;
• SIP connectivity;
• PSTN connectivity;
• DID numbers;
• voice termination and origination;
• telecom network resources obtained from a licensed operator;
• call routing infrastructure;
• hosted PBX functionality;
• SMS or messaging connectivity; or
• other network-based communication services.

The 2026 authorisation framework therefore makes it increasingly important to examine the actual service architecture, rather than simply describing the business as SaaS or CPaaS.

Enterprise Communication Service Authorisation Is Particularly Important

One of the most relevant developments for the cloud communications industry is the creation of the Enterprise Communication Service Authorisation.

According to the Department of Telecommunications’ Authorisation Portal, the authorisation covers services provided commercially including:

• Audio Conferencing Service
• Audiotex Service
• Cloud-Based EPABX Service
• Voice Mail Service

The DoT portal specifically describes this category in the context of cloud-based EPABX/CPaaS services.

This is significant.

It means CPaaS companies can no longer assume that providing communication functionality through the cloud automatically places the service outside the telecom authorisation framework.

The exact regulatory requirement will depend upon the company’s service model, network architecture and role in providing the telecom service.

Does Every CPaaS Company Need an Authorisation?

Not necessarily.

This distinction is extremely important.

A company that merely develops software which an authorised telecom operator or enterprise uses may have a very different regulatory position from a company that:

• contracts directly with enterprises for telecom services;
• provides telephone numbers;
• obtains SIP trunks or telecom resources from an NSO;
• originates or terminates calls;
• operates telecommunication switching or routing infrastructure;
• provides hosted EPABX functionality commercially;
• provides telecom connectivity as part of its CPaaS offering; or
• acts as the telecom service provider to the enterprise customer.

Therefore, CPaaS companies should not determine authorisation requirements simply on the basis of whether their product is called CPaaS, SaaS, cloud telephony or CCaaS.

The correct assessment requires examination of the entire service chain.

Three Questions Every CPaaS Company Should Ask

1. Who is actually providing the telecom service?

Consider a bank using a cloud contact-centre platform.

There may be several entities involved:

Bank / Enterprise → CPaaS or CCaaS Platform → VNO → NSO / Telecom Operator → Telecom Network

The responsibility of each entity must be clearly defined.

If the CPaaS company only provides software and the telecom service is independently contracted and delivered by an authorised operator, its position may be different.

But where the CPaaS provider itself packages, controls and commercially supplies telecommunications functionality to the enterprise, an authorisation analysis becomes necessary.

2. Whose telecom resources are being used?

Companies should identify:

• Who owns or allocates the telephone number?
• Who provides the SIP trunk?
• Who originates the call?
• Who terminates the call?
• Who controls routing?
• Who maintains call-detail records?
• Who is responsible for lawful interception requirements?
• Who handles regulatory complaints?
• Who is responsible for UCC compliance?
• Who has the relationship with the underlying Network Service Operator?

These questions reveal whether the CPaaS company is functioning merely as a technology vendor or has moved into the provision of regulated telecommunications services.

3. Which authorisation corresponds to the service architecture?

Depending upon the operating model, different authorisations may become relevant.

Two categories deserve particular attention.

Enterprise Communication Service Authorisation

This may be relevant to companies commercially providing functionality such as cloud-based EPABX, audio conferencing, audiotex and voicemail services.

The DoT currently specifies this authorisation for the national service area, and its portal lists a ₹10,000 processing fee, nil entry fee and ₹2 lakh guarantee.

VNO Wireline Access Service Authorisation

For companies whose business model goes beyond hosted enterprise communication and involves providing wireline access telecommunications to users using the network of an NSO, the Wireline Access Service Authorisation as a Virtual Network Operator becomes particularly important.

Under Rule 70 of the Principal Telecommunication Services Rules, the scope includes:

• voice and non-voice communications;
• internet-related services within the applicable scope;
• internet telephony;
• intra-circle long-distance calls;
• M2M services; and
• enterprise communication services.

The services are to be provided through wireline terrestrial networks and applicable fixed terminals.

This creates a potential regulatory pathway for cloud communication companies that want to operate not merely as software vendors, but as authorised VNOs providing telecom services to enterprises.

The VNO Model Could Become Increasingly Relevant to CPaaS

The new regime also reinforces an important distinction between a Network Service Operator (NSO) and a Virtual Network Operator (VNO).

A VNO provides authorised telecommunications services using the underlying network of an NSO.

The DoT Authorisation Portal expressly recognises separate NSO and VNO categories, with different scopes and requirements.

For many CPaaS businesses, this model could be strategically important.

Instead of remaining purely a customer purchasing SIP trunks, DIDs and connectivity from telecom operators, some cloud communication companies may evaluate whether operating as an authorised VNO provides a clearer regulatory structure for serving enterprises.

This distinction also affects the commercial relationship with the underlying telecom operator.

An authorised VNO should be treated within the appropriate NSO–VNO regulatory framework, rather than simply being viewed as another enterprise customer purchasing telecom resources.

Authorisation Is Only One Part of the Compliance Framework

Obtaining an authorisation does not end the regulatory responsibility.

For CPaaS companies providing calling and enterprise communication solutions, another major compliance area is the Telecom Commercial Communications Customer Preference Regulations, 2018 — TCCCPR.

TRAI amended the framework substantially through the Second Amendment Regulations, 2025, and a consolidated version was published by TRAI in May 2026.

This is particularly relevant where CPaaS platforms support:

• promotional calls;
• service calls;
• transactional communications;
• telemarketing;
• customer support calling;
• bulk enterprise communications; or
• communication campaigns conducted for Principal Entities.

Therefore, CPaaS regulatory compliance needs to be viewed as an integrated framework involving both DoT authorisation requirements and TRAI commercial communication regulations.

CPaaS Companies Should Review Their DLT and UCC Responsibilities

Cloud communication platforms frequently sit between enterprises and telecom networks.

This makes their role important in the prevention and handling of Unsolicited Commercial Communication (UCC).

Companies should review:

• Principal Entity onboarding;
• telemarketer relationships;
• DLT registration;
• header and template governance;
• consent requirements;
• number-series usage;
• promotional and service-call classification;
• complaint handling;
• traceability of communications;
• communication records;
• misuse of telecom resources; and
• escalation mechanisms with the NSO.

These responsibilities should also be clearly reflected in agreements between:

NSO → VNO → CPaaS / Telemarketer → Principal Entity

Lack of clarity in this chain can expose multiple entities to regulatory and operational risk.

Network Architecture Now Matters as Much as the Product

CPaaS companies should also review their technical architecture from a regulatory perspective.

A regulatory assessment should identify at least:

Enterprise Customer
↓
CPaaS / UCaaS / CCaaS Platform
↓
Application / Cloud Infrastructure
↓
VNO or Authorised Telecom Entity
↓
NSO / TSP
↓
PSTN / Telecom Network

The assessment should determine where:

• switching takes place;
• routing is controlled;
• telecom identifiers are allocated;
• call records are stored;
• lawful interception capability resides;
• telecom traffic enters the public network;
• customer verification takes place; and
• regulatory responsibility transfers between parties.

Two companies selling apparently identical CPaaS products may therefore require completely different regulatory treatment because their underlying network architectures are different.

Cloud Infrastructure Providers Must Also Examine the Network Rules

The 2026 framework has separately introduced a Cloud-Hosted Telecommunication Network Provider Authorisation.

This authorisation covers entities providing authorised telecom operators with physical infrastructure, cloud-hosted telecommunications equipment or cloud-hosted telecommunication network functionality for their telecom networks.

This does not mean that every ordinary public-cloud or SaaS provider automatically requires this authorisation.

However, where a company is providing cloud-hosted telecommunication network functionality to authorised telecom entities, the applicability of this category should be examined carefully.

What CPaaS Companies Should Do Now

Rather than waiting for a regulatory query or a telecom operator to change its onboarding requirements, CPaaS businesses should undertake a structured regulatory review.

A sensible exercise would include:

1. Map every communication service offered to customers.
2. Prepare the complete telecom and cloud network architecture.
3. Identify all NSOs/TSPs from whom SIP, DID, numbering or connectivity resources are obtained.
4. Determine whether the company is providing software or the underlying telecom service—or both.
5. Evaluate Enterprise Communication Service Authorisation applicability.
6. Evaluate VNO Wireline Access Service Authorisation where telecom access services are being provided.
7. Review any Cloud-Hosted Telecommunication Network implications.
8. Review NSO agreements and convert them into an appropriate NSO–VNO framework wherever applicable.
9. Establish TCCCPR, DLT and UCC compliance processes.
10. Create an ongoing DoT/TRAI regulatory compliance framework.

The Regulatory Question Has Changed

The cloud communication industry has evolved considerably.

CPaaS companies today are no longer merely providing APIs.

Many platforms now combine:

software + cloud infrastructure + telephone numbers + SIP + telecom connectivity + enterprise communications + automation + AI-enabled contact centres.

As the technology stack converges, the boundary between a software platform and a telecommunications service provider becomes increasingly important.

The 2026 Authorisation Rules recognise this changing telecom environment.

For CPaaS, UCaaS and CCaaS companies, the objective should therefore not simply be to obtain another regulatory approval.

The objective should be to build a business structure in which:

technology architecture, commercial agreements and regulatory authorisation are properly aligned.

Companies that undertake this exercise early will be better positioned to scale enterprise communication services in India without creating avoidable regulatory uncertainty.

VNOAI Perspective

The Virtual Network Operators Association of India (VNOAI) believes that the new authorisation regime creates an opportunity to build a clearer regulatory ecosystem between NSOs, VNOs, CPaaS providers, telemarketers and enterprise customers.

For the framework to operate effectively, clear NSO–VNO arrangements, access to telecom resources, DLT integration, UCC complaint-handling procedures and well-defined regulatory responsibilities throughout the communication chain will be critical.

VNOAI continues to engage with industry stakeholders and regulatory authorities on these issues as India’s telecom ecosystem transitions to the Telecommunications Act, 2023 framework.