The three largest US carriers launched network-based authentication as a commercial product in July 2026. GSMA Open Gateway now covers 80% of the world's mobile connections. Enterprise buyers are asking for CAMARA-compliant SIM verification across every market they operate in.

For operators evaluating or deploying their own network-based authentication capability, understanding the underlying technical mechanism is not optional — it is what determines whether your infrastructure can support the product, what your entitlement server needs to do, and why the security properties of network-based authentication are architecturally superior to anything built on SMS OTP.

This blog explains the full technical stack for operators: from the cryptographic keys inside every SIM, through the EAP-AKA challenge-response protocol, to the TS.43 entitlement framework that orchestrates it, to the CAMARA API that exposes it as an enterprise product. It covers what your network already does, why it makes network-based authentication possible, and exactly what infrastructure you need to deploy to commercialise it.

WHO THIS IS FOR

This blog is written for MNO network architects, CTO/CDO teams, and API product managers responsible for evaluating or deploying network-based authentication. It assumes familiarity with HLR/HSS, Diameter, and USSD — but no prior knowledge of EAP-AKA or TS.43 is required.

‍

1. The Foundation: What Every SIM Already Contains

Every SIM ever manufactured for a GSM, UMTS, LTE, or 5G network contains two critical components relevant to network-based authentication: a permanent subscriber identity (the IMSI) and a secret authentication key (the Ki).

IMSI (International Mobile Subscriber Identity): The unique identifier that tells the network which subscriber this SIM belongs to. It is transmitted to the network during attachment and is used to look up the subscriber record in the HLR or HSS.

Ki (Authentication Key): A 128-bit secret key burned into the SIM at manufacture, specific to that SIM and that subscriber. The Ki is never transmitted over the air. It never leaves the SIM. A matching copy is held in the operator's Authentication Centre (AuC), which is integrated with the HLR or HSS.

This is the root of trust for all mobile authentication. The Ki cannot be extracted from the SIM — even an attacker with physical access to the device cannot read the Ki from the SIM chip. The carrier's AuC holds the matching key under HSM-protected storage. The only thing that ever moves between the network and the device is a cryptographic challenge and response — never the key itself.

Network-based authentication works because this infrastructure already exists, at massive scale, in every operator's network. The EAP-AKA protocol and the TS.43 entitlement framework are mechanisms for exposing this existing verification capability as an API product. They do not add new trust to the system — they expose the trust that was already there.

‍

KEY POINT

Your network has been authenticating every subscriber's SIM, continuously, since the day it was activated — for every call setup, every data session, every roaming event. Network-based authentication monetises that existing authentication capability as a per-verification API product. The trust infrastructure is not new. The revenue model is

‍

2. EAP-AKA: The Cryptographic Protocol Inside Network-Based Authentication

EAP-AKA (Extensible Authentication Protocol – Authentication and Key Agreement) is the cryptographic protocol standardised by the IETF (RFC 4187) that enables SIM-based authentication over any transport channel — including IP data networks, not just circuit-switched GSM signalling. It is EAP-AKA that makes network-based authentication possible over a data API call, rather than requiring a live voice or data session to be active.

EAP-AKA works through a challenge-response mechanism. The network issues a challenge to the SIM. The SIM computes a response using its on-device Ki key. The network verifies the response against the expected value computed from its copy of the Ki in the AuC. If the response matches, the SIM has proved it holds the legitimate key — without the key ever being transmitted.

The EAP-AKA Parameters

Understanding what gets generated and exchanged in an EAP-AKA transaction is useful for network architects evaluating entitlement server integration:

‍

‍

Why EAP-AKA is phishing-resistant: The RAND challenge is unique per authentication session — generated fresh each time. A response computed from one RAND cannot be replayed for a different session. An attacker who intercepts the RES value cannot reuse it. There is no code that passes through the user's hands. The proof of identity is mathematical and session-specific, making it architecturally impossible to phish or relay in real time.

