The GSMA’s Telco Quantum Playbook Misreports the McKinsey Report It Cites

A lot of my consulting work is with telecom operators, and the question I get often is some version of “where does quantum computing actually help us, and how would we know?” The GSM Association (GSMA) convenes the mobile industry, and its name on a document counts for a great deal with the operators I work with. So when the GSMA Foundry published its 67-page Quantum Computing Implementation Playbook for Telco Operators in July 2026, I downloaded it the same day, expecting to give it a short and favourable write-up in my news section.

I got as far as Figure 2. The Playbook’s chart of estimated economic impact by industry gives telecom, media and technology a band of $50–150 billion by 2035, and it stars the sector for highest near-term impact potential. Both claims are sourced to McKinsey’s Quantum Technology Monitor 2026. McKinsey’s figure for telecom is $50–100 billion, and McKinsey puts telecom in its lowest near-term tier.

Telecom is the Playbook’s focus sector, and the source it cites puts that sector in its lowest tier.

The telecom number

The Playbook’s Figure 2 reuses a table from McKinsey’s page 17. In McKinsey’s report, telecom gets the smallest bar on the page. The Playbook turns that into the highest near-term impact potential. One could argue that the McKinsey’s table, especially its middle bands, are ambiguous. But telecom is not ambiguous.

The investment box on the same Playbook page has its own problem. It shows $1.8 billion of quantum investment in 2024 rising to $11.3 billion in 2025, at roughly 6.3 times year on year. McKinsey’s published pair is $12.6 billion in 2025 at roughly 6.3 times, and neither Playbook number appears anywhere in the Monitor. Both look back-derived: take the Monitor’s line that over 90% of quantum investment went to quantum computing, apply it to $12.6 billion, then reverse-engineer 2024 to preserve the multiple. That is arithmetic performed on a source and presented as the source.

The same substitution happens one page later, where Figure 3 shows five boxes of priority sectors and marks telecommunications as the focus of the Playbook. McKinsey’s five highest-rated segments for 2030–2035 are chemicals, financial services, pharmaceuticals, travel and transport and logistics, and aerospace and defense. Four of the Playbook’s five match, and the fifth swaps out aerospace and defense for telecom.

My own Quantum Utility Map research came at the same question from the opposite direction, by cataloguing peer-reviewed resource estimates, and it put telecom optimization nowhere near the front of the queue. The quantified industrial case concentrates where the system being modelled is itself quantum: molecular simulation, catalysis, battery chemistry, materials. I wouldn’t expect a telco playbook to lead with that finding. I would expect it not to claim the opposite on a mislabelled bar chart.

My disclaimer, so you can discount accordingly. I run Applied Quantum, which advises telecom operators on exactly this material, and I sell fractional chief quantum officer engagements. If the GSMA had asked me to write something like this, I’d have said yes before the sentence finished, and I think I’d have done a better job. That’s exactly what a competitor says, so weigh it accordingly. Everything below is checkable against two PDFs you can download yourself, and I give the page numbers.

The roadmap table

Figure 14 is in the Playbook’s validation phase, where operators are told to build business cases against a projected hardware envelope. It is a five-row table of vendor roadmaps, with columns for short, medium, and long term. The source line reads: McKinsey Quantum Technology Monitor 2026, pages 56–57, plus vendor roadmaps as of January 2026.

The first row is IBM: Loon and Nighthawk in the short term, Starling in 2029 at around 200 logical qubits, BlueJay after 2033 at around 2,000. The second row is also labelled IBM, and it describes Willow, Quantum Echoes, 105 physical qubits, verifiable quantum advantage demonstrations, and a long-term target of roughly one million physical qubits. Those are Google’s. The third row is labelled IBM too, and it describes Ankaa-3 at 84 qubits with a modular tile architecture and 99.5% fidelity targets, which is Rigetti’s machine.

That row is wrong about Rigetti as well. Ankaa-3 is a monolithic chip, and Rigetti’s own announcements call it the 84-qubit single chip and describe the next generation as a move away from a monolithic design toward chiplets. The tile language belongs to that next generation, Cepheus-1-36Q, four nine-qubit chiplets tiled together, generally available since August 2025. The 99.5% is not a target either, since Rigetti reported it as achieved median fSim gate fidelity on Ankaa-3 in December 2024.

