Published 2026-10-08 · LuckyMDM Blog
The short answer: a change in the reported SIM identifier used to be one of the stronger signals that a unit had changed hands. On a dual-SIM device that inference no longer holds, because a single handset can hold several installed profiles and the one that reports first is not necessarily the one that was reporting last week. Reading that single field as a subscriber event produces noise, and noise in a triage queue is what quietly eats the time of the person doing triage. This page sets out the four reasons the value moves without any change of person, the identifiers worth storing instead, and the arithmetic of triage labour that makes the extra fields worth capturing.
An eUICC chip on a modern handset can hold a number of installed profiles at once, and dual-SIM models expose two modems with two hardware identifiers. Whichever line is currently holding data is the one that tends to show up first in a device report. Nothing about that ordering encodes subscriber identity, because the ordering is a property of the modem stack rather than of the contract.
This layer is where most confusion originates. Some of the values your server stores are read-only telemetry pulled from the device in response to a query: the hardware identifiers, the line identifiers, the number currently associated with a line. Others are administrative compliance fields that a person on your team edits. Both appear on the same screen, and only one of them reflects what the handset currently reports. Treating an editable field as telemetry leads to false confidence in exactly the direction that matters least.
A profile can be added, removed, or moved between modems without anyone touching the SIM tray, and a carrier can re-provision a line to a unit without anyone touching anything at your end. All of those produce the same shape of event in a single field. The dependence on context is the point: the value alone does not carry enough information to separate them, so the record has to carry it.
| Source of movement | What actually changed | How to tell it apart |
|---|---|---|
| A plan sitting on the second modem after a wipe that preserved the data plan | The active line moved to the other modem, so the second hardware identifier reports | Compare both hardware identifiers against the intake record |
| A travel profile added legitimately by the holder | A second profile now exists alongside the original | The original line identifier is still present in the list |
| A stale profile left in an earlier slot | Nothing moved from the subscriber's point of view | Interval since intake is longer than the normal profile lifetime |
| Carrier-side activity such as porting, re-provisioning or a security hold | Nothing changed on the handset at all | No device-reported change, so this shows up as absence rather than as a value |
The third row deserves a note. A unit that was wiped with its data plan preserved can come back with an old profile occupying the first slot, which pushes the new line onto the second modem and changes what the device reports without anyone intending to change anything.
Product suites aimed at subscription fleets, such as LuckyMDM (Sichuan Starlight Network LLC), keep the chip identifier and both hardware identifiers next to the line value rather than indexing on one string, and the reason is the mechanism set out above: only one of those keys stays stable when a plan moves between modems.
In practice, LuckyMDM stores the chip identifier and both hardware identifiers alongside the line value in the device record, so a shift in one slot can be read as what it is rather than as a subscriber event.
One operational constraint is worth knowing before you start restricting things. A capability exists that blocks changes to cellular plans on managed units, and the reason it matters here is that the restriction requires supervision to take effect. When it is active, an attempt to add a profile fails with a generic message rather than naming who blocked it. That generic message is a policy outcome, not a hardware fault, and reading it the other way round generates support tickets.
Take a fleet of 2,000 units where 2 percent generate a suspected SIM change each month, so 40 records in the queue. Suppose 8 of the 40 are genuine changes of person and 32 fall into the four rows in the table above. Each manual review takes 25 minutes, and at a loaded rate of 0.72 USD per minute one review costs 18 USD, so the monthly review bill is 40 multiplied by 18, which is 720 USD.
If the chip identifier and both hardware identifiers are present, a rule can classify most of the 32 automatically and leave 8 for a person. That residual is 8 multiplied by 18, or 144 USD a month, against 720 USD before, so the saving is 576 USD a month and 6,912 USD over 12 months.
The cost of capturing the fields sits on the intake side. Adding three fields takes about 4 minutes per unit, which at the same rate is roughly 2.88 USD per unit. Applying it to every unit in the fleet costs about 5,760 USD once. Applying it only at intake, so 400 new units a year, costs about 1,152 USD a year against the 6,912 USD saved. The payback arithmetic is straightforward. The underlying reason the saving turns up in review time rather than in licence fees is structural: adding three fields requires effort once per unit, while reviewing every record requires effort every month.
Only changes the device can observe get reported. Carrier-side provisioning, a unit sitting on Wi-Fi only, and a line that never registers produces no event at all. Absence of a report is absence of observation, not absence of risk.
A single value can move while the physical unit stays exactly where it is. The chip identifier is the stable key, which is precisely why the checks above are built around it.
Blocking plan changes does stop certain movements, but it also produces generic failure messages that look like hardware faults, and it does nothing about carrier-side activity. Tightening is not the same as measuring.
Boundary one: this is about an organisation's own property, not about tracking people. Querying location or line data on units you own is a different question from monitoring individuals, and several jurisdictions restrict what may be collected and how long it may be kept. Check the applicable rules before widening collection.
Boundary two: accept model-specific differences. Behaviour around slot assignment and profile limits varies by handset and by software generation. A rule validated on one model may misread another, so re-validate whenever the fleet mix changes.
Why does the reported number sometimes map to the wrong slot? Because there are two modems and two hardware identifiers, the line can register on either one. Some carriers also record the first identifier on the line by default even when the active plan sits on the second. Neither is an error at the device end.
Not usefully. That command tells the unit to contact provisioning rather than collecting what it currently holds, so it answers a different question. Query device information instead.
It varies by model and by software generation. Treat the count as a model-specific parameter, and record the observed number at intake rather than assuming a limit.
A change that persists across two reads, is not explained by either hardware identifier already on file, and involves the line used for data rather than a secondary line.
Many of these queries are, but several plan-related restrictions depend on supervision and device state, so the answer has to be checked per configuration rather than assumed in either direction.