This is the property that NIST SP 800-63B-4 requires for AAL2 phishing-resistance: the authenticator must cryptographically prove possession of a bound credential that cannot be relayed. EAP-AKA satisfies this. SMS OTP does not — a one-time code can be read by the user and relayed to an attacker in real time.

3. TS.43: The GSMA Framework That Makes EAP-AKA an API Product

EAP-AKA has existed since the 2000s. What GSMA TS.43 adds is the framework that makes EAP-AKA usable as an enterprise API product — specifically, it defines how a carrier's entitlement server orchestrates EAP-AKA challenges over a standardised data channel, enabling authentication to work without a live circuit-switched connection.

TS.43 (Service Entitlement Configuration, GSMA Release 11) defines the protocol between a device and a carrier's entitlement server. In the context of network-based authentication, TS.43 specifies how the entitlement server: (1) identifies the subscriber via their data connection, (2) requests an authentication vector from the HLR/HSS, (3) issues the EAP-AKA challenge to the device, and (4) verifies the device's response. The result — match or no-match — is then delivered to the CAMARA API layer, which returns it to the enterprise calling the API.

The Entitlement Server's Role

The entitlement server is the central piece of infrastructure that operators need to deploy to enable network-based authentication. It sits between the enterprise-facing CAMARA API layer and the operator's core network (HLR/HSS/AuC). It receives authentication requests from the CAMARA API, translates them into EAP-AKA challenges via TS.43, and routes the challenge through the network signalling path to the subscriber's device.

Operators without a TS.43 entitlement server cannot offer network-based authentication. This is the critical infrastructure dependency. Our entitlement server deployment guide for MNOs covers the deployment architecture, HLR/HSS integration, and Diameter signalling requirements in detail.

The Data Channel vs USSD Fallback

TS.43 defines two authentication paths. The primary path uses the device's data connection (LTE or 5G) to carry the EAP-AKA challenge-response exchange. This is the default path for 4G and 5G devices.

The secondary path uses USSD (Unstructured Supplementary Service Data) — the GSM signalling channel available on every mobile network from 2G upwards. When a subscriber is on a 2G or 3G network, or using a feature phone without a data-capable browser, the TS.43 USSD fallback channel carries the EAP-AKA exchange over USSD signalling instead of data.

For operators in emerging markets — where a significant portion of the subscriber base may be on 2G or 3G, or using feature phones — the USSD fallback is not optional. It is the difference between network-based authentication reaching your full subscriber base and reaching only your smartphone users. U2opia's SilentAuth+ is the only commercially deployed network-based authentication implementation that includes the TS.43 USSD fallback channel at full production scale.

‍

4. The Full Authentication Flow — Layer by Layer

Here is what happens at each layer of the network when an enterprise calls a network-based authentication API — from the API call to the SIM challenge to the result returned in under 300ms:

‍

‍

WHAT MAKES THIS INVISIBLE TO THE SUBSCRIBER

Steps 03 through 06 happen at network signalling level — between the carrier's core network and the SIM's secure element. The subscriber's device receives and responds to the EAP-AKA challenge without any user-facing notification, prompt, or action. There is no screen flash, no notification, no code. From the subscriber's perspective, authentication simply completes before the login has finished loading.

‍

5. USSD Fallback: Network-Based Authentication for Every Subscriber

The standard TS.43 data-channel path requires the subscriber's device to have an active data connection — at minimum HSPA (3G data). For 4G and 5G subscribers, this is always available. For 2G subscribers and feature-phone users, it may not be.

The USSD fallback path addresses this. USSD (Unstructured Supplementary Service Data) is a GSM-era signalling protocol that operates on the circuit-switched signalling plane — available on every mobile network, including 2G, without requiring a data session. USSD is what powers short codes, USSD menus, and mobile money services in markets where data connectivity is limited.

