Here is a scene that plays out in telecom procurement more often than anyone admits. A vendor sails through the entitlement demo. The product looks sharp, the roadmap is convincing, everyone nods. Then the security questionnaire goes over, all three hundred rows of it, and the vendor who was so fluent on stage suddenly needs two weeks and a specialist to answer row 47. That moment, not the demo, is where entitlement deals are actually won or lost, and if you are evaluating Entitlement-Server-as-a-Service (ESaaS) or any entitlement platform, it pays to know what the review should really be probing. Our guide to Entitlement-Server-as-a-Service covers what the capability does; this one is about how to be sure it is safe to put near your network.

The frustrating part is that most entitlement security reviews ask the wrong questions. They reuse a generic SaaS questionnaire, tick the boxes about password policies and office Wi-Fi, and never get to the handful of things that actually matter for a system sitting this close to subscriber identity and the core network. So let us fix that.

‍

The short version

An entitlement server security review should check six things above all: where subscriber data physically lives and whether residency is enforced by architecture or just promised; how tenants and brands are isolated from one another; whether your operator credentials ever leave your own environment; how every entitlement decision is logged and whether it can be explained and exported; how the platform behaves when something fails, especially on paths that carry emergency calls; and what the vendor contractually commits to on availability, incident response and breach notification. Get clear answers on those six and you have covered the ground that generic questionnaires miss. A well-architected managed service can often pass this review more cleanly than a self-hosted build, which surprises people.

Now the detail, because each of those deserves a real answer.

‍

Why entitlement is a security problem, not just a telecom one

It helps to be clear-eyed about what this layer actually touches, because that is what makes the review matter.

An entitlement server sits in the blast radius of your most sensitive assets. It authenticates devices against SIM credentials, it reasons about subscriber identity, and it talks to core-network functions. The trust model it uses is unusual and easy to get subtly wrong, which we explain in the TS.43 authentication trust model, and the boundary it draws with the HSS and UDM is a genuine security surface in its own right, as we cover in TS.43 authentication boundaries between the core and the entitlement server. This is not a marketing microsite. A weakness here is a weakness next to identity and the network.

The stakes are not abstract either. IBM puts the global average cost of a data breach at USD 4.44 million in 2025 (IBM), and for a telecom operator the reputational and regulatory fallout of mishandled subscriber data runs well beyond the direct number. Telecom security is also governed by its own frameworks, coordinated through bodies like the GSMA Fraud and Security Group, which means an entitlement vendor should be fluent in telecom-specific obligations, not just the usual cloud checklist. If a vendor treats entitlement as a generic app, that is itself a finding.

‍

The questions that actually matter

Here is the review reframed around what counts. For each question, it helps to know what a strong answer sounds like and what should make you nervous.

‍

‍

Three of these are worth slowing down on, because they are where the real differences hide.

Residency, and whether it is real. Plenty of vendors will tell you data “stays in region.” The question is whether that is a configuration setting someone can fumble or a property of the architecture that cannot be violated by accident. Residency enforced by construction, where subscriber data is pinned to a nominated jurisdiction and cross-boundary movement is prevented by design, is a different and much stronger claim than a policy promise, and it maps directly onto obligations under regimes like the GDPR. Ask them to explain the mechanism, not the intention.

Credential handling, and where the trust boundary sits. This is the single question that separates a serious entitlement vendor from a hopeful one. The weak design pulls your operator credentials into the vendor’s platform and promises to guard them. The strong design never lets them leave your estate at all, placing a secure edge inside your environment so that the platform reaches your AAA and HSS without ever holding the keys. One is a promise. The other is a structural guarantee, and the difference is exactly the kind of thing a good review exists to surface. Our deeper write-up on security in entitlement servers walks through the full threat model behind this.

Failure behaviour, because the worst day is the real test. A system that works perfectly until it does not is not a secure system. The review should ask what happens when a downstream lookup times out or the platform degrades, and the only acceptable answer is that behaviour is configured per service class, so that voice never fails closed on a path carrying emergency calls. We wrote a whole piece on what happens when an entitlement server is unreachable precisely because this is the scenario buyers skip and operators regret.

The remaining questions have cleaner yes-or-no answers, but do not skip them.

On tenancy isolation, ask whether one brand or tenant can see another’s data or affect another’s decisions, and whether a load spike in one market can degrade service in another. A credible platform isolates tenants by design and attributes performance per tenant, so “the platform is slow” resolves to which tenant and which upstream system rather than a shrug.

On auditability, you want every decision recorded immutably with its inputs and the policy version that produced it, and exportable on demand. That is what lets your care team explain any answer to any subscriber, and lets compliance resolve a dispute with evidence instead of a guess.

On certifications, ask for current attestations such as SOC 2 Type II and ISO/IEC 27001, a recent penetration-test summary, and clear breach-notification terms. These are table stakes, and a vendor who cannot produce them quickly is telling you something.

On vendor viability, remember that you are trusting this provider with a live, critical path for years. Financial stability, a credible roadmap and sensible exit terms are security questions too, because a provider that quietly fails is its own kind of outage.

The three questions earlier, on residency, credentials and failure, are where vendors either demonstrate real engineering or start talking in adjectives. These four are where you confirm the basics are genuinely in place.

‍

The “self-hosted must be safer” myth

Somewhere in most security reviews, someone argues that the safest option is to build and host it yourself, because then the data never leaves the building. It feels obviously true. It usually is not.

Control and security are related, but they are not the same thing. Hosting it yourself gives you total control, which means you also carry total responsibility: for the threat modelling, the patching cadence, the key management, the penetration testing, the 24/7 monitoring, and the specialist telecom-security knowledge to do all of that for a system this sensitive. That is a standing security function, and it is expensive to do well, which is part of the broader argument in the true cost of running an entitlement server in-house.

