TS.43 Authentication Boundaries: HSS, UDM & Entitlement Servers

Authentication Boundaries in TS.43

If you run telecom infrastructure, the core network is where most people think authentication lives. The HSS. The UDM. The AKA challenge-response cycle baked into every LTE and 5G handshake. These components do an enormous amount of work, and they do it reliably at scale.

But TS.43-based architectures introduce a second authentication layer that operates entirely outside the core network. One that does not ask whether a device belongs to your network. It asks what that device is allowed to do once it gets there.

That distinction sounds academic. In production, it is the source of a surprising number of incidents, misdiagnoses, and architectural decisions that create technical debt for years.

This article walks through exactly where the core network's authority ends, where the entitlement server's authority begins, and the specific failure modes that emerge when those boundaries are misunderstood or ignored.

‍

What the Core Network Actually Authenticates

The HSS and UDM are purpose-built for a specific job: verifying that a SIM credential is legitimate and belongs to a subscriber on your network. They execute this through EAP-AKA or AKA', generate authentication vectors, and confirm identity at the network layer. This process is standardized, auditable, and mature.

What the HSS and UDM do not do is make service-level decisions. They have no concept of whether a subscriber's plan includes Wi-Fi Calling. They cannot evaluate whether an OEM has provisioned a device correctly for a specific carrier feature set. They have no mechanism to express "this subscriber is entitled to VoLTE on this device at this tier."

Core network authentication produces a binary answer: the device is on the network, or it is not. Everything beyond that binary is outside the scope of HSS and UDM. That scope gap is exactly what TS.43 was designed to fill.

‍

ARCHITECTURE PRINCIPLE: HSS and UDM answer one question: is this SIM legitimately on my network? The entitlement server answers a different question: given that it is, what is it allowed to do? Conflating these two questions is the root cause of most TS.43 boundary violations.

Why Authentication Moved Beyond HSS and UDM

The architectural decision to separate service entitlement from network authentication was not arbitrary. It reflects a fundamental difference in the nature of the two decisions.

Network authentication needs to be fast, stateless at the service layer, and consistent across all subscriber devices regardless of their service tier. Adding policy logic into the HSS or UDM would make those systems slower, harder to update, and operationally more complex. Carrier feature policies change frequently. OEM-specific provisioning rules change with every firmware cycle. Entitlement configurations vary by market, by device model, by subscriber tier, and by regulatory context.

None of that belongs in core network components that are optimized for speed and consistency. Pulling service decisions out into a dedicated entitlement server layer keeps both systems focused on what they do well.

The connection between the two layers is the authentication token. The core network confirms identity. That confirmation flows into an entitlement check. The entitlement server uses a verified identity as the basis for its service decision. Neither system needs to do the other's job.

What Entitlement Servers Can Decide

Service Entitlement Grants and Denials

The entitlement server has genuine authority over a well-defined service domain. When a device authenticates through the TS.43 flow, the entitlement server evaluates the request against its policy engine and returns an XML configuration document telling the device exactly what it is entitled to use.

Within that domain, the decisions are substantial. The server can grant or deny VoLTE entitlement. It can configure Wi-Fi Calling behavior at a granular level, including whether the device prefers Wi-Fi or cellular, what the handoff behavior should be, and how the device should handle emergency calls in a Wi-Fi-primary configuration.

It can also set IMS registration parameters, carrier-specific feature flags, and supplementary service configurations. These decisions reflect the subscriber's current plan, the device model's certification status, and any carrier-specific overrides that apply.

Token Lifecycle Management

The entitlement server controls the lifecycle of entitlement tokens. It issues them, sets their expiry, scopes them to specific services, and can invalidate them when circumstances change.

This lifecycle authority is meaningful. If a subscriber downgrades their plan, the entitlement server can return an updated configuration on the next check-in that removes previously granted services. If an OEM pushes a firmware update that changes a device's capability profile, the entitlement server can reflect that change. The service layer responds to what the entitlement server says, not to what it said last month.

The key constraint is that token lifecycle management is forward-looking. The entitlement server can decide what happens from now on. It cannot retroactively invalidate a service session that was already established based on a prior valid token.

