Description
User Security Settings (USS) is a critical component within the 3GPP security architecture, specifically defined as part of the Generic User Security Settings (GUSS) framework. It represents a collection of security-related subscription parameters associated with a specific user. These settings are stored in the user's home network, typically within the Home Subscriber Server (HSS) or a Unified Data Management (UDM) function in 5G systems. The USS contains essential data required for authentication and key agreement (AKA) procedures, such as the long-term secret key (K), authentication algorithms (e.g., MILENAGE, TUAK), and key derivation parameters. When a user attempts to access the network, the serving network (e.g., VLR, SGSN, MME, AMF) requests authentication vectors from the home network. The home network uses the USS to generate these vectors, which include a random challenge (RAND), an expected response (XRES), a cipher key (CK), an integrity key (IK), and an authentication token (AUTN). The serving network then uses these vectors to challenge the user equipment (UE) and establish secure ciphering and integrity protection keys for the session.
The architecture for USS management involves interfaces between the HSS/UDM and other network functions. In legacy systems, the USS is accessed via the MAP or Diameter-based interfaces (e.g., Cx, S6a, S6d). In 5G, the UDM provides USS data to the Authentication Server Function (AUSF) and the Access and Mobility Management Function (AMF) via the Nudm service-based interface. The USS is not a monolithic block but can be structured to support different authentication methods and services. For instance, it may contain separate settings for 3G/4G AKA and 5G AKA, or for authentication to the IP Multimedia Subsystem (IMS). This modularity allows the network to apply appropriate security mechanisms based on the access technology and requested service.
The role of USS in the network is foundational for subscriber security. It ensures that each user is uniquely authenticated and that subsequent communications are protected. The integrity and confidentiality of the USS data are paramount, as compromise would allow impersonation and eavesdropping. Network functions never receive the long-term secret key (K) itself; instead, they receive derived authentication vectors, following the principle of never exposing the root secret outside the home domain. The USS also supports features like key freshness and sequence number management to prevent replay attacks. Its proper configuration and synchronization across network elements are essential for preventing authentication failures and service disruptions.
Purpose & Motivation
The USS exists to provide a standardized, secure, and manageable repository for user-specific security credentials within 3GPP networks. Prior to its formalization within the GUSS concept, security settings were often tightly coupled with other subscriber data, making it difficult to manage authentication for multiple services (e.g., circuit-switched, packet-switched, IMS) independently. This could lead to inefficiencies and potential security gaps when introducing new authentication methods or services. The USS framework was created to decouple security settings from other subscription data, enabling more flexible and robust security management.
The primary problem it solves is the need for a consistent and reliable source of truth for user authentication parameters across different network domains and generations. It addresses the challenge of supporting heterogeneous access technologies (2G, 3G, 4G, 5G, non-3GPP) and service platforms (IMS, MMTEL) with a unified security data model. By having a dedicated USS, operators can update security algorithms or key materials for a user or a service without affecting other aspects of the subscription. This is crucial for phased rollouts of new security standards (e.g., moving from 4G EPS-AKA to 5G AKA) and for providing service-specific authentication, enhancing overall network security posture.
Historically, as networks evolved from single-service voice to multi-service converged IP networks, the limitations of monolithic subscriber data management became apparent. The creation of USS, particularly as part of GUSS from 3GPP Release 7 onwards, was motivated by the need for a modular, future-proof security substrate. It allows the network to authenticate a user once and then leverage those credentials for access to multiple services (single sign-on concept for network access), improving user experience while maintaining stringent security. It forms the bedrock for secure mobility and service continuity in modern cellular networks.
Classification
Release Timeline
Detected Changes Across Releases
from 3GPP Change RequestsSpecific changes extracted from the „Change history“ tables of 3GPP specifications (39 CRs across 3 releases). Complements the general historical overview above with the evidence-based evolution of this function.
In Release 17, the USS function was enhanced to more formally associate a CAA-level UAV ID with the 3GPP UAV ID within the USS and to correctly handle this authorized identifier. The update also standardized the use of the USS FQDN as the service-level AA server address and refined USS-initiated procedures. Furthermore, the release focused on aligning terminology, such as consistently using "USS/UTM," and made editorial corrections to the handling of USS authorization.
- Alignment of the term "USS/UTM" throughout TS 23.255 TS 23.255CR0019
- USS Initiated procedures update TS 23.256CR0005
- Association of CAA level UAV ID to 3GPP UAV ID in USS TS 23.256CR0016
- Correction on handling the authorized CAA-Level UAV ID provided by a USS TS 23.256CR0055
- USS FQDN as service-level-AA server address TS 24.301CR3745
- Consistent term on USS communication TS 24.501CR3566
+ 3 more changes
In Release 18, the USS function was enhanced to support multi-USS deployments, introducing new capabilities for UAS registration and new procedures for multi-USS configuration and management. Specifically, the release added detailed procedures for a change of USS, including new information elements in related messages and a dedicated API to facilitate this change. Furthermore, the specifications were updated with the structure, data semantics, and XML schemas required to support both multi-USS configurations and the USS change support procedure.
- Requirements for support for multi-USS deployments TS 23.255CR0026
- Additions to functional entities on support for multi-USS deployments TS 23.255CR0029
- Addition of multi-USS capabilities to UAE layer registration TS 23.255CR0030
- Addition of procedures for multi-USS configuration and support at change of USS TS 23.255CR0031
- Addition of IEs to messages related with change of USS TS 23.255CR0034
- Addition of API for change of USS TS 23.255CR0035
+ 12 more changes
In Release 19, the USS function was enhanced to support the provisioning of multiple USS instances serving different geographical areas, including the definition of a new USS NTZ policy and procedures for USS discovery in such deployments. The release also introduced new NEF service operations for USS and specified how to provide lists of USS addresses to both the 5GS and EPS. Furthermore, the specifications were corrected and completed with details on the USS changeover procedure and the corresponding OpenAPI file.
- KI#1.2: Support for multiple USS serving different geographical areas TS 23.256CR0127
- KI#1.2: Adding a new NEF service operations for USS TS 23.256CR0128
- USS discovery in multiple USS deployment TS 23.256CR0130
- New USS NTZ policy TS 24.257CR0053
- List of USS addresses in EPS TS 24.301CR4114
- List of USS addresses in 5GS TS 24.501CR6450
+ 6 more changes
Explore further
Broader topics and technologies where USS plays a role.
Defining Specifications
3GPP specifications that define or reference USS, with the latest known release. Sourced from the 3GPP document catalog — see methodology.
| Specification | Title | Release |
|---|---|---|
| TR 22.843 vj20 | Study on Uncrewed Aerial Vehicle (UAV) Phase 3 | Rel-19 |
| TS 23.255 vj50 | UAS Application Layer Support | Rel-19 |
| TS 23.256 vj50 | UAS Support Architecture Enhancements | Rel-19 |
| TS 23.700 vk00 | XR Services Application Enablement Layer | Rel-20 |
| TR 23.755 vh00 | Study on app layer support for UAS | Rel-17 |
| TS 24.109 vj00 | HTTP Digest AKA & GAA Stage 3 | Rel-19 |
| TS 24.257 vj40 | UAS Application Enabler (UAE) Layer | Rel-19 |
| TS 24.301 vj60 | NAS protocol for Evolved Packet System | Rel-19 |
| TS 24.501 vj50 | 5G NAS Protocols Specification | Rel-19 |
| TS 27.007 vj40 | AT Command Set for UE | Rel-19 |
| TS 28.853 vj10 | Charging for Uncrewed Aerial Systems | Rel-19 |
| TS 29.109 vj00 | GAA Bootstrapping Interfaces (Zh, Dz, Zn, Zpn) | Rel-19 |
| TS 29.255 vj20 | USS Services for UAS in 5G | Rel-19 |
| TS 29.256 vj30 | UAS-NF Stage 3 Protocol Specification | Rel-19 |
| TS 29.257 vj40 | Application layer support for Uncrewed Aerial System (UAS) | Rel-19 |
| TS 29.274 vj50 | GTPv2-C Control Plane Protocol Specification | Rel-19 |
| TS 29.309 vj10 | Nbsp Service Based Interface for GBA BSF | Rel-19 |
| TS 29.502 vj50 | 5G System; Nsmf Service Based Interface; Stage 3 | Rel-19 |
| TS 31.121 vi50 | UICC-terminal interface test specification | Rel-18 |
| TS 32.808 v1800 | Common User Profile Storage Framework | Rel-8 |
| TS 33.110 vj00 | UICC-Terminal Key Establishment | Rel-19 |
| TS 33.220 vj00 | Generic Authentication Architecture (GAA); Generic Bootstrapping Architecture (GBA) | Rel-19 |
| TS 33.223 vj00 | GBA Push Function Specification | Rel-19 |
| TS 33.256 vj10 | Security for Uncrewed Aerial Systems (UAS) | Rel-19 |
| TS 33.259 vj00 | Key Establishment between UICC Hosting & Remote Device | Rel-19 |
| TR 33.854 vh10 | Security aspects of Uncrewed Aerial Systems | Rel-17 |
| TR 33.924 vj00 | GBA-OpenID Interworking Specification | Rel-19 |
| TR 33.980 vj00 | GAA & Liberty Alliance Interworking Guidelines | Rel-19 |
| TS 38.213 vj10 | NR Physical Layer Control Procedures | Rel-19 |
| TS 38.523 vj20 | 5G NR UE Conformance Testing: Idle/Inactive | Rel-19 |