SUPI and SUCI in 5G: Identity Privacy That Actually Matters

Why SUPI and SUCI deserve a dedicated security discussion

If you have ever looked at legacy mobile security incidents, you have seen the same pattern repeat. A permanent subscriber identifier leaks early in the attach flow, and suddenly passive tracking becomes cheap. The 5G architecture tried to close that door by redesigning subscriber identity exposure at first contact.

That redesign is the SUPI and SUCI pair.

SUPI is the real identity. SUCI is the privacy preserving wrapper that is supposed to be safe to send over the air when the device first registers.

When it works, it reduces a whole category of identity leakage. When it is misconfigured, rotated badly, downgraded, or bypassed via fallback, you are back to legacy style exposure, just with better marketing slides.

What is SUPI

SUPI means Subscription Permanent Identifier. It is the long lived identifier that uniquely maps to a subscriber in the home network.

In most deployments, SUPI is structured as an IMSI style value, meaning a combination of:

1. Mobile country code
2. Mobile network code
3. Subscriber number portion

5G also supports a Network Access Identifier style SUPI in some scenarios, but the operational reality for many operators is still IMSI shaped identifiers with 5G core mapping.

Security implication: SUPI is the crown jewel for passive correlation. If an attacker can obtain it on the radio path or via weak interconnect exposure, it can be used as a stable key for tracking, profiling, and selective targeting.

What is SUCI

SUCI means Subscription Concealed Identifier. It is what the UE should send instead of SUPI during initial registration.

Conceptually, SUCI is:

A concealed form of SUPI created by the UE using the home network public key and a standardized protection scheme.

Operationally, SUCI includes fields that let the network reverse it, such as:

1. Home network identifier components
2. Protection scheme identifier
3. Home network public key identifier
4. Concealed payload

The home network can recover the SUPI because it has the corresponding private key and the correct de concealment logic.

Security implication: SUCI is designed to reduce permanent identity exposure on the radio interface during initial access, which is where legacy identity catch attacks historically lived.

The security goal SUCI is trying to achieve

SUCI exists to make first contact safer.

Instead of broadcasting a permanent identifier that can be collected and correlated, the device sends a concealed form that is useless to a passive observer.

That is the key word. Passive.

If you only harden passive exposure but still allow easy fallback to older generations that expose legacy identifiers, you get a privacy feature that works mainly in lab demos and executive keynotes.

So the real security objective is broader:

Keep permanent identity off the air whenever possible, and prevent forced fallback paths from re exposing it.

How SUCI is generated at a practical level

Without diving into implementation code or operationally risky detail, the important points for defenders are:

1. The UE needs the correct home network public key material and identifiers.
2. The protection scheme must be correctly selected and supported by both UE and core.
3. The home network must manage key lifecycle and rotation in a way that does not break registration or trigger unsafe fallback.
4. The network needs consistent de concealment in the AUSF and UDM path, and correct handling by AMF and related functions.

This means SUCI security is not just cryptography. It is configuration, provisioning, roaming integration, and key management discipline.

Where SUPI and SUCI fail in the real world

Most identity privacy failures are not because the math is broken. They are because systems fall back, mis signal capability, or get operated under constraints that prioritize attachment success over privacy.

1. Unsafe fallback and inter system mobility

A subscriber can still be forced onto older access technology in some conditions. Older generations can expose identifiers that are easier to correlate.

What to look for as a defender:

Is identity privacy maintained when the device is pushed into non standalone scenarios or older radio coverage conditions, and do policy controls prevent avoidable exposure?

2. Weak key lifecycle and rotation practices

Key rotation is required. It is also one of the fastest ways to create operational outages if not coordinated across UEs, provisioning, and core.

Common failure modes:

1. Keys rotated in the core but not provisioned to devices
2. Multiple key identifiers used inconsistently across regions
3. Roaming partners not aligned on supported schemes and identifiers

Security outcome: registration failures can lead to fallback behavior and identity exposure, or to emergency operational workarounds that disable protections.

3. Misconfiguration of protection scheme selection

If the network and device do not agree on the scheme, you can end up in degraded behavior.

Security outcome: concealment can be absent or weak, and troubleshooting often focuses on making registration succeed rather than preserving privacy.

4. Logging and observability that leaks what SUCI tried to protect

Even if SUCI works on the air interface, you can still leak stable identifiers inside:

1. Overly broad log retention in core functions
2. Debug logging in integration layers
3. Export of identifiers into analytics systems without proper governance

Security outcome: internal privacy posture collapses, and a single compromised monitoring or analytics plane becomes a subscriber correlation engine.

5. Roaming and interconnect exposure

Roaming introduces additional domains and trust boundaries. Identity data can surface in places you did not model during initial design.

Security outcome: correlation becomes possible via partner visibility and interconnect telemetry, even when the radio path is clean.

What security teams should test

The safe way to test is to focus on evidence, policy enforcement, and downgrade resistance in an authorized environment.

Validate that SUCI is actually used in first registration

You want empirical confirmation that, under normal 5G coverage, initial registration identity exchange uses SUCI and does not expose a permanent identifier.

Evidence sources can include controlled captures in a lab, and core side observability that confirms SUCI presence and correct de concealment outcomes.

Assess downgrade resilience

The question is not whether fallback exists. It is whether it can be triggered in ways that unnecessarily re expose permanent identity.

Evaluate policy, device behavior expectations, and whether operational practices inadvertently enable identity exposure during coverage edge cases.

Review home network key management and operational playbooks

Focus on:

1. Key provisioning to UEs
2. Key identifier consistency
3. Rotation cadence and rollback plans
4. Monitoring for rotation induced failures
5. Separation of duties and access controls around private key material

Audit identifier handling in logs and analytics

You are looking for:

1. Permanent identifiers written into logs that do not require them
2. Long retention of raw identity fields
3. Broad access to identity correlated telemetry
4. Lack of tokenization or privacy controls in downstream systems

Validate roaming alignment

Confirm that roaming configurations do not force scheme downgrades or cause registration behavior that trades privacy for attach success without explicit risk acceptance.

Threat modeling SUPI and SUCI the way engineers actually operate

If you are building a realistic threat model, split it across three planes:

1. Radio plane exposure
   Does the device ever transmit a stable identity in clear conditions that can be collected at scale?
2. Core plane handling
   Does the de concealment path keep secrets protected, and are identifiers minimized and controlled across functions and logs?
3. Operational plane behaviors
   When something breaks, do the emergency fixes disable privacy features, expand logging, or create persistent exceptions?

If you only model the cryptography, you will miss the failure modes that generate incidents.

Design and operations recommendations that hold up under pressure

These are deliberately practical, because privacy mechanisms fail most often during stress.

1. Treat identity privacy as an availability and operations problem, not only a security feature. If rotation causes outages, teams will bypass it.
2. Minimize identifier spread. The fewer systems that store stable identifiers, the fewer systems can leak them.
3. Make downgrade behavior explicit and controlled. If fallback increases exposure, document it, gate it, and monitor for it.
4. Align roaming expectations early. Multi domain identity handling is where clean designs go to die.
5. Build privacy checks into acceptance criteria. Do not make SUCI a checkbox item. Make it a measurable property.

Closing perspective

SUPI and SUCI are a meaningful step forward because they target a painful historical weakness: permanent identity exposure at first contact. But the security value is only realized when the entire system, from device provisioning to key lifecycle to roaming integration and to logging discipline, is operated in a way that refuses silent downgrade.

If you want 5G identity privacy to be real, you have to treat SUCI as a system property, not a protocol feature.