OEM and Device-Specific Configuration

One of the most underappreciated areas of entitlement server authority is device-specific configuration. Different OEMs implement carrier features differently. A Wi-Fi Calling configuration that works correctly on one device model may require different parameters on another, even when the subscriber and the carrier are identical.

The entitlement server can carry this device-specific logic. It can return different configuration payloads based on device model identifiers, firmware version, or OEM-specific fields in the authentication request. This is legitimate entitlement server territory because the decisions are scoped, policy-driven, and do not require access to core network state.

‍

What Entitlement Servers Must Never Decide

Core Network Identity Verification

The entitlement server must never attempt to perform or substitute for core network authentication. It receives a verified identity as an input. It must not treat indirect signals, like IP addresses, device headers, or OEM identifiers passed in HTTP headers, as a substitute for that verified identity.

This is not a theoretical concern. Some entitlement server implementations, particularly older ones or those built by teams with limited telecom background, attempt to infer device identity from HTTP-layer signals. This is heuristic matching, not authentication. It is spoofable, unreliable, and operates outside the entitlement server's legitimate authority.

If an entitlement server is making access decisions based on IP addresses or unverified device headers without a valid token from the network authentication anchor, it is operating outside its boundary. Full stop.

‍

CRITICAL RULE: An entitlement server that makes service decisions based on IP addresses, device fingerprints, or HTTP headers without a core-network-anchored token is not doing authentication. It is doing heuristics. The failure modes of heuristic-based access control are well-documented and not acceptable in production telecom infrastructure.

Retroactive Session Authority

The entitlement server must not attempt to terminate or modify service sessions that were established based on valid prior tokens. Once a service session is live, its continuity is governed by the service layer, not by the entitlement server's current policy state.

This boundary matters in practice when a subscriber's entitlement changes mid-session. The entitlement server's updated policy applies to the next check-in, not to the current session. Attempting to inject the entitlement server into active session management creates race conditions and undefined behavior that is very difficult to debug.

Cross-Network Identity Claims

The entitlement server must not make identity claims that span network boundaries without a fresh authentication anchor from each relevant network. An entitlement token issued by carrier A's entitlement server is scoped to carrier A's network. It is not evidence of identity or entitlement on carrier B's network, even if the subscriber has a roaming agreement in place.

Roaming configurations have their own authentication flows precisely because of this constraint. The entitlement server cannot extend its authority beyond the network whose core authentication it is anchored to.

Real Operator Scenarios Where Boundaries Break

Dual-SIM Identity Confusion

Consider a device with dual-SIM: SIM A from carrier A, SIM B from carrier B. The device authenticates to carrier A's entitlement server using SIM A credentials and receives an entitlement token. But at the moment of authentication, the device is routing data through SIM B.

Carrier A's entitlement server has done its job correctly. It issued a valid token based on verified identity. But the service layer is now attempting to use carrier A's entitlement configuration over carrier B's data path. The assumptions embedded in that entitlement configuration, about network path, IMS registration, and emergency call routing, do not hold.

This is not an exotic configuration. In markets with high dual-SIM penetration, this scenario is routine. The boundary violation is not in the entitlement server's decision. It is in the service layer's assumption that a valid entitlement token implies network path continuity. It does not.

MDM Profile Interference

Enterprise devices running MDM profiles present a related failure mode. The device authenticates to the entitlement server in a clean state. The MDM profile then modifies network routing, APN configuration, or DNS resolution. The entitlement token is still valid, but the network environment it was issued for no longer matches the environment the device is operating in.

The entitlement server is not aware of MDM state. It cannot be. MDM profile changes happen outside the entitlement flow. The result is a device operating with valid entitlement credentials in a network environment that those credentials were not issued for.

The practical fix is not to route MDM changes through the entitlement server. It is to ensure that network environment changes trigger a fresh entitlement check, so the token reflects the device's actual operating context.

Entitlement Server Assuming Core Network State

A more subtle boundary violation happens when entitlement server logic attempts to infer or assume core network state. For example, an entitlement server that assumes a device is on the home network because it received an authentication request from a domestic IP range is making an assumption it is not entitled to make.

