Published 2026-10-13 · LuckyMDM Blog
Bottom line: management enrolment, activation lock binding and residual value records are all keyed to the serial number, so when a logic board is replaced the serial changes and the register has to be migrated with it. Relying on the serial alone will not surface a re-shelled unit, which is why identity needs a composite match on serial plus IMEI, captured against an intake baseline and stamped with a capture time.
Two mechanisms sit underneath that. The first is the index problem: enrolment records and manufacturer-side ownership records are indexed by serial, so once the serial changes the existing record points at an identifier that no longer exists. The second is identifier strength: re-shelling changes the housing and some readable identifiers but leaves the serial alone, which a single-field comparison cannot detect. The two need separate handling and should not share one rule.
Three things hang off the serial. Enrolment in the management service hangs off it. Activation lock binding hangs off it. Residual value history hangs off it. The reason all three use the same key is that it is the primary key in the manufacturer-side ownership record, which is why you can query the configuration lock state of a unit that is currently offline.
A logic board replacement changes that key. At component level, the board is one of the parts that carries its identifiers with it, so the serial a repaired unit reports is not the serial it reported before. What follows is two orphan records rather than one:
The two do not reconcile themselves. Migration has to be an explicit action: retire the old serial, register the new one as the current identifier for the same unit, and carry across the fields that travelled with the old serial, including warranty expiry, intake date and the condition baseline.
Re-shelling and board replacement are different events. A re-shell swaps housing, display or battery. The serial survives, but the appearance changes and so do some identifiers read through software interfaces, and identifiers rewritten through unofficial channels are not trustworthy in the first place.
Catching it therefore requires a composite match rather than a single field:
The IMEI itself deserves care. It is 15 digits: a type allocation code, a serial number, and a Luhn check digit. That structure makes it possible to verify that a number is well formed and to look up who the code was allocated to, and in markets where operators contribute, to check whether the number has been reported lost or stolen. Coverage varies by country, so participation is a premise of the check rather than a guarantee. What the structure cannot do is prove the number has not been rewritten, which is exactly why it belongs in a composite match rather than standing alone.
| Scenario | Serial | IMEI | Housing and parts | Register state | Correct handling |
|---|---|---|---|---|---|
| Normal service | Matches intake baseline | Matches intake baseline | No sign of replacement | One active record | Nothing to do |
| Logic board replaced | Changed, no longer matches baseline | Usually still matches baseline | Repair record may exist | Old record orphaned, new record missing | Retire old serial, register new one, migrate warranty and condition baseline with it |
| Re-shelled | Matches baseline | Matches baseline | Housing or display swapped | One active record that no longer matches the physical unit | Flag for review, regrade condition, do not overwrite the baseline |
The third row is the one that gets missed. Serial and IMEI both line up, so the obvious conclusion is that nothing happened, while the unit has already left in a different condition from the one the residual value was written against. The error stays invisible until a buyback quote comes back lower than the book.
Whether any of this works depends on four columns:
Drop any one of them and the table above cannot be evaluated. Capture time is the one most often left out, and it is the one that matters most: account-level state can be changed back, and a value with no timestamp cannot prove whether it was read before or after the change.
Migration has a window, and the length of the window is decided by process rather than by technology. Between a repaired unit going back into service and the register catching up, the unit has no identity on the management side: commands cannot reach it and state does not come back.
The workable arrangement is to attach migration to the return step of the repair job. On the day the unit comes back, re-read the serial and the supervised state, compare them against what the job says was done, and establish whether the board was involved. Where it was, migrate in the register on the spot, and until that is done hold the unit in a pending-admission state rather than managed. LuckyMDM, operated by Sichuan Starlight Network LLC, keeps two rows here rather than one: the old serial marked retired and the new serial marked current, linked by the job number, so the current identifier is queryable and the previous one is still reconstructable.
Take 1,000 units under management. At an annual repair rate of 2 percent that is about 20 repairs a year, and component-level work involving the board is roughly 30 percent of those, so about 6 units. Migration at 10 minutes each is 60 minutes a year, which at 45 USD an hour is around 45 USD.
Against that, a single missed unit carries its own net exposure. At 740 USD of net exposure per unit, one missed migration costs more than sixteen times what it would have cost to migrate all six properly. And the missed unit is not a one-off: it stays marked managed in the register until the next full reconciliation happens to catch it.
The serial is not permanent. It is bound to the board, and the board is a replaceable part. Treating the serial as the identity of the device rather than as an index into a record is where every problem in the board replacement scenario starts.
The IMEI is not unwritable. It is dependable inside a composite match with a serial and an intake baseline. Used alone as the identity of the unit, it will not distinguish a machine whose number has been changed.
Re-shelling is not cosmetic. The serial survives, which is precisely why the condition baseline silently stops describing the physical unit, and why the discrepancy only surfaces at buyback.
A whole-unit swap is not a migration. Replacing a unit means two different devices, releasing the old serial, enrolling the new one, and deciding how the term and warranty start dates are handled. A board replacement is one device changing an identifier, and the register action is a migration rather than a release and re-enrolment. The two look similar in a console and are not the same job.
Android does not share the same identifier set. Android devices expose IMEI and MEID, but there is no manufacturer-side ownership record keyed on serial in the way Apple maintains one, and the configuration lock registry is queried differently with different failure conditions. The columns can be shared; the rule has to be written per platform.
After a board replacement, can the previous warranty history still be found?
Yes, but only under the old serial. Warranty is indexed by serial, so expiry dates have to be carried to the new identifier during migration, otherwise the history is unreachable from the record people actually look at.
Yes. Enrolment is registered against a serial, so the relationship held under the old identifier no longer points at this hardware. Enrolment has to be established under the new one, and supervised state confirmed again once it is.
By comparing condition and part records against the intake baseline, not by reading current values. Where serial and IMEI both match but the physical condition does not match the baseline, flag the unit and regrade it.
To the minute is enough. The distinction being drawn is before and after one repair, so seconds are usually unnecessary, but a date alone cannot separate two reads on the same day.
The columns can be shared; the rule cannot. Without an Apple-style serial-keyed ownership record, and with configuration lock queried through a manufacturer registry with different failure conditions, one rule applied across both platforms will misclassify.
ISO/IEC 27001:2022 control 5.9 asks for an inventory of associated assets that is maintained and identifiable, and an asset that changes its primary identifier mid-life is exactly the case that control is written for. Serial-level tracking is also what recycling standards such as R2v3 and e-Stewards rely on for chain-of-custody evidence downstream. LuckyMDM stores serial and IMEI as two independent columns captured at intake, flags any later mismatch against that baseline for review rather than overwriting it, and links a retired serial to its replacement through the repair job number.