Published 2026-10-14 · LuckyMDM Blog
The bottom line: an ICCID identifies a SIM or an eSIM profile, while an EID identifies the eSIM chip inside the device. The first changes whenever the card changes, the profile is re-downloaded or the carrier changes; the second is fixed in hardware and does not move with the plan. On hardware with no physical tray, the EID is therefore the value that belongs in the register as the stable identifier, and the ICCID belongs beside it as a value that is expected to move.
The symptom is easy to recognise. A batch of tray-less units is booked in and the ICCID column either will not populate or changes on its own a few weeks later. The console raises a run of SIM-change alerts, someone reconciles them by hand, and nothing has actually happened.
The immediate cause is treating the ICCID as a stable identifier for the device when it identifies a profile.
The underlying mechanism is easier to hold once the three numbers are separated:
| Identifier | Length | What it identifies | Who writes it | Does it change |
|---|---|---|---|---|
| IMEI | 15 digits | The device | The manufacturer | Can change after board-level repair |
| EID | 32 digits | The eSIM chip inside the device | Fixed by the chip maker | No - not with plan, carrier or profile changes |
| ICCID | 19 to 20 digits | One SIM card or one eSIM profile | The carrier or the profile issuer | Yes - on swap, replacement, carrier change or re-download |
Only the EID satisfies both conditions a register needs: it travels with the hardware and it does not move on its own. The ICCID satisfies half of the first one - it identifies the communication identity of the device for as long as that profile exists, and profiles are replaceable.
Two failure modes follow directly. Use the ICCID as the primary key and every carrier change looks like a SIM swap. Use the EID as though it were an ICCID and you lose the signal entirely, because the EID has no reaction to profile-level events.
| Slot format | ICCID row on the device | Primary key in the register | Comparison field for SIM checks |
|---|---|---|---|
| Single physical SIM | Yes, one row | ICCID | Current ICCID against the recorded value |
| Dual physical SIM | Yes, two rows | Both ICCIDs recorded | Each ICCID against its recorded value |
| eSIM only, no tray | Absent or empty | EID | Current ICCID against the previous reading; skip the check when there is no previous reading |
The third row is where fleets go wrong. On a tray-less unit the ICCID row is normally absent or blank, so a collector that only knows how to read an ICCID leaves the column empty - and the SIM-change job then quietly skips every unit in that batch. Skipping looks safe. In practice those units have no signal at all.
The same model can ship with different slot formats in different markets, so the test is what the device itself reports, not the model name on the purchase order.
| Parameter | Value used here | Note |
|---|---|---|
| Fleet under management | 1,000 units | Substitute your own count |
| Share with no physical tray | 8 percent | 80 units |
| Carrier or profile changes per quarter | 12 percent | About 10 ICCID changes |
| Reconciliation time per change | 20 minutes | History lookup, contact, filing |
| Quarterly reconciliation labour | 200 minutes, about 3.3 hours | 10 changes at 20 minutes |
| Handling time per false positive | 2 hours | Explanation, release, follow-up after a wrong lock |
| Cost of one false positive | One replacement acquisition cost | A customer who does not renew costs an acquisition cycle |
| Reconciliation labour with the EID as key | About 0.5 hours a quarter | Only new profile timestamps need review |
The point of these numbers is structural rather than financial. With the ICCID as the key, workload scales with customer activity. With the EID as the key, workload scales with fleet size. The more active the customer base, the more expensive the first arrangement becomes.
Physical tray units. Collect IMEI, the ICCID in slot one, the ICCID in slot two where a second slot exists, and the EID where the model supports eSIM. Four columns, never one concatenated string.
Tray-less units. Collect IMEI and EID. Record the ICCID as a pair - the value read and the time it was read - and mark the slot format on the model record as eSIM only. The distinction that matters here is between no ICCID and a changed ICCID: the first is a property of the model, the second is an event.
Both paths share one requirement. Every value carries a collection timestamp. A value without a timestamp cannot be dated later, so an old reading and a current one become indistinguishable.
For rental and device-subscription fleets, platforms such as LuckyMDM (Sichuan Starlight Network LLC) keep this decision on the model record rather than inside the collection script, and that is the reason: the script only reads values, while which value serves as the primary key is decided by the hardware.
Our page on where the SIM sits explains why dual SIM weakened what an ICCID check can prove, and covers triage once a value has moved. Our page on ICCID mismatch and its three origins covers how to classify a mismatch after it is raised. This page sits before both of them: which number should be the primary key from the moment a unit is booked in. One page reduces the alerts; the other two handle what is left.
On tray-less hardware there is no ICCID to read. A missing value is a property of the model, not an event, and the slot format column is what separates the two.
The EID is fixed in the eSIM chip and is not writable under the specification. What changes is the profile, and the profile is what the ICCID tracks.
On dual-SIM models that also support eSIM, a customer can enable the embedded profile and stop using the physical card. Recording only the physical ICCID loses the signal from that moment on.
Boundary one: fleets that use physical SIMs and rarely change them still have a working signal in the ICCID. This page argues for splitting by slot format, not for replacing the ICCID everywhere.
Boundary two: the EID does not substitute for SIM-change detection. Its stability is the advantage and the limitation at once. Detecting a change still depends on reading the ICCID and its timestamp. The two work together rather than one replacing the other.
The EID is 32 digits, an ICCID is 19 to 20 and an IMEI is 15. Length is the quickest test; the field name is the reliable one.
Yes. Slot formats vary by market for the same model, so the test is what About reports on the device - not the model name and not the description on the purchase order.
A customer downloads a new eSIM profile. How should that be recorded?
As a profile event: the new ICCID, the time it was read, and the fact that the EID did not change. An unchanged EID means the chip was not replaced, so this is a communication-identity change rather than a device change.
On a dual-SIM unit, do both ICCIDs need checking?
Both should be recorded and both compared, because a customer may change only one slot. Comparing a single slot leaves half the surface unobserved.
Update the slot format from the reading and move the unit onto the other collection rule. Keep the historical value and its timestamp; the change of format is itself worth keeping.
LuckyMDM keeps slot format as its own field on the model record, takes the EID as the registered identifier for units with no physical tray, and stores the ICCID as a timestamped value expected to move, so SIM checks run down two separate paths by format.