Re-keying a moving subscriber, hop after hop, without ever pausing
“Every time you cross a cell boundary in a moving car, your phone silently performs a cryptographic key change. It must be fast enough to be invisible and strong enough that the cell you just left can't follow you.”
— THE HANDOVER CHALLENGE
A handover moves a connected UE from one gNB to another without dropping the session. Security-wise, it is a key-management event: the target gNB needs keys, but the source gNB must not be able to compute them (forward security). 5G solves this with the NH/NCC key chain from Chapter 7. This chapter walks the handover types — intra-gNB, Xn, N2 — and the key handling, forward/backward security, and capability transfer behind them.
🎯 Learning objectives
Explain why handover is a cryptographic event.
Walk intra-gNB, Xn, and N2 handover key handling.
Explain NH/NCC, horizontal vs vertical derivation in mobility.
Define forward and backward security.
Cover UE security capability transfer and algorithm change at handover.
📘 Standards reference box — Chapter 16
Specification
Title
Release / version verified
TS 33.501
5G security — handover key handling (clause 6.9)
Rel-18, v18.11.0 (2026-04)
TS 38.300 / 38.413 / 38.423
NG-RAN / NGAP (N2) / XnAP (Xn) procedures
Rel-18/19 edition
Checked June 2026 — verify against the latest 3GPP version. NH/NCC mechanics build on Chapter 7.
16.1 Why Handover Is a Cryptographic Event
FIGURE 16.1Handover — a Key Change in Motion
Purpose: the core tension. A handover must hand the target usable keys, but the ideal is that the source — which may later be compromised — cannot reconstruct them and eavesdrop on the moved subscriber.
FIGURE 16.2The Key Chaining Model Across gNBs
Purpose: the NH chain in mobility. The AMF pre-computes the chain; each hop ideally draws a fresh NH (vertical), so the key sequence is one-way and the source can't predict forward.
FIGURE 16.3NH/NCC State Machine
Purpose: who holds and advances the chain. The NCC is the on-the-wire signal that lets the UE reproduce the exact derivation the network used.
FIGURE 16.4Horizontal Derivation (Same NCC)
Purpose: the fallback derivation. Used when no fresh NH is available; it works but the source gNB can compute the target's key — so it offers no forward security on that hop.
FIGURE 16.5Vertical Derivation (Fresh NH, NCC+1)
Purpose: the strong derivation. The fresh NH comes from the AMF — an entity the source can't impersonate — so the target's key is beyond the source's reach.
16.2 Intra-gNB, Xn, and N2 Handover
FIGURE 16.6Intra-gNB Handover Key Handling
Purpose: the simplest case. Within one gNB, key handling is local — useful baseline before the inter-gNB flows.
FIGURE 16.7Xn Handover — Full Message Flow with Keys
Purpose: the most common handover. The source prepares the target directly over Xn (fast), then a path switch to the AMF refreshes the NH for the next hop.
FIGURE 16.8Xn Path Switch — Refreshing the NH
Purpose: how forward security is periodically re-established. Even if a hop was horizontal, the path switch tops up the NH so the chain keeps moving beyond the source's reach.
FIGURE 16.9N2 Handover — Full Message Flow with Keys
Purpose: the core-mediated handover. When Xn isn't available or the AMF changes, the AMF computes the keys — inherently providing a fresh NH and forward security.
16.3 Forward and Backward Security
FIGURE 16.10Forward Security Explained
Purpose: forward security defined. A compromised gNB can't follow the subscriber forward in time/space — the vertical NH derivation breaks the chain ahead of it.
FIGURE 16.11Backward Security Explained
Purpose: backward security defined. Compromising a current gNB doesn't retroactively expose the subscriber's earlier cells — the derivations are one-way in both directions.
16.4 Capability Transfer and Algorithm Change
FIGURE 16.12UE Security Capability Transfer at Handover
Purpose: capabilities must travel with the UE. The target picks algorithms from the UE's real capability set — and the transfer must be protected so it can't be downgraded mid-handover.
FIGURE 16.13Algorithm Change at Handover
Purpose: algorithms can change cell to cell. Because the algorithm ID is a KDF input (Chapter 7), changing it re-derives the AS keys — keys are always bound to the algorithm in use.
FIGURE 16.14Compromised gNB — What Chaining Limits
Purpose: the realistic security promise. Chaining doesn't make a compromised gNB harmless in its own cell — but it stops the breach from spreading across the subscriber's journey.
FIGURE 16.15Handover Failure and Key Rollback
Purpose: graceful failure. A failed handover doesn't leave the UE in a broken key state — it falls back to the still-valid source context.
Purpose: the field reference. These are the exact parameters a security engineer reads in a handover capture to confirm the right (ideally vertical) key handling occurred.
16.5 The Practical Operator View
Verify NH refresh on path switch — a vendor that always derives horizontally never re-establishes forward security.
Protect Xn and N2 (Chapters 14–15) — handover key material crosses them.
Confirm capability transfer is protected against mid-handover downgrade.
Monitor handover failure rates — security mismatches (algorithm/capability) show up here.
Trace NCC behavior in samples to confirm vertical derivations occur regularly.
Common misconfiguration risks
Always-horizontal derivation (NH refresh broken) → no forward security.
Unprotected Xn → handover keys observable.
Capability transfer not integrity-protected → downgrade at handover.
Algorithm mismatch between neighbor gNBs → handover failures.
16.6 Threats and Mitigations
Threat
Vector
Defense
Source eavesdrops after move
horizontal-only derivation
vertical derivation, NH refresh
Handover key interception
unprotected Xn/N2
IPsec on Xn/N2 (Ch 14–15)
Algorithm downgrade at HO
tampered capability transfer
protected capability transfer
Breach spread across cells
compromised gNB
one-way key chaining (forward+backward)
Key state corruption
handover failure
rollback to source context
16.7 Terminology, Example, Checklist
Term
Meaning
NH / NCC
Next-hop key / next-hop chaining counter
K_gNB*
The new K_gNB derived for the target cell
horizontal / vertical
Derivation from current K_gNB / from fresh NH (forward-secure)
forward / backward security
Compromised gNB can't reach future / past cells
path switch
Post-Xn-handover step that refreshes the NH from the AMF
Real network example. A drive-test analysis on a dense urban cluster found that handovers between two vendors' gNBs were always using horizontal key derivation — the NCC never incremented across the boundary. The cause: the path-switch NH refresh wasn't being applied correctly in the multi-vendor Xn relationship, so no fresh NH was ever available, forcing horizontal derivation every time. Functionally everything worked; security-wise, forward security was never re-established along that route, meaning a compromise of one gNB could chain forward to the next. Fix: correct the path-switch handling so the AMF's fresh NH reached the target, restoring vertical derivations. Handovers can succeed perfectly while silently never refreshing forward security — only a trace of the NCC reveals it.
Verify path-switch NH refresh works, including multi-vendor Xn.
Confirm Xn/N2 are IPsec-protected.
Confirm capability transfer is integrity-protected.
Monitor handover failures for algorithm/capability mismatches.
★ Chapter Summary
Handover is a key-management event: the target needs keys the source ideally can't compute (forward security).
The NH/NCC chain (Chapter 7) provides fresh keys; vertical derivation (fresh NH) is forward-secure, horizontal is not.
Xn handover is source-prepared and fast, with a path switch to refresh the NH; N2 handover is AMF-mediated.
One-way derivations give both forward and backward security, containing a compromised gNB to its own cell's tenure.
UE capability transfer must be protected against downgrade; algorithm changes re-derive AS keys.
? Review Questions
Why is a handover a cryptographic event, and what is the security goal regarding the source gNB?
Distinguish horizontal and vertical derivation and which provides forward security.
Walk the Xn handover key flow and explain the role of the path switch.
When and why is N2 handover used instead of Xn, and how does it affect keys?
Define forward and backward security with a compromised-gNB example of each.
Why must UE capability transfer be protected at handover?
A trace shows NCC never incrementing across a boundary. What's wrong and what's the security impact?
What happens to keys when a handover fails?
🧪 Mini lab — read the NCC
In a lab with mobility (or from a real handover capture): (1) Trigger/capture an Xn handover and find the RRC reconfiguration carrying the NCC. (2) Note whether NCC incremented (vertical) or stayed (horizontal). (3) Find the subsequent path switch and confirm a fresh NH is returned. (4) Reflect: if you observed only horizontal derivations across a route, what forward-security property is missing, and what is the attacker scenario it enables? (5) Bonus: change neighbor-gNB algorithm support and observe how a handover re-derives AS keys for the new algorithm. You've now learned to audit mobility security from the one field that reveals it — the NCC.