Introduction: Why ODSA Matters in a Multi-Device World

Smartphones are no longer the only devices we carry. We have watches, tablets, wearables, IoT devices, even connected gadgets in the home or enterprise. As device diversity explodes, the old-school way of provisioning services via a physical SIM card is no longer enough. That’s where On-Device Service Activation (ODSA) comes in.

ODSA, as defined under GSMA TS.43, equips carriers and operators with a modern, flexible way to activate services not only on a primary phone, but also on companion devices and IoT endpoints.

In this post, we explore how entitlement flows differ when you activate services for a smartphone, a smartwatch, or an IoT module. Whether you are a telco operator, OEM, or simply curious; this will help you understand how connectivity works behind the scenes in a world of multiple devices per user.

Also read: What is entitlement server and why it matters

What We Mean by Primary, Companion, and IoT Devices

Primary Device

Primary devices are what most of us consider our “main device”, typically a smartphone (iPhone, Galaxy, etc.), equipped with a SIM or eSIM, full subscription, phone number, and full access to voice, data, messaging, and IMS-based services such as VoLTE or VoWiFi.

Companion or Secondary Devices

These are devices linked to the primary subscription but not identical to it. Think smartwatches, tablets, secondary phones, wearables, or “satellite” devices that piggyback on the main subscription. Often, companion devices may not have a dedicated physical SIM, or may rely on shared/sub-profiles under one subscription.

IoT Devices

IoT devices represent another category: smart meters, sensors, telemetry modules, connected appliances, enterprise devices, and more. Their usage patterns differ, often data-only, minimal or no voice/SMS, remote provisioning, bulk deployment, limited user interaction.

Because these categories vary so much in purpose, identity, usage and connectivity needs, a one-size-fits-all provisioning approach doesn’t work. That’s where ODSA + TS.43 brings value by delivering entitlement and service activation flows tailored for each device type.

How ODSA + TS.43 Enables Entitlement Across Device Types

For Primary Devices: Classic But Smart Activation

When a user inserts a SIM or activates an eSIM in a primary device, the phone triggers an entitlement request to the operator’s Entitlement Server. Under TS.43 this request invokes secure authentication (often using EAP-AKA), and the server checks subscription status, network readiness, device eligibility, and service support.

If all checks pass, the entitlement server returns a configuration specifying which services are allowed: voice-over-cellular (VoLTE/VoNR), WiFi-calling (VoWiFi), SMS-over-IP (SMSoIP), data plan, eSIM profile, etc. The phone then configures itself accordingly — often with no user interaction necessary. This makes activation streamlined and dynamic, and helps operators manage services more flexibly than old static provisioning.

This flow is ideal for primary phones that are designed to support full IMS services, eSIM, and all other capabilities.

For Companion / Secondary Devices: Extra Checks + Policy Control

When the device is not the main phone — say a smartwatch, tablet, or secondary eSIM-enabled device — ODSA flows still work, but with additional layers of validation and policy logic. According to TS.43, the “companion ODSA” use case exists as a dedicated application ID (e.g. “ap2006”) distinct from “primary ODSA” (ap2009) in the entitlement schema.

Here’s how it differs:

• Linked Subscription: The companion device must be linked to the primary subscription. Entitlement server must verify that the main subscription allows companion devices or secondary profiles under the same plan or account.
• Feature Restrictions: Not all services may be allowed for companion devices. For example, an operator may permit data-only access for a smartwatch, but disable voice or SMS over IMS on companion profiles.
• Consent or Policy Pages: TS.43 may require the entitlement client to show Terms & Conditions or user consent dialogs (for example for VoWiFi or number-sharing) before activating services on companion devices.
• Dynamic Activation/Deactivation: Companion devices may be added or removed dynamically. ODSA allows operators to grant or revoke entitlement in real time — helpful for multi-device subscriptions, family plans, shared device pools, etc.

This mechanism gives operators control over how many secondary devices a subscription can have, what services they get, and prevents misuse or over-subscription.

For IoT Devices: Lightweight, Scalable, Data-First Provisioning

IoT devices often have different requirements — many do not need voice or IMS, sometimes only data or telemetry, and often operate without human interaction. ODSA under TS.43 supports these needs as well.

Key aspects for IoT use:

• eSIM / eUICC Support: Modern IoT modules often ship with embedded UICC (eUICC). ODSA can trigger eSIM provisioning over-the-air, fetch profile from SM-DP+, and automatically enable data-only connectivity without user intervention. This simplifies mass deployment.
• Data-Only or Limited-Feature Profiles: Entitlement can limit the service to data-only (no voice/SMS/IMS), which is ideal for sensors, telemetry, telematics. This reduces cost, avoids unnecessary resource allocation, and aligns with device purpose.
• Bulk & Remote Management: For large fleets (smart meters, industrial sensors, enterprise devices), ODSA + Entitlement Server enables remote provisioning, activation, deactivation, and lifecycle management — reducing operational burden significantly.

Thus, ODSA allows operators to securely and efficiently onboard IoT devices on the same infrastructure used for phones and wearables — but with tailored entitlement logic per device type.

Key Differences & What Telcos / OEMs Should Watch Out For

Implementing ODSA for multiple device types brings big advantages, but also requires careful design and policy implementation. Some critical aspects to keep in mind:

Authentication & Identity: SIM vs Linked Subscription

