The framing question MNO security architects typically encounter in 5G post-quantum planning is whether to wait for 3GPP Release 19 before doing anything. That framing is wrong, and it is creating a delay in migrations that are already within reach. 3GPP's normative PQC specifications will eventually address SUCI, session key establishment, and protocol-layer security. But the TLS and IKEv2 interfaces that carry 5G core and RAN signalling today are not gated on 3GPP Release 19. They can be migrated to hybrid ML-KEM now, using standard TLS library updates, on the same timeline as any other enterprise TLS migration. Operators waiting for a single coordinated 5G PQC event are deferring tractable work.

For the broader CNI sector context and cross-sector migration prioritisation, see CNI Quantum Security: Sector Protection Roadmap. For the nation-state threat context that motivates the HNDL urgency analysis for telecoms, see Nation-State Quantum Programmes: CNI Implications.

What 3GPP has standardised and what is still open

3GPP's normative specification for 5G security is TS 33.501 (Security Architecture and Procedures for 5G System). This is the document that governs 5G-AKA, SUCI/SUPI, NAS and RRC security, and the TLS requirements for SBA inter-NF connections. The threat analysis for quantum computing attacks on 5G was developed in TR 33.700-17. A Release 18 study item (TR 33.700-40, Study on Security Aspects of Quantum Computing) examined PQC algorithms for 5G procedures including SUCI and security contexts. Release 19 is expected to move from study to normative specification, potentially introducing PQC-based SUCI profiles and hybrid key establishment for NAS and RRC sessions. As of August 2025, normative 3GPP PQC specifications were expected in Release 19 but not finalised. [ASSUMED: verify 3GPP Release 19 publication status before deployment planning.]

The core challenge specific to 5G PQC is multi-layer change dependency. Adding ML-KEM to the SUCI construction requires changes across the USIM card, UE modem firmware, and the AMF, AUSF, and UDM network functions in the 5G core. That breadth of change, across supply chains that include SIM vendors, device OEMs, and network equipment vendors, is why SUCI migration is on a different timeline from TLS interface migration.