The device might be using a VPN. It might be on a split-tunnel corporate network. Its IP address is not evidence of its network attachment. Entitlement server decisions based on IP-layer inferences about core network state are a category error that can produce incorrect service configurations and, in IMS contexts, incorrect emergency call routing.

‍

Building Architecture Clarity Into Your Stack

The practical output of understanding TS.43 authentication boundaries is a set of explicit design rules for your stack.

Every entitlement server decision must be anchored to a token that was issued by a core-network-connected authentication process. No token, no entitlement decision. Heuristic fallbacks are not acceptable for service grants.

Token scope must be explicitly defined and enforced. A token issued for Wi-Fi Calling entitlement is not authorization for VoLTE configuration. Service-specific scoping prevents token reuse across contexts.

Network state changes must trigger fresh entitlement checks. Device roaming, SIM switch, network handoff, and MDM profile changes all represent potential state changes that invalidate prior entitlement assumptions.

Entitlement server logs must be correlated with core network authentication logs. Boundary violations are often visible in log correlation before they surface as subscriber-facing incidents. Building that correlation into your monitoring stack is the fastest path to early detection.

‍

OPERATOR CHECKLIST: Before your next entitlement server deployment: confirm every service grant is anchored to a verified core-network token, confirm token scope is explicitly limited to specific services, confirm network state changes trigger re-entitlement, and confirm your monitoring stack correlates entitlement events with core network auth events.

‍

Why This Gets Misunderstood in Practice

The boundary confusion between core network authentication and entitlement server authority is partly a documentation problem and partly an organizational one.

On the documentation side, TS.43 specifies the entitlement flow but does not always make the boundary constraints explicit in a way that non-telecom engineers can easily absorb. Teams building entitlement server implementations against the spec sometimes miss the implicit assumptions about what the entitlement server receives as input versus what it produces as output.

On the organizational side, the teams responsible for core network authentication and the teams responsible for entitlement server development are often different groups. Without explicit boundary definitions agreed on by both teams, each group optimizes for its own domain and the interfaces between them become sources of undefined behavior.

The fix is straightforward: make the boundary explicit, document it in a format that both teams can reference, and include boundary compliance as a requirement in your entitlement server certification process.

FAQs: TS,43 Authentication Boundaries

What is the difference between HSS/UDM and an entitlement server?

The HSS or UDM authenticates a subscriber’s SIM credentials at the network level using AKA or EAP-AKA’. It confirms whether the subscriber belongs to the network.
An entitlement server operates after authentication and determines which services the subscriber is allowed to use, such as VoLTE or Wi-Fi Calling. Authentication verifies identity. Entitlement authorizes services.

Can an entitlement server authenticate a subscriber?

No. An entitlement server does not perform SIM-level authentication. It relies on identity verified by the core network. If an entitlement server makes service decisions based on IP addresses, device headers, or heuristics without a core-network-anchored token, it is operating outside its architectural boundary.

What triggers a new entitlement check in TS.43?

Re-entitlement should occur when network state changes. Common triggers include:

• SIM switch (dual-SIM devices)
• Roaming status changes
• Device firmware updates
• MDM profile modifications
• Network handoff events

Entitlement tokens must reflect current network and device state to prevent configuration drift and service failures.

Conclusion

TS.43 authentication boundaries are not just an architectural nicety. They are the difference between a service layer that behaves predictably under real-world conditions and one that produces mysterious failures when those conditions deviate from the happy path.

The HSS and UDM do their job. The entitlement server does its job. The problems emerge at the handoff between them, when one system makes assumptions about what the other has guaranteed, or when the entitlement server attempts to extend its authority into territory that belongs to the core network.

Understanding those boundaries precisely is the foundation of a TS.43 deployment that you can operate, debug, and scale with confidence.

About U2opia

U2opia builds operational intelligence for telecom operators managing TS.43-based authentication flows. Our platform provides entitlement server monitoring, token lifecycle analytics, boundary violation detection, and OEM behavior diagnostics at carrier scale.

‍

‍