5G Security Overview

Quick facts

Scope and security objectives

The main example on this page is a subscriber accessing the 5G Core through NR. The security architecture also covers other access types and interworking, but a radio connection labeled “5G” does not by itself establish which core security model applies. An EPC-anchored NSA deployment uses an EPS security context and the relevant dual-connectivity procedures; it should not be decoded as if it were a standalone 5GS registration.

The reference baseline is the set of Release 18 editions listed above. This is a defined baseline, not a claim that every described mechanism originated in Release 18 or that these are the latest published versions. Emergency access, non-public networks, and specialized procedures need their own conditions checked in the specifications.

Specification context: TS 33.501, clauses 4–5.

Security domains and protection boundaries

The 3GPP architecture distinguishes network access security, network domain security, user domain security, application domain security, service-based architecture security, and visibility and configurability of security. These domains describe different relationships: authenticating a subscription is different from authorizing a network-function service request or controlling access to the USIM.

For trace analysis, the most useful first step is to identify the two endpoints of the mechanism. NAS security terminates at the UE and AMF. The gNB carries NAS in access signaling but does not become the NAS cryptographic endpoint. NR access-stratum security terminates at the UE and gNB, with PDCP applying the radio protection. The UPF forwards user traffic in the core; it is not the endpoint of NR radio ciphering.

In a split gNB, the logical gNB endpoint needs to be mapped to the actual CU functions and PDCP placement. Protecting the air interface does not automatically protect F1, E1, transport networks, management interfaces, or stored subscriber data.

References: TS 33.501, clauses 4, 5.3, and 9; TS 38.323, clauses 5.8–5.9. Architecture reading: Security Architecture Overview.

Which entities perform the security functions?

Security functions are distributed between the device, serving network, and home network. Some names identify logical roles within a larger function rather than separate physical appliances. For example, SEAF is the serving security-anchor role associated with the AMF.

Reference: TS 33.501, clauses 4.2–4.3, 6.1, 7, and 7A. Continue with Security Entities.

Subscriber identity and privacy: SUPI, SUCI, and 5G-GUTI

SUPI is the Subscription Permanent Identifier. It identifies the subscription, rather than a particular radio connection. An IMSI is one SUPI format; the 5GS identity model is not limited to IMSI-based identifiers.

SUCI, the Subscription Concealed Identifier, allows the subscription to be identified without routinely exposing the permanent subscriber-specific identity on the access path when a non-null protection scheme is used. For an IMSI-based SUPI, the home-network identity and routing-related fields remain available while the subscriber-specific portion is protected. The home network provisions the public-key information and protection scheme; the SIDF in the home UDM performs de-concealment using the corresponding private key.

5G-GUTI is a temporary identity allocated by the AMF. It lets later signaling refer to stored context without repeating permanent subscription identification. If the network cannot resolve a supplied temporary identity, an identification procedure can request SUCI.

References: TS 33.501, clause 6.12 and Annex C; TS 24.501, clause 5.4.3. Continue with Identity and Privacy.

Primary authentication: 5G AKA and EAP-AKA′

Primary authentication establishes the subscription-based trust relationship and key material used by subsequent 5GS security procedures. The ordinary methods are 5G AKA and EAP-AKA′. The home network selects the applicable method. Non-public-network and other specialized cases extend this model and should be treated explicitly.

5G AKA

The UE receives a challenge containing RAND and AUTN. The USIM checks the authentication token and freshness and contributes the material from which the UE computes its 5G response, RES*. The serving network can check HRES* against HXRES*; the AUSF performs the home-network comparison with XRES*. These are different checks, so a locally observed response or serving-network check is not a substitute for the completed home-network result.

A synchronization failure and a MAC failure at this stage have different meanings. Synchronization failure can invoke authentication resynchronization handling. It should not be confused with a NAS message-integrity failure after security activation: AUTN verification and NAS integrity protect different exchanges.

EAP-AKA′

