Entitlement Server vs Entitlement-Server-as-a-Service: Build, Run, or Subscribe?

There is a slide that shows up in almost every operator’s roadmap review right now. It says something like “Entitlement server: build or buy?” and the moment it lands, the room splits. The network architects want to build, because they can and because owning the stack feels safer. Finance wants to buy, because the build estimate has a suspicious number of zeros. Procurement wants a shortlist. Nobody in the room is wrong, exactly. They are just answering the wrong question.

The wrong question is “build or buy,” because it hides a third option and flattens the real trade-off into a coin toss. The better question is “who should carry the operational weight of the entitlement decision for the next five years, and what is that actually worth to us?” Framed that way, Entitlement-Server-as-a-Service stops looking like the cautious choice and starts looking like the obvious one for most operators. But not all. This guide is the honest version of that comparison, including the cases where building still wins.
‍

The short answer

An entitlement server is the software you run to make GSMA TS.43 service-entitlement decisions. Entitlement-Server-as-a-Service (ESaaS) is that same capability delivered as a managed, multi-tenant subscription, with the provider carrying the software, the device certification, the specification upkeep and the SLA. Choosing between them is really a choice about who owns the ongoing operational cost and risk of the entitlement layer, not a choice about features. The capability is broadly the same in both cases. What differs is time to launch, cost shape, who chases the moving specification, and who is accountable when a service breaks at 2 a.m.

Hold that answer in your head, because the rest of this piece is about the details it glosses over.
‍

First, there are three models, not two

The “build or buy” framing collapses on contact with reality, because “buy” splits into two very different things.

Build in-house. You take the public GSMA TS.43 specification and implement it yourself. Your engineers own the code, the deployment, the test matrix, and the pager. This is the maximal-control option, and our step-by-step guide to implementing an entitlement server is an honest look at what that road involves before you commit to it.

License a product and run it yourself. You buy an entitlement server product from a core-network vendor and operate it in your own environment. You skip the initial build, but you keep almost all of the ongoing operational load, and our deployment and run-book checklist gives a sense of the surface area: upgrades, certification, capacity, incident response. This is the model most large operators defaulted into over the last decade, and it is the one people usually mean when they say “we already have an entitlement server.”

Consume Entitlement-Server-as-a-Service. You subscribe to the capability. The provider runs the software, keeps pace with the specification, maintains the certification lab, and carries the SLA, while you keep your systems of record and your customer relationship.

A quick note to avoid a common mix-up: this is not the same comparison as an entitlement server versus an authorization server versus a provisioning server. That one is about what kind of component you need. This one assumes you already know you need entitlement, and asks how you should source and run it. Different axis entirely.
‍

Where the real cost hides

Here is where most build-or-buy spreadsheets go wrong. They line up a software license or subscription fee against an estimated build cost, pick the smaller number, and call it analysis. The entitlement server does not cost what it costs to stand up. It costs what it costs to keep running correctly, forever. That carrying cost of readiness is the part that never makes it onto the slide.

Start with the specification itself. GSMA TS.43 is not a document you implement once and forget. It is a living standard, and it moves. As of early 2026 it had reached version 13.0 (GSMA), and it keeps advancing as new services and device classes arrive. Every revision is work: someone has to read it, interpret it, implement it, and regression-test it against your live traffic. The authentication mechanics underneath it, from EAP-AKA to the access token, have to be exactly right, because nothing downstream can be trusted if that handshake is even slightly off. And TS.43 does not sit alone. It interlocks with a web of related GSMA and 3GPP specifications, which we mapped in how TS.43 relates to RCC.14, IR.51 and IR.92. Owning the server means owning that entire reading list, indefinitely.

Then there is the device side, which is the cost nobody forecasts accurately. TS.43 is not implemented identically across manufacturers, and Apple and Samsung each carry their own behaviours that shift with new handset generations. We went deep on this in how entitlement servers support Apple and Samsung devices. Keeping current means running a certification lab that validates new device families before your subscribers ever meet them. That lab is not a project. It is a standing function with people, hardware, and a queue that never empties.

