Choosing the Right Primary ID for IoT Lines: Why MSISDN Is a Trap

In a traditional mobile account, it's easy to identify a line: you just use the phone number. For smartphones, that works fine as a unique service ID in your inventory and billing systems.

With IoT lines, it's not that simple.

IoT services often don't behave like phones. Many don't use voice at all. Some don't even truly "use" the phone number that the carrier assigns. Yet the same account may contain multiple identifiers:

• ICCID

• MSISDN

• IMSI

If you pick the wrong one as your primary key, your inventory, billing audit, and optimization processes will eventually break in subtle and painful ways.

Let's unpack the options first.

The Three Main IDs on an IoT Line

ICCID - SIM card identifier: ICCID (Integrated Circuit Card Identifier) is the unique ID of the SIM card itself. It's printed on the SIM, stored on the card, and stays tied to that physical (or eSIM) profile.

• One ICCID = one SIM profile

• Used at the card/profile level

• Changes only when you swap or reprovision the SIM

For IoT, the SIM is often the real asset that matters: it's embedded, soldered, or associated with a device that might never expose a "phone number" to anyone.

MSISDN - the phone number

MSISDN is essentially the telephone number assigned to the line.

• What humans dial

• What most people think of as "the line" on a smartphone

• For IoT, often present but not functionally used

On some IoT platforms (like Jasper-type environments), you'll still see MSISDN values, but they can be:

• Dummy or placeholder numbers

• Assigned after the fact

• Recycled across different devices over time

In other words: familiar, but not reliable.

IMSI - subscriber identify

IMSI (International Mobile Subscriber Identify) identifies the subscription on the network.

• Used by the carrier's core network for authentication

• Tied to the SIM profile and operator

• Very technical, rarely used as a business-facing key

It's important for network operations, but less friendly for finance, TEM, or inventory users.

Why MSISDN Is a Bad Primary Key for IoT

If you're used to smartphones, your instinct is to grab the phone number (MSISDN) as the unique ID. That's what many enterprise customers and even TEM providers have done by habit.

For IoT, that can be a serious mistake.

Reasons MSISDN is problematic in IoT:

1. IoT devices are not phones - Many of IoT endpoints never use voice. They send data (and maybe SMS), and the phone number is just a technical artifact in the carrier system.

2. MSISDN can be recycled - Carriers may reuse phone numbers. If a line is disconnected and later a new IoT device is assigned that same MSISDN, your TEM or inventory stem may think the old device came bac to life, or one device has magically transformed into another.

3. MSISDN may be assigned "just because" - On some IoT platforms, MSISDN is created for compatibility with legacy billing or provisioning systems, not because it's used operationally. It might change, get repurposed, or be meaningless in the real-world IoT deployment.

4. Cross-system mismatches - If your TEM, carrier portal, and internal asset system don't all agree on which ID is the "truth," recycled or changed MSISDN values will cause:

   1. Broken joins

   2. Orphaned records

   3. Optimization results that no longer match live inventory

This may work most of the time until it doesn't. When it breaks, you end up fixing it manually, line by line, under time pressure.

When Is ICCID a Better Primary ID?

For IoT, ICCID is usually the best candidate for a primary service ID, especially for billing and inventory integration.

ICCID works well when:

• You care about the SIM/profile as the primary asset

• Devices are deployed in the field and not touched for years

• Voice is not the core service (data and SMS are)

• The SIM is what you ship, track and reclaim when devices retire

Benefits of using ICCID as the primary key:

1. Stability - ICCID does not typically get recycled in the same way MSISDN can. It stays associated with that SIM until you physically or logically replace it.

2. Clear mapping to hardware - In IoT deployments, the SIM is often tied to a specific device or module. If you know the ICCID, you can map directly to that unit in the field.

3. Better alignment with IoT platforms - Many IoT management portals (Jasper-type systems, carrier IoT portals, etc.) treat ICCID as the central identifier, even if they still show MSISDN for legacy reasons.

4. Clear joins across systems - When ICCID is your primary key, your:

   1. carrier billing feeds,

   2. IoT portal exports, and

   3. internal asset/inventory all have a common stable ID to join on.

You can still store MSISDN and IMSI as secondary attributes, but the "truth" of the line should be anchored to ICCID.

Operational Risk of Picking the Wrong Primary ID

Choosing the wrong identifier doesn't always fail immediately. It fails later, and usually at the worst possible time.

If your primary key is MSISDN and the carrier recycles numbers:

• Your inventory and billing won't match

• Optimization tools may:

  • apply changes to the wrong device,

  • miss savings because history looks broken, or

  • double-count usage if the same MSISDN appears with two different physical devices.

I've seen TEM providers default to MSISDN because it feels familiar and "works fine" early on. Then, months or years later, when recycling or large migrations happen, they're forced to untangle everything in production under pressure from the customer.

It's avoidable pain.

Practical Advice Before You Lock In a Primary Key

Before you simply choose what looks familiar:

1. Ask the carrier/platform

   1. Which ID is considered stable for IoT?

   2. Is MSISDN ever recycled or reassigned?

2. Look at real data behavior

   1. Do you see the same MSISDN tied to different ICCIDs across time?

   2. Are there IoT lines with ICCID but no meaningful MSISDN usage?

3. Design your TEM/inventory model for IoT explicitly

   1. Use ICCID as primary key for IoT (in most cases).

   2. Keep MSISDN and IMSI as secondary attributes for troubleshooting and correlation.

4. Document the choice - Make sure your internal teams and external partners (TEM, MSP, carrier) know:

   1. Which ID is your "source of truth"

   2. How to map across systems

Closing Thoughts

IoT may live inside a wireless account, but it is not just "phones without people." Treating IoT like traditional mobility and using MSISDN as your primary identifier is comfortable but risky.

Choosing ICCID as the primary ID for IoT services:

• Reduces reconciliation issues

• keeps optimization tools aligned with reality

• Avoids nasty surprises when numbers are recycled or reassigned

When in doubt, resist the instinct to use the phone number just because that's what you've always done. IoT is a different category of mobile service and your identifiers should reflect that.