In the TS.43 USSD fallback path, the EAP-AKA challenge-response exchange is carried over USSD signalling rather than the data channel. The authentication mechanism is identical — the same EAP-AKA challenge, the same SIM key computation, the same XRES verification. The only difference is the transport layer.

For operators in South Asia, sub-Saharan Africa, and parts of Southeast Asia — where 2G and 3G penetration remains significant — the USSD fallback is what makes network-based authentication viable across the full subscriber base, not just the 4G/5G segment. Read more about how SilentAuth+ for operators implements the USSD fallback path and what it means for coverage reach.

‍

6. TS.43 on Wi-Fi: How NumberVerify2 Extends NBA Beyond Mobile Data

A subscriber on Wi-Fi — whether at home, in an office, or roaming abroad on a Wi-Fi-first plan — is not connected through the operator's mobile data network. The EAP-AKA challenge cannot be delivered via the usual data-channel path because there is no mobile data session to route it through.

GSMA TS.43 addresses this through a temporary token mechanism. When a subscriber authenticates over their mobile data connection, the entitlement server can issue a short-lived TS.43 token tied to that authentication event. This token can then be used to verify the subscriber's identity on a subsequent Wi-Fi session — within a defined validity window — without requiring a new EAP-AKA challenge.

This is the mechanism that NumberVerify2 (NV2) uses to extend network-based authentication to Wi-Fi sessions. NV2 combines the CAMARA Number Verification API specification with the CIBA (Client Initiated Backchannel Authentication) flow and the TS.43 temporary token to verify a subscriber's phone number even when they are off mobile data. This is a significant coverage extension for operators whose subscribers frequently switch between mobile data and Wi-Fi.

For operators, Wi-Fi extension matters commercially: it means network-based authentication can return a verified result for a larger fraction of API calls — including the growing share of subscriber sessions that happen on Wi-Fi — generating per-verification revenue on calls that would otherwise fail due to no mobile data connection.

7. Why EAP-AKA Satisfies NIST SP 800-63B-4 AAL2

NIST Special Publication 800-63B-4, finalized in July 2025, defines two key requirements for AAL2 (Authenticator Assurance Level 2) phishing-resistant authentication: the authenticator must use a cryptographic mechanism, and the proof of identity must be bound such that it cannot be relayed by the user to an attacker in real time.

EAP-AKA satisfies both requirements. The authentication is cryptographic — a challenge-response exchange using 128-bit keys. The proof (RES) is session-specific — computed from a fresh RAND challenge that is unique to this authentication event. It cannot be replayed for a different session, and it cannot be extracted from the SIM. There is no code, credential, or shareable secret that passes through the subscriber's hands — so there is nothing for an attacker to phish, relay, or intercept.

SMS OTP fails NIST AAL2 because the one-time code, once delivered to the subscriber, can be read and relayed to an attacker in real time — the subscriber themselves becomes the relay. NIST SP 800-63B-4 classifies SMS OTP as a 'restricted authenticator' that cannot satisfy AAL2 alone. For operators, this is a significant sales argument: every enterprise in US-regulated industries (financial services, healthcare, federal contracting) now has a compliance obligation to replace SMS OTP with an AAL2-compliant method. Network-based authentication is that method. See the forthcoming NIST 800-63B-4 operator playbook for the full compliance picture.

8. What Operators Need to Deploy: Infrastructure Checklist

For operators ready to deploy network-based authentication, here is the infrastructure required — with what each component does and why it is needed. U2opia's SilentAuth+ for operators provides or manages all of these components in the revenue-share deployment model.

‍

‍

Build vs partner: Operators building all of this from scratch typically face an 18–24 month deployment timeline and significant capex. SilentAuth+ for operators provides the entitlement server, HLR/HSS integration support, CAMARA compliance, USSD fallback, enterprise routing, and revenue settlement — on a revenue-share model with no upfront capex requirement. 104+ operators globally have deployed via this model.

