PQC for Telecommunications

What PQC means for telecommunications

Post-quantum cryptography is cryptography based on mathematical problems that future large-scale, fault-tolerant quantum computers are not expected to solve efficiently. The cited UK National Cyber Security Centre (NCSC) evidence identifies the threat to public-key cryptography (PKC) and describes migration to PQC as the primary mitigation. For telecommunications, the relevant scope is the complete communications ecosystem: network protocols and security technology standards, cryptographic libraries, cryptographic hardware, PKI and other infrastructure components, and IT applications and services. [C1]12

That scope includes mechanisms used to establish keys, authenticate users and machines, sign software and firmware, protect email and documents, and secure application transactions. NIST’s November 2024 Initial Public Draft (IPD) states that applications and services will need support for PQC algorithms for encryption, digital signatures, and key exchange; changes can include larger keys, different performance characteristics, protocol and library compatibility work, code refactoring, extensive testing, and sometimes user-interface redesign. [C2]2

Why telecommunications teams should act now

Future quantum computers could efficiently solve the hard mathematical problems on which today’s asymmetric public-key cryptography relies. The NCSC says organizations should begin or continue preparation now, most effectively as part of broader cybersecurity uplift and system replacement. This timing matters because telecommunications data and credentials may have long confidentiality, integrity, or operational lifetimes, and because infrastructure replacement, protocol changes, certificate issuance, and supplier upgrades require coordination. [C3]13

The risk is not limited to retrospective decryption of stored traffic. Public-key mechanisms also support identity, certificates, key establishment, code signing, and software or firmware updates. A migration plan therefore has to consider both confidentiality and authenticity. The joint CISA, NSA, and NIST fact sheet recommends prioritizing high-impact systems, industrial control systems, and systems with long-term confidentiality or secrecy needs. [C4]3

NIST’s cited IPD says it expects to prioritize migration to quantum-resistant key-establishment schemes to address “harvest now, decrypt later” attacks, particularly in interactive protocols such as TLS and IKE. This is a prioritization signal, not a universal deployment prescription: the correct sequence depends on the operator’s systems, data, protocol support, product maturity, and risk assessment. [C5]2

Where PQC touches the telecommunications architecture

A telecommunications architecture should be examined as a chain rather than as an isolated cipher suite. At the network edge and between services, teams need to identify protocols that establish keys or authenticate endpoints. Within the operator’s infrastructure, they must examine certificates, roots of trust, libraries, hardware modules, management platforms, applications, and software or firmware signing. Cloud-hosted products and externally cited network functions add dependencies that may not be visible from internal configuration alone. NIST’s transition material explicitly groups network protocols, libraries, hardware, PKI, and applications as separate migration areas. [C6]2

Enterprise PKI is a central workstream. The NCSC describes migration as requiring a new PQC root of trust and new PQC certificates for network entities; some devices may be updated remotely, while others may require physical interaction. A staged model may run a new PQC PKI alongside the traditional PKI for a period, using protocols such as TLS and IKE to negotiate which certificates are used. A single-step change may be possible only in controlled environments. [C7]1

Telecommunications operators with operational technology (OT), field devices, sensors, or industrial control systems need a distinct assessment. Remote logins into OT or IT zones need secure authentication, while fielded wireless devices may have especially important integrity requirements even when confidentiality is less demanding. Industrial IoT devices may be resource-constrained, difficult to service, embedded, non-replaceable, dependent on proprietary protocols, or not yet PQC-compatible. Internet-connected devices can also provide an entry point toward control networks and the enterprise IT zone through a demilitarized zone (DMZ). [C8]1

A practical PQC migration workflow

A useful operating workflow begins with governance and scope. Establish a quantum-readiness project team with IT, OT where applicable, network engineering, PKI, application, procurement, risk, and supplier-management responsibilities. The joint CISA, NSA, and NIST guidance recommends creating a roadmap and beginning proactive cryptographic discovery to identify current reliance on quantum-vulnerable cryptography. [C9]3

1. Create a cryptographic inventory covering network protocols, applications and libraries, servers and end-user assets, certificates and PKI components, hardware, firmware and code-signing paths, cloud services, and relevant OT or field devices.
2. Associate each discovered mechanism with the data, identity, function, system owner, supplier, location, expected service life, and operational criticality it supports. Include systems whose integrity is more important than their confidentiality.
3. Prioritize high-impact systems, long-term secrecy needs, critical control functions, externally exposed channels, and technologies that are difficult to replace or upgrade.
4. Define migration patterns for each class of dependency: PQC-only when supported and appropriate, or a controlled hybrid arrangement where interoperability or application requirements justify it.
5. Engage vendors and cloud service providers for product roadmaps, update mechanisms, configuration requirements, expected costs, and timelines. Record whether the supplier supports testing and rollback.
6. Pilot in representative environments, measure performance and interoperability, validate certificate and key-management behavior, and test that systems do not silently fall back to traditional cryptography.
7. Roll out in stages, refresh certificates and trust anchors where required, monitor actual adoption, remediate exceptions, and establish criteria for retiring traditional-algorithm support.

The inventory is not merely an asset list. The joint fact sheet says it should provide visibility into how cryptography is used across IT and OT, associate vulnerable technology with data criticality, help identify outside access to datasets, and support analysis of data that could be targeted now and decrypted when a cryptographically relevant quantum computer is available. [C10]3

Crypto agility and transition design

