Could NaaS be a $100B opportunity for telcos?

Could NaaS be a $100B opportunity for telcos?
A new report from STL Partners estimates that communications service providers (CSPs) could unlock $100 billion in “net-new” network-as-a-service (NaaS) revenue by 2030, which includes revenue from network APIs among other services. A recent McKinsey & Company projection is even more bullish, estimating that telcos can earn between $100 billion and $300 billion in the next five to seven years on network APIs alone. But realizing these new opportunities will require telcos to do a better job of defining NaaS and selling its benefits.
STL describes net-new NaaS revenue as revenue that CSPs can add on top of existing B2B revenue. McKinsey’s estimate includes revenue from network API connectivity and edge computing services, with another $10 billion to $30 billion possible from the sale of APIs themselves.
But TM Forum Chief Analyst Mark Newman is skeptical that telcos can earn an additional $100 billion to $300 billion from NaaS during the next five years. He points out that TM Forum’s latest revenue growth Benchmark finds that the total market for B2B telecoms services today is about $400 billion to $500 billion per year, though it’s difficult to assess CSPs’ income from such services because most of them don’t report the revenue separately in their financial statements.
“I question whether NaaS is creating demand for new connectivity or if it is replacing existing connectivity – are there situations where an enterprise is not using connectivity today but would do so if it was provided as NaaS?” Newman explains. “The two areas where I could buy this argument are IoT and network APIs. But I’m not sure that this is a $100 billion opportunity.”
For its part, STL sees net-new NaaS revenue coming from services like secure cloud connect, network APIs, IoT solutions and hybrid private networks, as opposed to the NaaS capabilities CSPs are selling today such as SD-WAN, SASE, and managed LANs and WANs.

“The way to think about it isn’t that it’s always higher-priced (in many cases, the opposite is true), or that it’s just a way to sell more connectivity at the same price (often the opposite is true here, too), or simply that it’s a way of selling services on top of connectivity,” said David Martin, Senior Analyst and Telco Cloud Lead at STL Partners, in an e-mailed response to questions from Inform. “It’s more about adapting the connectivity to the requirements of a service or app, whether that service / app is sold by the telco or a third party.”
Martin explained that NaaS is “essentially programmable and on-demand connectivity”, falling into five categories that range from “premium” connectivity, which is simply more reliable, to “bespoke” connectivity that realizes “the full vision of NaaS” where network functions are deployed and operated dynamically across any network or cloud, driven by AI.
Beyond technology
STL finds that the biggest NaaS opportunity today lies in secure cloud connect services.
“One of the factors for that is the growing dominance of multicloud or hybrid cloud strategies being adopted by enterprises who want access to the advanced tooling of multiple different cloud platforms,” said Anna Boyle, Senior Consultant and Edge & Cloud Practice Co-lead at STL Partners, during a webinar presenting the group’s latest NaaS research. “…The telco opportunity here is really to position yourself as a neutral middleman. So, you’re not one of the hyperscalers – you don’t come armed with their biases – and actually you can provide a really useful service to [enterprises] by being that really trusted interconnect partner.”
To tap net-new NaaS revenue CSPs must embrace a platform model that goes beyond just technology, said Boyle. So far, most operators have focused on developing their NaaS service architectures, but “a true platform model goes further, and it requires change in both the revenue and ecosystem architectures that telcos operate today,” she explained.
Net-new services must target either new customer segments – application developers, for example, in the case of network APIs – or transform existing relationships by enabling services that are more cloud-like (i.e., dynamic and customizable), said Boyle.
“But success in those areas requires more than just technological innovation. Telcos must develop new routes to market and create a new blueprint for their commercial relationships with customers,” she added.
Struggling to make the business case
TM Forum’s own recent research has found considerable confusion in the telecoms industry about NaaS concepts and business models, which could impede telcos’ ability to tap new revenue.
“From a business-model perspective, the industry has failed to explain the benefits of NaaS,” says Newman. “Concepts like network APIs, telco-as-a-service, network slicing and differentiated connectivity are all seen as ways to create incremental revenues. But there’s no consensus around what those concepts mean, and it’s not clear whether the revenues are coming from higher-priced connectivity, the sale of more connectivity at the same price or selling services on top of connectivity.”
Some of the confusion around NaaS stems from the use of the term to mean both network transformation and services sold to customers. Indeed, much of the telecoms industry views NaaS simply as the telco equivalent of what hyperscalers provide for cloud computing: a cloud-based product that offers pay-as-you-go networking services to enterprises.
Meanwhile, NaaS transformation focuses on the abstraction of technology-specific and vendor-specific network management APIs to a single API into the service layer above. “This means that configuring and managing the network can be done using a generic NaaS API rather than lots of different APIs performing the same function for different technology domains below,” explains Andy Tiller, EVP of Customer Products at TM Forum.
It’s possible for a CSP to provide NaaS capabilities to customers without transforming its network: “an operator could live with complex network-specific APIs hidden behind the NaaS APIs that are exposed to customers and partners”, Tiller explains. “But NaaS transformation certainly makes for a simpler internal architecture, which in turn makes the service offering more robust and scalable,” he adds.
The real value of NaaS likely lies in being able to add intent-based management to a network platform (what STL’s Martin might call “the full vision of NaaS”).
According to Tiller, this approach allows end customers “to express their network requirements using intent (for example, ‘I need high-quality video conferencing for an important meeting tomorrow morning’) rather than directly via bandwidth and latency parameters in API calls”. He notes that such services can be provided with or without partners, and they can be automated through zero-touch capabilities.
In the case of network APIs, the CSP provides network features designed for software developers to integrate into their own applications, such as enabling a financial institution to detect SIM swaps as part of fraud prevention or allowing a cloud gaming provider to add a boost button via a quality-on-demand API. Ericsson’s Aduna joint venture and the collaborative work happening between TM Forum and the CAMARA Project, which is aligned with GSMA’s Open Gateway initiative, focus on enabling these capabilities to open a brand new market to CSPs.
Time will tell whether such services can translate into $100 billion in new revenue.