5G Security: Why IMSI Catchers No Longer Work (SUPI, SUCI, ECIES)

In 2019, an investigative journalist covering a political summit received a call from his editor. He was being monitored. Not by a state intelligence service operating under a judicial warrant, but by a private actor using equipment available for a few thousand euros on the grey market. The device: an IMSI catcher. A rogue base station that impersonates a legitimate cell tower, forces the phone to identify itself, and captures its IMSI — the subscriber’s permanent identifier — in clear text, before a single byte of user data is exchanged.

This scenario is not hypothetical. IMSI catchers are documented in dozens of journalistic investigations, parliamentary reports, and court proceedings across Europe, the United States, and the Middle East. They are used by law enforcement, but also by malicious actors for target tracking, communications interception, and mass surveillance during protests.

5G Standalone was designed to make this attack structurally impossible. Not through a software patch or a configuration update, but through an architectural redesign of identity management. Here is how it works, and why the journey is not yet complete.

The evolution of subscriber identity security by mobile generation

Each mobile network generation brought improvements in authentication and subscriber identity protection. But each generation also retained inherited flaws or introduced new attack surfaces.

Generation	Authentication	Subscriber identity	Primary vulnerability
2G (GSM)	One-way (network authenticates terminal, not the reverse)	IMSI transmitted in clear	Trivial rogue BTS. No mutual authentication. A5/1 interception demonstrated since 2009.
3G (UMTS)	Mutual (AKA)	IMSI transmitted in clear at first attach, then TMSI	Mutual authentication protects against rogue BTS, but 2G fallback cancels this protection. IMSI remains exposed at initial attach.
4G (LTE)	Mutual (EPS AKA)	IMSI transmitted in clear during initial Attach Request, then GUTI	EPS AKA improves key derivation, but Identity Request of type IMSI remains possible. IMSI catchers exploit this window.
5G SA	Mutual (5G AKA / EAP-AKA’)	SUPI never transmitted in clear. SUCI encrypted via ECIES.	The SUCI is a disposable encrypted identifier. The IMSI catcher only sees an unusable cryptographic blob.

The critical point: in 2G, 3G, and 4G, there is always a moment when the terminal transmits its permanent identifier in clear over the radio interface. In 5G SA, that moment no longer exists.

How IMSI catchers work

The principle behind an IMSI catcher relies on three steps:

1. Network identity spoofing. The IMSI catcher broadcasts a signal stronger than the legitimate surrounding base stations, on the target operator’s frequencies. The mobile terminal, in accordance with 3GPP specifications, selects the cell offering the best signal level (S and R criteria for cell selection/reselection).

2. Identity request. Once the terminal has attached to the rogue station, the IMSI catcher sends a NAS Identity Request message with identity type set to IMSI. In 4G, the terminal is required to respond with its IMSI in an Identity Response message, in clear text, without prior verification of the network’s authenticity for this specific procedure.

3. Collection and tracking. The captured IMSI (format: MCC + MNC + MSIN, 15 digits total) uniquely identifies the subscriber. The attacker can then track the terminal’s movements (by triangulating with multiple IMSI catchers), correlate the network identity with a physical identity, or conduct man-in-the-middle attacks on communications.

In 4G, even though mutual authentication via EPS AKA is in place, the Identity Request procedure of type IMSI is a legitimate protocol feature. It is specified in 3GPP TS 24.301 for cases where the MME does not have the terminal’s GUTI (first attach, context loss, etc.). The IMSI catcher exploits a specified feature, not an implementation bug.

SUPI: the successor to IMSI in 5G

The SUPI (Subscription Permanent Identifier) is the subscriber’s permanent identifier in the 5G architecture, defined in 3GPP TS 23.003. Its structure is identical to that of the IMSI:

• MCC (Mobile Country Code): 3 digits identifying the country (e.g., 310 for the United States)
• MNC (Mobile Network Code): 2 or 3 digits identifying the operator (e.g., 260 for T-Mobile US)
• MSIN (Mobile Subscriber Identification Number): up to 10 digits uniquely identifying the subscriber within the network