Now take the column that row appears in. Figure 14 puts hundreds of qubits and scaling tile-based modular systems in Rigetti’s medium term, 2028 to 2030. Footnote 75 of the same Playbook, six pages earlier, cites Rigetti’s general availability announcement for a 108-qubit system in April 2026, three months before publication. So the document forecasts for 2030 a milestone it has already cited as reached, and that same footnote names IBM, Google, and Rigetti as three separate vendors. Six pages later, all three are labelled IBM.

McKinsey makes neither mistake. Page 58 of the Monitor is a table of selected announcements, and it attributes Quantum Echoes on the Willow chip to Google and the 99.921% two-qubit gate fidelity Helios system to Quantinuum, correctly, in plain text. Page 57 is something else entirely – a bar chart of published logical-qubit roadmaps for six named players, IonQ, Quantinuum, IBM, IQM, Alice & Bob, and Pasqal. Google is not on it, and neither is Rigetti, a name that appears exactly once in the whole 102-page report, in a market map. Neither page contains a short-medium-long table of any kind.

I ran the strings. Across the entire Monitor, “Ankaa” appears zero times, and so do “Loon,” “Nighthawk,” “Tempo,” “Apollo,” “Sol,” “racetrack,” “modular tile,” and “99.5.” That confirms the obvious: most of the table’s detail came from the second source class rather than the first, which is where the citation stops being useful. “Vendor roadmaps as of January 2026” names no vendor, no document, and no date a reader could check, and the table gives no cell-level attribution. So a reader who wants to know where the Willow row came from, or why it says IBM, has nowhere to go.

The IonQ row fails a third way. McKinsey’s chart shows IonQ at 800 logical qubits in 2027, 1,600 in 2028, 8,000 in 2029, and 80,000 in 2030 and 2031, and the Monitor’s announcement page records IonQ’s stated aim of two million physical and 80,000 logical qubits by 2030. The Playbook reads the first two bars, prints 800–1,600 logical qubits as IonQ’s position for 2028–2030, and drops the rest.

Three European players on that same chart, IQM, Alice & Bob, and Pasqal, do not appear in the Playbook’s table at all. That is a curious omission in a document whose own market section gives customer geography as 43% Europe.

The caveat under Figure 14 is McKinsey’s, transcribed nearly verbatim: goals are not comparable across modalities and are not a reliable indicator of actual delivery. The table reproduces that warning while combining material from sources it does not identify.

I’m not going to speculate in print about how this was produced, so I will describe the shape instead. Correct source, correct caveat, correct headline entities, and then attributions detached from the labels they belong to, with real-world detail arriving from somewhere the reader cannot follow. I publish an AI editorial policy on this site so readers can judge how my own drafts get made. The Playbook includes no equivalent disclosure of authorship or process, and after Figure 2 and Figure 14 I would like one.

What the Playbook gets right

There are good parts in the Playbook, too.

Section 5.3 defines five evaluation dimensions for benchmarking a quantum approach: solution quality, execution time, scalability, robustness, and computational cost. It names scalability as the most strategically informative dimension in the current hardware era, and it argues that a favourable scaling profile on a small instance is a stronger signal than absolute performance. That is correct, unfashionable, and the opposite of what most vendor benchmarking does.

Section 5.6 states that negative results are valuable, and that an experiment showing a quantum method does not suit a problem class narrows the search usefully. Section 4.1 tells operators not to apply quantum computing to a problem merely because the problem is important.

Section 4.3 observes that deployment feasibility is usually constrained more by data access and operations and business support system integration than by algorithmic performance, and that matches what I see inside operators. The five-phase adoption roadmap in Section 7 gates every phase on explicit exit criteria, including a statement that terminating an unsuccessful initiative is a valid outcome, and very few vendor-adjacent documents put that in writing.

The methodology in Sections 4 and 5 would improve most operator decisions on its own. What falls over is the evidence assembled to demonstrate it.

The missing baseline

Section 5.4 sets out three benchmarking reference points and puts a black bar underneath instructing the reader to apply all three together, since they are complementary rather than alternative. Reference point one asks whether the quantum approach beats the method the operator uses today.

Section 5.2 defines the classical baseline as the strongest realistic classical alternative, and it warns against misleading comparisons against artificially weak benchmarks. Section 6 then presents four validated use cases, and three of them report no matched comparison against a strong classical alternative.

