What Is an Entitlement Server?

An entitlement server (also called an Entitlement Configuration Server or ECS) is a core network function deployed by a mobile network operator that determines which services each SIM card is permitted to use — and delivers the configuration required to activate those services on the subscriber's device.

When a device powers on or connects to a new network, it queries the entitlement server. The server authenticates the SIM using EAP-AKA (the same cryptographic protocol used for network attach), checks the subscriber's plan and policy, and returns a signed configuration response: which services are active, which are blocked, and what parameters govern each.

Services managed by a TS.43-compliant entitlement server include: VoWiFi, VoLTE, VoNR, SMS over IP, eSIM provisioning (ODSA), companion device pairing, satellite messaging, Direct Carrier Billing, silent network authentication, and 5G network slice access.

‍

The Entitlement Gap — The Network Problem No One Talks About

Here is a scenario that plays out millions of times a day across mobile networks worldwide. A subscriber's iPhone arrives at a new location, switches to Wi-Fi, and tries to place a call using VoWiFi. The feature exists. The subscriber's plan includes it. The device supports it. The operator has deployed it. And yet — the call fails. The device presents a generic error. The subscriber calls support. Support cannot reproduce the issue. The ticket closes without resolution.

The cause, more often than not, is an entitlement server failure — or the absence of one. The device never received confirmation that it was authorised to use VoWiFi on that network, in that configuration, for that subscriber. Without that confirmation, iOS and Android devices do not activate the service. The capability exists in the network. The subscriber has paid for it. But the entitlement bridge between the two is broken or missing.

This is what the industry calls the entitlement gap — and in 2026, it is more commercially consequential than at any point in mobile history. With 350+ operators worldwide supporting VoWiFi (up from 120 in 2018), eSIM-enabled device shipments exceeding 633 million in 2026, satellite messaging coming to consumer devices, and CAMARA APIs creating new per-authentication revenue lines, the entitlement server has evolved from a backend device-pairing utility into the central policy and monetisation layer of a modern mobile network.

Operators that have not deployed a compliant, production-grade entitlement server are not just failing to activate services — they are leaving measurable revenue on the table while their subscribers encounter preventable friction. This guide explains exactly what an entitlement server is, what GSMA TS.43 mandates, how the authentication flow works, what use cases it enables, and what the deployment and revenue picture looks like in 2026.

Section 1: The Five Core Functions of an Entitlement Server

An entitlement server is not a monolithic product — it is a set of functions that work together to govern service access and configuration at the device level. Understanding each function clarifies where entitlement fits in the operator's network architecture and why each function matters commercially.

1. Device and SIM Authentication

Before any service configuration is delivered, the entitlement server must confirm that the device making the request is genuine and that the SIM inside it belongs to an active subscriber. This happens via EAP-AKA — the cryptographic challenge-response protocol already running in the operator's HLR/HSS for network attach. The entitlement server leverages the same authentication infrastructure, issuing a challenge that only the SIM's Ki (secret key) can answer correctly. This exchange produces a short-lived session token. No password, no user action, no OTP. The device is authenticated silently in milliseconds. See From EAP-AKA to Access Token for a deep dive into the full token issuance flow.

2. Subscriber Eligibility Verification

Once the SIM is authenticated, the entitlement server queries the operator's BSS (typically via an API to the subscription management layer) to determine what the subscriber is entitled to. Is VoWiFi included in their plan? Has the subscriber opted in? Is the service geographically restricted for roaming users? Are there device-level restrictions (e.g., eSIM not available on prepaid)? The entitlement server evaluates all of these conditions and produces an entitlement decision — allowed, denied, or conditionally allowed with specific parameters.

3. Service Configuration Delivery

For entitled services, the entitlement server returns a signed configuration response to the device. This response is not just a yes/no — it includes the specific parameters the device needs to activate the service: IMS core addresses for VoWiFi, SIP credentials, provisioning endpoints for eSIM ODSA, APN settings, and service-specific policy flags. The device's operating system (iOS or Android) processes this configuration and activates the service accordingly. Without this configuration, the device does not know how to connect to the service — even if the network is ready.

