From EAP-AKA to Access Token: How Device Authentication Works in a TS.43

When you strip TS.43 down to its core, everything starts with trust.
Before a device can download configuration, activate VoWiFi, or trigger an eSIM profile, the network must first know who is making that request and whether that request can be trusted.

That’s where authentication comes in.

Authentication in a TS.43 entitlement server isn’t just a handshake; it’s a carefully structured process that moves from EAP-AKA to token-based access control, ensuring every request is verified and traceable.

If you’ve already worked with entitlement systems, this guide will take you straight into the part that matters: how devices actually authenticate to the entitlement server, how tokens are issued and managed, and what best practices operators and OEMs rely on in live deployments.

For a broader view of security architecture, you can also check our recent article on Security in Entitlement Servers.

How the Authentication Flow Works

When a user initiates an entitlement-triggering action (like enabling VoWiFi or activating a companion device), the device entitlement client reaches out to the entitlement server defined by the operator’s configuration profile.

At that point, a multi-step authentication flow starts.

Here’s the typical sequence:

1. The device identifies itself and initiates an EAP-AKA authentication through the entitlement server.
2. The entitlement server communicates with the operator’s AAA or HSS system to validate the SIM identity (IMSI).
3. Once validated, the server issues an access token that the device can use for further interactions.

Each stage is designed to verify identity, issue short-lived credentials, and maintain a secure session for ongoing entitlement exchanges.

EAP-AKA: The First Layer of Trust

EAP-AKA (Extensible Authentication Protocol - Authentication and Key Agreement) is the starting point of device authentication in TS.43.

This protocol uses the SIM’s built-in credentials to establish mutual trust between the device and the operator’s network. The entitlement server acts as an EAP authenticator, passing authentication requests to the operator’s AAA or HSS for validation.

During this exchange, the network sends a challenge to the SIM, which responds using a cryptographic signature derived from its authentication key. If the response is correct, both sides generate shared session keys that secure the communication channel.

In short, EAP-AKA answers the question: Is this device truly tied to a legitimate subscriber in our network?

This step ensures that only valid SIMs and devices are even allowed to begin entitlement interactions.

Operator Tokens: Simplifying Subsequent Access

Once EAP-AKA authentication succeeds, the entitlement server issues an operator token (often in the form of an OAuth 2.0 access token).

Why? Because running EAP-AKA for every entitlement call would be inefficient and slow. Tokens simplify this by giving the device a temporary credential that can be reused for a defined period.

These tokens typically include claims such as:

• IMSI or MSISDN: identifying the subscriber
• AppID: identifying the service (VoWiFi, VoLTE, eSIM)
• Validity duration: typically short, for security
• Cryptographic signature: to ensure integrity and non-repudiation

Tokens can be JWT-based or integrated with OAuth 2.0 frameworks depending on the implementation.

The entitlement server validates these tokens on every API call to make sure the request still comes from an authenticated, authorized device.

To see where this fits in relation to other backend systems, you can read Entitlement Server vs Authorization Server vs Provisioning Server: What’s the Difference?. It breaks down how entitlement and authorization layers complement each other.

Credential and Token Management

Tokens are only as secure as the way they’re stored and refreshed.

On devices, operator tokens are stored in secure environments such as Android’s Keystore or Apple’s Secure Enclave. They are never exposed in plaintext or stored in general app storage.

On the server side, tokens are signed using private keys known only to the operator or entitlement service provider. Every API call is verified against these signatures to prevent replay attacks or token forgery.

Token lifetimes are intentionally short. When a token expires, the device either uses a refresh token to request a new one or triggers a new EAP-AKA authentication cycle if the session context has been lost.

This rotating credential model keeps the connection secure without adding friction to the user experience.

Access Tokens in Action

After authentication, every entitlement action uses the access token for authorization.

Here’s a simplified sequence using VoWiFi as an example:

1. The user enables Wi-Fi calling on the device.
2. The entitlement client sends a request to the server, including the operator-issued access token.
3. The entitlement server validates the token’s signature and claims.
4. If valid, the server checks the subscriber’s entitlement in the backend system (like BSS or policy DB).
5. If the subscriber is eligible, configuration is sent back to the device, enabling the service.

This flow is fast, secure, and fully compliant with TS.43 standards. It also ensures the operator maintains full control over who can activate specific services.

You can explore more about real-world applications of this in Use Cases of Entitlement Servers: Wearables, eSIM, VoWiFi, and Silent Authentication.

Token Expiry and Renewal Logic

Tokens are short-lived for good reason. Long-lived credentials increase exposure risk if compromised.

When a token expires, the device automatically:

1. Uses a refresh token (if available) to request a new access token.
2. Falls back to a new EAP-AKA exchange if refresh fails or if the session keys are invalid.

Operators define token validity based on their security posture. Many prefer shorter durations (24–48 hours) to minimize vulnerability.

This flow ensures that authentication is continuous but not repetitive, balancing user convenience with security.

Security Best Practices

Every authentication and token exchange must follow strict GSMA TS.43 security guidelines.

Key practices include:

• Enforcing TLS 1.3 for all entitlement traffic.
• Validating token signatures before processing requests.
• Integrating with AAA systems using secure EAP relay channels.
• Logging all authentication events for traceability and audit readiness.
• Using strict anti-replay and nonce mechanisms.

Properly implemented, this flow ensures that every entitlement configuration is both authenticated and authorized.

Implementation Insights

Based on real deployments, a few practical lessons stand out:

• Optimize EAP-AKA latency. Long authentication times can delay service activation, especially for companion devices.
• Align with OEM specs. Apple and Samsung, for instance, have strict token and certificate handling rules.
• Integrate identity systems early. Mapping OAuth 2.0 or custom token flows with existing operator identity frameworks avoids rework later.
• Ensure global consistency. Token management policies should align across markets for smooth multi-region entitlement.

Operators can refer to the TS.43 Entitlement Server Deployment Guide for Carriers & OEMs to assess readiness before rollout.

Conclusion: Trust Starts with Authentication

In TS.43, authentication is where everything begins. From that first EAP-AKA exchange to the final access token, each step is designed to protect the integrity of entitlement transactions.

As services evolve to include multi-device ecosystems, eSIM, and IoT connectivity, the quality of your authentication framework will define your scalability and security posture.

If you’re designing or auditing your TS.43 authentication flow, connect with our team. We help carriers and OEMs architect secure, standards-aligned entitlement frameworks built for future telecom environments.

FAQs

How does EAP-AKA authentication integrate with the TS.43 entitlement flow?

EAP-AKA is the first step in the TS.43 entitlement process. It verifies the SIM and device identity through the operator’s AAA or HSS, establishes session keys, and enables the entitlement server to issue secure access tokens for further configuration requests.

‍

How long are access tokens valid in TS.43 authentication flows, and how is token expiry managed?

Access tokens in TS.43 are short-lived, usually valid for 24–48 hours. When they expire, the device either refreshes them automatically or triggers a new EAP-AKA authentication to obtain a new token, ensuring secure continuous access.

‍

What’s the difference between the device’s authentication and the subscriber’s entitlement verification in TS.43?

Device authentication confirms the device and SIM are genuine using EAP-AKA. Entitlement verification checks if the subscriber’s plan or policy allows the requested service, such as VoWiFi or eSIM activation.