Home / Call Flows / 5G / Authentication Procedure

5G Authentication Procedure Call Flow

call-flow 5G NR | 5GC | NAS | AUSF | UDM | Security

5G Authentication is the primary trust-establishment procedure that proves a UE is a legitimate subscriber before the network allows protected service continuation.

It joins subscriber identity handling, challenge and response exchange, and security-anchor derivation into the first major security checkpoint of the 5G access path.

Introduction

This procedure usually appears during initial registration, but the same logic also matters in re-authentication and alternate-access security branches.

Operationally, its job is simple: build enough trust and key context that the network can safely continue into NAS Security Mode and later service procedures.

What Is Authentication Procedure in Simple Terms?

What starts the procedure: The network needs to verify the UE before protected 5G service can continue.
What the UE and network want to achieve: Prove subscriber legitimacy and derive the security anchor for later protection.
What success looks like: The UE is validated and the trace moves naturally into later security activation.
What failure means: The challenge, subscriber context, or response validation failed, so protected continuation cannot proceed.

Why this procedure matters

Authentication is the point where a 5G access attempt becomes trustworthy. If this phase is misunderstood, later security failures, identity loops, and registration problems are often diagnosed at the wrong layer.

Quick Fact Sheet

Procedure name	5G Authentication Procedure
Domain	5G subscriber authentication and primary security bootstrap
Main trigger	The network needs to verify subscriber legitimacy during registration or other security-sensitive access branches
Start state	UE has started a 5G access path but has not yet established trusted security context with the core
End state	The network validates the UE and derives key material that supports later NAS and AS security activation
Main nodes	UE, gNB, AMF, AUSF, UDM
Main protocols	NAS, 5G-AKA or EAP-AKA prime, N12, N8
Main success outcome	The UE proves knowledge of subscriber credentials and the core derives a valid security anchor
Main failure outcome	Authentication is rejected, vectors do not match, or the UE cannot proceed to later security activation
Most important messages	Registration Request, Authentication Request, Authentication Response, Authentication Result
Main specs	TS 23.501, TS 23.502, TS 24.501, TS 33.501

Preconditions

The UE has started a 5G access path that requires subscriber verification.
The AMF can reach AUSF and UDM to prepare authentication context.
The UE has valid subscriber credentials available through its secure identity context.
No protected continuation should proceed until authentication outcome is known.

Nodes and Interfaces

Nodes involved

Node	Role in this procedure
UE	Starts the access path, receives the authentication challenge, computes the response, and proves subscriber legitimacy.
gNB	Provides radio transport for NAS signaling between the UE and the core security functions.
AMF	Anchors the access-side security procedure and coordinates the authentication exchange with AUSF.
AUSF	Validates the subscriber response against the expected authentication result.
UDM	Provides subscriber-side credential context and generates authentication vectors or related security material.

Interfaces used

Interface	Path	Role
NR-Uu	UE <-> gNB	Carries the access-side signaling path for the NAS authentication exchange.
N1	UE <-> AMF via gNB	Carries Authentication Request, Authentication Response, and related NAS security messages.
N12	AMF <-> AUSF	Carries authentication context exchange between access management and the authentication server.
N8	AUSF <-> UDM	Carries subscriber credential and vector handling needed to validate the UE.

End-to-End Call Flow

UE               gNB               AMF               AUSF / UDM
|-- Registration Request ->|                 |                  |
|                          |---------------> |-- auth context ->|
|                          |                 |<- vectors / data -|
|<- Authentication Request-|                 |                  |
|-- Authentication Response ---------------->|                  |
|<----- Authentication Result / Reject ------|                  |

Major Phases

Phase	What happens
1. Access begins	The UE starts registration or another security-sensitive access procedure before trusted service is allowed.
2. Authentication context preparation	The AMF asks AUSF and UDM for the subscriber-specific challenge and expected response context.
3. Challenge and proof	The UE receives Authentication Request and answers with Authentication Response.
4. Validation and security bootstrap	The network checks the UE response and, if successful, prepares the security anchor for later NAS and AS protection.

Step-by-Step Breakdown

UE starts a registration or access path that requires trust establishment

Sender -> receiver: UE -> gNB -> AMF

Message(s): Registration Request or another access-start message

Purpose: Expose the subscriber access attempt to the network before protected continuation is allowed.

State or context change: The UE is visible to the network, but no trusted security context exists yet.

Note: The identity style in the first request strongly influences how the network prepares authentication and identity checks.

AMF prepares subscriber authentication context with AUSF and UDM

Sender -> receiver: AMF <-> AUSF <-> UDM

Message(s): Authentication vector request and authentication context delivery

Purpose: Build the challenge and expected verification data for this UE access attempt.

State or context change: The network now has the RAND, AUTN, and expected result needed to challenge the UE.

Note: If this stage is wrong, the later UE response can look incorrect even when the device behaves properly.

UE receives challenge and computes the response

Sender -> receiver: AMF -> UE and UE -> AMF

Message(s): Authentication Request and Authentication Response

Purpose: Prove that the UE holds the correct subscriber-side credentials.

State or context change: The exchange moves from network challenge to UE proof of legitimacy.