4. Entitlement Lifecycle Management

Entitlement is not a one-time event. When a subscriber upgrades their plan, the entitlement must be updated. When they roam to a partner network, their VoWiFi entitlement may change. When they add a companion device, that device needs its own entitlement. When their SIM is swapped, the previous device's session token must be invalidated. The entitlement server manages this lifecycle — processing real-time updates from BSS, handling expiry and re-entitlement flows, and managing multi-device entitlement state across a subscriber's portfolio of devices.

5. API Token Issuance for Network Capabilities

The most commercially significant function in 2026 is the entitlement server's role as a network capability API gateway. When an enterprise application calls U2opia's SilentAuth+ or NumberVerify2 APIs to silently verify a subscriber, the entitlement server is the component that issues the EAP-AKA-derived token. This token confirms subscriber identity to the enterprise — without any user action, OTP, or credential transmission. The entitlement server is what makes operator network intelligence programmable for external consumption via CAMARA APIs.

‍

Section 2: TS.43 — The GSMA Specification Every Operator Must Know

GSMA TS.43 (Service Entitlement Configuration)

TS.43 is the GSMA technical specification that defines the protocol, security model, and API contract between a device's entitlement client and the operator's Entitlement Configuration Server (ECS). It ensures that devices from any manufacturer — Apple, Samsung, Google, or any Android OEM — communicate with operator entitlement servers in a standardised, interoperable way.

TS.43 compliance is a prerequisite for Apple iOS entitlement support and is required by Samsung for certain Android VoWiFi and eSIM features. Without TS.43 compliance, operators cannot reliably activate entitlement-dependent services on the devices their subscribers use.

‍

Version History and the 2025 Expansion

TS.43 has evolved significantly from its original scope. The specification has gone through multiple major revisions, each expanding the services covered and the network scenarios supported.

The 2025 amendment is commercially significant: previously, TS.43 entitlement flows required the device to be on cellular data to carry the EAP-AKA signalling exchange. The 2025 update introduced Wi-Fi-native entitlement — meaning devices can complete entitlement and authentication flows without a cellular data connection. This is the technical foundation for NumberVerify2's Wi-Fi verification capability and for extending silent authentication coverage to users who are predominantly on Wi-Fi. See GSMA TS.43 v12.0 specification for the full technical detail. For how TS.43 relates to adjacent GSMA and 3GPP specs including RCC.14, IR.51 and IR.92, see this U2opia reference guide.
‍

What TS.43 Mandates — and What It Does Not

TS.43 mandates the API contract and security model between the device client and the entitlement server. It does not prescribe the entitlement server's internal architecture, BSS integration method, or database structure. This means operators have flexibility in how they build or procure their entitlement server — but they must ensure the external interface presented to devices conforms exactly to the TS.43 specification, including authentication flow, response schema, error handling, and token lifecycle management.

Non-compliant implementations — whether due to incomplete TS.43 coverage, incorrect error handling, or missing token refresh logic — result in device-level service activation failures. What Happens When an Entitlement Server Is Unreachable documents the full failure taxonomy and what each error state means for service availability.

Section 3: How EAP-AKA Authentication Works Inside a TS.43 Entitlement Server

DEFINITION: EAP-AKA (Extensible Authentication Protocol – Authentication and Key Agreement)

EAP-AKA is the IETF-standardised authentication protocol (RFC 4187) used in 3GPP mobile networks to authenticate subscribers using credentials stored on their USIM. It performs a cryptographic challenge-response exchange: the network generates a random challenge (RAND), the SIM computes a response (RES) using its secret key (Ki) and the RAND, and the network validates RES against its own computation. Neither the Ki nor any password is transmitted — only the challenge and response.

EAP-AKA is inherently phishing-proof, replay-proof, and immune to SMS-based attacks because no human-readable secret is involved. The SIM hardware is the authenticator.

