Part 6 · Threats, Attacks, and Operator Protection
28
5G Security Audit Checklist
Proving — not assuming — that the protections are on
"An audit isn't a formality. It's the one time someone actually checks whether the security you designed is the security you're running."
— WHY AUDITS EXIST
This chapter turns the entire book into an audit program. Each domain — RAN, core/SBA, roaming, slice/NPN, cloud, certificates, devices — gets a focused checklist drawn from the mechanism chapters, with the evidence to demand and the risk to score. It's the systematic version of Chapter 25's quick-scan, structured for a formal, repeatable security audit.
Checked June 2026 — verify against the latest 3GPP version. Reuse SCAS as audit seeds (Chapter 2, 11).
28.1 The Audit Methodology
FIGURE 28.1Audit Methodology Wheel
Purpose: the repeatable cycle. The non-negotiable principle: evidence-based — every "secure" claim is backed by a capture, config, or log, never a verbal assurance.
FIGURE 28.2RAN Audit Map
Purpose: the RAN checklist with evidence per item. Note each item names the proof to collect — a capture or config, not a claim.
FIGURE 28.3Core / SBA Audit Map
Purpose: the core/SBA checklist. The audience-claim negative test (Chapter 10) and the SBI reachability scan (Chapter 25) are the highest-yield items.
FIGURE 28.4Roaming Audit Map
Purpose: the roaming checklist. The "no bypass" and "filtering enabled" items catch the #1 roaming misconfiguration (Chapter 13/25).
FIGURE 28.5Slice and NPN Audit Map
Purpose: the slice/NPN checklist. "All four isolation layers" and "no eMBB defaults" catch the recurring slicing failures (Chapter 20).
FIGURE 28.6Cloud / Platform Audit Map
Purpose: the cloud checklist (Chapter 29). For cloud-native cores, this domain often has the most findings — the platform is new ground for telecom teams.
FIGURE 28.7Certificate / PKI Audit Map
Purpose: the PKI checklist. Certificate hygiene affects both security (un-rotated breach) and availability (expiry outage) — audit both angles.
FIGURE 28.8Audit Risk Scoring and Reporting Template
Purpose: the deliverable. An audit's value is a ranked, owned, dated remediation list — the executive sees the top criticals; the engineers get the evidence and the fix.
28.2 The Practical Operator View
Demand evidence, not assurances — captures, configs, scans; a verbal "it's on" is not an audit finding closed.
Score consistently (likelihood × impact) and sort by risk; map findings to mechanism chapters.
Re-verify fixes — a finding isn't closed until re-tested.
Run audits on a cadence; pair with continuous drift alarms (Chapter 26) between audits.
28.3 Domain-to-Chapter Map
Audit domain
Key items
Chapters
RAN
secure boot, interface IPsec, UP integrity, NCC
9,15,16
Core/SBA
mTLS, token validation, NRF/UDM hardening
10,11
Roaming
SEPP filtering, N32 protection, topology hiding
13
Slice/NPN
4-layer isolation, NSSAA, onboarding, OT segmentation
20,21
Cloud
image/K8s/secrets/supply-chain
29
Certificate
per-NF, rotation, revocation, root protection
10,14
Device
USIM root, EIR, fleet controls
4,23
Privacy
SUCI, GUTI rotation, LCS, minimization
4,19
28.4 Terminology
Term
Meaning
evidence-based audit
Findings backed by captures/configs/scans, not claims
SCAS / NESAS
Per-NF requirements / assurance scheme reused as audit seeds
risk score (L×I)
Likelihood × impact prioritization
re-verification
Re-testing a fix to confirm closure
Real network example. An operator's compliance team had been running an annual 5G "audit" that consisted of a vendor questionnaire — yes/no boxes the vendors filled in. It always came back green. When a new security lead replaced it with an evidence-based audit (the maps in this chapter), the first run found eleven findings across RAN, core, and roaming — including a critical disabled SEPP filter and a high-risk token-audience gap — none of which the questionnaire had ever surfaced, because the vendors had honestly answered "the capability exists" while the deployment had it switched off. The new audit's evidence requirement (a capture, a config, a scan per item) turned "we support it" into "here it is, running." The remediation list became the security roadmap. An audit that accepts assurances audits the paperwork; an audit that demands evidence audits the network.
★ Chapter Summary
The audit cycle is scope → evidence → score → report → fix → re-verify, and it is evidence-based — proof, never assurances.
Domain checklists cover RAN, core/SBA, roaming, slice/NPN, cloud, certificate, device, privacy, each drawn from its mechanism chapter.
Reuse SCAS/NESAS as audit seeds; score by likelihood × impact.
The deliverable is a prioritized, owned, dated remediation list, not a long document.
Pair periodic audits with continuous drift alarms (Chapter 26) between them.
? Review Questions
Why must an audit be evidence-based, and what's the failure mode of a questionnaire audit?
Name the audit domains and one high-yield item in each.
What is the single highest-yield core/SBA audit test, and why?
How do you reuse SCAS in an audit?
How should findings be scored and sorted?
Why is re-verification part of the audit cycle?
What does a good audit report look like?
Why pair audits with continuous drift alarms?
🧪 Mini lab — run a domain audit
Pick one domain (e.g., core/SBA) and run its checklist against a real or lab network you're authorized to test: (1) For each item, collect the evidence (capture/config/scan), not a claim. (2) Record pass/fail with the evidence attached. (3) Score each fail by likelihood × impact. (4) Produce a one-page prioritized, owned, dated remediation table (Figure 28.8). (5) For one finding, write the re-verification test that proves it's fixed. You've now produced the artifact that turns this entire book into action — and the input to the master checklist of Chapter 35.