5G Re-Authentication / Identity Recovery Procedure Call Flow
5G Re-Authentication / Identity Recovery is the later security-recovery branch used when the network no longer wants to trust the UE identity or security continuity without revalidation.
It combines Identity Request, renewed subscriber challenge, and protected continuation recovery into one practical security-repair path.
Introduction
This procedure is different from first-time authentication because it begins after some access or service context already existed.
In real traces it often appears when temporary identity is stale, AMF context has drifted, or a later service branch needs stronger proof before protected continuation can continue.
What Is Re-Authentication / Identity Recovery Procedure in Simple Terms?
- What starts the procedure: The network no longer trusts the current identity or security continuity enough to proceed.
- What the UE and network want to achieve: Recover a trustworthy identity view and re-establish subscriber trust.
- What success looks like: Identity recovery and renewed authentication succeed, and the trace returns to protected continuation.
- What failure means: The network cannot recover trust on the current branch, so broader restart or rejection follows.
Why this procedure matters
This procedure is where 5G repairs weak trust after context drift, stale temporary identity, or later service recovery problems. It prevents the network from continuing on an identity basis it no longer believes.
Quick Fact Sheet
| Procedure name | 5G Re-Authentication / Identity Recovery Procedure |
|---|---|
| Domain | 5G identity revalidation and security recovery |
| Main trigger | The network no longer trusts the current identity or wants to revalidate subscriber security context during later continuation |
| Start state | UE already has some access or service context, but identity certainty or security continuity is no longer sufficient |
| End state | The network regains confidence through Identity and Authentication exchange or forces broader recovery |
| Main nodes | UE, gNB, AMF, AUSF, UDM |
| Main protocols | NAS, Identity Request, Authentication, context recovery |
| Main success outcome | The network re-identifies the UE and completes renewed authentication so protected continuation can proceed |
| Main failure outcome | The UE cannot prove identity or subscriber legitimacy, so later access or service is rejected or restarted |
| Most important messages | Identity Request, Identity Response, Authentication Request, Authentication Response |
| Main specs | TS 24.501, TS 23.502, TS 33.501 |
Preconditions
- The UE already has or recently had some access or service context in the network.
- The network has a reason to distrust the old identity or security continuity.
- The UE can still receive and answer NAS identity and authentication signaling.
- AUSF and UDM remain reachable for renewed subscriber validation.
Nodes and Interfaces
Nodes involved
| Node | Role in this procedure |
|---|---|
| UE | Provides identity again when requested and proves subscriber legitimacy through renewed authentication. |
| gNB | Carries the NAS exchange while the network re-establishes identity and trust. |
| AMF | Decides the current identity or security state is not sufficient and restarts identity or authentication checks. |
| AUSF | Validates the renewed authentication attempt. |
| UDM | Provides subscriber context needed for identity recovery and renewed authentication. |
Interfaces used
| Interface | Path | Role |
|---|---|---|
| N1 | UE <-> AMF via gNB | Carries identity recovery and re-authentication NAS signaling. |
| NR-Uu | UE <-> gNB | Carries the radio transport for the renewed identity and security exchange. |
| N12 and N8 | AMF <-> AUSF <-> UDM | Carry renewed subscriber security context and validation support. |
End-to-End Call Flow
UE gNB AMF AUSF / UDM
| | | |
|<- Identity Request ----------------| |
|-- Identity Response -------------->| |
| |-- auth prep ---->|
|<- Authentication Request ----------| |
|-- Authentication Response -------->| |
|<-- Result / later Security Mode ---| |Major Phases
| Phase | What happens |
|---|---|
| 1. Trust degradation or identity uncertainty | The network decides the current identity or security context can no longer be relied on without revalidation. |
| 2. Identity recovery | The AMF requests a better identity view from the UE, often using Identity Request. |
| 3. Re-authentication | The network challenges the UE again using the renewed identity context. |
| 4. Protected continuation or restart | If the UE passes, the trace returns to protected continuation. If not, broader recovery is required. |
Step-by-Step Breakdown
Network decides current identity or security trust is no longer enough
Sender -> receiver: AMF internal logic
Message(s): Identity doubt, stale temporary identity, context loss, or security recovery trigger
Purpose: Prevent the network from continuing service on a weak or uncertain identity basis.
State or context change: The UE is still in a live access context, but the network no longer wants to trust the current identity view blindly.
Note: This often appears after mobility, context inconsistency, or later service recovery rather than at first registration.
AMF requests identity recovery from the UE
Sender -> receiver: AMF -> UE
Message(s): Identity Request and Identity Response
Purpose: Recover a trustworthy subscriber identity that can support renewed security validation.
State or context change: The network now refreshes its understanding of who the UE really is.
Note: Identity recovery is often the missing middle step between a stale temporary identity and a clean renewed authentication attempt.
Network challenges the UE again
Sender -> receiver: AMF <-> AUSF <-> UDM and AMF -> UE
Message(s): Authentication Request and Authentication Response
Purpose: Rebuild trust using the renewed identity context and current subscriber security data.
State or context change: The procedure moves from identity recovery into renewed proof of subscriber legitimacy.
Note: If this phase fails, the identity branch may have succeeded technically while security continuity still failed logically.
Network either restores trust or forces broader restart
Sender -> receiver: AMF -> UE
Message(s): Authentication Result, Authentication Reject, later Security Mode, or broader recovery behavior
Purpose: Decide whether protected continuation may proceed again.
State or context change: The UE either returns to a trusted branch or must restart more of the access lifecycle.
Note: A clean result should usually hand off into NAS security or resumed service rather than just ending silently.
Important Messages in This Flow
| Message | Protocol | Direction | Purpose in this procedure | What to inspect briefly |
|---|---|---|---|---|
| Identity Request | NAS | AMF -> UE | Requests a stronger or refreshed identity view from the UE. | Inspect which identity type is being requested and why the earlier view was insufficient. |
| Identity Response | NAS | UE -> AMF | Returns the requested identity material for revalidation. | Inspect SUCI, SUPI-related handling, or temporary-identity continuity. |
| Authentication Request | NAS | AMF -> UE | Restarts subscriber challenge after identity recovery. | Check whether the renewed challenge uses the correct recovered identity context. |
| Authentication Response | NAS | UE -> AMF | Proves subscriber legitimacy again after identity recovery. | Inspect whether the renewed trust path progresses into later Security Mode. |
Important Parameters to Inspect
| Parameter | What it is | Where it appears | Why it matters | Common issues |
|---|---|---|---|---|
| Identity type requested | Which form of identity the network wants the UE to provide again. | Identity Request | Explains whether the network is recovering from stale temporary identity, unknown subscriber, or broader context doubt. | Wrong expectation about identity type leads to bad analysis. |
| Temporary identity validity | Whether the existing 5G-GUTI or related temporary identity should still have been trusted. | Pre-recovery context | Helps explain why identity recovery became necessary. | If stale, later authentication may still be correct but triggered for the wrong reason. |
| Recovered subscriber context | The subscriber context re-established after identity recovery. | AMF, UDM, AUSF handling | Provides the basis for renewed authentication. | If inconsistent, the challenge can be valid for the wrong subscriber view. |
| Renewed challenge lineage | Whether the re-authentication challenge matches the recovered identity context. | Authentication Request | Connects identity recovery to later trust establishment. | Broken lineage causes repeated or confusing security failures. |
| Post-recovery continuation | What the network does after renewed trust is established. | Later NAS continuation | Proves whether the recovery actually restored useful service continuity. | If missing, the recovery may have been only partial. |
Success Criteria
- The network requests the right identity type for the real recovery problem.
- The recovered identity maps cleanly to the intended subscriber context.
- Renewed authentication validates successfully.
- The branch hands off into Security Mode or later protected continuation without looping again.
Common Failures and Troubleshooting
| Symptom | Likely cause | Where to inspect | Relevant message(s) | Relevant interface(s) | Likely next step |
|---|---|---|---|---|---|
| Identity Request repeats without stable recovery | The network keeps failing to rebuild a trustworthy identity view. | Identity type handling, AMF context stability, and temporary identity validity. | Identity Request, Identity Response | N1 | This often points to stale identity or AMF state loss rather than to RF trouble. |
| Identity recovery succeeds but re-authentication still fails | The subscriber identity was recovered, but the renewed trust challenge still did not validate. | Recovered subscriber context, vectors, and renewed challenge lineage. | Authentication Request, Authentication Response | N12, N8, N1 | Treat identity and authentication as two linked but distinct recovery stages. |
| Service loops back to fresh registration | The network could not re-establish enough trust to continue on the existing branch. | Whether the UE falls back into registration after failed identity and authentication recovery. | Identity Request, Authentication Reject, Registration Request | N1, N2 | This is a broader recovery symptom, not just one bad message. |
| Identity recovery appears during service request unexpectedly | The network lost confidence in the existing identity or context during later service continuation. | Temporary identity validity and context retention across idle or inactive periods. | Service Request, Identity Request | N1 | This is common in stale-context and later-recovery scenarios. |
What to Check in Logs and Traces
- First ask why the old identity was no longer trusted.
- Inspect the identity type requested and whether the UE answered with the expected format.
- Correlate identity recovery with the renewed authentication challenge that follows.
- If the branch loops, compare temporary identity validity and AMF context stability across attempts.
Related Pages
Related sub-procedures
Related message reference pages
Related troubleshooting pages
FAQ
What is 5G Re-Authentication / Identity Recovery?
It is the procedure family where the network re-identifies the UE and revalidates subscriber trust after the old context is no longer reliable enough.
Is this the same as normal initial authentication?
No. It happens later, after some context already existed, because the network needs to recover or refresh trust.
Why would Identity Request appear again after registration?
Because the temporary identity or security continuity may no longer be trustworthy in the current context.
What should I inspect first?
Start with why the network lost confidence in the old identity, then follow Identity Request into renewed authentication.
What usually follows successful recovery?
The trace should return to protected continuation, often through Security Mode and later service procedures.