Securing the most exposed equipment in the network
“The core lives in a guarded data center. The gNB lives on a rooftop, a lamppost, or inside a customer’s factory — holding live subscriber keys.”
— THE RAN SECURITY PROBLEM
The gNB is where cryptography meets the physical world — and where the network’s keys sit in the most exposed location it operates. Modern 5G RAN is also disaggregated into CU, DU, and RU units connected by new interfaces, each a link to protect. This chapter covers the gNB as a security endpoint, the CU/DU split, the F1/E1/Xn/NG interfaces, physical site security, and secure boot.
🎯 Learning objectives
Explain the gNB as a security endpoint holding AS keys.
Describe the CU/DU split and where security terminates.
Cover protection of F1, E1, Xn, NG interfaces.
Address physical site security and secure boot.
Note IAB and open fronthaul security considerations.
📘 Standards reference box — Chapter 15
Specification
Title
Release / version verified
TS 33.501
5G security — RAN security, gNB requirements
Rel-18, v18.11.0 (2026-04)
TS 33.511
SCAS — gNB security assurance
Rel-18 edition
TS 38.401 / 38.470+
NG-RAN architecture / F1 interface
Rel-18/19 edition
Checked June 2026 — verify against the latest 3GPP version.
15.1 The gNB as a Security Endpoint
FIGURE 15.1NG-RAN Architecture and the gNB's Trust Role
Purpose: the RAN's unique risk profile. The gNB does real cryptography (AS security, Chapter 9) and holds live keys, yet sits where an attacker can physically reach it.
15.2 The CU/DU Split — Where Security Terminates
FIGURE 15.2CU/DU/RU Split — Where the Keys Live
Purpose: disaggregation changes where keys live. Because PDCP runs in the CU, the CU is the crypto-critical unit — and it can be centralized in a more protected location than the cell-site DU/RU.
FIGURE 15.3Key Placement in Split RAN
Purpose: a security benefit of disaggregation. Keeping keys in a centralized CU means the thousands of exposed cell sites (DU/RU) hold nothing worth stealing.
15.3 Protecting the RAN Interfaces
FIGURE 15.4F1 Interface Protection (DU ↔ CU)
Purpose: the new link disaggregation creates. F1 carries the same traffic that AS security protects over the air — so it needs IPsec/DTLS, or the radio crypto is undone one hop inland.
FIGURE 15.5E1 and Xn Interfaces
Purpose: two more links to protect. E1 carries security context inside the CU; Xn carries handover key material between gNBs — both need protection, Xn especially (Chapter 16).
FIGURE 15.6E1 Security Considerations
Purpose: a subtle cloud-RAN gap. "Within the CU" can mean across hosts or even sites when CU-CP and CU-UP are separately virtualized — making E1 a real link to protect.
FIGURE 15.7Xn Interface Security in Detail
Purpose: why Xn protection is non-optional. Handover key material crosses Xn; expose it and you expose the forward-security machinery of Chapter 16.
FIGURE 15.8NG (N2/N3) — the Backhaul to the Core
Purpose: closing the interface tour. NG is the gNB-to-core backhaul protected by NDS/IP (Chapter 14) — the link most likely to traverse transport you don't own.
15.4 Physical Security and Secure Boot
FIGURE 15.9Cell-Site Physical Threat Model
Purpose: RAN threats that have nothing to do with radio. An attacker at the site can probe ports, tap fiber, or steal equipment — countered by tamper response, secure key storage, and (best) keeping keys in the centralized CU.
FIGURE 15.10gNB Secure Boot and Software Signing Chain
Purpose: the defense against tampered RAN software. Each stage verifies the next; modified firmware simply won't boot — essential when the hardware is physically reachable.
FIGURE 15.11IAB and Open Fronthaul Security Notes
Purpose: two modern RAN variants with extra surface. IAB turns backhaul into a radio link; open fronthaul adds multi-vendor interfaces — both expand what must be secured beyond classic gNB-to-core.
FIGURE 15.12RAN Hardening Checklist
Purpose: the RAN security job on one card. Combine air-interface crypto (Chapter 9), interface protection (Chapter 14), and physical/platform hardening — none alone is sufficient.
15.5 The Practical Operator View
Keep keys in the CU and site the CU in a controlled facility — turn disaggregation into a security win.
IPsec/DTLS the F1 midhaul and IPsec the Xn/N2/N3 — don't let radio crypto be undone one hop inland.
Enable secure boot and signed software on all RAN units; lock physical ports.
Treat E1 as a real link when CU-CP/CU-UP are separately virtualized.
Demand SCAS 33.511 evidence for gNBs in procurement (Chapter 2).
Common misconfiguration risks
F1 midhaul unprotected → RRC/user data exposed inland of the air interface.
Xn unprotected → handover key material observable/modifiable.
Secure boot disabled / unsigned software permitted on gNB.
Physical ports/consoles left enabled at exposed sites.
Open fronthaul deployed without protection or timing security.
15.6 Threats and Mitigations
Threat
Vector
Defense
Key extraction
physical access to gNB
secure storage, keys in CU, tamper response
Malicious RAN software
tampered firmware
secure boot + signed software chain
F1/Xn interception/injection
tap on midhaul/Xn
IPsec/DTLS, IPsec on Xn
Handover key compromise
unprotected Xn
IPsec on Xn (Chapter 16)
Fronthaul tap (O-RAN)
open fronthaul exposure
MACsec/IPsec + timing security
Port/console abuse
physical site access
port lockdown, access control
15.7 Terminology, Example, Checklist
Term
Meaning
CU / DU / RU
Central Unit / Distributed Unit / Radio Unit — the disaggregated gNB
CU-CP / CU-UP
CU control plane (RRC, control PDCP) / user plane (user PDCP)
Integrated Access and Backhaul — wireless gNB backhaul
Real network example. An operator deploying cloud-RAN virtualized the CU-CP and CU-UP as separate workloads — sometimes on different hosts in the edge data center. The team had protected F1 and N2/N3 but treated E1 as "internal to the CU" and left it unprotected, assuming the two halves shared a trusted machine. In reality, E1 traffic — carrying bearer security context — crossed the data-center fabric between hosts, observable to anything on that network segment. Fix: IPsec on E1 between CU-CP and CU-UP, and a policy that any inter-host RAN interface is treated as an untrusted link regardless of logical grouping. In cloud-RAN, "inside the CU" is a logical statement, not a physical guarantee.
Confirm keys reside in the CU; DU/RU hold no AS keys.
Verify IPsec/DTLS on F1, IPsec on Xn/N2/N3, and E1 if split across hosts.
Confirm secure boot + signed software on all RAN units.
Check physical tamper detection and port lockdown at sites.
Confirm SCAS 33.511 evidence for gNBs.
For O-RAN/IAB, verify the extra links and timing are protected.
★ Chapter Summary
The gNB is the only key-holding NF in physically exposed locations — RAN security combines radio crypto, interface protection, and physical/platform hardening.
The CU/DU split puts PDCP (and keys) in the CU; centralizing the CU shrinks the exposed key footprint.
Protect F1 (midhaul), Xn (handover keys), E1 (when split), and N2/N3 (backhaul).
Secure boot and signed software stop tampered RAN code; physical tamper response and port lockdown defend the site.
O-RAN open fronthaul and IAB add links and timing that need their own protection.
? Review Questions
Why is the gNB's security profile unique among NFs?
In the CU/DU split, where does PDCP run, and what security advantage does that enable?
Why must F1 be protected, and what is exposed if it isn't?
Why is Xn protection critical for mobility security?
Explain the secure-boot chain and what it prevents.
When is E1 a real link to protect, and why is "inside the CU" not a guarantee?
What extra security surface do O-RAN open fronthaul and IAB introduce?
How does centralizing keys in the CU improve site security?
🧪 Mini lab — map your RAN attack surface
Draw a disaggregated gNB: RU, DU, CU-CP, CU-UP, and the core. Label every link (fronthaul, F1, E1, Xn, N2, N3) and for each: (1) what traffic it carries, (2) where it physically runs, (3) its protection mechanism. Then mark where AS keys live and where they don't. Finally, walk a physical attacker from the cell site inward — at each link, what can they observe or inject if it's unprotected, and which control stops them? This map is exactly what a RAN security audit (Chapter 28) produces — build it once and reuse it.