Section 6 does say that cases are illustrative and are not intended to provide definitive benchmarking against operational production environments or baselines. It’s a kind of a defense for not comparing against classical alternatives, but I’m not sure readers would catch it.

Urban densification

The Playbook models over 11,250 candidate small-cell locations across a 3 km urban radius, formulates the placement problem as a quadratic unconstrained binary optimisation, and runs it on a commercially available annealing platform. The result is 427 small cells at $4.3–6.4 million, taking peak macro sector loading from 145% down to 70%. Table 1 sets that against a column headed “No Small Cells.”

That is a no-optimization counterfactual, not simulated annealing, not tabu search, and not the radio-frequency planning tool the operator already licenses. Without one of those, the roughly 15,250-variable formulation establishes neither that the problem is classically hard nor that the quantum step contributed anything. The Playbook reports that runtime was dominated by orchestration overhead rather than the optimisation itself, and never isolates what the quantum processor did.

I worked on similar problems in the past. With this number of variables, I can’t imagine current quantum annealing providing any quantum advantage. I am not sure what is the use case illustrative of in that case.

Sleep mode scheduling

Same structure on the next use case. Table 2 reports 6,060 kWh for the modelled hotspot with all equipment active against 2,550 kWh for the optimized sleep configuration, and it headlines a 59% energy reduction over the 90 minutes after busy hour. All equipment active is a no-optimization counterfactual, not an operating policy. The Playbook itself says on page 44 that operators already combine rule-based policies, traffic prediction, and machine-learning optimisation, and then benchmarks against the absence of all three.

The document then reports, as Ericsson figures, savings of 24–26% with Optus and an average of 33% with Vodafone, notes that direct comparison is difficult, and moves on. Those are different networks, different interventions, and different measurement windows, so they are context rather than baselines. The decision-grade comparison is the annealer’s schedule against the operator’s incumbent scheduler, on one topology, over one 90-minute window. It wasn’t run.

The scale of the run doesn’t reconcile either, since page 43 builds the problem to 12,285 spatial decision variables, from 455 sites across three sectors, three bands, and three operating modes. Page 47 then says the case used approximately 140,000. Eight time windows would take it to 98,280, and nothing in between accounts for the rest. Scalability is the dimension the Playbook itself calls the most strategically important one.

These first two cases also share a base, an illustrative operator holding one-third market share, a 3 km urban radius, a European city drawn from OpenCellID, and the same five daily usage profiles. Two of the four validated use cases sit on one simulated network, which makes the set less independent than four cases sound.

Anomalous traffic detection

This one contains no quantum computation and no quantum hardware. Att all. It is a quantum-inspired tensor-train autoencoder running in Python on a standard CPU, and the Playbook says so plainly, which I credit. The benchmark column is a range drawn from published literature, which really is not a benchmark: different datasets, different features, different splits, different compute budgets. No matched in-house comparator is reported.

Backhaul maintenance scheduling

The fourth use case is the only one with a classical comparator.

The backhaul maintenance case models two interconnected fibre rings with six links each, and it uses iterative quantum amplitude estimation to forecast the probability that a link degrades into a higher-risk maintenance state. That forecast feeds a classical integer linear programming scheduler.

Table 5 compares the pipeline against three alternatives, and against a fixed-interval strategy it cuts mean maintenance cost by 56%. Against run-to-failure it cuts direct intervention cost by 34%, and it also produces 41% more emergency interventions than run-to-failure. The prose directly above the table says the predictive approach reduces emergency interventions relative to both reactive and fixed-interval strategies. The table says otherwise, and nobody reconciled them. Against classical Monte Carlo feeding the same scheduler, it delivers plus zero percent, plus zero percent, and plus zero percent. Identical results.

