Published 2026-09-04 · LuckyMDM Blog
Short answer: whether a rented device genuinely needs enforcement comes down to one action, not one claim - after a factory reset and re-activation, does the device still check back in with the original MDM server? If it does, enforcement is real. If it does not, what was installed was a removable profile, and the moment the device changes hands you have lost control of it. Along that line, the market splits into three tiers of enforcement: profile-based (user-removable, erased by reset), serial-number-level via Apple Business Manager / Android zero-touch (re-enrols after reset), and supervised with a hardware root of trust (the reset itself can be blocked). This page covers the technical boundary between the tiers, a five-minute erase test you can run during procurement, three business shapes that genuinely do not need enforcement, three criteria that make it mandatory, and the remarketing spread between a device you can clear and one you cannot. Caveat: every capability here depends on enrolment state, connectivity, OS version, enrolment method and the authorisation relationship behind it. The purpose is to reduce risk and shorten detection time, not to guarantee an outcome.
Ask whether device rental needs MDM enforcement and you get two confident, contradictory answers. One side says it is non-negotiable. The other side says it does nothing, because their devices still walked.
Both are describing real experiences, just different tiers. The first is talking about serial-number-level enrolment. The second is talking about a profile the customer can delete in four taps. The industry calls both things "MDM lock" or "supervision", which is why the argument never resolves. Separate the tiers and the question answers itself.
The cleanest dividing line is whether the control survives an "Erase All Content and Settings". Sorting the market by that test gives three tiers.
The device is handed to the user with an MDM profile installed. Installation requires a few confirmations in Settings; removal requires the same. On iOS the path is Settings → General → VPN & Device Management, select the profile, tap Remove Management, enter the passcode. Control ends there.
A factory reset is more final. The profile is wiped along with the data, and on re-activation the device is a clean retail unit with no relationship to the previous server.
This tier is cheap to deploy and is what many low per-device monthly plans actually deliver. It is a reasonable fit for employer-issued laptops and phones, where payroll and offboarding processes carry the real weight. Applied to rental, it hands the control switch to the person renting the device.
This tier runs on Apple Business Manager (formerly DEP) for iOS, and zero-touch enrolment for Android Enterprise. The mechanism: before the device is ever activated, its serial number has been registered against an organisation in Apple's or Google's records. When the device boots and reaches the activation step, it queries the vendor's activation service, which replies with an instruction - this unit belongs to organisation X, report to its MDM server.
Enrolment therefore happens inside the setup assistant, and the user cannot skip it. The part that matters for rental is what happens after a reset: the device erases, reboots, runs activation again, queries again, receives the same instruction, and re-enrols. Practitioners call this "uneraseable", which is imprecise - the honest description is erasable, but it comes back.
A side effect worth knowing: at this tier the MDM profile cannot be removed by the user. It can only be lifted by an unenrolment command from the server, or by releasing the serial number inside ABM.
Tier 3 adds supervision on top of tier 2. Once a device is marked supervised, the OS unlocks a set of management commands that only apply to supervised units - and one of them disables erasing the device.
That is the real boundary between the tiers. Tier 1: the user can turn the control off. Tier 2: the user can reset the device, but it lands back inside the control. Tier 3: the user cannot reset it at all.
Tier 3 is still not absolute, and it is worth being precise about where it holds. Since iOS 15, activation lock keys are fused into the Secure Enclave, and remote software-only bypass success rates have dropped to a low single-digit percentage. But Checkm8 is a BootROM-level vulnerability affecting A5 through A11 silicon (iPhone 4s to iPhone X). It is permanent and unpatchable by software update, and the trade-off for using it - lost cellular, lost Face ID or Touch ID - is acceptable to someone who was never going to keep the device. The practical rule: tier 3 is the strongest available control on current hardware running a current OS, and materially weaker on hardware old enough to have a published bootrom path. That is part of why older units trade at a discount, not just depreciation.
Tiers are easy to describe and hard to verify from a datasheet. Run the test instead. Do not rely on marketing language, and do not rely on the text shown on the device.
There are only three outcomes. Erase blocked = tier 3. Erased but re-enrolled automatically = tier 2. Erased and completely clean = tier 1.
Many buyers check Settings → General → About and look for the line stating the device is supervised and managed by an organisation. That line has two problems.
First, it only appears on supervised devices. A tier 2 device - enrolled but not supervised - shows nothing, and is routinely misread as unprotected. Second, it can be edited. After a jailbreak, modifying system files is enough to remove or forge it, which is exactly how laundering operations hide management from a buyer. One documented case involved three engineers who processed more than 7,000 devices in a year through a rent-then-resell chain.
The reliable evidence is elsewhere: the serial number's ownership record in ABM, and the erase test above.
Not every rental model depends on remote control. These three carry a risk structure that something else already covers.
What these have in common: the exposure is already covered by something else.
| Criterion | Threshold | Why it crosses the line |
|---|---|---|
| Unit value | Replacement cost exceeds what the deposit can lawfully cover | Deposits are capped at fair market value, so a deposit alone cannot secure a premium handset |
| Remote fulfilment | The device ships, with no in-person handover | Shipping removes the one control that predates software: physically seeing the unit change hands |
| Term length | Six months or longer | Circumstances change, devices get resold, and OS updates arrive; all three raise the odds of drift |
Of the three, remote fulfilment is the one most often missed. Shipping is now the default, which means the handover check quietly disappears from the process. Once it is gone, device-side state is the only thing left telling you where the asset is - and that is what enforcement actually buys. Its function is not locking a device; it is keeping the device visible for the length of the term.
Converting the tiers into money is clearest at the remarketing end. Take a recent flagship at equivalent cosmetic grade: a clean unit trades at roughly full second-hand market value, while a unit carrying management residue - one that re-enrols after a reset - trades at a substantial discount, with the size of the discount depending on whether it can be cleared properly.
The gap is not caused by damage. It is caused by the next buyer pricing in the risk that the device locks itself later, or re-enrols to someone else's server the moment it is wiped. Two consequences follow:
The full comparison, then, is: the cost of enforcement (per-device subscription or licence) plus the operational cost of clean offboarding, against the combined cost of loss rate and residual-value discount without it. At portfolio delinquency rates in the region of 7% - which is already at the better end of the market, and higher under other denominators - enforcement pays for itself once unit value crosses the second criterion.
These three move the conversation past "yes, we do MDM".
The third question deserves emphasis. Remote lock sits late in the chain. By the time you want to lock something, it is usually already offline or already with someone else. What determines the size of the loss is the interval between "state went abnormal" and "someone acted". Alert granularity and detection latency matter more than how many flavours of lock a vendor offers.
That is the part of the chain where a platform earns its keep. LuckyMDM, for example, treats enrolment state, last check-in timestamp and erase-or-jailbreak signals as ordinary fields in the asset register, so an abnormal device surfaces as a row on a report rather than as a diagnostic exercise. As always, what is actually available varies by brand, model, OS version, enrolment route and network conditions; the compatibility list and a hands-on test settle it, not the datasheet.
Judge on the second criterion, not on scale. If devices ship and unit value exceeds the deposit, a fleet of forty carries the same risk structure as a fleet of four thousand - only the absolute numbers differ. If everything is handed over in person against a full deposit, you can defer it and put the budget into identity verification.
No. Capability depends on enrolment state, connectivity, OS restrictions and the authorisation relationship, and no vendor can responsibly promise an outcome. What it does is shorten the interval before an anomaly is noticed and give you graded options once it is - reducing the probability and the size of a loss, not eliminating either.
Only loosely. Android Enterprise offers device-owner and work-profile modes rather than a single equivalent of supervision, and capability varies materially by OEM and OS build. Some devices support full device-owner management, others only a limited subset. Test on the exact models you buy.
Keep the boundary explicit, and keep it in writing. Management covers device state and asset security - it is not a licence to read contacts, photos or location. Collection scope and purpose belong in the contract and the consent record. Overreach is not only a reputational problem; it undermines the legal basis for recovery later. Consumer protection bodies have flagged exactly this pattern in device rental.
In order: confirm the account is settled; unenrol from the MDM server and confirm the profile is gone from the device; release the serial number in ABM; have the renter sign out of iCloud and turn off Find My; then erase and inspect. Getting the activation-lock and MDM steps in the wrong order is how a working device becomes a brick, or stays managed without anyone noticing.