eSIM Orchestration: Open, Closed or Somewhere Between?
The next eSIM power struggle will not be fought over QR codes, destination counts or whose app installs a profile with one fewer tap. It will happen deeper in the stack, where operators and eSIM brands decide how much infrastructure one supplier should control.
Two models are becoming easier to recognise. One is an integrated platform that supplies or operates most of the commercial and technical chain. The other places an orchestration or abstraction layer above multiple provisioning systems, connectivity providers or operator back ends.
The labels “open” and “closed” are useful editorial shorthand, not formal GSMA architecture categories. That matters, because several different products are now sold as eSIM orchestration. The real question is not which label sounds more modern. It is which architecture lets the buyer change suppliers, contain failures and negotiate from something stronger than optimism.
First, separate the three kinds of orchestration
Consumer remote SIM provisioning, IoT profile management and travel-eSIM inventory aggregation are related, but they are not the same thing.
Consumer eSIM architecture is governed through the GSMA’s SGP.21 and SGP.22 specifications and includes components such as the eUICC, Local Profile Assistant, SM-DP+ and discovery services. The newer IoT architecture is defined through SGP.31 and SGP.32, with the eSIM IoT Remote Manager, or eIM, and IoT Profile Assistant playing distinct roles. The GSMA published version 1.3 of both IoT specifications in May 2026.
READ MORE: Remote SIM Provisioning (RSP): The Technology Powering eSIM Flexibility
A travel eSIM brand may also connect several wholesale suppliers through APIs and present their plans in one storefront. That is a commercially valuable abstraction, but it does not automatically mean the brand orchestrates GSMA provisioning infrastructure. It may still depend on each supplier for profile generation, network access, usage records, and fault resolution.
The distinction is not pedantic. A platform can be open at the catalogue level and closed at the provisioning level—or support multiple SM-DP+ systems while tying billing, customer data and support workflows to one vendor.
Why closed stacks remain attractive
A closed or vertically integrated platform can combine connectivity, a mobile core, remote SIM provisioning, entitlement, policy controls, APIs and operational tooling. The provider may not literally own every network involved, but it controls enough of the service chain to present one product and one point of accountability.
1GLOBAL is a clear example of this direction. Its own product materials describe a full-stack telecom platform built around a global core network, telecom licences, roaming relationships, APIs, an entitlement server and SM-DP+ infrastructure. Its consumer RSP service also advertises geographically redundant hosting in London and Amsterdam. These are company claims, but they illustrate what the integrated model is intended to provide.
For an operator launching a sub-brand, or a travel company embedding mobile service into its app, this model can be entirely rational. Integration is faster. Technical components have already been designed to work together. There is one commercial relationship and fewer gaps where a provisioning incident can bounce between suppliers like an unwanted conference call.
Closed does not mean fragile. A single provider can operate multiple network agreements, redundant infrastructure and sophisticated failover. It may deliver better day-to-day reliability than a loosely assembled multi-vendor system.
The trade-off appears when the buyer wants to leave. If provisioning, connectivity, charging logic, analytics and customer workflows are tightly coupled, replacing one layer may require rebuilding several others. Operational simplicity has then been purchased with a larger migration problem.
What an open layer can—and cannot—change
An open orchestration model separates at least part of the decision and workflow layer from the infrastructure underneath it. Depending on the product, it may coordinate several SM-DP+ environments, integrate with a separately selected eIM, connect different connectivity providers or normalise data from multiple operator systems.
The market already contains examples, although their scopes differ. Cisco says its Control Center eSIM Orchestrator integrates with an eIM procured by the communications service provider. Valid says its SM-Connect framework can extend selected capabilities to another vendor’s SM-DP+, supporting multi-sourcing. 10T Tech markets a consumer platform that can operate across multiple SM-DP+ systems, including a secondary environment during maintenance or failure.
READ MORE: Booking Platforms Monetized Flights and Stays. Connectivity Is Next
These are vendor descriptions, not proof that every deployment is portable or supplier-neutral. They do, however, show why orchestration has become a separate competitive category. Counterpoint Research now evaluates consumer and IoT eSIM orchestration in different 2026 rankings, reflecting the fact that lifecycle management, entitlement, BSS/OSS integration and IoT profile switching require different capabilities.
Open architecture can give an operator more freedom to retain its digital channels while changing an RSP supplier. It can give an IoT enterprise a way to manage profile changes separately from the company reselling connectivity. For a mature travel eSIM brand, a commercial abstraction layer can reduce dependence on one wholesale catalogue and improve its ability to steer demand among suppliers.
But openness stops where portability stops.
Resilience is about separate failure domains
“Multi-network” and “multi-provider” are often treated as synonyms for resilience. They are not.
A service may access several radio networks through one profile and one core. That can reduce coverage risk when alternative networks are genuinely available, but the service may still have a single failure point in its core network, provisioning platform, API gateway or charging system.
An open design can distribute those risks, but only when the alternatives are operationally independent. A secondary SM-DP+ is useful if new activations can actually be routed to it. A second connectivity supplier is useful if compatible profiles, commercial terms and support procedures already exist. An IoT profile-switching policy is useful only if bootstrap connectivity, the eIM, IPA and target operator systems work together under real deployment conditions.
READ MORE: eSIM Orchestration Rankings 2026: Amdocs and Valid Lead
The GSMA specifications provide standardised machinery; they do not provide a complete resilience strategy. Contracts, routing, local regulation, rights over issued profiles, testing and incident procedures still decide whether a supplier switch works outside a demonstration. Independent analysis from Transforma Insights similarly argues that SGP.32 is separating profile orchestration from connectivity resale, while warning that most enterprises will still consume these capabilities as managed services.
Bargaining power begins with a usable exit
The open model generally offers greater potential bargaining power because it can make suppliers more replaceable. Potential is doing a great deal of work in that sentence.
A buyer has genuine leverage when it can export operational data, retain customer identities and transaction history, preserve its app and APIs, introduce another connectivity or RSP provider, and migrate without forcing customers to begin again. Contract minimums, profile migration rights and access to diagnostic data matter as much as interface documentation.
This is where a supposedly open orchestrator can become the next lock-in point. If it owns the policy engine, billing records, workflow logic and supplier integrations in proprietary form, the buyer may have exchanged one dependency for a more elegant-looking dependency.
Conversely, a closed provider may offer credible portability through documented APIs, data-export rights, migration support and contractual exit provisions. Architecture influences control, but procurement determines whether that control is enforceable.
The best model is the one with a tested exit
Closed platforms remain the stronger choice for companies prioritising speed, integrated accountability and limited internal telecom expertise. Open orchestration becomes more valuable for large operators, established eSIM brands and global IoT deployments that have enough scale to manage several suppliers and test the boundaries between them.
Alertify assesses that the most defensible approach will usually be hybrid: an integrated operating experience above replaceable provisioning and connectivity components, supported by open interfaces, exportable data and a contractually defined migration path.
The winner is therefore not automatically the platform with the most layers, nor the orchestrator with the most partner logos. It is the model that can absorb a supplier failure, introduce a credible alternative and preserve the customer relationship while doing so. In eSIM infrastructure, control is not what the dashboard allows on a good day. It is what the business can replace on a bad one.