• Primary phones use SIM/eSIM-based identity and EAP-AKA authentication — straightforward and secure.
• Companion or IoT devices may lack a full SIM identity (especially IoT or embedded devices), so entitlement server must rely on linked subscription, device-ID, or other identifiers to verify eligibility. This raises complexity in identity management, consent, and lifecycle tracking.
• Security is vital to avoid unauthorized device attachments or fraudulent use of a subscription across multiple devices.

Also read: How Is the Device Authenticated to the Entitlement Server

Service Profiles & Feature Limitations

• Companion devices may not need or be allowed full IMS capabilities. Operators must define policies: data-only, limited voice/SMS, or full services depending on plan.
• IoT devices usually require only data, enabling voice or IMS may waste resources or pose compliance/security risks.

Multi-Profile / Multi-Device eSIM Management

• With eSIM and eUICC, operators can manage multiple profiles (primary, companion, IoT) under one subscription. But the entitlement server must handle profile lifecycle: activation, deactivation, transfer, etc.
• When users switch devices, or add/remove companion devices, ODSA flows must update entitlement status, profile assignments, and billing/usage tracking correctly.

Regulatory, Compliance, and Policy Considerations

• Some regions or operators may impose restrictions on companion-device voice/SMS, IoT data, or multi-device usage. Entitlement server logic must respect those regional and regulatory constraints.
• For IoT or enterprise devices, operators may need extra features like lawful-intercept compliance, privacy controls, consent management — these must be integrated into entitlement flows.

Also read: Security in Entitlement server

Real-World Use Cases: From Smartwatch to Smart Meter

Adding a Smartwatch to Your Phone Plan

Imagine you buy a smartwatch and scan its onboard eSIM or companion-profile QR. The companion ODSA client on your smartphone requests entitlement. The server checks your subscription, verifies companion-device allowance, and returns an entitlement allowing data (and maybe voice/SMS if policy permits). Your smartwatch gets provisioned — no SIM card swap, no manual setup.

Family or Multi-Device Plans

One subscription, multiple devices: tablets, kids’ phones, secondary eSIM devices. ODSA lets operators provision each device under the same subscription, apply policy per device (data-only, limits, parental controls), and manage billing and usage centrally.

Large-Scale IoT Deployment (Smart Meters, Sensors, Industrial Devices)

A utility company needs to deploy thousands of IoT modules. With ODSA, each module can get its eSIM profile remotely, entitlement set to data-only plan, lifecycle managed centrally — no need for physical SIM distribution. This dramatically lowers costs and increases deployment speed.

Enterprise Device Fleets or Shared Device Environments

Enterprises using shared tablets, IoT gateways, or device fleets can benefit from centralized entitlement management. Devices can be activated, re-assigned, suspended or revoked via the entitlement server — all without physical SIM swaps or manual configuration.

Benefits & Challenges of ODSA-Based Multi-Device Entitlement

Benefits for Operators and OEMs

• Reduced provisioning overhead — no physical SIM management, easy over-the-air provisioning
• Scalable device onboarding — from phones to IoT — using same infrastructure
• Better user experience — users get services activated quickly, no manual SIM swaps required
• Flexible subscription models — single subscription can support multiple devices, different service levels per device

Challenges That Need Careful Planning

• Authentication and identity management for devices without SIM or with embedded eUICC
• Policy definition per device type to avoid over-provisioning or misuse
• Reliable lifecycle management for devices — adding/removing devices, reassigning subscriptions, handling eSIM transfers or device replacement
• Compliance with regional regulations, lawful intercept, privacy laws — especially for IoT or enterprise deployments
• Ensuring device firmware and OEM provisioning apps correctly support TS.43 and ODSA flows

Conclusion: ODSA and TS.43 Are Key for the Multi-Device Future, But Implementation Matters

The device world is changing fast. Phones are just part of the ecosystem — watches, tablets, IoT modules, wearables, enterprise devices, smart appliances — all demand connectivity. With On-Device Service Activation (ODSA) under TS.43, operators gain a unified, flexible, scalable way to serve all these devices with tailored entitlement flows.

But the benefits come with responsibilities. Operators and OEMs need to plan how to handle identity, service profiles, device lifecycle, regulatory compliance and user consent. When designed carefully, ODSA enables a seamless, scalable multi-device experience. When ignored, it can lead to service gaps, compliance issues or user frustration.

For modern networks and forward-looking telcos, ODSA is not optional. It is the foundation for the next generation of connected devices — and those who implement it well stand to gain big.

FAQs

What identity methods should we use for companion devices that lack a full SIM identity?

Use a hybrid identity model combining device attestation, a pairing token issued via the primary phone, and TLS client certificates. The primary device proves subscription ownership, while the companion uses short-lived tokens and hardware-backed keys to authenticate securely without a SIM.

‍

What testing matrix is required to validate ODSA flows across iOS, Android, wearable OS and multiple OEMs?

Test across device types, OS versions, OEM variants, eSIM flows, IMS features, roaming, weak connectivity, security failures, and performance at scale. Use a controlled lab with IMS, SM-DP+, and roaming simulations plus automated regression testing on real device models.

‍

How does ODSA integrate with SM-DP+, eUICC lifecycle management and subscription transfer flows?

ODSA triggers entitlement checks, then requests SM-DP+ to deliver the correct eSIM profile to the eUICC. The eUICC installs and manages the profile state, while ODSA coordinates activation, deactivation and subscription transfer with the operator’s BSS/OSS systems.

‍