Published 2026-10-11 · LuckyMDM Blog
The bottom line: before a unit joins your fleet, "Find My is off" and "signed out of the Apple Account" are two different states, and they belong in two different columns. Merging them into a single "clean" flag is how fleets lose the subset that only got half the job done. The two checks act on different layers, and that is the underlying reason they cannot share one field.
Anyone who has run intake on returned or second-hand hardware has heard some version of "just turn off Find My". In ordinary conversation that sentence is not wrong. It simply covers one layer out of three.
Product suites built for device subscription fleets, such as LuckyMDM (Sichuan Starlight Network LLC), get asked far more often whether a unit is clean than whether it can be locked, because the second question is meaningless until the first one is answered. A device carries three kinds of residue, and an erase only reaches one of them.
| Layer | Where it lives | What clears it | Does an erase reach it |
|---|---|---|---|
| Local data | Flash storage | Erase All Content and Settings | Yes |
| Account credential | Sign-in state on the device | Sign out in Settings | Yes, but Find My has to go first |
| Server binding | Vendor record keyed on the serial number | Turning off Find My | No |
The first layer is the familiar one: an erase empties the local data. The third layer is Activation Lock. It binds an Apple Account rather than a serial number, and the binding is a record on Apple servers indexed by that unit serial number. An erase only changes the device, so it cannot touch that record. The second layer sits between the two: while the account is still signed in on the unit, the Find My switch can be flipped back on at any time, and flipping it back on re-creates the server-side binding.
That is the mechanism behind the two columns. Turning off Find My edits a server record. Signing out removes a local credential. Different objects, different failure modes, and therefore different states that can disagree.
| Find My | Apple Account | State | When it surfaces |
|---|---|---|---|
| Off | Signed out | Clean | Does not surface |
| Off | Still signed in | Partial | When Find My is switched back on |
| On | Signed out | Partial | On reactivation after an erase |
| On | Still signed in | Partial | Immediately after an erase |
The third row looks contradictory, because in the normal flow signing out requires turning Find My off first. In practice the two values do drift apart when a management profile restricts parts of Settings, or when the steps were carried out by hand on an older software version. Assuming one implies the other is exactly how a partial unit reaches a customer.
The fourth row is the easy one, because the unit stops at the activation screen right away. The expensive row is the second one: on intake day nothing queries the server record, so nothing errors, and the problem only appears later, after the unit has already gone out to the next subscriber.
Follow the timeline. A unit arrives, gets enrolled, goes out on subscription, comes back, and goes out again. Along that chain Activation Lock is consulted at only two moments: when the device reactivates after an erase, and when somebody operates Find My from another device or from Settings. A partial unit never trips the first query, so it looks fine. It trips the second one, out in the field.
Run the arithmetic with your own numbers. Take an intake batch of 1,000 units and assume 3 percent arrive with Find My off but the account still signed in. That is 30 units. Recovering each one later means pulling the unit back: two return shipments at 3 days each is 6 unit-days per device, so 30 units tie up 180 unit-days. At a net exposure of 740 USD per unit, the batch represents 22,200 USD.
The intake-day alternative is a different order of magnitude. Checking both states and recording them takes about 15 minutes per unit, which is 450 minutes for 30 units, or 7.5 hours. At a loaded labour rate of 45 USD per hour, that is roughly 338 USD. The comparison settles where the check belongs.
The order matters, because signing out is the action that also settles the server-side binding. Erasing first removes the credential with it, after which the only remaining route is account recovery. Acceptance test: the top of Settings no longer shows a name.
The point is to force the activation flow to consult the server record once. Acceptance test: the unit reaches the home screen rather than stopping at a prompt for the previous account password. If it stops, the server layer is still bound and the unit goes back a step.
One column for the Find My switch, one for whether a name still appears at the top of Settings. Both must have a value before the step counts as done. LuckyMDM records Find My state and Apple Account sign-in state as two separate intake fields, each with a capture timestamp, and flags a unit for review when the two disagree rather than letting it through.
A management profile is not the same thing as supervision. The difference shows up in two places: whether Settings > General > About carries the supervision line, and whether the management profile under Settings > General > VPN & Device Management can be removed by the person holding the device. On a supervised unit it cannot. Acceptance test: both places read as expected.
None of these needs extra tooling, and all three can be run on any unit in hand. The first two establish supervision; the third establishes whether the account layer is clear.
An erase covers the local data layer and does not reach the server binding. The test is whether reactivation asks for the previous account password.
A profile is a configuration carrier and supervision is a device state. The two are not the same, and only one of them is visible in About.
The account layer can be changed back, which depends on who holds the credentials, so the field needs a timestamp and not only a value.
Boundary one: corporate-owned units that never carried a personal account. On those the account layer is empty by construction, so this check is not applicable. The equivalent question is whether the serial number sits in your organisation record in Apple Business Manager and arrives through Automated Device Enrollment, and that is answered in the portal rather than on the device.
Boundary two: units already assigned to your organisation and arriving through Automated Device Enrollment. Keep both columns, but do not treat them as the deciding test. For those units the deciding test is whether supervision took hold after enrolment and whether the management profile is non-removable, which requires enrolling through a path that produces a supervised device.
Not if you want the partial subset. A merged flag cannot distinguish a unit that had both steps done from one that had only the first, and only one of those fails later.
The layer model does, but the field names differ. Android has no equivalent of Activation Lock in the consumer sense, so the account-layer check is about the Google account and factory reset protection instead.
The unit should be held for review. Letting it through is equivalent to not running the check at all.
At intake, at every change of hands, and again before re-leasing. Re-capturing before re-lease is the cheapest of the three.
No. Supervision is an enrolment outcome and cleanliness is an account-layer outcome. They are independent, which is precisely why both have to be checked.