The SUPI can also take the form of a NAI (Network Access Identifier) for non-3GPP subscribers (WiFi access, satellite, etc.).

The fundamental difference from the IMSI: the SUPI is never transmitted in clear over the radio interface. It is stored in the USIM and in the UDM (Unified Data Management) of the core network, but it never crosses the air interface in readable form.

SUCI: identity encryption via ECIES

To transmit its identity to the network, the 5G terminal generates a SUCI (Subscription Concealed Identifier). The SUCI is the result of encrypting the MSIN contained in the SUPI, using the ECIES (Elliptic Curve Integrated Encryption Scheme) cryptographic scheme, as defined in 3GPP TS 33.501.

The SUCI generation process takes place within the terminal’s USIM:

1. Operator public key. During USIM provisioning, the operator writes its ECIES public key (based on Profile A: X25519 or Profile B: secp256r1 curves) to the card. This public key is stored permanently on the card.

2. Ephemeral key generation. At each registration procedure, the USIM generates a new ephemeral key pair. The ephemeral private key is combined with the operator’s public key through an Elliptic Curve Diffie-Hellman exchange to produce a unique, disposable shared encryption key.

3. MSIN encryption. The MSIN is encrypted with this shared key. The resulting SUCI contains: the MCC, the MNC (in clear, for network routing), the terminal’s ephemeral public key, and the encrypted MSIN.

4. Transmission. The SUCI is sent in the NAS Registration Request message. The clear-text elements (MCC+MNC) allow the network to route the request to the correct operator. The encrypted MSIN ensures the subscriber’s unique identity remains protected.

The result: even if an IMSI catcher intercepts the SUCI, it only sees the MCC+MNC (which identify the operator, not the subscriber) and a cryptographic blob that changes with every registration attempt. Without the operator’s private key (stored in the UDM), the MSIN is unrecoverable.

The 5G AKA flow: authentication and decryption

SUCI decryption and mutual authentication are part of the 5G AKA (Authentication and Key Agreement) protocol, defined in 3GPP TS 33.501. Three core network functions are involved:

SEAF (Security Anchor Function) — co-located with the AMF. It receives the SUCI from the terminal and initiates the authentication procedure by contacting the AUSF.

AUSF (Authentication Server Function) — verifies authentication. It forwards the SUCI to the UDM for decryption and authentication vector generation.

UDM (Unified Data Management) — holds the operator’s ECIES private key. It is the only entity capable of decrypting the SUCI to recover the SUPI. The UDM generates the authentication vectors (RAND, AUTN, XRES*, KAUSF) via its SIDF (Subscription Identifier De-concealing Function) and ARPF (Authentication credential Repository and Processing Function) modules.

The simplified flow:

1. The terminal sends a Registration Request containing the SUCI to the AMF/SEAF.
2. The AMF/SEAF forwards the SUCI to the AUSF (Nausf_UEAuthentication_Authenticate message).
3. The AUSF forwards the SUCI to the UDM (Nudm_UEAuthentication_Get message).
4. The UDM’s SIDF decrypts the SUCI into the SUPI, then the ARPF generates the authentication vectors.
5. The UDM returns the vectors to the AUSF, which forwards them to the AMF/SEAF.
6. The AMF/SEAF sends an Authentication Request to the terminal (containing RAND and AUTN).
7. The terminal verifies AUTN (network authentication), computes RES*, and returns it.
8. The AUSF verifies RES* against XRES* (terminal authentication).
9. Mutual authentication is complete. Session keys are derived.

At no point does the SUPI travel over the radio interface. Authentication is mutual: the terminal verifies the network’s authenticity (via AUTN), and the network verifies the terminal’s authenticity (via RES*/XRES*). An IMSI catcher cannot provide a valid AUTN because it does not have the keys stored in the UDM.

The persistent vulnerability: 5G NSA

5G NSA (Non-Standalone) represents the majority of commercial 5G deployments in 2026. It uses 5G NR radio for the user plane but retains the 4G core network (EPC) for the control plane and initial signaling.