Note: This is the main comparison point for RAND, AUTN, RES star, and XRES star reasoning.

Network validates the result and prepares protected continuation

Sender -> receiver: AUSF -> AMF -> UE

Message(s): Authentication Result or Authentication Reject

Purpose: Decide whether the UE may continue into later security activation and service procedures.

State or context change: Successful authentication creates the security basis for NAS Security Mode and later AS protection.

Note: A successful authentication exchange is not the end of security; it is the handoff into later protection activation.

Important Messages in This Flow

Message	Protocol	Direction	Purpose in this procedure	What to inspect briefly
Registration Request	NAS	UE -> AMF	Starts the access path that leads into authentication.	Inspect SUCI or temporary identity style and whether the request matches the expected access scenario.
Authentication Request	NAS	AMF -> UE	Carries the subscriber challenge from the network.	Inspect RAND, AUTN, and whether the challenge belongs to the right UE and access attempt.
Authentication Response	NAS	UE -> AMF	Returns the UE-computed proof based on the challenge.	Inspect RES star continuity and whether the UE response timing and content are sensible.
Authentication Result	NAS	AMF -> UE	Confirms successful authentication and prepares later protected continuation.	Check whether the trace moves naturally into NAS Security Mode.
Authentication Failure	NAS	UE -> AMF	Shows that the UE could not accept or validate the challenge.	Inspect failure cause because sync failure and general authentication failure mean very different next actions.

Important Parameters to Inspect

Parameter	What it is	Where it appears	Why it matters	Common issues
SUCI or UE identity	The identity presented before or during authentication.	Registration Request and identity handling	Explains how the network locates the subscriber context needed to challenge the UE.	Wrong identity interpretation often causes the network to challenge the wrong context.
RAND	The random challenge value sent by the network.	Authentication Request	One of the core inputs used by the UE to compute the response.	If it is mismatched across systems, the UE response will never validate.
AUTN	The authentication token proving network-side legitimacy to the UE.	Authentication Request	Lets the UE verify that the challenge came from a trusted source.	Bad AUTN commonly causes explicit authentication failure or sync issues.
RES star and XRES star	The UE-computed result and network-expected result.	Authentication Response and AUSF validation	They determine whether the UE is accepted as legitimate.	A mismatch points to credential, vector, or synchronization trouble.
K_SEAF bootstrap context	The post-authentication security anchor used for later security procedures.	Authentication result handling	Connects authentication success to later NAS and AS protection.	If the anchor is not derived or passed correctly, later security mode can still fail.

Success Criteria

The network prepares the correct subscriber authentication vectors.
The UE validates the challenge and returns the correct response.
AUSF accepts the result and the AMF receives usable security-anchor context.
The procedure hands off cleanly into NAS Security Mode and later service continuation.

Common Failures and Troubleshooting

Symptom	Likely cause	Where to inspect	Relevant message(s)	Relevant interface(s)	Likely next step
Authentication Request arrives but the UE rejects it	The UE could not validate the challenge or authentication token.	AUTN, sync state, and whether the challenge belongs to the right subscriber context.	Authentication Request, Authentication Failure	N1	This is not just a bad password-style failure; network legitimacy can also be the issue.
UE sends Authentication Response but the network still rejects	The network expected result and the UE-computed result did not match.	Vector generation, UDM data, and RES star versus XRES star comparison.	Authentication Response, Authentication Reject	N12, N8, N1	The problem may be in vector preparation, not in the radio leg.
Authentication succeeds but later security mode fails	Primary authentication worked, but the security anchor was not translated cleanly into later protection setup.	K_SEAF continuity, AMF context, and later NAS security selection.	Authentication Result and later Security Mode Command	N1, N12	Treat this as a handoff failure between security phases.
Authentication loops or repeats unexpectedly	The network is losing context, the UE state is resetting, or identity handling is inconsistent.	Registration continuity, UE identity reuse, and AMF context stability.	Registration Request, Authentication Request	N1, N2	Repeated authentication often means a broader state problem, not just bad credentials.

What to Check in Logs and Traces

Start with the identity presented before authentication, especially SUCI or temporary-identity handling.
Inspect RAND, AUTN, and the later RES star versus XRES star comparison.
If the UE sends Authentication Failure, read the cause before assuming a generic credential mismatch.
After success, verify the trace really moves into later security activation rather than stalling between phases.

Related sub-procedures

Related message reference pages

Related troubleshooting pages

FAQ

What is the 5G Authentication Procedure?

It is the procedure that proves the UE is a legitimate subscriber before protected service continuation is allowed.

Does authentication itself encrypt all later signaling?

No. Authentication bootstraps trust and key material, but later NAS and AS security activation still has to happen.

How is 5G-AKA different from later Security Mode?

5G-AKA proves subscriber legitimacy and derives security context, while Security Mode activates the chosen protection algorithms for ongoing signaling.

What should I inspect first in a failing trace?

Start with identity handling, the authentication challenge values, and whether the failure came from UE validation or network-side comparison.

Why can authentication succeed but service still fail?

Because later NAS Security Mode, AS security, registration, or session procedures may still fail after trust establishment.