That is a null result, reported honestly, and then framed as demonstrating that amplitude estimation can be integrated into predictive maintenance workflows built on Monte Carlo. It can be, and the question an operator needs answered is what integrating it costs. The Playbook prints the answer two pages apart without ever multiplying. Table 6 gives the toy model’s economics as roughly 300,000 circuit iterations at 5–10 ms each, 25–50 minutes of runtime, and $1,000–1,350 benchmarked against public Amazon Braket pricing, to produce about 3,000 probability estimates. Table 7 then gives the realistic operational scale as roughly one million risk evaluations, requiring around 100 million amplitude-estimation iterations at the same precision target. That is 333 times the toy model. Apply the Playbook’s own per-iteration timing and pricing in a straight line and one planning cycle takes 5.8 to 11.6 days of continuous quantum processor time and costs $333,000 to $450,000. That is an extrapolation, not an observed cost, and it holds only if time and price per iteration stay flat, which the Playbook neither states nor justifies. It is also the only side of the comparison that carries a number at all.

The Monte Carlo pipeline that produced the identical answer is never timed or priced. But I guarantee you that it’s nowhere close.

Then there’s page 55, where the Playbook states that the circuit was developed in IBM’s Qiskit and executed with its StatevectorSampler on the “[WIP]” quantum computer. StatevectorSampler is Qiskit’s reference primitive, and IBM’s documentation defines it as an implementation using full state-vector simulation. The bracketed placeholder is in the copy I downloaded on August 17, 2026, from the GSMA’s own resource page.

On the evidence of its own methods line, then, the gate-based use case was simulated rather than executed on quantum hardware. Page 37 describes it as implemented on a gate-based superconducting quantum computer, and Table 6 prices it as time that would have been bought on one. Page 9 tells the reader that the four validated use cases were implemented on real quantum computers. One of them admits to running on a CPU and one ran on a simulator, which leaves two.

Where the optimisation thesis comes from

Page 12 has the sentence everything else depends on. A classical register of n bits encodes one of 2ⁿ states at a time. A register of n qubits in superposition represents all 2ⁿ basis states simultaneously, the Playbook says, and that is given as the structural reason quantum computers are expected to deliver meaningful advantage on problems with large solution spaces such as combinatorial optimisation.

The first half is standard, and the second half is the exponential parallelism fallacy, doing heavy work in a telco document. Holding amplitudes across 2ⁿ basis states is not the same as evaluating and reading out 2ⁿ candidate solutions. Measurement returns one outcome, and extracting a useful answer requires an interference pattern that concentrates amplitude on it. No general method for building that pattern is known for generic combinatorial optimization.

Grover’s algorithm gives a quadratic speedup for black-box unstructured search, and that speedup is provably optimal in the oracle model. The quantum approximate optimization algorithm, named in Section 4.2 as the gate-based candidate for every optimization use case in the document, has not demonstrated decision-grade advantage over well-tuned classical heuristics on any industrial workload. The strongest evidence to date is a scaling result on one benchmark problem family under noiseless simulation.

Ryan Babbush and colleagues at Google argued in 2021 that quadratic speedups are unlikely to deliver advantage on early fault-tolerant machines unless error-correction overheads improve substantially. My own Quantum Utility Ladder reached the same place from the resource-estimate literature. The strongest quantified industrial case sits in molecular, chemical, and materials simulation, and telecom network optimization is not in that group.

None of that makes the four use cases worthless. Quantum-inspired tensor networks are useful on classical hardware today, and annealing services solve real scheduling problems whether or not the quantum part contributes anything. But the document motivates its telco thesis with an account of quantum parallelism that does not support the conclusion drawn from it, then backs the thesis with a market claim that misreports its source. Strip both out and what remains is a competent evaluation methodology looking for a use case, which is a defensible thing to publish and a different thing from what was published.

The decision the GSMA made

The Playbook’s own front matter states that the report was prepared from information and views contributed by QCentroid, that the opinions are those of the authors and sponsors rather than the GSMA, and that the whole thing is presented as an opinion piece. It describes QCentroid, in the same front matter, as a business-to-business quantum-as-a-service company. All four validated use cases ran on QCentroid’s QuantumOps platform, and QCentroid appears in Figure 1’s market landscape as one of five named orchestration platforms, in a figure the same document produced. No individual author, technical reviewer, or drafting process is named anywhere.

And the launch page announces the Playbook as the foundation for the GSMA Foundry x QCentroid Discovery Sandbox, whose Accelerated Track is a 16-week guided programme in which members pilot one of the validated use cases.

Vendor-contributed isn’t the problem. Vendors write good technical documents constantly, and the QCentroid team has clearly done real engineering work here. The problem is vendor-contributed, vendor-evidenced, vendor-benchmarked, and commercially downstream of a programme the same vendor runs, published under the badge of the body that convenes the industry, carrying errors a basic source check would have caught.

