Home / Call Flows / 5G / Security Context Update

5G Security Context Update Procedure Call Flow

call-flow 5G NR | 5GC | Security Refresh | Mobility | NAS | RRC

5G Security Context Update is the procedure family that refreshes or realigns active security context when the old state should no longer be used unchanged.

It matters most in long-lived sessions, mobility-heavy traces, and cases where protected signaling fails only after a context change rather than at first access.

Introduction

A security context update is not just a key rotation event. It is the operational handoff from one trusted context to the next across NAS, radio control, and sometimes mobility.

That is why troubleshooting must follow both the update trigger and the first protected messages that appear afterward.

What Is Security Context Update in Simple Terms?

What starts the procedure: Mobility, timers, policy, or context changes require a refreshed security state.
What the UE and network want to achieve: Switch safely from the old context to a fresh valid one without breaking protected service.
What success looks like: The new context activates cleanly and later protected signaling continues normally.
What failure means: The refresh is asymmetric, late, or only partially applied, causing later protected signaling to fail.

Why this procedure matters

Security context refresh is where long-lived 5G sessions either stay trustworthy and stable or start to show subtle integrity, mobility, and continuity problems. Many of the hardest intermittent issues live here.

Quick Fact Sheet

Procedure name	5G Security Context Update
Domain	5G security refresh across NAS and access-side continuity
Main trigger	The network needs to refresh, re-derive, or realign security context after mobility, policy, timer, or context-change events
Start state	The UE already has a working security context, but it is no longer ideal or valid enough for future continuation
End state	The UE and network align on refreshed keys or security-anchor continuity for later signaling and traffic
Main nodes	UE, gNB, AMF, optionally target gNB and related core functions
Main protocols	NAS, RRC, key derivation, mobility-linked security handling
Main success outcome	The refreshed context is activated cleanly and later protected signaling continues without mismatch
Main failure outcome	Key continuity breaks, new context is activated inconsistently, or later protection fails after update
Most important messages	Security Mode Command, RRC Reconfiguration, later protected signaling
Main specs	TS 33.501, TS 23.502, TS 38.331

Preconditions

The UE already has an active security context with the network.
The network has a valid reason to refresh or realign that context.
Any linked mobility or access-state changes are known to the relevant nodes.
The UE can still receive the update and continue with protected signaling afterward.

Nodes and Interfaces

Nodes involved

Node	Role in this procedure
UE	Applies refreshed security context and uses the new keys or identifiers for later protected continuation.
gNB	Maintains or refreshes access-side security context, especially across radio and mobility changes.
AMF	Maintains NAS-side context and coordinates refresh or handoff of new security material.
Target gNB or mobility partner	May consume refreshed or newly derived context during handover or radio-context transfer.

Interfaces used

Interface	Path	Role
N1	UE <-> AMF	Carries NAS-side security updates or the later protected NAS continuation that proves the update worked.
NR-Uu	UE <-> gNB	Carries access-side reconfiguration and later radio signaling under the refreshed context.
N2	gNB <-> AMF	Carries access-side and core-side security continuity during context refresh or mobility.

End-to-End Call Flow

UE                  gNB                  AMF
|                   |                    |
|<-- update / reconfig / security mode --|
|-- apply refreshed context ------------>|
|==== later protected NAS and RRC continue ====|

Major Phases

Phase	What happens
1. Refresh trigger appears	Mobility, timer, policy, or context relocation creates a need to refresh the active security context.
2. New security material or continuity anchor is prepared	The network derives or selects the next security context that should protect later communication.
3. UE and access side align on the refreshed state	The new context is activated through NAS or radio-control handling depending on the branch.
4. Protected continuation under the new context	Later signaling and traffic prove whether the refresh was operationally successful.

Step-by-Step Breakdown

Network detects that the current security context should be refreshed

Sender -> receiver: AMF or gNB internal logic

Message(s): Mobility trigger, key-lifetime event, policy update, or context relocation

Purpose: Start a planned refresh before the old context becomes unsafe or operationally inconsistent.

State or context change: The current context still exists, but the system has decided it should not be used unchanged forever.

Note: The reason for refresh matters because mobility-driven updates and timer-driven updates fail differently.

Fresh keys or next-stage security context are prepared

Sender -> receiver: AMF and or gNB security handling

Message(s): Key derivation and security-anchor continuity preparation

Purpose: Create the next valid context for protected communication.

State or context change: The network now has a replacement or refreshed context ready for activation.

Note: Many failures here show up later as mismatched integrity or ciphering, not as obvious key-derivation alarms.

UE receives the updated security behavior

Sender -> receiver: Network -> UE