SUCI (Subscription Concealed Identifier) is the mechanism in TS 33.501 that protects the SUPI (the subscriber's permanent identity, equivalent to IMSI) from active eavesdroppers on the air interface. The UE constructs a SUCI by encrypting the MSIN component of the SUPI using ECIES with the home network's public key embedded in the USIM. TS 33.501 currently specifies Profile A (X25519) and Profile B (P-256) for the SUCI ECIES construction. Both are quantum-vulnerable to Shor's algorithm. A post-quantum SUCI would replace the ECIES ephemeral ECDH with ML-KEM encapsulation: the UE encapsulates a symmetric key under the home network's ML-KEM public key provisioned in the USIM. This requires a new SUCI profile (Profile C or equivalent) standardised in 3GPP, and ML-KEM public keys provisioned in USIM cards at subscriber scale.

GSMA FS.49 (Post-Quantum Cryptography in Mobile Networks, 2022) is the primary industry reference for PQC migration planning in mobile networks. It covers AKA, SUCI, SUPI exposure, roaming interfaces, and signalling plane security, and recommends a hybrid classical-plus-PQC approach during the transition period. FS.49 predates FIPS 203 and FIPS 204 finalisation and uses the pre-standard algorithm names Kyber and Dilithium. Operators implementing from FS.49 must map Kyber to ML-KEM and Dilithium to ML-DSA and verify parameter alignment with the finalised specifications.

Air interface and RAN: where PQC is operationally complex

The RAN control plane interfaces relevant to PQC migration use TLS, DTLS, and IKEv2 for security. F1-C (between DU and CU-CP in disaggregated RAN, TS 38.473) uses DTLS over UDP or TLS over TCP. E1 (between CU-UP and CU-CP, TS 38.462) uses TLS and DTLS. Xn (between gNBs, the X2 equivalent) uses TLS, DTLS, and IPsec IKEv2. N2 (gNB to AMF, TS 38.412) uses SCTP over TLS.

PQC migration on these interfaces means updating TLS, DTLS, and IKEv2 implementations on the gNB and CU-DU components to support hybrid ML-KEM key exchange. For disaggregated O-RAN deployments, the O-RAN Alliance WG11 security specifications govern TLS requirements for A1, O1, and E2 interface security on near-RT RIC and non-RT RIC connections. O-RAN's open interface architecture creates a larger TLS surface than traditional monolithic RAN: more logical interfaces means more TLS sessions to migrate. WG11 specifications will require updates aligned with 3GPP and IETF PQC TLS standards. [ASSUMED: verify O-RAN WG11 PQC specification update status.]

RAN equipment has stricter real-time and resource constraints than 5G core network functions. The approximately 2 KB of additional key exchange material per TLS ClientHello from an ML-KEM-768 hybrid (1,184 bytes ML-KEM-768 public key plus 1,088 bytes ciphertext) must be assessed against F1-C and E1 timing budgets in your specific RAN configuration. In the majority of deployments this will not be a constraint; in latency-critical fronthaul configurations with tight packet budgets, it is worth measuring.

The air interface cipher suites deserve a separate note. 5G uses NEA (New Encryption Algorithm) and NIA (New Integrity Algorithm) for Uu interface security: NEA1/NIA1 (AES-128), NEA2/NIA2 (SNOW 3G), NEA3/NIA3 (ZUC). AES-128 retains approximately 64-bit post-quantum security under Grover's algorithm, below NIST's 128-bit quantum security threshold but not zero. 5G optionally supports 256-bit variants (NEA4/NIA4, AES-256) with approximately 128-bit post-quantum security, but these are not widely implemented in deployed networks. For operators assessing air interface HNDL exposure, the question is whether their device populations and RAN equipment support NEA4/NIA4 and whether the migration effort is proportionate to the risk profile of the traffic carried.

5G core signalling: the higher-priority migration target

The 5G Service-Based Architecture (SBA) uses HTTP/2 over TLS for communication between all network functions: AMF, SMF, UPF, AUSF, UDM, PCF, NRF, and others. TS 33.501 Section 9 specifies TLS 1.2 as the minimum version (TLS 1.3 recommended) for SBA inter-NF connections. Every SBA interface is quantum-vulnerable at the key exchange layer (ECDH) and authentication layer (RSA or ECDSA certificates). The surface is large: tens of TLS connections per second between NFs in an active deployment. The reason this is a tractable migration despite the surface area is that modern cloud-native 5G core deployments run software NFs where TLS library updates follow standard software release cycles, not hardware refresh cycles.

N32 (the roaming interface between operators via Security Edge Protection Proxies) deserves priority attention beyond its position as one interface among many. N32 carries inter-operator signalling across IPX (IP Exchange) networks operated by third parties. Traffic on N32 includes subscriber identifiers, authentication vectors, and location information. It traverses infrastructure where more parties have access than on a domestic 5G core fabric. International roaming traffic is among the highest-value HNDL targets for nation-state adversaries with both the patience and the infrastructure to harvest at scale.

N32 uses PRINS (Protection of the Inter-PLMN Roaming Signalling, RFC 8519) over TLS. PQC migration of N32 requires coordinated action between roaming partners: if one operator migrates its SEPP to hybrid ML-KEM TLS but its counterpart's SEPP does not support ML-KEM, TLS version negotiation falls back to X25519. Migration on the N32 path requires bilateral coordination, prioritised along high-traffic and geopolitically sensitive roaming corridors first.

Equipment vendor readiness: where Ericsson, Nokia, and others stand

No major RAN or 5G core equipment vendor had documented generally available software releases with GA ML-KEM or ML-DSA support as of August 2025. The landscape by vendor:

Ericsson has published white papers on PQC in 5G (Ericsson Technology Review, "Making 5G Ready for the Quantum Era"), participated in GSMA FS.49 development, and engaged with ETSI ISG QSC work items. Ericsson's Packet Core and AirScale RAN product lines were not publicly documented as having released GA PQC-capable versions. [ASSUMED: verify with Ericsson product release notes.]

Nokia has published analysis on PQC impacts on 5G through Nokia Bell Labs and participated in GSMA FS.49. Nokia's published migration approach phases control-plane interface migrations (TLS and IKEv2 on Xn, N2, and SBA) ahead of protocol-layer changes such as SUCI. Nokia AirScale and Nokia Core products were not publicly documented as having GA ML-KEM or ML-DSA support. [ASSUMED: verify with Nokia product documentation.]

Huawei participates in 3GPP SA3 and ETSI and has published research on PQC in 5G. For operators in markets where national security reviews have restricted Huawei equipment deployment, PQC migration planning must account for vendor restriction timelines separately from PQC readiness. In the UK, the Telecommunications (Security) Act 2021 imposes statutory obligations: designated operators must remove Huawei from access network equipment by 2027, with core exclusion already in force. That is a legal deadline. In contrast, the EU 5G Toolbox is a non-binding set of risk mitigation recommendations agreed by member states; implementation varies by jurisdiction and operator, and there is no single EU-wide statutory removal date. A rip-and-replace schedule and a PQC migration schedule that fall in the same period represent a compounded planning challenge. This is a political and contractual dependency, not a technical one, but it is a genuine planning variable — and the statutory weight of the obligation differs materially between the UK and EU contexts.

Samsung Networks and ZTE have participated in 3GPP standardisation and published 5G PQC research. Neither had GA PQC-capable 5G product releases documented in public sources as of August 2025. [ASSUMED: verify with vendor documentation.]

USIM vendors (Thales, Giesecke+Devrient, IDEMIA, and others) had not publicly released USIM products with ML-KEM key provisioning capability as of August 2025. PQC SUCI requires ML-KEM public keys to be provisioned in USIM cards at the time of SIM personalisation or delivered via over-the-air (OTA) profile update, where USIM hardware supports it. At typical MNO subscriber scales, SIM replacement for PQC SUCI is a multi-year operational programme regardless of when 3GPP Release 19 specifications are finalised. The supply chain lead time from specification to deployed SIM is measured in years, not months. Operators should not use USIM readiness as the trigger for starting SBA TLS migration, which has no USIM dependency at all.

Migration sequencing for operators

Three migration tiers, ordered by HNDL urgency and supply-chain independence:

Priority 1 (no USIM dependency, deploy hybrid ML-KEM now):

• SBA TLS: update TLS library to support X25519+ML-KEM-768 hybrid key exchange across all software NFs. This is within the normal software release cycle for cloud-native 5G core. Use X-Wing (draft-connolly-cfrg-xwing-kem) for the hybrid construction, consistent with NIST IR 8547's hybrid recommendation and GSMA FS.49.
• N32 SEPP TLS: coordinate bilateral hybrid TLS migration with roaming partners. Prioritise high-traffic corridors and roaming partners with geopolitically sensitive traffic profiles first. TLS fallback negotiation prevents a hard cutover requirement.
• RAN interface TLS (Xn, N2, F1-C, E1): assess RAN vendor roadmaps for ML-KEM TLS support in released software. Deploy as vendor releases become available. Assess RAN packet budget implications for F1-C and E1 in latency-critical configurations.

Priority 2 (USIM supply chain dependency):

• SUCI: adopt the PQC SUCI profile once standardised in 3GPP Release 19 or later. Requires new USIM cards with ML-KEM public key provisioning capability, or OTA profile updates where USIM hardware supports it. Plan 2 to 3 years from 3GPP specification publication to mass deployment.

Priority 3 (lower urgency, Grover headroom):

• NEA/NIA air interface algorithms: assess device and RAN equipment support for NEA4/NIA4 (AES-256) and migrate where the operator and device populations support it. AES-128 retains approximately 64-bit post-quantum security, which is below the NIST 128-bit threshold but not zero. This is a proportionate response for high-security deployments, not a universal immediate requirement.

The hybrid TLS rolling deployment model applies throughout Priority 1. X-Wing (draft-connolly-cfrg-xwing-kem) combines X25519 and ML-KEM-768 so that each NF-to-NF connection is secure against both classical and quantum adversaries simultaneously. TLS extension negotiation allows hybrid-capable NFs to fall back to classical X25519 when the counterpart NF does not yet support ML-KEM. This enables incremental deployment without a hard cutover date and without a flag day requiring simultaneous updates across all NF software versions in the estate.