The review failure isn’t a matter of inference, only of reading the copy currently posted:

• Three consecutive rows of the vendor roadmap table are labelled IBM, two of them describing Google and Rigetti products.
• An unreplaced [WIP] placeholder sits in the methods line of a use case.
• Figure 13’s caption is Figure 9’s caption, copied verbatim. Figure 13 is a table of training courses and industry forums.
• The section dividers on pages 6 and 10 carry a navigation strip reading executive summary, introduction, why, terms and definitions, references, overview of controls, general controls, voice, SMS, customer service, additional topics. None of those is a section of this document. It is the contents bar of some other GSMA deliverable, left in the layout.
• The Phase 3 outputs cell in Figure 12 contains text lifted from the scalability row of Figure 8, and Phase 4’s subtitle duplicates Phase 3’s.
• The table of contents lists section 6.2 as “Market and Technology Landscape,” duplicating section 2.2. Section 6.2 is sleep mode scheduling.
• Footnote 71 cites two different sources in two different places. Reference 22 on page 15 is attached to McKinsey’s sector list but points at the EU Quantum Flagship’s KPI document. Orphan markers survive at “[19], 28” and “(P3329)24.” Pages 38 and 43 use “[see section 2.1]” as a footnote marker.
• Figure 1 on page 13 lists Oxford Ionics as an independent hardware vendor. Figure 14 on page 63 treats it as merged into IonQ.
• The core-concepts pages carry the sentences a non-specialist reader depends on most, and nobody proofread them. Systems that “are engineers such that.” Qubits that “should not be understoof as having simple of / off states.” Reconfigrable qubit arrays. An approach that relies “mathematical concepts.” A use case that “may prove impractical is integration effort.” And a sentence on page 43 with no verb in it.
• Page 19 reports that US operators invested $107 billion in network capex in 2026, citing an ITU dataset accessed in May 2026. In Section 3.2.5, two operator pilots are cited to LinkedIn posts, one operator’s name is garbled, and the claim that TIM was first in Europe to run quantum computing live on a mobile network is sourced to February 2020 and never followed up.
• Page 63 tells the reader that partner selection is discussed in Section 7.6. The Playbook has a Section 7.1 and a Section 7.2, and stops there.
• Page 61 refers the reader to Section 8.4, and Figure 9 on page 34 refers to the adoption stages in Section 8, and there is no Section 8. Page 31 sends the reader to Section 4.1.2, and there is no 4.1.2 either.
• Section 5.4 instructs the reader to benchmark every candidate against the strongest realistic classical alternative, and puts a black bar under the instruction. Three of the four use cases in Section 6 have no classical comparator at all.

This is a one-hour review that GSMA didn’t bother to invest in.

What the GSMA could do about it isn’t complicated, and none of it needs a policy review. Authorship and the commercial relationship belong on the cover rather than in the front matter, in the same type size as the title. A document that feeds into a vendor-supported implementation programme should say so where the reader meets it. An independent technical reviewer, from an operator or a university rather than a competing vendor, costs a day and would have caught most of this.

A corrections page with a version number is the piece I would prioritize, because this document will get pasted into operator board papers as evidence that the GSMA considers telecom a priority sector for quantum computing. And here the front matter and the artwork pull against each other. The disclaimer says the document is not an official GSMA position. Figure 3 says telco is among the five priority sectors, under GSMA Foundry branding, on the strength of a display that does not reproduce the source it names.

The GSMA already knows how to run this process. It formed the Post-Quantum Telco Network Taskforce with IBM and Vodafone in September 2022, chaired by Lory Thorpe of IBM with Luke Ibbetson of Vodafone as vice-chair. That group produced the industry’s first post-quantum telco whitepaper and the PQ document series that followed. Multiple operators, multiple vendors, named chairs, an actual working group. That is the standard the badge was built on, and the Playbook didn’t go through anything like it.

Footnote 7

On page 9, in the smallest type in the document, the Playbook records that post-quantum cryptography and the other methods used to address the quantum threat are “not within the scope of the Implementation Playbook.” The document confines itself to the positive impact of engagement.

The editorial logic is clear enough, a document about opportunity should not become a document about risk, and the GSMA covers the threat elsewhere. But consider what that scope line does to this specific document.