EAP-AKA′ uses an EAP exchange and its own method-specific key derivation before feeding the 5GS anchor-key hierarchy. It is not synonymous with “Wi-Fi authentication.” The primary authentication method and the access-security mechanism are separate concepts. In particular, EAP-5G used in untrusted non-3GPP access carries access and NAS-related signaling; it is not another name for EAP-AKA′.

Primary authentication also differs from optional secondary authentication of a PDU session toward a data-network AAA server. A subscription can pass primary authentication and still fail a later data-network authorization step.

Reference: TS 33.501, clauses 6.1, 7.2.1, and 11; NAS behavior: TS 24.501, clause 5.4.1. Procedure: 5G Authentication.

Key hierarchy: why 5G uses separate keys

The long-term subscription key is the starting credential for ordinary AKA-based authentication. It is not sent across the radio interface or distributed to the gNB. Authentication produces method-specific material, which feeds a sequence of derived keys with narrower purposes.

K_AUSF supports the home authentication context; K_SEAF binds the serving anchor to the serving-network name; and K_AMF binds the AMF-level context using inputs that include SUPI and ABBA. The latter is an anti-bidding-down parameter. From K_AMF, the UE and network obtain separate NAS working keys and access-specific material.

Key derivation is not just a sequence of renamings. It uses defined inputs, including purpose and algorithm identifiers at the relevant derivation steps. A wrong serving-network name, subscription identity, algorithm choice, or access-context input can therefore produce a mismatch even when both ends started from valid subscription credentials.

Reference: TS 33.501, clause 6.2 and Annex A. Continue with Key Hierarchy.

NAS security, RRC security, and user-plane protection

NAS and AS security use different endpoints, key branches, and activation procedures. A NAS Security Mode Complete does not prove that RRC security has completed. Conversely, a healthy radio-security context does not establish that a particular NAS message is valid under the AMF’s current context.

NAS security mode

The AMF selects NAS algorithms using UE capabilities and network policy. The Security Mode Command identifies the selected context and algorithms and replays UE security capabilities so the UE can check for modification. The command is integrity protected but not ciphered; it is part of establishing the protection state, not an ordinary post-activation payload. Security Mode Complete confirms successful UE handling. Consult the procedure rules for how initial NAS content is protected or retransmitted in a NAS container.

Access-stratum security mode

The gNB receives access security material and selects AS algorithms. RRC SecurityModeCommand and SecurityModeComplete establish the initial AS security state. PDCP applies integrity and ciphering according to the activation rules. The precise treatment of the command, response, and following packets matters when decoding a capture around the transition.

User-plane security is policy-controlled

For data radio bearers, inspect the user-plane security policy and actual bearer configuration. Do not assume every DRB uses integrity protection merely because RRC integrity is active. Likewise, successful registration does not prove confidentiality if null ciphering is selected. Radio protection ends in the access network; application TLS or another end-to-end mechanism serves a different relationship.

References: TS 24.501, clauses 4.4 and 5.4.2; TS 38.331, clause 5.3.4; TS 38.323, clauses 5.8–5.9; TS 33.501, clauses 6.6–6.7.

Security establishment in a fresh registration

The following sequence highlights the security dependencies when no reusable context is available. It is not a complete registration call flow: subscription retrieval, registration acceptance, session signaling, and several transport messages are omitted.

1. Identify the subscription or resolve existing identity information. Inspect the Registration Request identity and any Identity Request/Response exchange.
2. Complete primary authentication. Follow both the UE-facing exchange and the home-network result; associate the result with the correct UE context.
3. Establish NAS security. Verify context selection, algorithm selection, capability checking, and the NAS Security Mode response.
4. Install the access context. Relate the core-provided security material and capabilities to the gNB’s UE context.
5. Activate AS security. Confirm the RRC response and subsequent protected signaling; inspect data-bearer security separately when those bearers are configured.

A later service request can reuse a valid security relationship, and mobility can derive or transfer context without a new full primary authentication. Absence of Authentication Request in a short capture is therefore not enough to conclude that authentication was skipped incorrectly.

Procedure references: TS 24.501, clauses 5.4.1–5.4.3; TS 38.331, clause 5.3.4. Full procedures: Initial Registration, NAS Security Mode, and AS Security Activation.

