IQF

Identity Query Function

Security →
Introduced in Rel-16

IQF is a 5G network function that provides privacy-preserving identity verification by allowing other functions to query if a concealed subscriber identifier corresponds to a valid subscription.

Category
Security
Introduced
Rel-16
Where
Core Network › 5G Core
Specifications
2 specs
IQF Description Purpose Related Classification Detected Changes Specifications

Description

The Identity Query Function (IQF) is a security function introduced in 3GPP Release 16 as part of the enhanced 5G security architecture. It operates within the home Public Land Mobile Network (HPLMN) and serves as a critical privacy safeguard. Its primary role is to process queries about concealed user identities. In 5G, to protect user privacy, the permanent subscriber identifier (SUPI) is never sent in clear text over the air. Instead, the UE sends a Subscription Concealed Identifier (SUCI), which is an encrypted form of the SUPI. The IQF provides a way for other authorized network functions to validate this SUCI without those functions ever being exposed to the plaintext SUPI.

Architecturally, the IQF is a standalone Network Function (NF) that exposes a service-based interface, typically based on HTTP/2. It interacts primarily with the Unified Data Management (UDM) and the Authentication Server Function (AUSF). When a consuming NF (such as a Network Exposure Function (NEF) or a Service Communication Proxy (SCP)) receives a service request containing a SUCI, it may need to verify the user's subscription status before proceeding. Instead of decrypting the SUCI itself (which would require the home network's private key), the consuming NF sends an identity query request to the IQF. This request contains the SUCI and the context of the query.

The IQF processes this request by first decrypting the SUCI to retrieve the SUPI. This decryption is performed securely within the IQF's trusted environment using the home network's private key. The IQF then performs a lookup in the UDM to verify the subscription status associated with that SUPI. Crucially, the IQF does not return the SUPI to the requesting NF. Instead, it returns a binary response (e.g., valid/invalid) or a token attesting to the validity of the subscription. This process ensures that the consuming NF can authorize a service request based on a valid identity, while the principle of subscriber identity confidentiality is maintained. The SUPI remains known only to the UE, the AUSF (during authentication), and the UDM/IQF within the home network.

Purpose & Motivation

The IQF was created to resolve a tension between service authorization and user privacy in 5G networks. 5G introduced strong subscriber identity privacy by mandating the use of SUCI over the air interface. However, many network services and exposure APIs require knowledge of a user's subscription status to authorize requests. Prior to IQF, network functions that needed to validate a user had to either handle the SUCI themselves (compromising the privacy boundary) or rely on indirect methods that were inefficient or insecure. For example, a third-party application server accessing the network via the NEF might receive a SUCI and need to check if the user is a valid customer.

The IQF provides a standardized, secure, and privacy-preserving solution to this problem. It establishes a clear functional separation: the IQF is the only entity (besides the AUSF during primary authentication) that decrypts SUCI within the network core. This centralizes the handling of the sensitive private key and minimizes the attack surface. It enables new business models and network exposure scenarios where external or internal service providers can verify user legitimacy without learning their permanent identity, thus upholding the stringent privacy requirements of GDPR and similar regulations. The IQF is a key enabler for secure service-based architecture (SBA) operations in scenarios involving concealed identifiers.

Classification

Part ofUDM
Related approachesAUSFNEF

Release Timeline

Detected Changes Across Releases

from 3GPP Change Requests

Specific changes extracted from the „Change history“ tables of 3GPP specifications (3 CRs across 2 releases). Complements the general historical overview above with the evidence-based evolution of this function.

Studied in Rel-16, normative work from Rel-17.

Rel-17 1 change

In Release 17, the primary change for the Identity Query Function (IQF) was the clarification and correction of inconsistent use of terminology related to the IEF, ICF, and IQF functions themselves. This ensured consistent naming across the specification for these key Lawful Interception functions and their defined interfaces, such as LI_IQF, LI_XQR, and LI_HIQR. No new interfaces or technical procedures for the IQF were introduced beyond this terminology harmonization.

  • Inconsistent use of IEF, ICF and IQF terminology TS 33.127CR0165
Rel-18 2 changes

In Release 18, the key enhancement for the Identity Query Function (IQF) was the addition of Cell Site Information (CSI) to its query responses. This new capability, as specified in clause 5.7.1, allows the IQF to provide CSI data to the Law Enforcement Agency (LEA) over the LI_HIQR interface when responding to identifier association queries.

  • Addition of Cell Site Information for IQF responses. TS 33.127CR0245
  • Addition of Cell Site Information for IQF responses. TS 33.128CR0668

Explore further

Broader topics and technologies where IQF plays a role.

Defining Specifications

3GPP specifications that define or reference IQF, with the latest known release. Sourced from the 3GPP document catalog — see methodology.

SpecificationTitleRelease
TS 33.127 vj50 Lawful Interception Architecture and Functions Rel-19
TS 33.128 vj50 3GPP TS 33.128: Lawful Interception Protocols Rel-19
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.