Home / Call Flows / 5G / EAP-AKA’ / Non-3GPP Access Authentication

5G EAP-AKA’ / Non-3GPP Access Authentication Procedure Call Flow

call-flow 5G | Non-3GPP Access | EAP-AKA’ | AUSF | Security

5G EAP-AKA’ / Non-3GPP Access Authentication is the subscriber-trust procedure used when the UE reaches 5G services over an alternate access path rather than ordinary NR radio access.

It connects alternate-access entry, EAP challenge and response, and 5GC trust integration into one security branch.

Introduction

This procedure matters because a subscriber can be perfectly valid in the 5G core but still fail to continue over a non-3GPP branch if the alternate-access authentication path is weak.

The troubleshooting mindset is slightly different from ordinary radio-access authentication because EAP session continuity and alternate-access integration matter as much as subscriber credentials.

What Is EAP-AKA’ / Non-3GPP Access Authentication in Simple Terms?

What starts the procedure: The UE tries to use 5G over a non-3GPP access branch that requires EAP-based authentication.
What the UE and network want to achieve: Prove subscriber legitimacy and enable protected 5GC continuation over alternate access.
What success looks like: The EAP exchange succeeds and real 5GC continuation follows.
What failure means: Alternate-access authentication or its integration into 5GC continuation breaks down.

Why this procedure matters

Non-3GPP access broadens how users reach 5G services, but it also adds a separate trust and integration path. This procedure is where alternate-access security either becomes usable or breaks away from the main 5G service promise.

Quick Fact Sheet

Procedure name	5G EAP-AKA’ / Non-3GPP Access Authentication
Domain	5G authentication over alternate non-3GPP access
Main trigger	The UE is reaching 5G services through a non-3GPP access branch that requires EAP-based subscriber authentication
Start state	UE is attempting trusted or untrusted non-3GPP access and still needs core-trusted subscriber validation
End state	The UE is authenticated for non-3GPP access and can continue into protected service establishment
Main nodes	UE, non-3GPP access entity, AMF, AUSF, UDM
Main protocols	EAP-AKA prime, NAS context, alternate-access security
Main success outcome	The UE completes EAP-based authentication and obtains trusted continuation into 5GC service
Main failure outcome	Alternate-access authentication fails and the UE cannot continue on that branch
Most important messages	EAP-AKA prime challenge and response exchange, later 5GC security continuation
Main specs	TS 23.501, TS 23.502, TS 33.501

5G EAP-AKA prime non-3GPP access authentication call flow

Preconditions

The UE is attempting 5G service over a trusted or untrusted non-3GPP access branch.
The alternate-access entity can relay EAP-based authentication signaling.
AUSF and UDM are reachable for subscriber validation.
A later 5GC continuation path exists if authentication succeeds.

Nodes and Interfaces

Nodes involved

Node	Role in this procedure
UE	Participates in EAP-AKA prime challenge and response over the non-3GPP access branch.
Non-3GPP access entity	Carries alternate-access authentication signaling between the UE and core security functions.
AMF	Coordinates access management and ties the non-3GPP authentication outcome into 5GC continuation.
AUSF	Validates the EAP-based subscriber proof.
UDM	Provides subscriber-side authentication context for alternate access.

Interfaces used

Interface	Path	Role
Non-3GPP access path	UE <-> alternate access entity	Carries the EAP-based authentication signaling over the non-3GPP access branch.
AMF to AUSF and UDM security interfaces	AMF <-> AUSF <-> UDM	Carry subscriber authentication context needed for EAP-AKA prime validation.

End-to-End Call Flow

UE           Non-3GPP Access         AMF / AUSF / UDM
|                  |                       |
|-- access entry ->|---------------------->|
|<- EAP challenge -|<----------------------|
|-- EAP response ->|---------------------->|
|<-- success / failure and later continuation --|}

Major Phases

Phase	What happens
1. Alternate access entry	The UE begins a 5G access path over trusted or untrusted non-3GPP connectivity.
2. EAP-based challenge preparation	The core prepares the subscriber challenge and EAP-AKA prime validation context.
3. EAP challenge and response exchange	The UE and network exchange the challenge-response sequence needed to prove subscriber legitimacy over alternate access.
4. 5GC continuation	Successful alternate-access authentication allows later 5GC service and protection setup to continue.

Step-by-Step Breakdown

UE enters 5G through non-3GPP access

Sender -> receiver: UE -> non-3GPP access entity -> 5GC

Message(s): Alternate-access attach or service-entry context

Purpose: Start a 5G service path that does not originate from ordinary NR radio access.

State or context change: The UE is visible to the 5G system through an alternate-access branch, but still not trusted enough for full continuation.

Note: Always classify whether the access is trusted or untrusted, because the security envelope and troubleshooting scope differ.

Core prepares EAP-AKA prime validation

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

Message(s): EAP-AKA prime authentication context preparation

Purpose: Build the alternate-access challenge and expected result for this subscriber path.

State or context change: The network is ready to challenge the UE over the non-3GPP branch.

Note: If this context is wrong, the alternate-access UE can look broken even when its EAP behavior is correct.