Add the operational floor. This is a real-time service that has to answer inside a device’s timeout window, which means low latency, high availability, and multi-region resilience. Building that well is genuinely hard, and our notes on architecting a scalable entitlement system exist because the naive version falls over at exactly the wrong moment: a flagship launch day, when activation volume spikes and your capacity headroom decides whether the launch is a triumph or a trending complaint. And the activation journeys themselves, the ODSA flows that provision primary, companion and IoT devices, are long-running and multi-step, so every one needs a clean rollback path that you also have to design, build and own.

None of these costs scale down when your traffic is quiet. That is the crucial point. A managed model turns most of them into a variable that tracks usage. Running it yourself turns them into a fixed floor you pay whether you launched anything this quarter or not.
‍

The comparison, dimension by dimension

Here is the same trade-off in a form you can drop into a decision document. To keep it readable, “run it yourself” covers both the build and the license-and-operate models, since their ongoing profile is nearly identical.

Tables are useful, but the two rows worth arguing about are failure handling and control. So let us argue about them. And if you would rather watch these dimensions play out on your own traffic than read about them, book a demo and we will run them live.
‍

Who owns the failure when Wi-Fi Calling breaks at 2 a.m.?

Every entitlement decision is fine until the one that is not. A downstream lookup times out, a policy edge case fires, a new handset does something the spec did not quite anticipate, and suddenly Wi-Fi Calling is silently dead for a region while your dashboards stay a reassuring green. We wrote an entire piece on what happens when an entitlement server is unreachable because this is the scenario operators consistently underprepare for, and the roaming and Wi-Fi-only edge cases in how roaming impacts entitlement flows are where it bites hardest.

When you run the server yourself, that failure is entirely yours. You detect it, you diagnose it, you fix it, and you explain it, with your own people, at your own hours. There is no external target to hold anyone to, because you are the target.

With a managed model, the accountability moves. A serious Entitlement-Server-as-a-Service provider carries an SLA with defined availability and latency targets, measured at agreed points, with credits when they miss. More importantly, they engineer fail-safe behaviour as a discipline rather than an afterthought, configured per service class so that voice never fails closed on a path that carries emergency calls. That is not a feature you can buy off a shelf and bolt on later. It is a way of operating, and it is the thing you are really paying for.
‍

The security question everyone gets backwards

The instinct is that running it yourself must be more secure, because the data never leaves your walls. That instinct is worth examining, because it is often wrong.

Self-hosting gives you total control, which is genuinely valuable, but control and security are not the same thing. Control means you can build a strong posture. It also means you have to, from privacy to fraud prevention, and our guide to security in entitlement servers shows how much surface that actually is. A well-designed managed platform can be structurally at least as safe, because it places a secure edge inside your own environment so that your operator credentials reach your AAA and HSS without ever entering the provider’s platform. Your credentials stay yours. The trust boundaries are enforced by architecture rather than by policy, which matters, because TS.43’s authentication trust model is unusual and easy to get subtly wrong.

Residency works the same way. With the right provider you nominate the jurisdiction, and the platform pins subscriber data there by construction, with isolation tiers ranging from shared multi-tenant to a cluster deployed inside your own estate. Our breakdown of cloud, on-premise, hybrid and multi-tenant deployment models walks through how to choose. The point is that “managed” does not have to mean “your data lives somewhere you cannot see.” Designed properly, it does not.
‍

The honest part: what you give up with a managed model

If this reads too one-sided, let me correct that, because pretending there is no trade-off is how you lose a technical audience.

When you subscribe, you give up operational control over the stack. You cannot patch the code at 3 a.m. on a hunch. You cannot bend the protocol implementation to a bespoke internal requirement without going through your provider. You take on a vendor relationship, which means you should care about their roadmap, their financial stability, and above all your exit terms. If entitlement is a place where you genuinely intend to differentiate, at a level no standards-based platform can express, then that lost control is a real cost and you should weigh it honestly.

The good news is that the gap is narrower than it sounds. A well-built platform gives you policy as versioned configuration, so the levers that actually change your commercial behaviour, offers, market rules, service eligibility, stay in your hands even though the code does not. And the deploy-in-your-estate isolation tier exists precisely for operators who need managed operations without handing over the keys. Control is a spectrum, not a switch.
‍

