School of Specs The 5G system architectureIn depth

What the system does · chapter 16 of 27 · 14 minutes

16 Who you are and who may listen

What the architecture document actually settles about authentication, security contexts, identifier privacy and user-plane protection — and the much larger part it hands over to TS 33.501.

Built from §5.10 §5.39

16.1 Why this chapter is mostly about a boundary

TS 23.501 says which functions exist, what each one holds and who talks to whom. It contains no key derivation, no algorithm, no authentication message exchange and no description of how an identifier is concealed.

All of that is in TS 33.501 [29], "Security architecture and procedures for 5G system". Clause 5.10 lists the security features in six lines and points there §5.10.1.

The clause names six features §5.10.1:

  • Mutual authentication — the network satisfies itself that the subscriber is who they claim to be, and the device satisfies itself that the network is the real one.

  • Security context generation and distribution — the shared state that all the protection runs on is made once and handed to the functions that need it.

  • User-plane confidentiality and integrity protection — your traffic can be encrypted, and can be checked for tampering, on the way to the mast.

  • Control-plane signalling confidentiality and integrity protection — the same two guarantees for the messages that set that traffic up.

  • User identity confidentiality — the permanent name of the subscriber is never sent in the clear over the air.

  • Support for lawful interception under TS 33.126 [35], subject to regional regulation, including protecting the interception data itself when a network function stores or forwards it.

16.2 Primary authentication: which function does what