Algorithms, COUNT, and replay protection

The NEA family identifies 5G ciphering algorithms; NIA identifies integrity algorithms. Algorithm selection is distinct from key derivation and activation. The selected identifier, the corresponding key, and the message-processing inputs must all agree at both endpoints.

These are the conventional 128-bit NEA/NIA families in the baseline. Support requirements, algorithm preference, and exceptions must be read in context; “supported” does not mean “selected.” NAS and AS choices should each be read from their own procedure.

COUNT is part of the cryptographic state. The NAS sequence number transmitted in a message is only part of NAS COUNT; the receiver also maintains overflow state. Uplink and downlink are tracked separately. At PDCP, COUNT is formed from the PDCP sequence number and hyper-frame state for the relevant bearer. A decoder that guesses the wrong overflow, direction, bearer, or security context can fail integrity verification or deciphering even with the expected algorithm.

Replay protection uses the accepted message history and counter rules, not just a valid-looking sequence number. Do not reset counters independently while reusing a key context. For an integrity problem, reconstruct the activation or context-transfer point before interpreting isolated packets.

References: TS 33.501, clause 5.11 and Annex D; TS 24.501, clause 4.4.3; TS 38.323, clauses 5.8–5.9.

Security context lifecycle and mobility

A security context includes more than keys: context identifiers, selected algorithms, counters, capabilities, and state determine how the keys are used. The NAS key-set identifier, ngKSI, helps identify a context; it is not itself a key and does not make stale contexts equivalent.

Native 5G contexts originate from 5GS authentication. Mapped contexts arise in defined interworking procedures. Current and non-current context handling also matters during transitions. The correct behavior depends on the procedure and whether the UE and network still have corresponding valid state.

• Idle access: releasing an access connection does not necessarily destroy the NAS security relationship.
• RRC inactive and resume: retained AS context and resume validation must be checked against the specific RRC transition.
• Handover: target access keys and next-hop material can change without a new subscription authentication. NH and the next-hop chaining count, NCC, belong to this mobility handling.
• AMF change or interworking: context transfer, key derivation, and counter handling must be correlated across both sides of the transition.

References: TS 33.501, clauses 6.8–6.11; TS 24.501, clause 4.4.2; TS 38.331, clauses 5.3.5.7 and 5.3.13. Continue with Security Context Lifecycle.

Core-network, roaming, and non-3GPP access security

Service-based interfaces and network domains

Inside the 5G Core, network functions need protection and authorization for their service interactions. TLS-based transport protection and service authorization, including OAuth 2.0 mechanisms where applicable, address this relationship. A successful UE authentication does not authorize every network function to call every API.

NDS/IP addresses protection between network domains and network elements using IP-layer security arrangements. A security gateway and its security associations protect a different boundary from NAS or PDCP. Check which link and traffic class a mechanism covers before describing the whole network as “encrypted.”

Roaming and perimeter protection

The serving network may be visited while the subscription credentials and home authentication functions remain in the home network. SEPPs protect service-based inter-PLMN signaling across N32. N32-c handles the control and security negotiation relationship; N32-f handles forwarding protection under the negotiated arrangement. The selected TLS or application-layer protection arrangement matters when intermediaries are involved.

SEPP does not encrypt the subscriber’s user-plane packets. User-plane perimeter controls, including the IPUPS function, address a separate boundary. Transport protection and application security remain relevant alongside those controls.

Non-3GPP access

For untrusted non-3GPP access, the UE uses the N3IWF and an IKEv2/IPsec-based access-security arrangement, with EAP-5G involved in the establishment procedure. Trusted non-3GPP access uses a different architecture and procedure, including the TNGF. “Trusted” describes the architectural access model; it does not mean the UE can omit authentication or that every packet is already protected.

References: TS 33.501, clauses 4.2, 7, 7A, 9, and 13; TS 33.210. Continue with Roaming and Interconnect Security, Network Domain Security, or Non-3GPP Access Security.

How to analyze a 5G security trace

Begin with the last verified successful stage and the capture point. An over-the-air trace, a decoded UE log, an N2 trace, and a core service log expose different parts of the same procedure. Correlate UE identities and timestamps before treating events in different logs as one security context.

