5G is not just faster 4G. The radio side gets a lot of attention because that is where the speed numbers come from, but the bigger architectural change is invisible to most users. The 5G core network is built on a Service Based Architecture (SBA) where every network function is a microservice that talks to other microservices over HTTP/2 and TLS. This is a fundamental break from how 3G and 4G core networks were built, and it changes everything about how cryptography works inside a mobile operator's infrastructure.
The relevant 3GPP specification is TS 33.501, "Security architecture and procedures for 5G System". It defines how subscribers authenticate, how SUCI (Subscription Concealed Identifier) replaces IMSI to protect identity, how AKA (Authentication and Key Agreement) works in 5G, and how every interface in the SBA is protected. For post-quantum cryptography, every one of these surfaces is a migration target, and the 3GPP working groups have been actively studying PQC integration for several years.
What Service Based Architecture Means
In a 4G EPC (Evolved Packet Core), the core network was a collection of fixed-function boxes connected by point-to-point interfaces with names like S1-MME, S5, and S11. Each interface ran a specific protocol. The MME (Mobility Management Entity) was its own box. The HSS (Home Subscriber Server) was its own box. The interfaces between them were specified down to the individual message and field.
In a 5G core, the architecture is fundamentally different. Functions like AMF (Access and Mobility Management Function), SMF (Session Management Function), UDM (Unified Data Management), AUSF (Authentication Server Function), and PCF (Policy Control Function) are all microservices that expose RESTful HTTP/2 APIs. They register themselves with the NRF (Network Repository Function), which is essentially a service registry. When one function needs to call another, it queries the NRF, gets a target URL, and makes an HTTPS request.
This is the SBA. It looks a lot like a cloud-native microservices architecture, because that is what it is. The cryptography on this architecture is TLS, with mutual authentication via certificates, OAuth 2.0 for service-to-service authorization, and JSON Web Tokens (JWTs) for short-lived credentials.
Where PQC Lands in TS 33.501
TS 33.501 is the master security spec for 5G. It defines several distinct layers where cryptography matters:
- Subscriber identity protection: The SUPI (Subscription Permanent Identifier) is the subscriber's permanent identity. SUCI is the encrypted version that gets sent over the air. SUCI uses an Elliptic Curve Integrated Encryption Scheme (ECIES) to encrypt SUPI under the home network's public key. This is the layer where PQC matters most for over-the-air privacy.
- AKA authentication: The 5G-AKA protocol uses pre-shared keys (the long-term subscriber key K stored on the SIM and in the UDM). The protocol itself is symmetric and quantum-resistant in principle, but the SUCI encryption that protects the identity uses public-key cryptography that is vulnerable to quantum attack.
- N32 interface security: When two operators interconnect (for roaming, for example), the N32 interface carries authentication and signaling between Security Edge Protection Proxies (SEPPs). N32 uses TLS 1.3 with certificates, and is one of the prime PQC migration targets because the traffic is high-value and long-lived.
- SBA interface security: Every microservice-to-microservice call inside the core uses TLS 1.3 with mutual authentication. PQC migration here is similar to any cloud-native deployment.
- User plane integrity protection: 5G adds optional integrity protection on the user plane. The integrity algorithms are AES-CMAC and ZUC-based, which are quantum-resistant in symmetric form. Key derivation uses HKDF, which depends on hash functions and is also quantum-resistant in the relevant sense.
For a broader view of the 5G/6G migration, see PQC telecom 5G and 6G.
SUCI and the Identity Protection Problem
SUPI is the subscriber's permanent identifier. In 4G it was the IMSI, and IMSI was sent over the air in plaintext during initial attach. This led to IMSI catchers, devices that pretended to be base stations and harvested IMSIs from nearby phones. The privacy implications were obvious and serious.
5G fixed this by introducing SUCI. The phone encrypts SUPI under the home network's public key before sending it over the air. The home network can decrypt SUCI to recover SUPI. An attacker without the home network's private key cannot.
The encryption uses ECIES (Elliptic Curve Integrated Encryption Scheme) with profile A (Curve25519) or profile B (P-256). Both are vulnerable to quantum attack. A future attacker with a sufficiently large quantum computer could record SUCI values today and decrypt them later, recovering subscriber identities and their movement patterns over time.
3GPP TR 33.700-41, the study item on "Study on enabling Post-Quantum Cryptography in 5G", explicitly covers SUCI as a migration target. The current direction is to add new SUCI profiles based on ML-KEM. The challenge is bandwidth: an ML-KEM-768 ciphertext is 1088 bytes, compared to 32 bytes for a Curve25519 ECIES output. This affects every initial attach and registration message, multiplied by billions of devices.
The NRF and Service Discovery
The NRF (Network Repository Function) is the service registry of the 5G core. Every network function registers itself with the NRF on startup. When one function needs to call another, it queries the NRF.
This makes the NRF a high-value target. Compromise the NRF and you can redirect any service-to-service call to a malicious endpoint. Read NRF traffic and you learn the entire topology of the operator's core network.
NRF interactions are protected by TLS 1.3 plus OAuth 2.0 access tokens. The OAuth tokens are short-lived (typically 5 to 15 minutes), but the underlying TLS sessions and the certificate chain that authenticates services to the NRF are long-lived. PQC migration for the NRF means migrating both the TLS certificates and the OAuth signing keys.
The NEF and Third-Party API Exposure
The NEF (Network Exposure Function) is the gateway through which the 5G core exposes APIs to third parties. Enterprise customers, IoT platforms, and value-added service providers can call NEF APIs to subscribe to network events, query subscriber location, control QoS for specific flows, or trigger device wake-ups.
NEF APIs use TLS plus OAuth 2.0, the same as internal SBA traffic, but with additional concerns about external attack surface. Every NEF deployment is a potential breach point if the cryptography is weak.
For PQC migration, the NEF is a priority because its TLS sessions cross the operator boundary into untrusted networks. Any traffic that an adversary could record on those external links is a candidate for harvest-now-decrypt-later attacks.
SEPPs and N32 Interconnect
When two operators want to roam, they connect their cores via Security Edge Protection Proxies (SEPPs). The N32 interface between SEPPs is where roaming signaling, authentication exchanges, and policy negotiations happen. It is one of the most security-sensitive interfaces in the entire 5G ecosystem because a compromise affects subscribers from both operators.
N32 uses TLS 1.3 with certificate-based mutual authentication. There is also an option for additional application-layer integrity protection on top of TLS, called PRINS (Protocol for N32 Interconnect Security), defined in TS 33.501.
For PQC, N32 is a priority. The traffic is long-lived, the keys are persistent, and the attacker has motive to record traffic for long-term decryption. Hybrid ML-KEM is the recommended migration path. Read more about why hybrid is the conservative choice in hybrid encryption.
AKA, Long-Term Keys, and the SIM
5G-AKA, the authentication and key agreement protocol, is symmetric. The subscriber's permanent key K (often called Ki for legacy reasons) lives on the SIM card and in the operator's UDM. K is used to derive session keys for over-the-air encryption and integrity protection.
In a pure symmetric sense, AKA is quantum-resistant. AES is quantum-resistant for sufficiently large key sizes, and HKDF-based key derivation is quantum-resistant. The problem is the supporting infrastructure: the certificates that protect K during provisioning, the SUCI public-key encryption, and the cryptography on every interface that handles K-derived material.
Read more about ML-KEM in detail to understand why the public-key migration matters even when the core protocol is symmetric.
OAuth 2.0 and JWT Signatures
The SBA uses OAuth 2.0 for service-to-service authorization. The NRF acts as the OAuth authorization server (or delegates to a separate authorization server). Services request access tokens, present them on calls to other services, and the receiver validates the token signature.
OAuth tokens in 5G are JWTs (JSON Web Tokens) signed with RS256 (RSA-SHA256) or ES256 (ECDSA-SHA256). Both are vulnerable to quantum attack on the signature side. PQC migration means moving to ML-DSA-based signing for JWTs. The JWT format supports custom signing algorithms via the alg header, and IETF drafts are defining the values for ML-DSA.
The trade-off is signature size. RS256 produces 256-byte signatures; ES256 produces 64-byte signatures; ML-DSA-65 produces 3293-byte signatures. JWTs are passed in HTTP headers and on every API call, so the size growth has a real bandwidth cost. Operators are evaluating whether to use ML-DSA for tokens or to use a hybrid scheme where the token is signed by both algorithms.
Migration Timeline
3GPP has published a study item (TR 33.700-41) and is expected to publish normative specifications in Release 19 and Release 20 of the 3GPP standards. Vendor implementations typically lag the specification by 12 to 24 months. Operator deployments lag vendor implementations by another 12 to 24 months.
Realistically, hybrid PQC for 5G core deployments starts appearing in production around 2027 to 2028. Full deployment across major operators is expected by 2030 to 2032, in line with NIST's PQC migration timeline. Read the NIST FIPS guide for the broader policy context.
Network Slicing and PQC
5G network slicing lets operators create logical networks tailored to specific use cases: enhanced mobile broadband, ultra-reliable low-latency communications, massive machine-type communications, and enterprise private networks. Each slice has its own QoS policies, security policies, and sometimes its own dedicated network functions.
For PQC, network slicing introduces additional cryptographic complexity. Each slice may have its own certificate authority for slice-specific authentication. Slice-isolated network functions may have different cryptographic profiles. The slicing control plane (NSSF, Network Slice Selection Function) coordinates slice instantiation and uses TLS extensively.
Migrating slicing infrastructure to PQC follows the broader 5G core PQC roadmap. Operators running enterprise private slices for verticals like manufacturing, healthcare, or public safety often have stricter PQC timeline requirements driven by industry regulations.
OSS/BSS and PQC Integration
Beyond the technical 5G core, operators run Operations Support Systems (OSS) and Business Support Systems (BSS) that manage the network and the customer relationship. These systems include billing, customer relationship management, network inventory, fault management, and service activation.
For PQC, OSS/BSS migration is similar to enterprise IT migration: TLS connections need PQC, certificates need PQC, signed software needs PQC. The complication is that OSS/BSS systems often integrate with many third-party systems (regulators, partners, settlement providers), and each of those integrations has its own PQC migration timeline. Operators have to manage the migration in coordination with their entire ecosystem.
Frequently Asked Questions
Will my SIM card need to be replaced for PQC? Probably not for the symmetric authentication core. AKA itself is symmetric and quantum-resistant. SIMs may need updates for new SUCI profiles based on ML-KEM, but this is typically delivered as an OTA update rather than a card swap, depending on the SIM platform.
Does PQC slow down 5G attach? For now, no. Production deployments still use ECIES for SUCI. When PQC SUCI rolls out, the attach time will increase by a few milliseconds and the SUCI ciphertext will grow from 32 bytes to about 1100 bytes. For the user, this is imperceptible.
What about 5G non-standalone (NSA)? NSA reuses 4G EPC for the core and 5G NR for the radio. The same PQC migration applies on the EPC side, but EPC has fewer SBA-style interfaces. The S6a interface (between MME and HSS) is the main TLS-protected control surface. SA (standalone) deployments have the full SBA and the broader PQC migration scope.
Is N32 already encrypted today? Yes. N32 uses TLS 1.3 with certificate-based mutual authentication. The PQC question is which key exchange and signature algorithms underlie the TLS session.
Do operators have a choice in PQC algorithms? Within the 3GPP framework, yes, with constraints. 3GPP normatively specifies which algorithms are allowed at each layer, and operators implement the algorithms supported by their vendors. ML-KEM and ML-DSA are expected to be the primary PQC algorithms in 3GPP specifications, with hybrid modes mandatory during transition.
Sources
- 3GPP TS 33.501, "Security architecture and procedures for 5G System", https://www.3gpp.org/DynaReport/33501.htm
- 3GPP TR 33.700-41, "Study on enabling Post-Quantum Cryptography in 5G", https://www.3gpp.org/DynaReport/33700-41.htm
- NIST FIPS 203, "Module-Lattice-Based Key-Encapsulation Mechanism Standard", https://csrc.nist.gov/pubs/fips/203/final
- NIST FIPS 204, "Module-Lattice-Based Digital Signature Standard", https://csrc.nist.gov/pubs/fips/204/final
- IETF RFC 7519, "JSON Web Token (JWT)", https://www.rfc-editor.org/rfc/rfc7519.html
- 3GPP TS 23.501, "System Architecture for the 5G System", https://www.3gpp.org/DynaReport/23501.htm
Related Articles
- What is Post-Quantum Cryptography?
- ML-KEM Explained
- PQC for Telecom 5G and 6G
- Hybrid Encryption
- Harvest Now Decrypt Later
Protect Your Data Before Q-Day Arrives
QNSQY's NIST-standardized post-quantum encryption protects files against both current and quantum-era threats.