NSSAA

Network Slice-Specific Authentication and Authorization

Network Slicing →
Introduced in Rel-16 Also in: Security

NSSAA is a 5G security framework that performs slice-specific authentication and authorization, ensuring a user device is explicitly permitted to access a particular network slice beyond general network access.

Category
Network Slicing
Introduced
Rel-16
Where
Core Network › 5G Core
Also touches
1 segments
Specifications
12 specs
NSSAA Description Purpose Related Classification Detected Changes Specifications

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

Part ofNSSAAF
Specific typesNSSAAF
Related approachesNSSAIS-NSSAI

Release Timeline

Detected Changes Across Releases

from 3GPP Change Requests

Specific 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.

Rel-16 61 changes

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

Rel-17 37 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

Rel-18 12 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

Rel-19 1 change

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
Rel-20 1 change

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.

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.

SpecificationTitleRelease
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
Patrick Zandl

About the author: Patrick Zandl (b. 1974)

Telecommunications specialist, technology journalist (founder of the Mobil server), and developer who has been running since 2025 — the largest Czech-language resource on AI-assisted programming. Formerly Chief Wizard Architect at Prusa3D and head of development for Turris at CZ.NIC; currently a consultant and instructor on AI implementation in companies.