So when does building actually make sense?

Here is the framework, stated plainly, because a comparison that only ever points one way is marketing, not analysis.

Building or licensing-and-running makes sense when at least one of these is clearly true. You are a tier-one operator with the scale to amortise a standing platform team and a certification lab across a very large base. Entitlement is, for you specifically, a genuine competitive differentiator rather than a utility, and you have a concrete plan to express that difference in ways a shared platform cannot. You have unusual regulatory or architectural constraints that no external provider can currently satisfy. Or you already run a mature, well-staffed entitlement platform and the marginal cost of continuing is genuinely low.

Consuming it as a service makes sense when the opposite pattern holds, which is most of the time. Entitlement is a utility you need to be excellent but do not need to own. Speed matters, because you have eSIM, Wi-Fi Calling or a device programme on a roadmap that will not wait a year. You would rather your scarce engineers work on the network and the customer than on a device-certification treadmill. Or you are an MVNO or MVNE, where standing up your own entitlement server rarely pencils out against a hosted-network model in the first place, yet the services it unlocks are exactly what set you apart. For that whole second group, Entitlement-Server-as-a-Service is not the compromise. It is the more defensible engineering decision, and the business benefits of a TS.43 entitlement server show up faster because there is no build to finish first.

The market is drifting the same way the logic does. Counterpoint’s 2025 Global Entitlement Server Landscape places the traditional core-network vendors as the incumbents while noting that momentum is moving toward agile, API-first providers. That is the license-and-run model handing ground to the as-a-service model, in real time, across the industry.
‍

A pragmatic middle path most people miss

One more option deserves its own mention, because the “your cloud or theirs” debate obscures it. The strongest Entitlement-Server-as-a-Service platforms will run inside your environment. You get the operated service, the certification, the SLA and the specification upkeep, while the deployment sits in an isolation tier you control, with credentials held at a secure edge on your side. It is managed operations without full outsourcing, and for a security-conscious operator it is often the sweet spot. If that sounds like your situation, it is worth a conversation before you assume you have to choose the extremes. Talk to our team and we can map it against your estate.
‍

Bringing it back to the decision

The entitlement decision is going to be made billions of times across your subscriber base, on a widening range of devices, under real regulatory and experience pressure. The demand for it is not in question. The only open question is who should carry the cost and the risk of getting it right, at 2 a.m., on launch day, for every new handset that ships. For a small number of operators, the answer is genuinely “us.” For most, the honest answer is that entitlement is a utility worth consuming as Entitlement-Server-as-a-Service from someone who does nothing else.

If you want to pressure-test that against your own numbers, we will help you model it properly, including the carrying costs that usually get left off the slide. Book a working session with our team and bring your build estimate. We will show you where the hidden line items sit, and you can decide with the full picture in front of you.
‍

Frequently asked questions

1. Is Entitlement-Server-as-a-Service more expensive than building your own? On the sticker, a subscription can look larger than a one-off build estimate, but that comparison is misleading. Running an entitlement server carries standing costs that do not scale down: OEM certification, continuous TS.43 upkeep, 24/7 low-latency operations, and peak capacity for launch events. Entitlement-Server-as-a-Service turns most of those fixed costs into usage-based operating expense, which is usually lower in total for any operator that is not at tier-one scale. The right comparison is total cost of ownership over several years, not build cost versus first-year subscription.

2. Do we lose control if we use a managed entitlement service? You give up operational control of the software, but not commercial control. A well-designed platform exposes policy as versioned configuration, so offers, market rules and service eligibility stay in your hands. For teams that need more, a deploy-in-your-estate isolation tier keeps the service managed while the deployment and credentials sit inside your own environment. Control is a spectrum, and most operators find the levers that matter to them remain fully theirs.

3. When does it make sense to build an entitlement server in-house? Building makes sense when you have tier-one scale to amortise a standing platform and certification team, when entitlement is a genuine competitive differentiator for you rather than a utility, when you have regulatory or architectural constraints no provider can meet, or when you already operate a mature entitlement platform at low marginal cost. For most operators, and effectively all MVNOs and MVNEs, consuming it as a service is the stronger decision.

‍