5G Security Architecture

Security architecture topics

Read the system model first, then choose an identity, access, or network-boundary topic according to the security relationship you need to understand.

Architecture model and scope

A useful security architecture view answers four questions for each relationship: who participates, what is protected, which credentials or keys establish trust, and which state must remain synchronized? These questions apply separately to subscriber access, radio bearers, network-function services, and inter-operator communication.

The main model here is ordinary subscription-based access to 5GC, with NR as the radio example. Home and serving network roles are distinct even when both belong to the same operator. Roaming places them in different public land mobile networks (PLMNs), adding interconnect boundaries without turning the visited network into the holder of the subscriber’s long-term credential.

The baseline is TS 33.501 V18.8.0, Release 18. EPC-anchored NSA, emergency access, non-public networks, and specialized interworking require their applicable security procedures. A “5G” radio indicator alone does not identify the core security model.

Security domains: scopes of protection

The security domains in TS 33.501 organize the architecture by the relationships being protected. They are not successive protocol layers, and a single registration can involve several domains. Network access security addresses the UE’s access relationship; network domain security addresses communication among network entities. User-domain and application-domain controls concern different endpoints again.

Service-based architecture security covers network-function service interactions, including authentication and authorization. Visibility and configurability concern awareness and control of security features. Neither should be inferred solely from the fact that NAS integrity or radio ciphering is active.

Reference: TS 33.501, clauses 4.1, 5.9, and 5.10.

Entities and responsibilities

Functional roles do not necessarily imply separate physical nodes. The Security Anchor Function (SEAF) is associated with the serving AMF; ARPF and SIDF describe authentication-credential and identity-processing responsibilities associated with the home-network subscription architecture.

References: TS 33.501, clauses 4.2–4.3, 6.1, 6.6, 7, and 7A; TS 23.501. Continue with Security Entities.

Trust boundaries and interfaces

A reference point identifies a communication relationship; it does not, by itself, specify that every packet on that path is protected by the same mechanism. Operators can divide their networks into multiple trust zones. Crossing an internal zone boundary can require protection even when both endpoints belong to one operator.

In a split gNB, locate the actual PDCP termination and identify the CU/DU and CU-CP/CU-UP transport boundaries. A single box labeled “gNB” is useful for the logical model but insufficient for deciding which F1 or E1 link needs protection.

References: TS 33.501, clauses 5.3, 5.9.1, 9, and 13; TS 33.210.

Identity and authentication across home and serving networks

Identity handling answers which subscription is involved? Authentication answers can the subscription and network establish the required trust? Keep those questions separate when following the roles of UDM, AUSF, and AMF/SEAF.

SUPI identifies the subscription permanently. SUCI provides a concealed representation when a non-null protection scheme is used, while retaining the information needed for routing toward the home network. The home SIDF de-conceals the identity. The serving AMF can allocate a 5G-GUTI for subsequent temporary identification. SUCI concealment therefore does not imply that the serving network can never learn SUPI through an authorized procedure.

Primary authentication normally uses 5G AKA or EAP-AKA′ in the subscription-based case. The serving network coordinates the access-facing exchange, while the home network performs its authentication responsibilities and provides appropriate anchor material. A response seen on N1 is one part of that relationship; it is not evidence that every home-network check has completed.

The next architectural step is the distribution and derivation of purpose-specific keys. Authentication does not mean NAS security, AS security, and every data bearer have all been activated at once.

Reference: TS 33.501, clauses 6.1 and 6.12, and Annex C. Topic references: Identity and Privacy and Authentication Architecture.

Key custody and separation of security contexts

The key hierarchy limits which material each function needs. In ordinary AKA-based access, the long-term subscription secret is not sent to the gNB. Authentication-derived material leads through K_AUSF, K_SEAF, and K_AMF to working keys scoped to NAS and access protection. The UE derives corresponding keys for its side of those relationships.

Keys alone are not a complete security context. Algorithm identifiers, key-set identifiers, direction, counters, and context lifecycle state determine how the material is used. A correct-looking key with a stale counter or wrong context selection can still fail verification.

Reference: TS 33.501, clause 6.2 and Annex A. Continue with Key Hierarchy; the security overview includes a key-dependency diagram.

NAS, AS, and non-3GPP access security

Non-Access-Stratum (NAS) security is the UE–AMF relationship. Access-Stratum (AS) security is the radio-access relationship; for NR, it terminates at the UE and gNB. NAS Security Mode and RRC SecurityMode are separate procedures, use separate working keys, and establish different protection states.

RRC protection and user-plane protection also need to be distinguished. Radio signaling integrity does not prove that every data radio bearer has user-plane integrity enabled. The bearer configuration, UE capabilities, and user-plane security policy must be checked. Radio protection ends at the gNB; application-level protection can continue to a remote server.

Non-3GPP access keeps the broader 5GS security model but changes the access path and its security establishment. The Non-3GPP Interworking Function (N3IWF) serves untrusted access, using the specified IKEv2/IPsec arrangement. Trusted non-3GPP access uses a different model, including the Trusted Non-3GPP Gateway Function (TNGF). “Trusted” does not mean authentication or access security can simply be omitted.