This is a fundamental security problem: in 5G NSA, the attach procedure goes through the 4G MME, not the 5G AMF. The terminal registers via an EPS Attach procedure, which uses the 4G security architecture. The IMSI is transmitted during the initial Attach Request exactly as in pure LTE.

The consequences are direct:

• No SUCI. ECIES identity encryption only exists in the 5GC (5G SA core) architecture. The 4G core does not handle the SUCI.
• No 5G AKA. Authentication relies on EPS AKA, with the same limitations as in LTE.
• IMSI catchers remain operational. Surveillance equipment designed for 4G works without modification on 5G NSA networks.

For an operator or enterprise, the distinction is critical: deploying 5G NR radio does not improve subscriber identity protection if the core network remains 4G. Only the transition to the 5G SA core activates the SUPI/SUCI/ECIES mechanisms.

In Europe, the 5G SA deployment rate remains below 10% of commercial networks. This means that for over 90% of European 5G subscribers, the IMSI catcher remains an operational threat. The “5G” label displayed on the phone does not guarantee identity protection.

What 3GPP TS 33.501 specifies

3GPP TS 33.501 (Security architecture and procedures for 5G System) is the reference specification for 5G security architecture. The sections relevant to identity protection:

• Section 6.12: Subscription privacy. Defines the SUPI/SUCI mechanism and encryption requirements.
• Section 6.1: Security features. Specifies that the SUPI must never be transmitted in clear over radio and transport interfaces.
• Annex C: ECIES protection profiles. Details Profile A (X25519 + AES-128-CTR + HMAC-SHA-256) and Profile B (secp256r1 + AES-128-CTR + HMAC-SHA-256).
• Section 6.1.3: 5G AKA and EAP-AKA’. Defines the two supported authentication methods.

The specification mandates that the null-scheme (SUCI = SUPI in clear, scheme ID 0x00) should only be used for lab testing and emergency situations. In production, an ECIES scheme is mandatory.

Implications for security engineers and field testers

For network security professionals and field engineers, the IMSI-to-SUPI/SUCI transition carries several practical implications:

Security auditing. When auditing a 5G network, verify that it actually uses the 5G SA core and not just NR radio on a 4G core. A terminal displaying “5G” may still be vulnerable to IMSI catchers in NSA configuration. Analyzing NAS messages on the radio interface reveals the procedure in use: Registration Request (5G SA) vs. Attach Request (4G/NSA).

Signaling analysis. In L3 traces, the SUCI appears in the 5GS Mobile Identity field of the Registration Request message. The field contains the identity type (SUCI), the protection scheme (ECIES Profile A or B), and the encrypted MSIN. If the identity type indicates a null-scheme in a production environment, it is a critical security alert.

Conformance testing. 3GPP conformance tests include verifying terminal behavior when facing a SUPI-type Identity Request. In 5G SA, the terminal must refuse to transmit its SUPI in clear if the network requests it through a non-conformant procedure.

Operator awareness. For operators in the NSA-to-SA migration phase, explicitly document that SUPI/SUCI protection is not active as long as the 5G SA core is not operational. Marketing communications mentioning “5G security” in an NSA context are technically inaccurate regarding identity protection.

Key takeaways

Subscriber identity protection in 5G SA is not a peripheral security add-on. It is a fundamental architectural change that eliminates an entire class of attacks (IMSI catching, passive tracking, identity correlation) through cryptographic design. The ECIES encryption of the MSIN within the SUCI, combined with 5G AKA mutual authentication and exclusive decryption by the UDM, creates a system where the subscriber’s permanent identity is never exposed on the radio interface.

But this protection only exists if the network runs on 5G SA. As long as the 4G core handles signaling, the IMSI travels in clear, and IMSI catchers work. For a field engineer, the relevant question is not “does the terminal display 5G?” but “does the registration procedure go through a 5G SA core?”

---

The technical terms in this article (SUPI, SUCI, ECIES, 5G AKA, UDM, AMF, AUSF) are detailed in the HiCellTek glossary. To dive deeper into 5G network slicing security and NIS2 obligations, see our dedicated article on network slicing and NIS2.