Inside a TS.43 entitlement server, EAP-AKA serves as the first layer of a two-stage authentication-and-authorisation flow. Here is the exact sequence:

1. Device initiates entitlement request. The device's entitlement client sends an HTTP request to the operator's entitlement server URL (configured by the OEM or pre-loaded). The request includes the SIM's IMSI and the service the device is requesting configuration for (e.g., VoWiFi).

2. Entitlement server issues EAP-AKA challenge. The server queries the operator's HLR/HSS using a standard Diameter interface (Cx/Dx or SWx), retrieves the authentication vectors for the IMSI, and returns an EAP-AKA challenge (RAND + AUTN) to the device.

3. SIM computes the response. The device passes the challenge to the USIM application on the SIM. The USIM computes RES using the Ki and RAND. The device returns RES to the entitlement server.

4. Entitlement server validates and creates session. The server compares the received RES against its own XRES (expected response, computed from the same authentication vectors). On match, the SIM is authenticated. The server creates a short-lived session token (typically JWT or similar) bound to the IMSI and device.

5. Entitlement response delivered. The server queries BSS for subscriber eligibility, computes the entitlement decision, and returns a signed configuration response with the session token. The device stores the token and activates the services specified in the response. Token refresh is triggered on session expiry or plan change.

This five-step flow completes in under 300 milliseconds under normal network conditions. The device receives its service configuration silently — no user prompt, no credential entry, no OTP. This is exactly the mechanism that powers SilentAuth+ silent authentication: when an enterprise calls the API to verify subscriber identity, the entitlement server performs steps 1–4 on the operator's behalf and returns the EAP-AKA result as a verification signal to the enterprise application.

‍

Section 4: Six Use Cases Operators Are Running in Production Today

The entitlement server is not a single-purpose network function. In production deployments, it manages service access across six distinct use cases — each generating its own operational value and, increasingly, its own revenue line.

‍

The VoWiFi Case — Why It Remains the Largest Production Deployment

VoWiFi is where most operators first deployed an entitlement server — and the numbers show why it matters. As of 2025, more than 350 mobile network operators support VoWiFi globally, up from 120 in 2018 — a 191% increase in eight years. The global VoWiFi market was valued at $9.59 billion in 2025, growing at a CAGR exceeding 18%. Over 6.8 billion smartphones worldwide now include VoWiFi capability. Every single one of those VoWiFi sessions on iOS and Android devices passes through an entitlement check before the IMS registration is attempted. An entitlement failure means a failed call, a frustrated subscriber, and a support ticket — at scale. Operators running VoWiFi without a compliant, highly-available entitlement server are operating at risk on their largest advanced voice deployment.

‍

The eSIM Case — The Fastest-Growing Entitlement Surface

eSIM is the fastest-growing workload for entitlement servers. ABI Research forecasts 633 million eSIM-enabled device shipments in 2026, with GSMA Intelligence projecting global eSIM smartphone connections reaching 4.9 billion by 2030 — representing 55% of all smartphone connections. Every eSIM activation requires an entitlement step: the device must authenticate, confirm eligibility for eSIM provisioning (plan, geography, device compatibility), and receive the SM-DP+ endpoint and activation token. Without a production-grade entitlement server handling ODSA flows, eSIM activations fail at scale — precisely at the moment when subscriber intent and operator revenue opportunity align. For operators still using manual or semi-automated eSIM provisioning paths, entitlement server deployment is the single highest-impact infrastructure investment available.

‍

The Silent Authentication Case — The New Revenue Line

Silent network authentication via CAMARA APIs is the newest and commercially most forward-looking entitlement use case. When an enterprise application calls the NumberVerify2 API or SilentAuth+, the entitlement server performs EAP-AKA authentication and returns the result to the enterprise — via U2opia's platform and GSMA Open Gateway — as a verification signal. The enterprise pays per verification. The operator receives a revenue share. The subscriber sees nothing. For operators, this represents authentication-as-a-service: monetising the EAP-AKA capability that was previously only used for network attach and service entitlement. The Number Verification API market was valued at $3.8 billion in 2025 and is projected to reach $11.2 billion by 2034. The entitlement server's token issuance function is what enables operators to participate in that market.

