Who writes the rules, and how to read them like an engineer
“The specification is the only document the attacker has also read. Know it better than they do.”
— EVERY GOOD TELECOM SECURITY AUDITOR, EVENTUALLY
Every 5G security mechanism you will ever configure was argued over, line by line, in a working group called SA3. Understanding how 3GPP produces security standards — and how to read them — turns the 33-series from intimidating PDFs into your most reliable engineering tool. This short chapter is the map you will use for the rest of the book.
🎯 Learning objectives
Describe 3GPP’s structure and SA3’s role in producing security specifications.
Explain how TS 33.501 relates to TS 23.501 / TS 23.502 — and why you need all three open at once.
Trace security evolution from Release 15 to Release 18/19.
Decode a 3GPP version number and find the right spec version for your network.
Navigate TS 33.501’s structure and the SCAS assurance specs.
📘 Standards reference box — Chapter 2
Specification
Title
Release / version verified
TS 33.501
Security architecture and procedures for 5G System
Rel-18, v18.11.0 (2026-04)
TS 23.501
System architecture for the 5G System
Rel-19, v19.6.0
TS 23.502
Procedures for the 5G System
Rel-19, v19.5.0
TS 33.916
Security assurance methodology (SECAM)
Rel-18 edition
Checked June 2026. Rel-19 SA3 deliverables were still maturing — verify against the latest 3GPP version.
2.1 How 3GPP Is Organized
3GPP (Third Generation Partnership Project) is not a company. It is a partnership of seven regional standards bodies — ETSI (Europe), ATIS (North America), ARIB/TTC (Japan), CCSA (China), TTA (Korea), TSDSI (India) — under which the world’s operators, vendors, and governments write one common set of mobile specifications.
The work splits across three Technical Specification Groups (TSGs): TSG RAN (the radio), TSG SA (the system — architecture, security, management), and TSG CT (protocol detail — NAS coding, HTTP APIs). Two working groups matter most for this book: SA2 writes the architecture (TS 23.501/502); SA3 writes the security (the 33-series).
💡 Key idea
SA2 builds the house, SA3 installs the locks, CT1/CT4 manufacture the keys to drawing tolerance. When SA2 invents a new procedure, SA3 must produce its security analysis — which is why security specs always lag architecture specs by a few meetings, and why a brand-new feature may briefly exist with “security TBD.”
FIGURE 2.13GPP Organizational Structure — TSGs and Working Groups
Purpose: place SA3 in the overall machine. Whenever you wonder “who owns this spec?”, come back to this chart — security always lives in the dark box.
2.2 SA3: The Security Working Group
SA3 meets roughly five times a year. Its inputs: new SA2 features needing protection, documented attacks from academia and GSMA, lawful-interception requirements (the SA3-LI subgroup), and member contributions. Its outputs:
Technical Reports (TR 33.8xx/9xx) — studies: threat analyses and candidate solutions. Non-normative. Example: TR 33.899, the huge study that shaped 5G security.
Change Requests (CRs) — the unit of evolution. Every difference between v18.10.0 and v18.11.0 is a set of approved CRs, each traceable in the 3GPP portal.
💡 Key idea
A study (TR) tells you what the committee worried about; the spec (TS) tells you what survived the argument. When a TS clause seems oddly specific, the matching TR usually contains the attack that put it there. Reading TRs is the fastest way to learn 3GPP threat thinking.
FIGURE 2.2SA3 in the 3GPP Machine — Inputs and Outputs
Purpose: standardization as a traceable process. Every clause in TS 33.501 entered through one of the four doors on the left.
2.3 The Specification Triangle: 23.501, 23.502, 33.501
You can rarely answer a 5G security question from one document. The working set is a triangle:
TS 23.501 defines what exists: the NFs, the architecture, the interfaces.
TS 23.502 defines what happens: procedures as message flows. Security appears as single boxes (“authentication is performed”).
TS 33.501expands those boxes: full authentication runs, key derivations, security mode procedures, protection requirements per interface.
Daily reading pattern: find the flow in 23.502 → identify the security step → open the matching clause in 33.501 → for exact message encodings continue to stage-3 specs (TS 24.501 NAS, TS 29.5xx SBA, TS 38.331 RRC).
Purpose: the daily navigation pattern. Architecture → procedure → security clause → stage-3 encoding. Bookmark all three documents; you will hop between them constantly.
2.4 The 33-Series Family
TS 33.501 is the flagship, but the 33-series is a family. The members you will meet in this book:
Spec
Scope
Chapters
TS 33.501
5G security architecture & procedures
everywhere
TS 33.210
NDS/IP — IPsec between network nodes
14
TS 33.310
PKI / certificate enrollment (CMPv2)
10, 14
TS 33.122
CAPIF — API framework security
12
TS 33.535
AKMA — application keys from network auth
5, 12
TS 33.558
Edge computing security
22
TS 33.401 / 33.102
EPS / UMTS security (legacy + interworking)
1, 17
TS 33.511–33.5xx
SCAS — per-NF security assurance
11, 28
TR 33.8xx/9xx
Studies — threats, candidate solutions
24, 32
FIGURE 2.4The 33-Series Security Specification Family
Purpose: a mental shelf for every security spec cited later. When 33.501 says “as specified in TS 33.210,” the requirement physically lives on that shelf.
2.5 Release 15 → 19: Security Evolution
Releases are 3GPP’s shipping vehicles. The security highlights:
Rel-15 (2018/19) — the baseline. SUCI, unified authentication (5G-AKA, EAP-AKA′), full key hierarchy, NAS/AS protection incl. UP integrity (rate-limited), SBA TLS+OAuth, SEPP with N32.
Rel-19 (in progress) — post-quantum migration analysis, further AIML security, ambient-IoT studies, SCAS expansion. Check the live SA3 work plan before quoting Rel-19 content.
⚠️ Warning
“Release X network” rarely means every node implements Release X. Real networks are release mosaics: a Rel-15 core with Rel-16 UP-integrity-capable RAN and Rel-17 features in one slice. Security audits must record the release per function, not per network.
FIGURE 2.5Release Timeline — Security Features Rel-15 to Rel-19
Purpose: date-stamp every feature so you can match capabilities to your network’s actual release mix. The dashed card is law: Rel-19 is unfrozen — verify before designing against it.
2.6 How to Read a 3GPP Security Spec
TS 33.501’s structure (stable across versions; clause numbers can shift — verify in your copy):
Interface/topic clauses — RAN security, interworking, SBA, SEPP (clauses ~9–13).
Annexes — the gold: KDF input strings (Annex A), SUCI ECIES profiles (Annex C), algorithm specs, test vectors. Most “how exactly?” answers are in annexes.
FIGURE 2.6Anatomy of a 3GPP Spec — How to Read TS 33.501
Purpose: turn a 200-plus-page specification into a navigable structure. The dark band is where you will spend Part 2 of this book; the red band answers “how exactly.”
2.7 Version Numbers Decoded
A 3GPP version is x.y.z: x = release (15, 18…), y = technical version (increments with approved CRs), z = editorial fixes. ETSI republishes the same content as “ETSI TS 133 501 Vx.y.z.”
Critical implication: releases are maintained in parallel. In April 2026 both v15.19.0 and v18.11.0 of TS 33.501 were published — the Rel-15 branch still receives corrections. Your compliance target is a branch, and the newest version of an old branch can post-date an early version of a new one.
FIGURE 2.73GPP Version Numbering Decoded
Purpose: prevent the classic mistake of treating spec versions as one sequence. Audit against a branch; record x.y.z per network function.
2.8 SCAS: Standardized Security Assurance
3GPP doesn’t only specify protocols; it specifies how to test that a network product is securely built:
SECAM (TR 33.916) — the methodology: how evaluations run, who is accredited.
SCAS (TS 33.117 generic + TS 33.511/512/513… per NF) — concrete test requirements for the gNB, AMF, UPF, UDM, AUSF, SEPP, NRF, NEF and more.
GSMA NESAS operationalizes it: vendors’ processes and products audited against SCAS by accredited labs.
For operators SCAS matters twice: in procurement (“NESAS/SCAS evidence required” belongs in every RFP) and in audit (Chapter 28 reuses SCAS requirements as checklist seeds).
FIGURE 2.8SCAS / SECAM Security Assurance Process
Purpose: how paper requirements become tested products you can demand. If your RFP doesn’t ask for NESAS/SCAS evidence, you are trusting marketing.
2.9 The Practical Operator View
Maintain a spec register: for each NF — vendor, release compliance, the TS 33.501 version tested against. Without it, no audit finding is provable.
Subscribe to the public 3GPP work plan and SA3 meeting reports. A CR today is your patch requirement next year.
In RFPs, require NESAS/SCAS evidence and a statement of which “should” requirements the vendor skipped.
When vendors disagree about behavior, resolve with the CR history, not the marketing slide.
Common misconfiguration risks
Auditing against the wrong release branch (e.g., demanding Rel-16 full-rate UP integrity from a Rel-15 RAN).
Treating “should” items as implemented without verification.
Quoting draft Rel-19 behavior as if frozen — drafts change.
Assuming ETSI “TS 133 501” differs from 3GPP TS 33.501 — same content, different cover.
2.10 Threats and Mitigations
Threat
Mechanism
Mitigation
Vendor ships unverified “should” gaps
Optional requirements silently skipped
RFP deviation statement + SCAS evidence
Audit against wrong branch
Version confusion
Spec register; record x.y.z per NF
Stale security posture
CRs not tracked
SA3-report monitoring duty in engineering
Procurement of untested products
No assurance demanded
NESAS gate in procurement
2.11 Terminology, Example, Checklist
Term
Meaning
TSG / WG
Technical Specification Group / Working Group
SA3 / SA3-LI
Security working group / its lawful-interception subgroup
TS / TR
Normative specification / non-normative study
CR
Change Request — the atomic unit of spec evolution
Stage 1/2/3
Requirements / architecture / protocol detail
SECAM / SCAS / NESAS
Assurance methodology / per-NF test specs / GSMA audit scheme
Real network example. An operator’s security team rejected a core vendor’s claim that “OAuth on all SBI interfaces is mandatory, so it’s on by default.” The actual Rel-15 text made token-based authorization subject to deployment configuration — the vendor default was off. The team added a configuration acceptance test and an RFP clause citing the exact clause and version. The spec text and version decide; defaults and marketing do not.
Identify the exact spec version (x.y.z) each NF vendor claims compliance to — from documentation, not memory.
For any disputed behavior, locate the governing clause and check shall / should / may.
Check the CR history between the vendor’s version and the latest for relevant fixes.
Confirm which release branch your audit baseline uses.
For Rel-19 features: confirm freeze status before relying on them.
★ Chapter Summary
3GPP splits work across TSG RAN/SA/CT; SA2 designs the system, SA3 secures it, CT encodes it.
Your daily working set is the triangle 23.501 → 23.502 → 33.501, backed by stage-3 specs.
The 33-series is a family: NDS/IP, PKI, CAPIF, AKMA, edge, legacy, SCAS.
Rel-15 set the baseline; Rel-16 hardened industry; Rel-17 covered new accesses; Rel-18 opened 5G-Advanced; Rel-19 is in flight — always verify.
Versions are per-branch and parallel; shall/should/may carries legal-grade weight.
? Review Questions
Which working group defines the AMF, and which defines how the AMF’s interfaces are protected?
Your RAN vendor claims full-data-rate user-plane integrity. What is the minimum release, and how do you verify the claim documentarily?
Why can TS 33.501 v15.19.0 be newer in publication date than v18.2.0?
What is the obligation difference between “shall,” “should,” and “may” — and where do vendor gaps usually hide?
What is SCAS, which spec holds the generic NF requirements, and how does an operator use it in procurement?
A Rel-19 feature appears in a draft TS. What must you do before designing against it?
🧪 Mini lab — meet your companion document
Download the latest TS 33.501 from the public 3GPP portal. (1) From the cover, note release, version, date. (2) Find the key-hierarchy clause and write down its number — you will use it constantly from Chapter 7. (3) Open Annex A and count how many derived keys have defined KDF input strings. (4) Find one “should” requirement and write two sentences on what an attacker gains where a vendor skipped it. Keep the PDF open — it is your companion for the next 33 chapters.