Cryptographic agility is the capability to replace and adapt algorithms in protocols, applications, software, hardware, firmware, and infrastructure while preserving security and ongoing operations. In telecommunications, this capability reduces dependence on a single algorithm, library, device generation, certificate hierarchy, or supplier release cycle. It should be treated as an architectural and operational property: algorithm selection, protocol negotiation, configuration, key and certificate lifecycle, testing, monitoring, and change control all matter. [C11]4

Hybrid key-establishment or dual-signature techniques may help maintain interoperability during transition, and NIST’s cited IPD says NIST intends to accommodate hybrid techniques in its cryptographic standards where their use is desired. However, NIST also notes that the decision depends on implementation cost, performance reduction, engineering complexity, and the need for proper independent security reviews. [C12]2

Interoperability is a telecommunications-specific concern because endpoints, network functions, subscriber equipment, management systems, and suppliers may transition at different speeds. Backward compatibility and interoperability during the transition are described by NIST as crucial to maintaining trust and security across the network. Compatibility testing must therefore cover negotiation, certificate selection, key sizes, performance, failure handling, logging, and interactions with legacy peers. [C14]2

Standards, suppliers, and evidence limits

The source set contains NIST IR 8547 IPD, identified as an initial public draft published November 12, 2024. Its transition observations should be preserved as draft guidance rather than treated as a final implementation specification. The CISA, NSA, and NIST joint fact sheet is marked final and was published August 17, 2023. The NCSC migration-timelines material is marked current and dated March 20, 2025. The cited NIST CSWP 39 Update 1 is marked final, published December 19, 2025, and updated June 29, 2026. [C15]24

Organizations should ask commercial off-the-shelf (COTS) vendors when and how each product will support PQC, what upgrades or configuration changes are required, and what migration costs are expected. The joint guidance says cloud-hosted products require similar engagement with cloud service providers. It also encourages vendors to review NIST’s draft standards while recognizing that final implementation specifics were incomplete in the cited fact-sheet passage. [C16]3

Procurement language should require an evidence-based roadmap rather than a generic “quantum-safe” label. Useful questions include: Which protocols and algorithm choices are supported? Can certificates and trust anchors be rotated? Can the product report negotiated mechanisms and fallback? Which devices need physical replacement? What is the support lifecycle? How are performance, interoperability, independent review, and rollback addressed? These questions follow the cited evidence on vendor roadmaps, implementation uncertainty, PKI migration, and assurance testing. C7 [C16]123

Testing, assurance, and measures

A deployment is not demonstrated merely because a PQC-capable option exists in a product. The NCSC evidence recommends additional testing to confirm that standardized PQC cipher suites, when available, are actually being used and that systems are not falling back to traditional cryptography. It also recommends a rigorous assurance process covering whether the migration and related cybersecurity uplift meet core goals. [C17]1

• Coverage: percentage of in-scope assets, protocols, certificates, applications, libraries, and devices represented in the cryptographic inventory.
• Exposure: number and criticality of quantum-vulnerable mechanisms, especially on externally accessible or long-lived data paths.
• Adoption: percentage of software clients, connections, certificates, or services actually using approved PQC-capable configurations.
• Fallback: identified sessions, devices, or services that continue to negotiate traditional cryptography when PQC-capable paths are expected.
• Lifecycle: number of products with a documented supplier roadmap, upgrade path, support date, and tested migration procedure.
• Readiness: number of critical exceptions with owners, compensating controls, target dates, and an approved retirement or replacement decision.

Metrics should support decisions, not create a misleading score. A high adoption percentage can conceal a small number of highly consequential legacy devices; conversely, a low percentage may reflect a deliberately staged pilot. Report measures by service, protocol, asset criticality, supplier, and operational environment, and retain evidence from configuration checks and observed network behavior. The cited NCSC passage specifically identifies quantifying clients using PQC and identifying those that are not as a way to gauge progress, determine remedial action, and decide when traditional algorithms can be turned off. [C18]1

Key risks and limitations

PQC migration introduces engineering and operational tradeoffs. New algorithms can affect key and certificate sizes, performance, memory, bandwidth, protocol messages, hardware support, and device lifecycle planning; the cited NIST application evidence explicitly calls out changes in key sizes and algorithm performance. Hybrid approaches add another layer of protocol and implementation complexity. These effects must be measured in the operator’s actual traffic and device populations rather than assumed from a product claim. C22

Legacy and embedded equipment can be the limiting path. Some industrial IoT devices may not be upgradeable or may use proprietary communications protocols. Some PKI participants may require physical interaction. Physical infrastructure changes require significant planning and should, where possible, coincide with other maintenance and improvement work. These constraints make inventory quality, supplier engagement, replacement planning, and exception governance essential. C71

Finally, standards and product support evolve. The NCSC states that algorithm standards are building blocks for protocols, products, and services and that further guidance on patterns and configurations will evolve as technical standards mature. Organizations should therefore avoid freezing an unreviewed design and should maintain the ability to adapt configurations as authoritative guidance and interoperable implementations develop. C1524

Conclusion

PQC for telecommunications is a coordinated transformation of cryptography, identity, protocols, devices, applications, and suppliers. Start with discovery and a risk-linked inventory; prioritize key establishment, high-impact systems, long-lived secrets, critical integrity functions, and hard-to-upgrade equipment; then use staged, tested migration supported by vendor roadmaps and crypto agility. Treat hybrid mechanisms as controlled transition tools, verify actual negotiated behavior rather than relying on configuration claims, and use adoption, fallback, coverage, and exception metrics to decide when legacy support can safely be retired. The cited evidence supports beginning this preparation now while preserving the stated draft status and evolving nature of some standards and implementation details.1324