‍

Section 5: The September 2025 Signal — GSMA Launches Entitlements-as-a-Service

On September 4, 2025, the GSMA made the most significant public investment in operator entitlement infrastructure in the specification's history. In partnership with telecom software company NetLync, the GSMA launched GSMA Entitlements — a cloud-based, TS.43-compliant entitlement platform positioned explicitly as Entitlements-as-a-Service. The announcement cited capabilities including eSIM Transfer, Satellite messaging, Cross RCS, 5G data management, VoWiFi, and companion device support — the full scope of what a modern entitlement server needs to manage. Critically, the GSMA press release noted that operators who trialled the service integrated it into their OSS/BSS stack in under four weeks, using two to three developers. That is a dramatic reduction from the 3–6 month integration timelines that have historically characterised entitlement server deployments.

The GSMA's direct entry into the entitlement market sends three clear signals to operators. First, TS.43 entitlement is now considered foundational infrastructure — not an optional enhancement. Second, the market has matured to the point where a standards body has productised a reference implementation. Third, the industry has recognised that deployment complexity was the primary barrier to operator adoption, and that a hosted, low-integration-effort model is the path to scale.

The Mobile Ecosystem Forum reinforced this trajectory in April 2026, publishing analysis confirming that TS.43 is the key enabler of silent authentication and the mechanism through which operators will expose their network intelligence commercially. See MEF's April 2026 analysis for the full industry perspective on TS.43's authentication role.

‍

Section 6: The Revenue Equation — From Infrastructure Cost to Monetisation Engine

For most of its operational life, the entitlement server was accounted for as a cost centre: infrastructure required to activate services that subscribers had already paid for. In 2026, that framing is obsolete. The entitlement server is the revenue-generating component at the centre of three of the highest-growth markets in the operator ecosystem.

‍

‍

The commercial logic is straightforward. Every service the entitlement server manages is either directly monetised per event (silent authentication API calls), indirectly monetised via service revenue (VoWiFi ARPU uplift, eSIM activation fees), or competitively critical (companion devices, 5G slicing). An operator without a production-grade entitlement server is unable to realise value from any of these categories at scale. U2opia's SilentAuth+ for Operators guide covers the full per-verification revenue model and GSMA Open Gateway commercial framework in detail, including an illustrative revenue calculator for operators of different subscriber scale. And for a deeper view of how silent authentication drives MNO revenue, see our MNO silent authentication revenue guide.
‍

The VoWiFi Revenue Equation — Why Entitlement Quality Drives ARPU

VoWiFi increases mobile usage on Wi-Fi — reducing the churn risk of subscribers who primarily use data-only connectivity and increasing voice ARPU for operators with usage-based voice plans. But VoWiFi ARPU uplift is only realised when the service activates reliably. An entitlement server that produces intermittent activation failures — due to TS.43 non-compliance, timeout issues, or BSS query failures — degrades VoWiFi reliability below the threshold at which subscribers adopt it as their primary voice path. Reliable entitlement is, in the VoWiFi case, a direct prerequisite for ARPU realisation.

‍

Section 7: Deployment Options for MNOs — Cloud, On-Network, and Hybrid

Operators evaluating entitlement server deployment in 2026 have three architectural options. The right choice depends on data residency requirements, internal NF deployment capability, existing BSS/OSS architecture, and time-to-revenue targets.

Option 1: Cloud-Hosted / Entitlements-as-a-Service (Fastest to Deploy)