References: TS 33.501, clauses 6.4–6.7, 7, and 7A; TS 24.501, clause 5.4.2; TS 38.331, clause 5.3.4. Continue with NAS and AS Security or Non-3GPP Access Security.

Core-network and roaming perimeter security

Inside the core, a network function needs an authorized service relationship with its peers. Transport protection, NF authentication, and service access authorization are different checks. TLS and OAuth 2.0 mechanisms appear in the service-based security architecture under their applicable conditions; the presence of a secure transport channel alone does not establish permission to invoke every service.

At an operator boundary, separate the control plane from the user plane. SEPP protects inter-PLMN service-based signaling across N32. N32-c supports control and security negotiation; N32-f supports the forwarding relationship using the applicable protection arrangement. These functions must not be described as a tunnel for all subscriber traffic.

Inter-PLMN UP Security (IPUPS) is UPF functionality that enforces GTP-U security on N9 between visited and home UPFs. This is distinct from SEPP and from deciding which network transport is cryptographically protected. NDS/IP supplies the network-domain framework for applicable IP-layer protection; its security gateways and associations are not interchangeable with subscriber NAS or AS contexts.

References: TS 33.501, clauses 4.2, 5.9.3, 9, and 13; TS 33.210. Continue with Perimeter Security, Roaming and Interconnect Security, and Network Domain Security.

Security architecture includes context lifecycle

The network topology can remain unchanged while the active security context changes. The architecture must account for creation, activation, retention, transfer, key update, and eventual removal of state. Otherwise, a diagram can show the correct endpoints while still hiding the reason a procedure fails.

• Registration and activation: associate authentication-derived material with the context selected for NAS, then establish the required access security state.
• Idle and resume: releasing or suspending a radio connection does not automatically imply deletion of all NAS and AS context. Apply the rules for the actual transition.
• Mobility: distinguish target access-key derivation from AMF-level context changes. A handover does not necessarily require full primary authentication.
• Recovery: compare context identifiers, algorithms, counters, and the last successful activation or transfer on both sides before diagnosing a key mismatch.

References: TS 33.501, clauses 6.8–6.11; TS 24.501, clause 4.4. Continue with Security Context Lifecycle.

Reading paths and practical analysis

For a first reading, follow architecture overview → security entities → identity and authentication → keys → NAS/AS protection → lifecycle. Add perimeter, non-3GPP access, and network domain topics according to the deployment.

For message fields, continue into the NAS and RRC message libraries. For failure analysis, use the security troubleshooting reference after locating the relevant endpoint and context.

Specification references

The architecture baseline uses a specific Release 18 edition so the clause references are reproducible. The protocol references below use the same editions as the security overview. Directory links list editions for the companion system and network-domain specifications.

1. 3GPP TS 33.501 V18.8.0 — Security architecture and procedures for 5G System

   Clauses 4.1–4.3: domains, perimeter, and entities; 5.9: core trust boundaries; 6.1–6.2: authentication and keys; 6.4–6.7: access protection; 6.8–6.12: lifecycle and privacy; 7/7A: non-3GPP access; 9: network interfaces; 13: service-based and interconnect security; Annex A: key derivation.

2. 3GPP TS 23.501 — System architecture for the 5G System

   Companion reference for network functions, reference points, access models, and roaming arrangements. Select the edition that matches the deployment.

3. 3GPP TS 33.210 — Network Domain Security; IP network layer security

   Network-domain protection, security gateways, and IP-layer security arrangements.

4. 3GPP TS 24.501 V18.9.0 — NAS protocol for 5GS

   Clause 4.4: NAS security and context handling; 5.4.1: authentication; 5.4.2: security mode control; 5.4.3: identification.

5. 3GPP TS 38.331 V18.4.0 — NR RRC protocol specification

   Clause 5.3.4: initial AS security activation; 5.3.5.7: AS security key update; 5.3.13: resume.

6. 3GPP TS 38.323 V18.4.0 — NR PDCP specification

   Clauses 5.8–5.9: ciphering and integrity processing at the radio security endpoint.

Frequently asked questions

What does the 5G security architecture define?

It defines the security domains, functional responsibilities, trust relationships, key separation, and protection mechanisms used across the 5G System. The architecture connects UE access security with home-network authentication, core-network services, and operator interconnect protection.

How is this architecture hub different from the security overview?

The security overview explains the mechanisms and their progression in a connection. This hub organizes the architecture topics around the functions, boundaries, and contexts that implement those mechanisms, and provides routes into each architecture reference.

Does the gNB terminate NAS security?

No. NAS security terminates at the UE and AMF. The gNB transports NAS signaling and separately terminates the NR access-stratum security relationship, including radio signaling and configured user-plane protection.

Is SEAF a separate physical network node?

SEAF is a logical Security Anchor Function associated with the AMF in the serving network. A functional architecture diagram should not be read as a requirement to deploy every named role as a separate appliance.

Does SEPP protect the roaming user plane?

SEPP protects inter-PLMN service-based control-plane signaling over N32. The user-plane boundary is separate; IPUPS is UPF functionality for GTP-U security on N9 between visited and home networks. Neither should be confused with end-to-end application encryption.

Where should I read about AUSF and UDM?

Use the existing AUSF and UDM pages under the 5G Core Network reference for their full node descriptions. The security architecture section explains how those functions participate in identity handling, authentication, and key management.