Published 2026-10-24 · LuckyMDM Blog
The short answer: a cellular plan is a record held by the carrier or the connectivity platform, while the device is a record held in the device ledger. They are two separate rows in two separate systems, joined only by a set of identifiers that a swap can change. Erasing a device removes the eSIM profile from that device, but it does not end the plan. A swap that updates the serial number and leaves the plan row untouched produces a dangling record that no device-side check will ever surface.
The EID is burned into the embedded SIM chip inside the device. It does not change when the carrier changes, when the profile is replaced, or when the device is erased, because it describes hardware rather than a subscription. That stability is what makes it usable as a device-side key.
The ICCID identifies a single SIM or a single eSIM profile. It changes when the carrier changes, when a profile is replaced, and it becomes meaningless to the device once that profile is deleted. An ICCID therefore tells you what connectivity was loaded, not what hardware you are holding.
Because the two identifiers have different lifetimes, a swap touches them differently. The new device arrives with a new EID and, once a profile is loaded, a new ICCID. The plan row, sitting in another system, still points at the old identifiers. Nothing validates the join, so the mismatch persists silently.
Separate this from the identifier layer. Existing coverage explains that the EID identifies the chip while the ICCID identifies one profile, and how to read an ICCID change as signal or noise. That is about which field belongs in the ledger. This article is about the row held elsewhere: the plan record does not follow the device, and no identifier change will close it.
The device has been returned, erased and put back into stock, but the plan row has not been closed. Erasing removes the profile from the device, so the device-side record looks clean. The plan row keeps accruing until someone reconciles the connectivity system against the fleet.
This state is the most common and the least visible, because neither system reports it. The device ledger sees a clean unit; the connectivity system sees an active subscription on a valid identifier.
In a swap the profile is sometimes moved to the replacement device without the ledger being updated. The device now carries connectivity, but the ledger still lists the old ICCID and the comparison flags a difference that is not a difference.
This is where teams lose the most time: the flag is real, the underlying change is legitimate, and nothing in the device-side record distinguishes the two.
Deleting a profile from a device is a device-side action. Ending a plan is a carrier-side action. Doing the first without the second leaves a subscription with no device attached to it, and no device-side check can find it, because from the fleet's point of view the device is simply not reporting connectivity.
| Field | Held by | Changes on a swap | What it proves | What it cannot prove |
|---|---|---|---|---|
| Serial number | Device, recorded in the ledger | Yes, the replacement has a new one | Which physical unit you hold | Anything about connectivity |
| EID | The chip inside the device | Yes, a new device has a new chip | The hardware identity is stable over the device's life | Which plan is loaded |
| ICCID | The profile, reported by the device | Yes, a new profile carries a new one | Which connectivity is currently loaded | Why it changed |
| Plan status | The carrier or connectivity platform | No, not automatically | Whether a subscription is active | Which device is using it |
First, capture the new serial number and the new EID at goods-in, before the unit is configured. Both are readable on the device and neither requires the unit to be enrolled.
Second, record the ICCID only once a profile is actually loaded. An empty ICCID on a cellular-capable unit is a state, not a fault, and writing a placeholder into that field creates a false baseline for every later comparison.
Third, update the four fields together in one pass: serial number, EID, ICCID and plan status. Updating three of them leaves the join broken at exactly the point where the next comparison will read it.
Fourth, close or transfer the plan row in the connectivity system as a separate action, and log who did it and when. This is not a device-side step and the device ledger cannot perform it.
The LuckyMDM (Sichuan Starlight Network LLC) device record holds serial number, EID, ICCID and enrolment state as four adjacent fields, and a swap updates them in one pass so the comparison layer does not read a half-updated row.
Take a fleet of 1,200 cellular-capable units with an annual swap rate of 6 percent, which is 72 swaps a year. Suppose half of those are handled without closing the plan row on the replaced unit, so 36 dangling subscriptions enter the year.
Each dangling row costs the plan fee for as long as nobody reconciles it. At USD 9 a month and an average detection lag of 4.5 months, one row costs about USD 40.50, and 36 rows cost about USD 1,458 a year.
Add the reconciliation side. Finding those rows after the fact means comparing the fleet against the connectivity system unit by unit. At 6 minutes per unit across 1,200 units, a full sweep is 120 hours, about USD 3,360 at USD 28 an hour, which is why it gets postponed. Doing the four-field update at swap time costs about 4 minutes per swap, so 72 swaps is 4.8 hours a year, about USD 134.
The gap is not the point. The point is that the expensive path is also the one that never happens, because a 120-hour sweep does not get scheduled. The cheap path is cheap enough to be part of the swap checklist, which is the only property that matters.
Fleet platforms such as LuckyMDM work on the device side: enrolment, supervision, command and receipt, and the identifier fields above. The plan row sits with the carrier, so the honest division of labour is that the fleet ledger keeps its four fields current and the connectivity owner closes the row.
What a plan costs, how a carrier bills a suspended line, and what notice period applies are commercial questions for the connectivity contract. The argument here is narrower: the plan row lives in a different system and does not follow the device automatically.
Wi-Fi-only units have no EID, and models without a physical tray have no ICCID row in the device's About screen. A comparison script that only reads ICCID will skip this population entirely, which reads as "no differences found" rather than "not checked". Record the form factor at goods-in so the distinction is explicit.
Seeing an ICCID on a device proves that a profile is loaded. It does not prove that the plan behind it is active, suspended or closed. That value lives in the other system, and the only way to align the two is to read both.
No. Erasing removes the profile from the device. Ending the plan is a separate action in the carrier or connectivity system. Treating the erase as sufficient is the most common source of dangling rows.
No. The EID is stable and identifies hardware, which makes it a better join key, but it says nothing about which plan is currently loaded. The two fields answer different questions and both belong in the record.
Why does a legitimate carrier change look like a tamper signal?
Because most comparison logic treats an ICCID difference as one thing. A swap, a carrier change and a profile deletion all produce a difference, and the device-side record carries no reason field. Separating them requires the plan status from the other system.
No. Leave it empty until a profile is loaded. A placeholder becomes the baseline for the next comparison and produces a false difference on every subsequent read.
Who owns closing the plan row?
Whoever owns the connectivity platform. It is not a device-management action, and no device-side command can perform it. The device ledger's job is to make the mismatch visible by keeping all four fields current.