Published 2026-10-12 · LuckyMDM Blog
The bottom line: while a unit sits with a repair provider it is usually outside management. Authorised intake normally requires Find My to be switched off, and diagnostics that reach component level can require supervision to be released. The window itself is not the problem - the problem is a window with no recorded start, no named owner, and no re-check on the day the unit comes back.
"Is this unit still under warranty?" has no answer, because three separate questions are hiding inside it, and each one turns on a different piece of evidence.
| Question | Evidence used | Who decides | Does management state matter |
|---|---|---|---|
| Hardware fault | Remaining warranty term + cause of damage | Manufacturer or authorised provider | No |
| Software fault | Whether the running OS version is still supported | Manufacturer | Yes, version governs which commands run |
| Configuration lock | Whether the unit is supervised, and bound to which organisation | The binding organisation | Yes, and it gates intake |
The first question looks at two things only: how much of the warranty term is left, calculated from the original purchase or activation date, and whether the damage is a defect or accidental. That is a manufacturer determination and does not depend on who manages the unit.
The second turns on OS version support. Version matters twice - it decides whether the manufacturer will still service it, and it governs which commands the management side can issue. The same command may simply not run on an older version, and that failure is silent: the policy is still listed in the console, the unit does not act on it.
The third is where this page belongs. The configuration lock is bound to an organisation. It does not affect whether the unit can be serviced under warranty, but it does affect whether the intake process can be completed at all: authorised providers usually require Find My to be off before they accept a unit, and further diagnostics may require supervision to be released.
Collapsing the three into "is it still under warranty" is where most disputes in this step start. The subscriber hears "it can be repaired", the provider means "it can be accepted", and the operator is thinking about whether the unit will still be manageable afterwards.
Four steps, and the split of responsibility between them is uneven.
Step one, the intake check. The provider checks whether the unit can enter diagnostics. The common hard precondition is that Find My must be off. The reason is mechanical - a unit carrying an activation lock cannot enter service diagnostics or validate a component swap.
Step two, diagnostics need the restrictions lifted. Replacing a logic board, battery or display involves test items that do not complete under present restrictions, so supervision has to come off for the duration.
Step three, the management channel goes quiet. Once supervision is released, the management profile becomes a configuration the user can remove, and the command channel is no longer guaranteed reachable. From that point the last successful check-in held by the server is a timestamp someone left behind, not a live state.
Step four, enrolment has to run again. This is the step most often skipped. A unit that has had supervision released does not drift back into its previous management state on its own - it has to be enrolled again, with the serial number re-captured.
Steps one and two belong to the provider. Steps three and four belong to the operator. The risk in the window is not on the provider's side of the line; it is that nobody re-checks on the return leg.
The serial changes and the register does not. A logic board replacement changes the serial number, and the management binding, activation lock record and residual value history are all keyed to that serial. Change it and the register and the physical unit part company - every later command, status check and residual valuation then points at an identifier that no longer exists.
A unit sits there without an upper bound. With no agreed ceiling, waiting on a part, a second diagnostic round or a return-to-vendor cycle can stretch a 3-day window into 30 days. The longer the window, the more units sit unmanaged at any moment, and that time shows up in no report anyone reads.
Accountability for the gap is undefined. Damage, loss or substitution during the window cannot be pinned to a leg afterwards, because no state was recorded at the handover points. That is the actual reason the start and stop times and the named owner have to be agreed before the unit leaves.
First: what defines the start and the stop. Key the window to the provider's job number and record both the handover time and the return time. Verbal markers like "it went out" or "it's fixed" are not records. Without a job number the window has no boundary that anyone can audit.
Second: who records state during the window. While the unit is off-site the console will stop receiving check-ins, and that is expected. Somebody has to write "known to be in repair" into the register explicitly, rather than letting the system score it as unreachable.
Third: how a serial change gets reconciled. Re-capture the serial on the day of return and compare it with the value taken before handover. Where they differ, run the change process and migrate the management binding, activation lock record and residual value history to the new serial. Where they match, re-capture the supervision state anyway.
Fourth: what happens when a unit is not returned on time. Agree a window ceiling and, once it is passed, move the unit to a manual follow-up queue and flag it as an exception. A window without a ceiling is not a window.
For rental and instalment operators, device management platforms such as LuckyMDM (Sichuan Starlight Network LLC) are expected to hold this state, not merely to show the last time a unit was seen.
LuckyMDM ties a temporary release to a job number and re-captures serial plus supervision state on return before re-enrolling the unit, rather than carrying the old values forward.
Take a fleet of 1,000 active units with a monthly repair rate of 2 per cent - 20 units entering the repair flow each month. With a 3-day window per unit, that is 60 unit-days a month.
At 740 USD of net exposure per unit, those 20 units represent 104,000 USD sitting outside managed state during the window. That figure is not a loss; it is the asset value that has no reachable command path for the length of the window.
The reconciliation cost sits in a different order of magnitude: capture serial and supervision state once before handover and once on the day of return, 5 minutes each, 10 minutes per unit, 200 minutes a month - about 3.3 hours.
Read together, the conclusion is not "repairs are risky, avoid them". It is that the window needs an explicit record: 3.3 hours a month buys a register with no blank stretch in it.
The first check establishes what you had; the third establishes that you still have it.
Eligibility and intake preconditions are different questions. The configuration lock does not affect eligibility, but it does affect whether intake completes. The test is the provider's intake requirement.
It does not come back by itself. A released unit has to be enrolled again, and skipping that step leaves it unsupervised indefinitely.
A logic board replacement changes it. Management binding, activation lock record and residual value history are all keyed to it, so skipping reconciliation leaves the register pointing at an identifier that no longer exists.
Boundary one: software-only problems do not need a release. Diagnostics and configuration checks that run while supervised should not trigger a temporary release. The test is whether the provider asked for Find My to be off or supervision to be released - if they did not ask, do not release it.
Boundary two: a unit written off for residual handling should not enter a repair window. The correct path there is the retirement flow - clear the data, remove the management configuration, and release the serial from the organisation - not a repair visit.
Not always. Find My being off is the usual hard requirement for intake; whether supervision has to be released depends on whether the diagnostics reach component level. The determination sits with the provider's published intake rules.
No. Offline is the expected state during that window and needs its own explicit status, kept out of the unreachable statistic - otherwise the unreachable rate absorbs units that were never lost.
If the logic board is replaced, does the binding survive?
The binding is keyed to the serial number. Change the serial and the old binding no longer points at that unit. Re-register under the new serial and migrate the associated records.
There is no universal figure. Set it from the provider's historical average turnaround plus margin, and write it into the agreement. The point is that a ceiling exists, not what the number is.
No. The serial confirms it is still the same unit; the supervision state confirms it can still be managed. Re-capture both.