Figure 14, the mislabelled roadmap table, is a fault-tolerance forecast – Starling in 2029 at roughly 200 logical qubits, BlueJay after 2033 at roughly 2,000. Those are among the milestones I track in the CRQC Quantum Capability Framework as inputs to when a cryptographically relevant quantum computer becomes plausible. Logical qubit counts alone do not date cryptographic failure, and McKinsey’s own caption on page 57 says qubit count does not describe computational capability. The point is narrower and harder to dismiss. The Playbook puts the fault-tolerance trajectory in front of a telco audience as an opportunity signal, and sends the migration risk that runs off the same trajectory to a footnote.

The scope line also sits awkwardly against the GSMA’s own research. GSMA Intelligence reports that quantum key distribution is the most widely deployed quantum use case among the operators it surveyed, and estimates that about 8% of active global IoT devices are quantum safe. Reporting on the same survey work in April 2026, RCR Wireless recorded that 60% of the 100 operators surveyed have quantum on their roadmap, with network security ranked as the top use case ahead of network efficiency. Operators told the GSMA that security is their first quantum priority, and the Playbook that followed excludes security in a footnote and spends 67 pages on efficiency.

The Playbook’s own Figure 4 does list network security as a quantum-enabled value area, on the strength of better anomaly detection. It cites cybersecurity spending rising from $15–19 billion in 2025 to $42 billion by 2030 as a driver. So the document does address network security. It addresses the part quantum computing might improve, excludes the part quantum computing breaks, and tells the reader so once, in a footnote, on page 9.

The migration argument doesn’t depend on Q-Day arriving on any particular date, and that’s why I keep saying the date is the wrong thing to argue about. Governments and standards bodies have already published migration milestones – the UK’s National Cyber Security Centre set 2028, 2031, and 2035 for discovery, priority migration, and completion – the sensitive traffic crossing a carrier’s network today is exposed to harvest-now-decrypt-later collection whether or not anyone has yet built the machine to decrypt it, and PQC migration takes years of vendor-dependent work inside a network operator. A telco building its quantum capability programme from this Playbook builds the optimization half and nothing else.

What I would tell an operator

Take Sections 4 and 5 and use them. The screening criteria, the five evaluation dimensions, and the insistence on a classical baseline are sound, and an operator applying them rigorously will make better decisions than one working from vendor decks.

Then apply them to Section 6, where three of the four validated use cases report no matched classical comparison and the fourth produces the same scheduling output as classical Monte Carlo. None of that argues against experimenting, only for holding the experiment to the standard the document itself sets and didn’t meet.

Then start experimenting anyway. Nothing above argues for sitting the technology out, and the strongest paragraph in the Playbook is the one on page 7 that has nothing to do with McKinsey: the organisational learning curve cannot be compressed once the technology matures. That is true, and I have watched it play out with cloud, with machine learning, and with every other capability operators bought late. An operator that has run three honest pilots by 2030, with real baselines and documented negative results, will make better decisions in 2032 than one that starts hiring then.

The use cases that eventually pay off are probably not the four in Section 6. They are not on anyone’s list yet. They will be found by teams who already know how to formulate a telco problem as a solvable one, choose a modality, and read a benchmark without being sold to. That capability is cheap to build now and expensive to buy later.

Two of the four implementations in the Playbook are classical in execution, the tensor network on a CPU and the gate-based case on a simulator, and that is not an embarrassment. Quantum-inspired methods can be tested on conventional hardware today, and simulated circuits still build the formulation and benchmarking skills that hardware will eventually need.

Run the other programme in parallel, and give it the harder deadline. The optimisation work is optional and its schedule is set by engineering nobody controls. The migration work is not optional, its schedule is already on published government roadmaps, and the harvesting half of harvest-now-decrypt-later needs no quantum computer at all. A telco can afford to be wrong about when quantum optimisation becomes useful. It cannot afford to be wrong about when its roaming interfaces stop being confidential.

And don’t carry Figure 2 into a budget meeting. The number for telecom is $50–100 billion, McKinsey puts the sector in its lowest near-term tier, and both facts sit on page 17 of a report anyone can download. Checking it took me ten minutes, and it should have taken the GSMA the same ten minutes before the logo went on.