Primary authentication is the decision about whether this subscriber may use this network at all. Three functions carry it, and this document names each one's part.

  • The AMF (the function that tracks where a device is and whether it can be reached) terminates the NAS signalling — the messages a device exchanges with the core rather than with the radio mast — and does its ciphering and integrity protection. It also carries the Security Anchor Functionality, the SEAF, as specified in TS 33.501 [29] §6.2.1.

  • The AUSF (the authentication server) supports authentication for 3GPP access and untrusted non-3GPP access, and for the Disaster Roaming service §6.2.8. That entry is two lines long, but the document also settles how the AUSF is found and picked §6.3.4, which services it offers §7.2.7, and what it does when a private network authenticates against an outside AAA server §5.30.2.9.2.

  • The UDM (the function that owns a subscriber's data, usually stored in the UDR behind it) generates the 3GPP AKA authentication credentials, stores the SUPI for every subscriber, and de-conceals the privacy-protected identifier §6.2.7.

The network may authenticate the device during any procedure that establishes a NAS signalling connection, and may separately check the equipment identity against the 5G-EIR §5.2.3.

A fourth function appears when the credentials do not live in the operator's own UDM: the NSSAAF (the go-between for authentication somebody else does).

It relays EAP messages — the standard back-and-forth of an authentication exchange — to a AAA server, and through a proxy when that server belongs to a third party §6.2.23 §5.30.2.9.2.

16.3 The security context, and why it outlives the connection

A security context is the shared state, set up by authentication, that lets the two ends protect what they send. This document never lists its contents; it says where it lives and how long it lasts.

NAS signalling rides on it: security of the NAS messages is provided based on the security context established between the UE and the AMF §8.2.2.1.

It outlives a connection on purpose. Even in RM-DEREGISTERED, parts of the UE context stay in both the device and the AMF — explicitly so that authentication does not have to run at every registration §5.3.2.2.2.

The 5G-GUTI is the handle that finds the context again, and while the device is in CM-IDLE the AMF may delay issuing a new one until the next NAS transaction §5.9.4.

Two accesses at once give two contexts, not one. When a device is attached over NG-RAN (the 5G radio network — the masts and the kit that runs them) and over a standalone non-3GPP access, each N1 connection is secured with its own NAS security context.

Both are derived from the context in the corresponding SEAF — the same SEAF when one AMF serves both §5.10.2.1.

It even outlives leaving 5G. A device in single-registration mode moving to 4G keeps its native 5G-GUTI and its native 5G security context so the context can be reused on return §5.17.2.1 — see Living next to 4G.

16.4 Hiding the subscriber's name

The permanent name of a subscriber is the SUPI. It is globally unique, provisioned in the UDM and UDR, and it contains the address of the home network so that roaming can work.

It may hold an IMSI, a network-specific identifier in NAI form for private networks, or a line identifier for fixed access §5.9.2.

Broadcast a permanent name over the air and anyone with a receiver can follow a person around, so the device never sends it in the clear.

The concealed form is the SUCI §5.9.2a. How it is computed is TS 33.501's business. What matters architecturally is which parts of it stay readable, so that a serving network can route the authentication home without being able to read who the subscriber is:

  • The Home Network Identifier and the Routing Indicator, which the AMF uses to find the right AUSF §6.3.4 and the right UDM §6.3.8.

  • Optionally the Home Network Public Key Identifier, which says which public and private key pair was used to protect the SUPI, so the home network knows which key de-conceals it §3.1.

Only the UDM turns the SUCI back into a SUPI §6.2.7.

16.5 Secondary authentication: the data network gets its own say

Getting onto the network is one decision. Getting into a particular data network is another, and its owner may want to make it themselves.

Secondary authentication runs at PDU session establishment, against a DN-AAA server that may sit inside the core or out in the data network §5.6.6. The mechanism:

  • The SMF (the function that sets up a data session and steers it) decides whether it is needed, from its policy for that data network. If the device supplied credentials for its DN-specific identity, the SMF passes them on — through the UPF when the server is out in the data network. If it did not, the SMF asks for one using EAP.

  • A failure means the PDU session establishment is rejected.

  • Success may return DN Authorization Data: a profile index into policy configured in the SMF or PCF, allowed MAC addresses and VLAN tags for Ethernet sessions, a DN-authorized Session-AMBR that beats the subscribed one from the UDM, framed route information, and L2TP details.

  • The session between SMF and DN-AAA is kept afterwards. Either side may re-authenticate later, and the DN-AAA may revoke the authorization at any time, which lets the SMF release or update the PDU session §5.6.6.

This sits on top of, not instead of, the access authentication the AMF handles §5.2 and the session authorization the SMF does against UDM subscription data. The session itself is The connection to a data network.

16.6 Authentication per slice

The third decision is whether this device may use this slice. Subscription data marks some S-NSSAIs — the names that slices go by — as subject to Network Slice-Specific Authentication and Authorization, and then the serving network has to run it §5.15.10.

  • The device declares in its Registration Request whether it supports the feature. If it does not, the marked slices are rejected outright. If it does, they go on the Pending NSSAI while the check runs §5.15.5.2.1.

  • The AMF runs an EAP-based procedure per S-NSSAI and stores the status as pending; on completion the slice moves into the Allowed NSSAI or into the rejected list. The status moves with the device when the AMF changes.

  • Primary authentication of the SUPI must have succeeded first, and if the SUPI's authorization is revoked the slice authorization goes with it.

  • The AAA server may re-challenge or revoke at any time. On revocation the AMF sends a new Allowed NSSAI and releases every PDU session on that slice for that access type §5.15.10.

  • The result is kept while the device stays registered, so the check does not run again at every periodic registration update.

More on slices in One network, many networks.

16.7 Who decides whether your traffic is encrypted

This is the part of §5.10 with real machinery in it, and the answer is neither the device nor the radio network. The SMF decides, at PDU session establishment, and writes it down as User Plane Security Enforcement information — two settings, three values each §5.10.3.

Setting Required Preferred Not Needed
Integrity protection shall apply to all traffic on the session should apply shall not apply
Confidentiality protection shall apply to all traffic on the session should apply shall not apply

Three inputs go into the decision §5.10.3:

  • S1. The subscribed User Plane Security Policy, part of the session-management subscription data from the UDM.

  • S2. A policy configured locally in the SMF per DNN (the name of the data network a session leads to) and S-NSSAI, used only when the UDM supplies none. The UDM value takes precedence.

  • S3. The device's maximum supported data rate for integrity protection, sent in the Integrity protection maximum data rate IE (an information element — one named field of a message). A device with NR as its primary radio technology sets it to full rate; a device that does not support NR as its primary radio and does support E-UTRA connected to 5GC sets it to NULL.

Two properties catch people out: it applies only over 3GPP access, and once determined at establishment it holds for the life of the PDU session §5.10.3.

Enforcement belongs to the NG-RAN. The SMF sends it the enforcement information, plus the maximum integrity rate when integrity protection is Required or Preferred, at session establishment or at user-plane activation. Then:

  • A radio node that cannot meet Required rejects the user-plane resources, and the SMF releases the PDU session.

  • A radio node that cannot meet Preferred carries the session anyway and notifies the SMF.

  • At handover the enforcement information and the rate travel from source node to target node. A target that cannot meet them rejects the resources, the session is not handed over, and it is released.

  • Downlink, the radio network keeps the integrity-protected rate it delivers below the stated maximum. Uplink, the device is expected to stay under it but is not required to enforce strictly §5.10.3.

The SMF may also refuse the session outright, on local configuration, when the device's maximum integrity rate is too low for what that data network needs §5.10.3.

A large part of the clause goes on moving such a session to 4G. Not every 4G network can protect the user plane's integrity, so a session with integrity protection Required only survives the move if the device, the eNB and the MME all indicate support.

Otherwise the SMF+PGW-C rejects the request or releases the session, and towards GERAN or UTRAN it is always released. Confidentiality set to Required does not block the move §5.10.3.

16.8 Getting credentials you do not have yet

Credentials for primary authentication come with the subscription, and this document does not say how they reach the device.

Those for slice-specific and for secondary authentication are a different thing, and this document says twice that they are not specified §5.15.10 §5.6.6. A device may simply not have them.

Clause 5.39 is how they get there. The subscribed network — the HPLMN or the subscribed SNPN — may provision or update them, and the transport is the user plane §5.39.1:

  • P1. The device establishes an ordinary PDU session for provisioning, over a DNN and S-NSSAI that can reach the Provisioning Server (PVS). The AMF picks the SMF the usual way §6.3.2.

  • P2. If the SMF holds PVS addresses or FQDNs for that DNN and S-NSSAI, it returns them in the Protocol Configuration Options of the PDU Session Establishment Response — but only if the device asked for them in the request §5.39.2.

  • P3. Otherwise the device may already be configured with a PVS address, or the PVS may subscribe to UE Reachability Notification and use the Application Triggering procedure to make the device set the connection up §5.39.1.

  • P4. If it still has no address or FQDN after the session is up, the device may construct an FQDN for PVS discovery as defined in TS 23.003 [19] §5.39.2.

The configuration data behind this — PVS IP addresses and FQDNs, optionally tied to particular DNNs and S-NSSAIs — is either pre-configured on the device or given by the network, and what the network gives takes precedence.

It may be held in the ME §5.39.2 — the mobile equipment, meaning the handset itself rather than the card in it.

16.9 Where else security shows up

Two functions guard the border with another operator. The SEPP filters and polices every control-plane message crossing it and hides the topology behind it §6.2.17Being served by somebody else's network.

IPUPS is a UPF role that forwards GTP-U packets arriving on N9 only when they belong to an active PDU session and are not malformed §5.8.2.14Where the packets actually go.

Lawful interception is the listening the system is built to allow. It is one of the six features §5.10.1 and one of the parts of network access control §5.2.7, and those two clauses are the ones that send you to TS 33.126 [35].

The AMF, the SMF and the UDM each carry it as a named function too, but those entries do no more than name the capability §6.2.1 §6.2.2 §6.2.7.

For the identifiers see Every name the system uses, and for the registration in which the first authentication happens, Registration, reachability and paging.

Check yourself

Answers appear when you pick one, with where they come from.

Q16.1 Where are the authentication methods and key derivations of 5G defined?

Q16.2 Which function decides the User Plane Security Enforcement information for a PDU session?

Q16.3 The radio network cannot meet a User Plane Security Enforcement value of "Required". What happens?

Q16.4 Which function de-conceals the SUCI back into a SUPI?

Q16.5 What has to have happened before slice-specific authentication can run for a device?

Q16.6 Which credentials does the remote provisioning of clause 5.39 deliver?

This chapter was written against TS 23.501 version 20.2.0, verified 2026-08-04. A newer version of the document may say something else.