9. Summary: The Technical Case for Network-Based Authentication

Network-based authentication is built on three decades of mobile network cryptography — EAP-AKA, the SIM Ki key, and the AuC/HLR/HSS subscriber record — that every operator's network already has. TS.43 provides the framework to orchestrate this into an API-accessible authentication product. CAMARA provides the standardised enterprise-facing interface. GSMA Open Gateway provides the distribution channel.

The technical properties that result — SIM-bound proof, non-replayable challenge-response, sub-300ms verification, 2G-to-5G coverage via USSD fallback — are not achievable by any SMS-based or app-based authentication method. They are native to the operator's network infrastructure, and they are what enterprises in regulated markets are now being mandated to adopt.

For operators, the opportunity is to commercialise what your network already does. The U2opia SilentAuth+ platform is the fastest path from existing network infrastructure to commercial network-based authentication revenue — across the U2opia authentication hub, including SIM swap detection and number verification.

‍

Frequently Asked Questions

‍

What is EAP-AKA and how does it authenticate a SIM?

EAP-AKA (Extensible Authentication Protocol – Authentication and Key Agreement) is an IETF-standardised protocol (RFC 4187) that performs SIM-based authentication using a cryptographic challenge-response mechanism. The network issues a random challenge (RAND) to the SIM. The SIM computes a response (RES) using its on-device authentication key (Ki) — a 128-bit secret that cannot be extracted from the SIM. The network's Authentication Centre computes the expected response (XRES) from its copy of Ki and compares it to the SIM's RES. A match confirms the SIM's identity without the key ever being transmitted. The challenge is unique per session, so EAP-AKA responses cannot be replayed or reused.
‍

What is TS.43 in mobile authentication?

TS.43 is the GSMA Service Entitlement Configuration standard (Release 11) that defines how a carrier's entitlement server orchestrates EAP-AKA authentication over a data channel — enabling network-based authentication to work as an IP-based API product rather than requiring a circuit-switched connection. TS.43 specifies the protocol between a subscriber's device and the operator's entitlement server, including the EAP-AKA challenge delivery, the USSD fallback mechanism for 2G/3G devices, and the temporary token mechanism that enables Wi-Fi session verification.

‍

What is an entitlement server in network-based authentication?

An entitlement server is the network infrastructure component that implements TS.43 — it receives authentication requests from the CAMARA API layer, queries the operator's HLR/HSS for subscriber authentication vectors, issues EAP-AKA challenges to subscriber devices, and verifies their responses. The entitlement server is the critical infrastructure dependency for operators deploying network-based authentication: without it, a carrier's network cannot process NBA API calls. See our entitlement server guide for MNOs for the full deployment architecture.

‍

Why does USSD fallback matter for network-based authentication?

The default TS.43 path carries EAP-AKA over the mobile data channel — which requires the subscriber to be on a 4G or 5G data connection. USSD fallback carries the same EAP-AKA challenge over the GSM signalling plane, which is available on every mobile network from 2G upwards, including feature phones without data browsers. For operators in emerging markets where a significant share of subscribers are on 2G/3G or feature phones, USSD fallback extends network-based authentication to the full subscriber base rather than only the smartphone segment. U2opia SilentAuth+ is the only commercial NBA implementation with USSD fallback at production scale.

‍

What infrastructure does an MNO need to deploy network-based authentication?

The core requirements are: (1) a TS.43 entitlement server connected to your HLR/HSS via Diameter; (2) a CAMARA Number Verification API layer exposing the entitlement server to enterprise callers; (3) optionally, a USSD gateway for 2G/3G fallback; (4) BSS billing integration for per-verification event rating; and (5) a distribution channel — either GSMA Open Gateway membership or a specialist aggregator like U2opia. SilentAuth+ for operators provides all of these on a revenue-share model with no upfront capex. Contact the U2opia operator partnerships team for a deployment assessment.

‍