A well-architected managed platform can be structurally at least as safe, and sometimes safer, for a reason that catches people off guard. Because the strongest designs keep your credentials inside your own estate through a secure edge, the provider never holds the thing that would do the most damage if breached. Add a dedicated security team whose entire job is this one system, isolation tiers you can dial up to a cluster in your own environment, and residency enforced by design, and the managed option often clears a rigorous review with fewer caveats than a stretched internal team building its first entitlement platform. The honest exception is the operator with a mature, well-resourced security organisation and a genuine reason to own the stack. For everyone else, “we will host it ourselves” is a decision to take on a large security liability, not to avoid one, and the deployment models guide lays out the middle options between the two extremes.

It is worth naming that middle path explicitly, because reviews often miss it: a managed service deployed inside your own environment. You get the vendor’s security team, certifications and specification upkeep, while the cluster and the credentials sit in your estate rather than in a shared public cloud. For a security-conscious operator that cannot accept a pure public-cloud model, that option frequently settles the whole debate, because it keeps the control you actually care about and hands over the operational burden you do not.
‍

How to run the review so it actually tells you something

A security review is only as good as how you run it. A few habits make the difference between a rubber stamp and real assurance.

Get the right people in the room early. That means your CISO or network-security lead, your data-protection or compliance officer, and someone from the team that will operate the integration, not just procurement working through a form. Entitlement sits across all of their domains, and a gap any one of them spots is cheaper to find now than after signing.

Ask for architecture, not adjectives. “Enterprise-grade security” is not an answer. A diagram showing where credentials live, where data is pinned, and where the trust boundaries sit is. If a vendor cannot draw it, they probably have not built it.

Ask for the evidence, not the claim. A current SOC 2 report or an ISO 27001 certificate, a recent penetration-test summary, and the actual SLA and breach-notification terms in writing. The difference between a vendor who has these ready and one who needs to “check internally” is itself a signal.

And test the failure story with a real scenario. Give them a specific case: a regional BSS slowdown during a flagship launch, say, and ask exactly what their platform does, decision by decision. The quality of that answer tells you more than any certificate. If you want to run that exercise against a live platform rather than a questionnaire, book a technical session with our team and bring your hardest scenario.
‍

Three answers that should make you push harder

A few responses should stop you in your tracks. If residency comes back as “usually” or “we can probably keep it in region,” it is not enforced, it is hoped for. If credential handling is “they are encrypted inside our platform,” then your keys are leaving your estate, encrypted or not, and that is a different risk profile from never handing them over. And if the failure story is “it is highly available, so that will not happen,” they have not designed for the day it does. None of these is automatically disqualifying, but each one means the real answer is still somewhere ahead of you, and you should keep asking until you reach it. If you want a straight, vendor-neutral read on any of these, we are happy to help.
‍

What a strong answer looks like in practice

For completeness, here is the shape of a good answer to the whole review, which is also how we built Entitlement-Server-as-a-Service (ESaaS).

Subscriber data is pinned to the jurisdiction you nominate, with residency enforced by construction rather than configuration. Isolation runs across defined tiers, from shared multi-tenant through to a dedicated cluster deployed inside your own estate, so you can choose the posture your security review demands instead of negotiating exceptions. Your operator credentials never enter the platform, because a secure edge inside your environment reaches your AAA and HSS on your side of the boundary. Every entitlement decision is recorded immutably, with its inputs and the policy version that produced it, and can be exported so your care and compliance teams can explain any answer and resolve any dispute with evidence. Behaviour under failure is configured per service class, so the emergency path is never at the mercy of a platform-wide default. And availability, latency and incident response are committed in an SLA with defined measurement points, written before the deal rather than after it. The difference between the licensed-product era and the managed-service era, which we traced across this entire series, shows up clearly here: structural guarantees instead of best-effort promises.
‍

The bottom line

The entitlement security review is not a formality to survive. It is the single best tool you have for telling a real platform apart from a convincing demo, because the questions that matter here, about residency, credentials and failure, cannot be answered with marketing. Ask them precisely, insist on architecture over adjectives, and the right choice tends to make itself obvious.

If you would like a security-ready walkthrough of how a managed model answers each of these, talk to our team and we will bring the architecture diagrams, not the adjectives.
‍

Frequently asked questions

1. What should a security review for an entitlement server cover?
At minimum it should cover data residency and whether it is enforced by architecture or policy, tenant and brand isolation, whether operator credentials ever leave your environment, how entitlement decisions are logged and whether they can be exported, how the platform behaves under failure (especially on emergency-calling paths), and the contractual SLA and breach-notification terms. Standard items like SOC 2 or ISO 27001 certification, penetration-test evidence and access controls matter too, but the telecom-specific questions above are the ones generic questionnaires miss.

2. Is a managed (ESaaS) entitlement server less secure than hosting it ourselves?
Not necessarily, and often the opposite. Hosting it yourself gives you full control but also full responsibility for threat modelling, patching, monitoring and specialist telecom security. A well-architected managed platform keeps your credentials inside your own estate through a secure edge, offers isolation tiers up to a dedicated in-estate cluster, and enforces residency by design, so it can clear a rigorous review with fewer caveats than a stretched internal team. The exception is an operator with a mature security organisation and a specific reason to own the stack.

3. Where does subscriber data live with Entitlement-Server-as-a-Service?
With a well-designed platform, subscriber data is pinned to the jurisdiction you nominate, and residency is enforced structurally so it cannot be moved across boundaries by accident. Isolation can extend to a dedicated cluster deployed inside your own environment, and operator credentials are held at a secure edge on your side rather than inside the provider’s platform.

‍