Description
Network Slice-Specific Authentication and Authorization (NSSAA) is a critical security mechanism introduced in 3GPP Release 16 to complement the primary authentication and authorization performed by the Authentication Server Function (AUSF). While primary authentication verifies the UE's identity for the 5G Core Network (5GC) as a whole, NSSAA provides an additional, granular layer of security for individual network slices. This is essential because different slices may have vastly different security requirements, business models, and trust domains. For instance, a slice for massive IoT sensors may have different security postures compared to a slice for ultra-reliable low-latency communication (URLLC) in industrial automation. NSSAA ensures that access to a high-security slice is not granted based solely on credentials valid for a lower-security slice.
The NSSAA procedure is typically triggered after successful primary authentication when a UE requests a network slice that requires slice-specific authentication, as indicated by the Subscribed Network Slice Selection Assistance Information (S-NSSAI). The procedure is orchestrated by the Network Slice-Specific Authentication and Authorization Function (NSSAAF), which acts as an intermediary. The NSSAAF receives an authentication request from the Access and Mobility Management Function (AMF) and communicates with external, slice-specific Authentication, Authorization, and Accounting (AAA) servers. These external AAA servers are considered part of the slice tenant's domain and are responsible for evaluating the UE's credentials against policies specific to that slice. The communication between the NSSAAF and the external AAA server can use protocols like the Extensible Authentication Protocol (EAP), allowing for a wide range of authentication methods (EAP-AKA', EAP-TLS, etc.) as defined by the slice provider.
The architecture involves several 5GC network functions. The AMF is the main point of contact, initiating the procedure upon slice request. The NSSAAF, a dedicated logical function, can be deployed as a standalone Network Function (NF) or co-located with another NF like the AUSF. It interfaces with the external AAA server via the N33 reference point. The Unified Data Management (UDM) may store indications of which S-NSSAIs require NSSAA for a given subscriber. The procedure's result (success, failure, or on-going) is conveyed back to the AMF, which then allows or denies the UE's registration for the requested slice. A key aspect is that NSSAA can run in parallel for multiple slices, and its failure for one slice does not necessarily impact the UE's registration for other, already authorized slices. This provides flexibility and maintains service continuity where possible.
Purpose & Motivation
NSSAA was created to address the security and business model challenges inherent in network slicing. Prior to its introduction in Release 16, network slice access control was primarily based on subscription data stored in the UDM, which could indicate whether a subscriber was allowed to use a slice. However, this was a simple binary check and did not support dynamic, real-time authentication and authorization decisions that might involve external credentials or tenant-specific policies. This limitation was a significant barrier for enterprises and vertical industries wishing to operate their own slices with their own identity management systems.
The primary problem NSSAA solves is the need for enhanced security isolation between slices. In a shared physical infrastructure, it is paramount to ensure that a compromise or weak authentication in one slice does not become a vector to access a more sensitive slice. By delegating the final authorization decision to an external AAA server controlled by the slice tenant, NSSAA enables strong, domain-specific authentication. This is crucial for business models where a Mobile Network Operator (MNO) provides network-as-a-service to third-party enterprises. The enterprise can retain control over which of its devices or users are allowed onto its dedicated slice, using its existing corporate credentials and security policies, without the MNO needing to manage those identities directly. This separation of concerns facilitates the commercialization of network slicing.
Classification
Release Timeline
Detected Changes Across Releases
from 3GPP Change RequestsSpecific changes extracted from the „Change history“ tables of 3GPP specifications (112 CRs across 5 releases). Complements the general historical overview above with the evidence-based evolution of this function.
In Release 16, the NSSAA function introduced the concept of a "Pending NSSAI" to manage S-NSSAIs undergoing slice-specific authentication, requiring the UE to wait for procedure completion before using associated services. The release specified detailed handling for roaming scenarios, including updates to the Rejected NSSAI IE for failure cases and clarifications on AAA server addressing. It also defined UE behavior for re-attempting requests after NSSAA failure or revocation and mandated that the AMF indicate its NSSAA capability.
- "S-NSSAI not available in the current PLMN" when non NSSAA supported UE requesting the S-NSSAI subjects to NSSAA TS 24.501CR1598
- NSSAI storage impact with NSSAA TS 24.501CR1602
- Introduction of pending NSSAI for network slice-specific authentication and authorization TS 24.501CR1505
- Deleting Editors note regarding indefinite wait at the UE for NSSAA completion TS 24.501CR1912
- Updating requirements of NSSAA for roaming scenarios TS 24.501CR2059
- Updating Rejected NSSAI IE for failed NSSAA case in roaming scenerios TS 24.501CR2108
+ 55 more changes
In Release 17, enhancements to NSSAA introduced the capability for **remote provisioning of credentials** for the authentication procedure. The release also added clarifications and procedural handling for scenarios such as **radio link failure during NSSAA**, **AMF behavior after NSSAA failure**, and the management of the **Allowed and Pending NSSAI** upon procedure initiation or failure. Furthermore, it defined UE behavior for **re-initiation of NSSAA** and handling of **PDU session establishment requests** during an ongoing re-authentication.
- Remote provisioning of credentials for NSSAA or secondary authentication/authorisation TS 23.501CR2714
- Clarification of the UCU procedure upon completion of NSSAA TS 24.501CR3570
- Allowed NSSAI when NSSAA fails TS 23.501CR2923
- Redirection to dedicated frequency band(s) at the end of NSSAA TS 23.501CR3067
- Correction on remote provisioning of credentials for NSSAA or secondary authentication/authorization TS 23.501CR3146
- Correction on remote provisioning of credentials for NSSAA or secondary authentication/authorization TS 23.501CR3277
+ 31 more changes
In Release 18, the NSSAA function was enhanced with clarifications and new handling procedures, including the explicit provision of a Partially Allowed NSSAI to the UE post-authorization and refined collision handling between NSSAA and other procedures like Service Request. The release also introduced more detailed rules for managing re-NSSAA, network slice replacement scenarios, and the storage of rejected NSSAI associated with Equivalent PLMNs. Furthermore, corrections and clarifications were made to the Nnssaaf_NSSAA API and the triggers for NSSAA message content.
- The AMF sends the partially allowed NSSAI to the UE after NSSAA TS 24.501CR5433
- Clarifications about the Alternative S-NSSAI subject to NSSAA TS 23.501CR5170
- Handling of re-NSSAA or network slice-specific authorization revocation result TS 24.501CR4528
- Alignment of term re-NSSAA TS 24.501CR4529
- NSSAA and SR procedure collision handling TS 24.501CR4747
- Store the rejected NSSAI for failed or revoked NSSAA associated with EPLMN TS 24.501CR5152
+ 6 more changes
In Release 19, the NSSAA function was enhanced to ensure service request procedures for emergency services fallback can be performed while the network is executing the Network Slice-Specific Authentication and Authorization. This allows critical emergency access to proceed even when the slice-specific EAP-based authorization procedure for other S-NSSAIs is pending or ongoing.
- Performing service request for emergency services fallback when the network is performing NSSAA TS 24.501CR6397
In Release 20, the key enhancement for the Network Slice-Specific Authentication and Authorization (NSSAA) function was the introduction of NSSAA over EPC, enabling this procedure for PDN connections in EPS. This allows a UE, by indicating support in the PCO, to use an S-NSSAI subject to NSSAA for a PDN connection when the SMF+PGW-C selects it.
- Introducing NSSAA over EPC TS 23.501CR6451
Explore further
Broader topics and technologies where NSSAA plays a role.
Defining Specifications
3GPP specifications that define or reference NSSAA, with the latest known release. Sourced from the 3GPP document catalog — see methodology.
| Specification | Title | Release |
|---|---|---|
| TS 23.501 vk00 | 5G System Architecture Stage 2 | Rel-20 |
| TS 24.501 vj50 | 5G NAS Protocols Specification | Rel-19 |
| TS 28.204 vi11 | Charging management | Rel-18 |
| TS 29.518 vj50 | AMF Service Based Interface Protocol | Rel-19 |
| TS 29.526 vj30 | Nnssaaf Service Based Interface Stage 3 | Rel-19 |
| TS 29.571 vj50 | Common Data Types for 5G Service Based Interfaces | Rel-19 |
| TS 31.105 vj10 | Slice Subscriber Identity Module (SSIM) Application | Rel-19 |
| TR 31.826 vi00 | Technical Report | Rel-18 |
| TS 32.291 vj40 | Charging Management: Service-Based Interface Protocol | Rel-19 |
| TR 32.847 vi00 | Technical Report | Rel-18 |
| TS 33.501 vk00 | 5G Security Architecture and Procedures | Rel-20 |
| TS 33.700 | 3GPP TR 33.700 | Rel-16 |