Use the NAS message library for Authentication, Identity, and Security Mode fields, and the RRC message library for radio security messages. The security troubleshooting reference expands the failure branches.

Common interpretation errors

• “SUCI means all identity information is hidden.” Routing information remains available, and concealment depends on the selected scheme.
• “Authentication success means security activation completed.” NAS and AS activation are subsequent procedure states to verify.
• “NAS and RRC Security Mode are the same exchange.” They have different endpoints, messages, and working keys.
• “All packets before security activation must already be protected.” Initial access and initial NAS have defined exceptions and protection mechanisms; evaluate the actual message and state.
• “Every user-plane bearer has integrity protection.” Check the applicable policy, capabilities, and configured activation.
• “5G radio ciphering is end-to-end encryption.” Radio protection terminates at the gNB. Application protection can extend to a remote server.

Specification references

The first four references identify the exact Release 18 editions used for clause numbering on this page. The companion links provide edition directories. Diagrams are original explanatory views and omit branches explicitly identified in their captions; consult the normative specification for complete conditions and failure handling.

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

   Release 18 architecture baseline. Clauses 4–5: domains, entities, and requirements; 6.1: authentication; 6.2 and Annex A: keys; 6.4–6.7: signaling, user-plane protection, and security mode; 6.8–6.11: state changes and mobility; 6.12 and Annex C: subscriber privacy; 7 and 7A: non-3GPP access; 9: network interfaces; 13: service-based interfaces and interconnect.

2. 3GPP TS 24.501 V18.9.0 — NAS protocol for 5GS; Stage 3

   Release 18 NAS baseline. Clause 4.4: security contexts, COUNT, integrity, ciphering, and initial NAS protection; 5.4.1: authentication; 5.4.2: security mode control; 5.4.3: identification; clauses 8–9: message and information-element definitions.

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

   Release 18 RRC baseline. Clause 5.3.4: initial AS security activation; 5.3.5.7: AS security key update; 5.3.7: re-establishment; 5.3.13: resume; clause 6.2.2: RRC message definitions.

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

   Release 18 PDCP baseline. Clause 5.8: ciphering and deciphering; 5.9: integrity protection and verification. Use these with the RRC bearer configuration and 5GS user-plane security policy.

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

   Companion specification for NDS/IP, security domains, security gateways, and network-layer protection. The link lists published editions; select the edition applicable to the deployment.

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

   Companion system architecture reference for network functions, reference points, access types, and roaming models. The link lists published editions.

Frequently asked questions

Does successful 5G authentication mean all traffic is encrypted?

No. Authentication establishes trust and key material. NAS security, AS security, and user-plane security policy determine subsequent protection. A selected null ciphering algorithm provides no confidentiality, and application encryption has separate endpoints.

What is the difference between SUPI, SUCI, and 5G-GUTI?

SUPI is the permanent subscription identifier. SUCI is a representation used for concealed subscription identification, with privacy depending on the protection scheme. 5G-GUTI is an AMF-allocated temporary identity used to reduce repeated use of permanent subscription identification.

Does the gNB know the NAS security keys?

The gNB receives the access security material needed for its role, rather than the UE–AMF NAS working keys. It transports NAS messages between the UE and core while terminating its own access-stratum security relationship.

Is EAP-AKA prime only for Wi-Fi access?

No. 5G AKA and EAP-AKA prime are primary authentication methods in 5GS. The primary authentication method and the mechanism that secures a particular access are separate choices; EAP-5G on untrusted non-3GPP access is also distinct from EAP-AKA prime.

Why can NAS integrity fail when the key appears correct?

Integrity verification also depends on the selected algorithm, message bytes, direction, COUNT, and the correct active security context. A stale context or counter mismatch can produce failure even when the assumed key looks plausible.

Does this overview apply unchanged to every 5G deployment?

No. The main example is ordinary subscription-based access to 5GC using NR. EPC-anchored NSA, emergency access, interworking, non-public networks, and specialized access procedures have additional or different rules. Check the applicable specification version and procedure.