Quantum computing often appears in discussions about 6G, but one area where its impact is already influencing 3GPP work is security.
Many of the public-key cryptographic algorithms used today rely on mathematical problems that are extremely difficult for conventional computers but could be solved much more efficiently by a sufficiently powerful quantum computer. RSA, Diffie-Hellman and elliptic-curve cryptography are the main examples. This does not mean that a future quantum computer suddenly breaks all 5G security.
The most immediate concern is public-key cryptography. Symmetric mechanisms such as those used for 5G authentication, NAS security and PDCP protection are affected differently and remain considerably more resistant. The main quantum threat to symmetric cryptography comes from Grover’s algorithm, which provides a theoretical quadratic speed-up rather than the much more dramatic impact that Shor’s algorithm has on RSA and elliptic-curve cryptography.
For 3GPP, the issue is therefore not simply “make 5G quantum safe”. The first task is to identify where vulnerable public-key cryptography appears across the system and determine which standards organisation is responsible for replacing it. This work is now well underway in 3GPP SA3.
The main study is 3GPP TR 33.703, Study on Transitioning to Post Quantum Cryptography (PQC) in 3GPP. The latest published version at the time of writing is V20.0.1, Release 20.
Importantly, the study is generation agnostic. PQC should therefore not be thought of as a 6G-only feature. It affects existing 5G systems, 5G-Advanced evolution and future 6G networks.
3GPP had already prepared for this work through TR 33.938, 3GPP Cryptographic Inventory, which identifies where cryptography is used across the 5G System. The inventory includes mechanisms such as TLS, IKEv2, PKI certificates, JOSE, COSE, ECIES, EAP-TLS, EAP-AKA’, 5G-AKA, NAS security, PDCP security and MIKEY-SAKKE.
At a simplified level:
| 3GPP area | Typical mechanism | Quantum relevance |
|---|---|---|
| Subscriber identity privacy | SUCI / ECIES | Directly affected by elliptic-curve cryptography |
| Primary authentication | 5G-AKA / EAP-AKA’ | Primarily symmetric cryptography |
| NAS / PDCP protection | Symmetric encryption and integrity | Different quantum-security considerations |
| 5G Core interfaces | TLS | Public-key key establishment and signatures |
| IPsec interfaces | IKEv2 / IPsec | Public-key or DH key establishment |
| Certificates | PKI / X.509 | Public-key signatures |
| API and application security | JOSE / COSE | Signatures and key establishment |
| Mission Critical Services | MIKEY-SAKKE | Existing asymmetric key-management mechanism |
This distinction is important because much of the cryptography used by 3GPP is actually defined elsewhere. TLS, IKEv2, JOSE, COSE and PKI are mainly developed in the IETF and related standards bodies. 3GPP therefore does not need to invent new post-quantum versions of those protocols. Instead, SA3 can adopt and profile PQC-capable versions as they mature.
TR 33.703 consequently separates protocols largely dependent on other standards organisations from mechanisms that are more directly controlled by 3GPP.
The most important 3GPP-specific case is SUCI, the Subscription Concealed Identifier. 5G introduced SUCI to avoid routinely transmitting a subscriber’s permanent identity, the SUPI, over the air. For an IMSI-based subscription, the part identifying the subscriber is concealed using a home-network public key. The home operator provisions the relevant public-key information into the USIM, and the home network later recovers the subscriber identity using the corresponding private key.
The currently standardised public-key SUCI protection schemes use ECIES, the Elliptic Curve Integrated Encryption Scheme.
TS 33.501 defines:
| Scheme | Identifier | Public-key mechanism |
|---|---|---|
| Null scheme | 0x0 | No concealment |
| Profile A | 0x1 | X25519 / Curve25519 |
| Profile B | 0x2 | secp256r1 |
| Future standardised schemes | 0x3–0xB | Reserved |
| Proprietary schemes | 0xC–0xF | Home-operator specific |
A simplified existing SUCI procedure is:
UE / USIM Home Network HN public key │ ▼ Generate ephemeral EC key pair │ ▼ Perform ECDH │ ▼ Shared secret │ ▼ KDF │ ├── Encryption key ├── Initial counter └── MAC key │ ▼ Protect subscriber-specific identity (e.g. MSIN for an IMSI-based SUPI) │ ▼ Create SUCI │ └──────────────────────────────────► SIDF │ ▼ Use HN private key │ ▼ Verify protection and reconstruct SUPI
The symmetric AES encryption inside this procedure is not the main quantum problem. The vulnerable component is the elliptic-curve key agreement used to establish the shared secret. That makes SUCI particularly interesting from a 3GPP perspective because it cannot simply wait for TLS or IKEv2 to be updated elsewhere. 3GPP needs new SUCI protection mechanisms of its own.
This is one reason a large part of TR 33.703 is devoted to possible future SUCI constructions. The obvious candidate from the post-quantum world is ML-KEM, the Module-Lattice-Based Key Encapsulation Mechanism standardised by NIST in FIPS 203. ML-KEM is a Key Encapsulation Mechanism rather than a conventional public-key encryption algorithm.
The basic idea is:
Home Network creates: Public key Private key UE receives HN public key │ ▼ ML-KEM Encaps / \ / \ ▼ ▼ Shared secret KEM ciphertext │ │ │ └────────────► Home Network │ │ ▼ ▼ Derive keys ML-KEM Decaps │ │ ▼ ▼ Conceal SUPI Same shared secret
The UE and home network end up with the same shared secret, which can then be used to derive keys for protecting the subscriber identity.
TR 33.703 studies both standalone PQC and hybrid approaches. With standalone PQC, a mechanism such as ML-KEM could replace the elliptic-curve key agreement completely. With a hybrid approach, the new post-quantum mechanism operates alongside the traditional one:
X25519 shared secret ────┐
├──► Combiner ───► Shared secret
ML-KEM shared secret ────┘
The attraction of a hybrid is that security does not depend entirely on one new algorithm during the migration period. If elliptic-curve cryptography eventually becomes vulnerable to quantum attack but ML-KEM remains secure, the post-quantum component protects the result. If a weakness were instead discovered in the newer PQC algorithm before large quantum computers became practical, the traditional component could still provide protection against conventional attackers. The trade-off is increased complexity, larger messages and more demanding interoperability.
TR 33.703 therefore places considerable importance on cryptographic agility, meaning that algorithms need to be replaceable without redesigning the surrounding system every time cryptographic recommendations change. The SUCI study contains many possible approaches rather than a single selected solution. These include standalone PQC, hybrid PQC, nested hybrid schemes, symmetric-key approaches and mechanisms concerned with protection-profile selection. The presence of a proposal in TR 33.703 should therefore not be interpreted as meaning that 3GPP has standardised it.
One particularly useful proposal for understanding the direction of travel considers ML-KEM-768, either on its own or in combination with X25519. In the standalone case, ML-KEM replaces the ECDH operation used by today’s ECIES-based profiles. In a hybrid case, the result from ML-KEM is combined with a conventional X25519 shared secret before deriving the keys used for SUCI protection.
There is, however, a major engineering problem. Post-quantum cryptography is much less compact than the elliptic-curve cryptography currently used for SUCI. For Profile A, the ephemeral X25519 public key is only 32 bytes. The transmitted MAC adds another 8 bytes, with the concealed subscriber identifier adding only a small amount more.
ML-KEM is very different:
| Parameter set | Public key | Ciphertext |
|---|---|---|
| ML-KEM-512 | 800 bytes | 768 bytes |
| ML-KEM-768 | 1,184 bytes | 1,088 bytes |
| ML-KEM-1024 | 1,568 bytes | 1,568 bytes |
The ML-KEM-768 ciphertext alone is therefore more than thirty times larger than the ephemeral X25519 public key currently carried in SUCI Profile A. This creates a very practical 3GPP problem. A future PQC-protected SUCI could become larger than the limits assumed by protocols carrying the identity.
3GPP SA3 highlighted this to the IETF in 2026, noting that a PQC SUCI could exceed the 1020-byte EAP MTU and, depending on the selected algorithm and construction, potentially even exceed the size normally associated with a 1500-byte Ethernet MTU. This affects EAP-AKA’ because EAP currently does not provide a suitable way to fragment the identity involved in this exchange.
The apparently simple migration:
X25519 → ML-KEM
can therefore turn into:
Larger PQC ciphertext
↓
Larger SUCI
↓
Larger EAP identity
↓
Existing MTU exceeded
↓
Fragmentation required
↓
EAP-AKA' changes
↓
IETF and 3GPP coordination
This is one of the most useful examples in TR 33.703 because it shows that PQC migration is not merely an algorithm substitution problem. It is a protocol and system-design problem. There is a similar issue inside the UE and USIM. The home-network public key used for SUCI protection has to be provisioned and stored somewhere accessible to the SUCI calculation function.
For X25519 this is only 32 bytes.
For ML-KEM-768 it is 1,184 bytes.
If SUCI calculation takes place inside the USIM, the USIM may also need to support the relevant post-quantum computation. If it takes place in the ME, both the ME and USIM still need to understand the new protection profile and associated provisioning.
This raises practical migration questions for 5G devices already in the field:
- Can existing USIMs support the new profile?
- Can the HN public key be updated remotely?
- Can existing devices execute ML-KEM?
- Does SUCI calculation happen in the ME or USIM?
- How is algorithm capability indicated?
- How are HN keys rotated?
- How do old and new devices coexist?
- What happens during roaming?
These issues are particularly important because mobile devices, IoT devices and SIMs can remain deployed for many years. SUCI is not the only part of the 5G security architecture that needs to evolve. TLS is extensively used within the 5G Service-Based Architecture. Post-quantum migration affects both TLS key establishment and, eventually, certificate signatures. IKEv2 and IPsec also need quantum-resistant key-establishment options. PKI migration affects CAs, certificates, trust stores, HSMs and network functions. JOSE and COSE also rely on public-key mechanisms that need to evolve.
In these areas, 3GPP is largely dependent on the work of the IETF and other standards organisations:
NIST │ │ standardises PQ algorithms ▼ IETF and other SDOs │ │ integrate them into protocols ▼ 3GPP │ │ profiles them for mobile systems ▼ Vendors and operators
This dependency explains why PQC transition work has to begin years before the cryptographic threat becomes immediate. It is also worth being precise about 5G-AKA. 5G-AKA does not simply need to be replaced by ML-KEM. The long-term subscription credential used by 5G-AKA is symmetric, and the resulting authentication and key hierarchy are based largely on symmetric cryptographic mechanisms. The same applies to NAS and PDCP encryption and integrity protection. The quantum-security question for these mechanisms is therefore different from the public-key problem affecting SUCI, TLS, certificates and IKEv2.
A useful simplified distinction is:
SUCI
│
└── ECIES / ECDH
│
▼
Public-key PQC problem
5G-AKA / NAS / PDCP
│
▼
Symmetric cryptography
│
▼
Different quantum-security problem
This is why statements that “quantum computers will break 5G security” are too simplistic.
The second specifically 3GPP-related mechanism considered in TR 33.703 is MIKEY-SAKKE, which is used within Mission Critical Services. The current study identifies the post-quantum issue but does not provide the final migration solution. This is another reminder that TR 33.703 is a transition study, not the final quantum-safe security architecture. The work has already started moving beyond the study phase. 3GPP now has a Release 20 normative work item called Post-quantum Cryptography Migration Phase 1, or PQCMigration_Ph1-SEC.
The overall progression can therefore be seen as:
TR 33.938
Cryptographic Inventory
│
▼
Where is cryptography used?
│
▼
TR 33.703
PQC Transition Study
│
▼
What needs to change?
│
▼
Rel-20 PQC Migration Phase 1
│
▼
Normative specification changes
│
▼
Further migration phases
This is particularly relevant when looking towards 6G. Release 20 is the main 6G study release, but PQC is deliberately not being treated as something that starts only with a new 6G air interface or 6G Core. The migration needs to begin across existing 5G security mechanisms so that 5G, 5G-Advanced and 6G systems can coexist during what is likely to be a long cryptographic transition.
For mobile networks, the challenge is not just choosing a post-quantum algorithm. It is supporting old and new devices, existing and future SIMs, roaming partners, new certificate chains, larger protocol messages, multiple algorithm generations and potentially hybrid cryptography at the same time. That is why crypto-agility is likely to be one of the most important outcomes of the work.
The industry does not know exactly when a Cryptographically Relevant Quantum Computer will become available. It also cannot assume that today’s preferred post-quantum algorithms will remain unchanged for the lifetime of a mobile-network generation. The network therefore needs to be designed so that cryptographic algorithms and profiles can evolve without requiring another fundamental redesign. Perhaps the most useful lesson from TR 33.703 is that the cryptographic mathematics may turn out to be the easy part.
Changing a 32-byte elliptic-curve value into a more than 1-kilobyte post-quantum ciphertext can affect SUCI, USIM provisioning, device implementations, EAP, MTUs, fragmentation, roaming and interoperability. And that is just one security procedure.
PQC in 3GPP is therefore not really a future 6G feature. It is an ongoing migration of the security foundations that 5G, 5G-Advanced and 6G will all depend on.
Related Posts:
By