The vendor deploys and operates the TS.43-compliant entitlement server on cloud infrastructure, connecting to the operator's HLR/HSS via Diameter (SWx/Cx/Dx) or REST interfaces. The operator's subscriber data stays on-network — only authentication vectors and entitlement results cross the interface. No new network functions are deployed by the operator. BSS integration typically completes in 4–8 weeks. This is the model used by GSMA Entitlements (NetLync) and by U2opia's hosted deployment path. Recommended for operators prioritising speed-to-market and lowest initial investment.

Option 2: On-Network / Operator-Deployed NF

The entitlement server NF runs on the operator's own infrastructure — cloud-native deployment on the operator's CNF platform or on-premise hardware. All subscriber identity processing remains fully on-network. Full data sovereignty. The operator controls upgrade cycles, capacity scaling, and BSS integration depth. Recommended for operators with strict data residency requirements, large subscriber bases where on-network processing is economically justified, or operators with existing CNF deployment capability. Typical deployment timeline: 12–20 weeks including internal NF provisioning and acceptance testing.

Option 3: Hybrid

The entitlement logic runs on-network for primary subscribers and on-cloud for roaming, MVNO, or secondary device flows. Allows operators to maintain data sovereignty for domestic subscribers while handling complex roaming entitlement scenarios through a managed service layer. U2opia's architecture supports hybrid deployment — see the TS.43 deployment checklist for the full deployment option decision framework and infrastructure requirements for each model.

OEM Compliance Requirements

Regardless of deployment model, the entitlement server must pass OEM certification for Apple iOS and Samsung Android to ensure device-level service activation. Apple requires TS.43 compliance and specific response schema versions for VoWiFi, eSIM, and wearable entitlement. Samsung requires TS.43 compliance plus Samsung-specific extension headers for certain Galaxy device features. Full OEM certification detail is covered in How Entitlement Servers Support Apple and Samsung Devices. For a step-by-step implementation guide covering HLR/HSS integration, BSS connectivity, and OEM certification, see How to Implement an Entitlement Server (TS.43).

‍

Section 8: Five Questions Every MNO Should Ask Before Choosing an Entitlement Server

• Does it cover the full TS.43 v12.0 specification? Including Wi-Fi-native entitlement, satellite messaging, and the 2025 amendment additions. Partial TS.43 implementations will block activation on the latest OEM firmware versions.

• What is the HLR/HSS integration model? Does it support your existing Diameter interfaces (SWx, Cx, Dx)? Does it support REST-based HSS interfaces for 5G SA cores? Can it handle multiple HLR/HSS instances for roaming partners?

• What is the availability and failover architecture? Entitlement servers are on the critical path for VoWiFi registration and eSIM activation. Downtime means service outages. What are the SLA commitments, geographic redundancy provisions, and failover RTO/RPO targets? See what happens when an entitlement server is unreachable for the failure taxonomy.

• Does it support CAMARA API token issuance for Open Gateway revenue? A TS.43 entitlement server that only manages VoWiFi and eSIM, but does not expose EAP-AKA token issuance for CAMARA API calls, will not generate the per-verification revenue available via GSMA Open Gateway. Confirm CAMARA integration explicitly.

• What is the BSS integration depth? Real-time BSS queries are required for accurate entitlement decisions (plan changes, opt-ins, geographic restrictions). A server that uses cached subscription data will produce entitlement errors after plan changes. Confirm real-time BSS connectivity and update latency.

‍

Frequently Asked Questions

What is the difference between an entitlement server and an authorisation server?

An authorisation server (in OAuth/OIDC terms) grants access tokens for API resources based on user identity and consent. An entitlement server in the telecom context is a network function that determines which services a SIM card is permitted to use and delivers the technical configuration to activate them — based on SIM identity (authenticated via EAP-AKA) and subscription policy. The entitlement server is not user-facing and does not manage OAuth scopes or consent. It manages service eligibility at the network level. A full comparison of entitlement servers vs authorisation servers vs provisioning servers is covered in the U2opia blog series.

Is a TS.43 entitlement server required for VoWiFi on all devices?

