Hardening each NF for the job — and the blast radius — it owns
“Chapter 10 secured the conversations between NFs. This chapter secures the NFs themselves — because a perfectly authenticated UDM that exports its keys is still a catastrophe.”
— THE COMPLEMENT TO SBA SECURITY
Chapter 10 protected the wires. This chapter protects the boxes. Each network function has a distinct security mission, a distinct blast radius, and a distinct hardening profile drawn from 3GPP’s per-NF Security Assurance Specifications (SCAS). We go NF by NF — AMF, SMF, UPF, AUSF, UDM, NRF, PCF, NEF, SCP — asking what it protects, what it must never leak, and how to harden it.
🎯 Learning objectives
State the security responsibility of each core NF.
Identify each NF’s blast radius and crown-jewel status.
Explain why UDM/ARPF and NRF demand the strongest controls.
Map SCAS per-NF assurance to operational hardening.
📘 Standards reference box — Chapter 11
Specification
Title
Release / version verified
TS 33.501
5G security — NF security requirements
Rel-18, v18.11.0 (2026-04)
TS 33.117
SCAS — generic NF security requirements
Rel-18 edition
TS 33.512–33.521
SCAS — AMF, UPF, UDM, AUSF, SMF, NRF, NEF, SEPP…
Rel-18 edition
Checked June 2026 — verify against the latest 3GPP version.
11.1 The NF Security Responsibility Matrix
FIGURE 11.1NF Security Responsibility Matrix
Purpose: the chapter on one page. Defense is not uniform — the UDM and NRF earn the most paranoia because their loss is unrecoverable or system-wide.
11.2 AMF, SMF, UPF — the Serving Trio
FIGURE 11.2AMF Security Functions and Interfaces
Purpose: the AMF is RAN-facing (N2) and key-rich — a high-value, exposed target. Region isolation limits how far one compromised AMF reaches.
FIGURE 11.3SMF and UPF — Session Control and the Traffic Plane
Purpose: the session pair. The SMF’s power is the UP security policy (manipulate it and you weaken protection invisibly); the UPF’s exposure is the internet edge.
11.3 AUSF and UDM — the Home Crown Jewels
FIGURE 11.4AUSF — More Than Authentication
Purpose: the AUSF is not just a login server — KAUSF protects roaming-steering and parameter-update messages, so its compromise has reach beyond authentication.
FIGURE 11.5UDM/ARPF/SIDF/UDR — Protecting the Subscriber Vault
Purpose: the single most important hardening target in the network. Everything about the UDM domain assumes that losing it loses everything — so defense in depth is mandatory, not optional.
FIGURE 11.6Protecting K — HSM Integration at the ARPF
Purpose: how K is protected in practice. The HSM executes the AKA functions internally, so K never appears in general-purpose memory — defeating memory-scraping malware on the core platform.
11.4 NRF — Owning It Owns the Core
FIGURE 11.7NRF as Crown Jewel — Compromise Scenarios
Purpose: the three ways NRF compromise cascades. Because it both authorizes (tokens) and directs (discovery), owning it lets an attacker rewrite the core’s trust map.
FIGURE 11.8PCF and SCP — Quieter but Sharp
Purpose: two NFs whose risk is easy to underestimate. The PCF quietly controls traffic; the SCP quietly sees all of it.
FIGURE 11.9NEF — the Deliberate Hole in the Wall
Purpose: the NEF is exposure-by-design, so it is also defense-by-design. It is the one NF whose job is to mediate the untrusted world (Chapter 12).
11.5 SCAS — Standardized Per-NF Hardening
FIGURE 11.10SCAS Requirements Coverage per NF
Purpose: you don’t have to write NF hardening from scratch — 3GPP did. Generic requirements (33.117) plus per-NF specs give you ready-made audit and procurement criteria.
FIGURE 11.11The Per-NF Hardening Stack
Purpose: the layered recipe applied per NF. The same stack everywhere, dialed to the blast radius — maximum for the crown jewels, proportionate elsewhere.
FIGURE 11.12NF Lifecycle Security — Onboarding to Decommission
Purpose: security spans the whole NF lifecycle. Decommissioning is the chronically forgotten phase — a retired NF’s certificate and NRF registration must be revoked, or they become attack surface.
11.6 The Practical Operator View
Tier your controls by blast radius: UDM/ARPF and NRF get the full hardening stack and the deepest monitoring; supporting NFs get proportionate effort.
HSM the UDM/ARPF; encrypt the UDR; forbid key export anywhere in policy and configuration.
Use SCAS/NESAS as procurement gates and audit seeds (Chapters 2, 28) — don’t hand-roll hardening lists.
Treat the SCP like the NRF if deployed — it concentrates traffic and (Model D) tokens.
Common misconfiguration risks
UDM without HSM; K exportable for “migration.”
NRF reachable from OAM/enterprise networks; unauthenticated registration.
Default admin credentials / unnecessary services left enabled on NFs.
Decommissioned NFs with live certs and stale NRF registrations.
SCP deployed without NRF-grade protection.
11.7 Threats and Mitigations
NF
Top threat
Primary mitigation
UDM/ARPF
K theft
HSM, no export, encrypt UDR, MFA admin
NRF
token forgery / discovery poisoning
hardening, mTLS, signed tokens, monitoring
AMF
NAS-key harvesting / N2 overload
region isolation, overload control
AUSF
SoR/UPU forgery
K_AUSF protection, SBI authorization
SMF
UP-policy manipulation
policy integrity, change audit
UPF
interception / DDoS
N4/N6 protection, anti-DDoS (Ch 14, 27)
SCP
mass interception / impersonation
NRF-grade hardening + audit
11.8 Terminology, Example, Checklist
Term
Meaning
SCAS / NESAS
Per-NF security assurance specs / GSMA audit scheme using them
HSM
Hardware Security Module — protects K and runs AKA internally
blast radius
Scope of damage if a given NF is compromised
SoR / UPU
Steering of Roaming / UE Parameter Update — protected by K_AUSF
Real network example. During a cloud-core migration, an operator’s old UDM VMs were spun down but their certificates were never revoked and their NRF registrations were never removed. Months later, a security review found the decommissioned instances still listed as valid UDMs in the NRF. Had any of those VM images or their key material been recovered from the (un-wiped) cloud storage, an attacker could have presented a still-trusted certificate. Fix: a decommissioning runbook mandating cert revocation, NRF deregistration, and cryptographic erasure — and a periodic reconciliation between live NFs and NRF registrations. The crown jewels were protected in production; the forgotten lifecycle end was the gap.
Confirm UDM/ARPF HSM-backed, no key export, UDR encrypted at rest.
Check no default credentials / minimal services on every NF (SCAS 33.117).
Reconcile live NFs against NRF registrations; revoke decommissioned certs.
Confirm SCP (if present) has NRF-grade controls.
Map monitoring depth to blast radius (deepest on UDM/NRF).
★ Chapter Summary
Each NF has a distinct security mission and blast radius; defenses should be tiered accordingly, not uniform.
UDM/ARPF (K vault) and NRF (tokens + discovery) are the crown jewels — losing them is total or SBA-wide.
HSM the ARPF (K never leaves), encrypt the UDR, and forbid key export.
The NRF compromise cascades three ways: forged tokens, rogue registration, poisoned discovery.
SCAS (33.117 + per-NF) gives ready-made hardening for procurement and audit; lifecycle security (especially decommissioning) is the common gap.
? Review Questions
Rank UDM, AMF, UPF, NRF by blast radius and justify each from what it holds.
Beyond authentication, what does a compromised AUSF enable, and which key makes that possible?
List the five non-negotiable hardening measures for the UDM domain.
Explain the three ways NRF compromise spreads through the SBA.
How does an HSM protect K even against malware running on the core platform?
Why is the SCP a crown-jewel-class target in Model D deployments?
Which lifecycle phase is most often neglected, and what specific artifacts must be cleaned up?
How would you use SCAS in a procurement RFP and in an audit?
🧪 Mini lab — reconcile the NRF
In Open5GS: (1) Query the NRF for all registered NF profiles. (2) Compare against the NFs actually running. (3) Stop one NF without graceful deregistration and re-query — observe the stale registration (until heartbeat timeout). (4) Reflect: in a large cloud core with hundreds of CNF instances scaling up and down, how would you automate this reconciliation, and why is a stale registration (with a still-valid certificate) a security risk, not just an inventory error? Write the three steps of a decommissioning runbook: revoke cert, deregister, destroy keys.