Message(s): Security Mode Command, RRC Reconfiguration, or related update signaling

Purpose: Move both sides onto the refreshed security context for future protected continuation.

State or context change: Old context is being retired and new context is taking over.

Note: The exact activation path depends on whether the change is primarily NAS-side, access-side, or mobility-linked.

Later protected signaling proves the refresh worked

Sender -> receiver: UE <-> network

Message(s): Protected NAS, protected RRC, and later user-plane continuation

Purpose: Demonstrate that the refreshed context is actually usable in live operation.

State or context change: The security refresh moves from configuration intent into operational reality.

Note: This is where context mismatch becomes visible if the update was only partially aligned.

Important Messages in This Flow

Message	Protocol	Direction	Purpose in this procedure	What to inspect briefly
Security Mode Command	NAS	AMF -> UE	Often activates refreshed NAS-side protection behavior or context continuity.	Inspect whether the command belongs to a genuine refresh and not a first-time activation.
RRC Reconfiguration	RRC	gNB -> UE	Can carry radio-side changes linked to refreshed access security behavior.	Inspect whether mobility or radio changes are linked to the new context.
Protected follow-on NAS or RRC messages	NAS and RRC	UE <-> network	Show that the refreshed context is actually working after activation.	These messages are often the quickest proof of real success or mismatch.

Important Parameters to Inspect

Parameter	What it is	Where it appears	Why it matters	Common issues
Refresh trigger	The operational reason for updating the security context.	Policy, timers, mobility trace	Explains what kind of continuity or derivation should have happened.	If misunderstood, the wrong logs get blamed.
Next-hop or derived key lineage	How the new key material relates to the previous context.	Security derivation handling	Shows whether the refresh path was logically valid.	Broken lineage causes later mismatch even when activation messaging looks fine.
Security context identifier	The version or reference of the active context.	Update signaling and later protected traffic	Helps prove whether both sides switched to the same context.	Mixed context IDs are a classic source of intermittent failure.
Mobility correlation	Whether the refresh was tied to gNB or AMF movement.	Mobility timeline	Critical for understanding access-side and core-side update ordering.	Out-of-order mobility handling leaves one side stale.
First protected messages after refresh	The earliest real operational use of the new context.	Post-update trace	Best evidence that the update worked end-to-end.	If these fail, the refresh was not really complete.

Success Criteria

The network derives the correct next context for the real trigger scenario.
The UE and network agree on the same refreshed context version.
Protected NAS and or RRC continue without integrity mismatch after refresh.
Mobility or later service continuity remains stable under the new context.

Common Failures and Troubleshooting

Symptom	Likely cause	Where to inspect	Relevant message(s)	Relevant interface(s)	Likely next step
Security refresh is activated but later integrity fails	One side switched context while another side stayed on the old one.	Context identifiers, derivation lineage, and first protected messages.	Security Mode, RRC Reconfiguration, later protected NAS	N1, N2, NR-Uu	This is the classic signature of asymmetric security refresh.
Mobility works but protected signaling breaks after handover	The mobility event refreshed access security badly or incompletely.	Handover timing and target-side security continuity.	RRC Reconfiguration and later protected signaling	NR-Uu, N2	Treat it as security continuity trouble inside mobility, not only as handover failure.
Update seems to happen repeatedly	The network keeps failing to stabilize on one context version.	Refresh trigger logic, timers, and repeated activation attempts.	Security Mode and related update signaling	N1, N2	Repeated refresh is often a state-management symptom rather than a one-time command failure.
Traffic resumes briefly then fails again	The new context worked partially, but one plane or node still used stale material.	First protected NAS and RRC plus user-plane continuity after refresh.	Protected follow-on traffic	N1, N2, NR-Uu	Look for split-brain context across planes or nodes.

What to Check in Logs and Traces

Identify the refresh trigger before deciding which logs matter most.
Track the new context identifier or lineage across participating nodes.
Inspect the first protected messages after refresh rather than treating the update command itself as proof of success.
If mobility was involved, verify that source and target security continuity was aligned.

Related sub-procedures

Related message reference pages

Related troubleshooting pages

FAQ

What is a 5G Security Context Update?

It is the refresh or realignment of the active security context used to protect later signaling and traffic.

When does it usually happen?

Common triggers include mobility, key lifetime events, context relocation, and security policy changes.

Is it only a NAS procedure?

No. It can involve both NAS and access-side security continuity depending on the branch.

What should I inspect first in a failure?

Start with the refresh trigger, then check key lineage, context identifiers, and the first protected messages after the update.

How do I know the update really worked?

The first protected NAS or RRC messages after refresh should continue cleanly without mismatch or retry loops.