Yes for iOS and for most Android OEMs including Samsung. Apple requires iOS devices to complete a TS.43 entitlement check before registering with the operator's IMS core over Wi-Fi. Without a successful entitlement response, the device will not attempt VoWiFi registration — regardless of Wi-Fi signal quality or IMS core availability. Samsung Android devices require similar entitlement checks for VoWiFi and certain 5G features. Operators offering VoWiFi without a TS.43-compliant entitlement server will see systematic activation failures on Apple and Samsung devices.

How does roaming affect entitlement server behaviour?

When a subscriber roams to a visited network, the device's entitlement client still queries the home operator's entitlement server — not the visited network's. The home operator's entitlement server must determine whether the subscriber's plan includes roaming VoWiFi, whether the visited network is a supported partner, and what configuration applies. Operators with entitlement servers that do not handle roaming entitlement correctly will see VoWiFi drop when subscribers cross borders, even if both operators support VoWiFi. This is one of the most common entitlement failure modes in production deployments.

What subscriber data is exposed to enterprise applications via the entitlement server's API token?

None. When the entitlement server issues an EAP-AKA-derived token for a CAMARA API call (e.g., NumberVerify2 or SilentAuth+), the enterprise application receives only a verification result — match or no-match for the phone number. No IMSI, no subscriber PII, no network parameters, and no session data are returned to the enterprise. The token is cryptographically bound to the SIM and session, and expires on a short timer. The CAMARA API design explicitly enforces data minimisation: the enterprise cannot retrieve subscriber identity from the API response.

How long does it take to deploy a TS.43-compliant entitlement server?

In a hosted (Entitlements-as-a-Service) model, operators integrating with GSMA Entitlements (NetLync) or U2opia's hosted deployment typically complete OSS/BSS integration in 4–8 weeks with 2–3 developers. In an operator-deployed (on-network NF) model, deployment typically takes 12–20 weeks depending on internal CNF deployment processes and BSS integration complexity. Both timelines assume a standard HLR/HSS Diameter interface and existing BSS subscription management APIs.

Can an entitlement server handle eSIM and VoWiFi simultaneously for the same subscriber?

Yes — and it must. Modern subscribers expect a seamless experience across VoWiFi calls, eSIM activations, and companion device pairing, often triggered in rapid succession. A production-grade TS.43 entitlement server maintains independent entitlement state for each service type per subscriber and handles concurrent entitlement requests across services and devices. Session management, token isolation per service, and concurrent BSS query handling are all required for multi-service, multi-device entitlement at operator scale.
‍

Conclusion: The Entitlement Server Is No Longer Optional Infrastructure

The entitlement server began as a narrow device-pairing utility — the component that told an iPhone it was allowed to use VoWiFi. In 2026, it is the central policy and monetisation layer for VoWiFi (350+ operators, $9.59B market), eSIM (633M device shipments in 2026 alone), silent network authentication (CAMARA's $3.8B Number Verification API market), 5G network slicing, satellite messaging, and companion device orchestration. Every major growth vector in the operator product portfolio now runs through the entitlement server.

The September 2025 GSMA Entitlements launch, the TS.43 2025 Wi-Fi extension, and the CAMARA Fall25 stable API release have collectively removed the two barriers that previously limited entitlement server adoption: specification complexity and deployment difficulty. Operators can now deploy a TS.43-compliant entitlement server connected to GSMA Open Gateway in under eight weeks, with no capital expenditure, and begin earning per-verification revenue from CAMARA API calls against their subscriber base from day one.

The operators who deploy production-grade entitlement servers in 2026 will be positioned to monetise the full scope of GSMA Open Gateway's network API ecosystem as it matures. Those who do not will continue activating services at reduced reliability, losing VoWiFi and eSIM revenue to entitlement failures, and watching silent authentication revenue flow to operators whose networks are already in coverage. U2opia's entitlement server and authentication platform covers all six use cases above, with TS.43 v12.0 compliance, USSD fallback for 2G/3G, and full CAMARA/Open Gateway integration. Contact U2opia's MNO partnerships team to start the technical conversation.