UE and network exchange EAP challenge and response

Sender -> receiver: UE <-> non-3GPP access entity <-> core

Message(s): EAP-AKA prime challenge and response

Purpose: Prove subscriber legitimacy over alternate access without relying on ordinary NR radio entry.

State or context change: The branch moves from access presence to subscriber trust.

Note: The exact EAP sequence matters more here than ordinary NAS message expectations from radio access traces.

Authentication result feeds 5GC continuation

Sender -> receiver: Core -> UE

Message(s): EAP success or failure and later 5GC security continuation

Purpose: Decide whether the non-3GPP branch may proceed into protected service use.

State or context change: The alternate-access path either becomes trusted or is denied.

Note: A successful EAP exchange should hand off into later 5GC continuation, not just end in isolation.

Important Messages in This Flow

Message	Protocol	Direction	Purpose in this procedure	What to inspect briefly
EAP-AKA prime challenge	EAP	Network -> UE	Provides the alternate-access challenge used to validate the subscriber.	Inspect whether the challenge belongs to the correct subscriber and branch.
EAP-AKA prime response	EAP	UE -> network	Returns the UE proof for alternate-access validation.	Inspect whether the response reaches the core cleanly through the access entity.
Later 5GC continuation signaling	Security continuation	Core -> UE	Shows whether alternate-access authentication successfully fed into 5GC trust and service continuation.	If absent, the EAP success may not have been integrated properly into the service path.

Important Parameters to Inspect

Parameter	What it is	Where it appears	Why it matters	Common issues
Access type	Whether the branch is trusted or untrusted non-3GPP access.	Alternate-access context	Defines the security envelope and expected continuation behavior.	Wrong classification leads to wrong troubleshooting assumptions.
EAP session continuity	The integrity of the ongoing EAP exchange across the alternate-access path.	EAP challenge-response sequence	Explains whether the subscriber proof can even reach validation cleanly.	Middlebox or access-entity handling can disrupt an otherwise correct UE.
Subscriber context used for EAP	The credential context pulled from UDM for alternate-access authentication.	AUSF and UDM handling	Determines whether the challenge is valid for the intended subscriber.	Wrong subscriber mapping leads to impossible validation.
Result integration into 5GC	How the successful EAP outcome is turned into usable service continuation.	Post-authentication handling	Shows whether alternate-access authentication actually enables real 5G service.	A detached success result is operationally useless.
Later protection setup	What security activation or service steps follow EAP success.	Post-EAP continuation	Proves end-to-end usefulness of the authentication branch.	If missing, the issue may be after authentication rather than inside it.

Success Criteria

The alternate-access branch is classified correctly and carries the EAP exchange cleanly.
AUSF and UDM validate the intended subscriber context.
The UE completes the EAP-AKA prime exchange successfully.
The result feeds into real 5GC continuation rather than ending as an isolated success.

Common Failures and Troubleshooting

Symptom	Likely cause	Where to inspect	Relevant message(s)	Relevant interface(s)	Likely next step
EAP challenge never completes	The alternate-access signaling path or the UE EAP handling broke before validation finished.	EAP session continuity and access-entity forwarding.	EAP challenge and response sequence	Alternate-access path	This is often transport or integration trouble rather than subscriber credential trouble.
EAP validation fails unexpectedly	The network and UE did not agree on the subscriber context for alternate access.	AUSF, UDM, and subscriber mapping for the access branch.	EAP result handling	Security interfaces	Treat subscriber-context mapping as a first-class suspect.
EAP succeeds but 5GC service still does not continue	The authentication result was not integrated cleanly into later service or protection setup.	Post-EAP continuation into 5GC context and security activation.	EAP success and later continuation	Core integration	Do not stop at the EAP result if the user journey still fails.
Problems only occur on non-3GPP access	The subscriber is fine on ordinary 5G access, but the alternate-access integration path is weak.	Compare radio-access authentication with non-3GPP behavior.	EAP and later service continuation	Alternate-access path	This helps isolate the issue to alternate-access security rather than general subscriber state.

What to Check in Logs and Traces

First identify whether the path is trusted or untrusted non-3GPP access.
Inspect EAP session continuity across the alternate-access entity.
If validation fails, compare the subscriber context used by AUSF and UDM with the intended access branch.
After success, confirm that 5GC continuation actually follows.

Related sub-procedures

Related message reference pages

Related troubleshooting pages

FAQ

What is 5G EAP-AKA’ / Non-3GPP Access Authentication?

It is the alternate-access subscriber authentication branch used when the UE reaches 5G through non-3GPP connectivity.

How is it different from ordinary 5G authentication?

It uses EAP-based alternate-access handling instead of the ordinary radio-access authentication path.

What should I inspect first in a failure?

Start with access type, EAP session continuity, and whether the alternate-access entity forwarded the exchange correctly.

Why can EAP succeed but service still fail?

Because the authentication result must still be integrated into real 5GC service and protection continuation.

When is this page most useful?

It is most useful when alternate-access service looks broken even though ordinary 5G radio access works.