Published 2026-10-15 · LuckyMDM Blog
Bottom line: a device management console has two kinds of commands, and they deserve two different control levels. Policy pushes and app deployments can be undone. Remote lock, erase, and release of a serial number from the organisation record cannot. For the second group, requiring a second approver is not bureaucracy; it is the only control that catches the failure mode that actually happens, which is not malice but a wrong selection made quickly.
Most fleet teams adopt approval workflows only after an incident. The incident is rarely dramatic: someone selects a filtered list, intends to lock 12 units, and the filter still holds 120. The command succeeds, the receipts come back clean, and 108 customers discover the problem before the operator does.
The dividing line is not severity. It is whether the device returns to its prior state on its own.
| Command | Reversible | What it changes | Who can undo it |
|---|---|---|---|
| Policy push, restriction change | Yes | Configuration state | Re-push the previous policy |
| App deployment or removal | Yes | Installed software | Reverse the deployment |
| Remote lock | No as executed | Availability of the device | Requires unlock and a second action |
| Erase | No | All local data | Nothing restores it |
| Release of serial number from organisation record | No as executed | Ownership binding | Re-enrolment requires physical access |
A useful way to state the test: if the undo path requires physical access to the device, the command is irreversible in operational terms, even when the console offers a theoretical reverse action.
When a customer disputes a lock, the question is never whether a lock command exists. It is whether the lock was applied to the right unit, at the right time, for the right reason. A record with one operator and one timestamp cannot answer any of those three questions.
The underlying mechanism is that submitting and approving are different events with different actors, and collapsing them into one record destroys the only evidence that separates a considered action from a misclick. Four fields carry the whole story: requester, approver, request time, and approval time. Two of them are identity, two are time, and the gap between the two times is itself informative.
A request-to-approval interval measured in seconds is a rubber stamp. An interval measured in minutes suggests someone looked at something. Neither is proof on its own, but a register where every irreversible command shows the same two-second gap is a register where the second approver is not doing anything.
Separation of duties is not a device management invention. NIST SP 800-53 Revision 5 defines AC-5, Separation of Duties, as dividing mission functions among different individuals or roles. ISO/IEC 27001:2022 lists segregation of duties as an organisational control in Annex A. Applying either to a device console means the same thing in practice: the person who identifies the device is not the only person who confirms the action.
Approval overhead that scales badly gets switched off. So tie the control to blast radius rather than applying it uniformly.
| Affected units | Control | Extra step |
|---|---|---|
| 1 unit | Second approver | Requester and approver must differ |
| 10 to 99 units | Second approver plus sample check | Reconcile receipts for at least 10 percent of the batch |
| 100 units or more | Batched execution | Split into groups of 50, reconcile each group before the next |
Making the distinction explicit in the console, rather than leaving it to operator judgement, is what makes the thresholds below enforceable. LuckyMDM (Sichuan Starlight Network LLC) marks three command types as irreversible, remote lock, erase, and release of a serial number from the organisation record, and requires a second approver before submission, recording requester, approver, request time, and approval time as four separate fields.
The middle row is where most value sits. A batch of 40 units with one missing receipt is invisible unless somebody counts receipts against the batch, and counting 4 out of 40 takes under two minutes.
Assume a fleet of 1,000 units, a device price of USD 1,399, a monthly payment of USD 49, a 24-month term, labour at USD 36 per hour, and net exposure per unit of USD 372 once a unit goes to loss. These are worked assumptions for the arithmetic; substitute your own figures.
One wrongly locked unit. Handling runs about 30 minutes at USD 36 per hour, about USD 18, plus one month of service credit at USD 49. Together about USD 67, and that understates it, because it excludes the trust cost of telling a customer their working device was locked by mistake.
A wrongly locked batch of 100 units. At USD 67 each, about USD 6,700 in direct handling and credits, plus whatever share of those accounts do not renew.
Cost of the control. Adding a second approver costs about 30 seconds per irreversible command. At 1,200 such commands a year that is about 10 hours, about USD 360 a year.
Reading them together. Preventing one 100-unit mis-batch a year returns about USD 6,700 against roughly USD 360 of overhead, about 18 times over. The control only has to catch one incident every few years to justify itself, which is the argument that survives a budget review.
The other direction. The risk of over-tightening is delay: if approval adds hours, genuine loss events get locked late. Keep the approval path under a few minutes for single-unit cases; that is the constraint that keeps the control from costing more than it saves.
Export the last 30 days of irreversible commands. Compare requester and approver on every row. Any row where they match means the control did not run, regardless of what the policy document says.
For each approval, confirm the approver had the device identifier and current state in front of them. An approval screen that shows only a count, such as 40 units selected, does not meet the bar; it should list identifiers.
Reconcile one batch end to end. Pick a batch command from the last month. Count the units targeted, count the receipts returned, and confirm the two numbers match. A mismatch that nobody flagged means receipt reconciliation is not happening.
Why it is wrong: a receipt confirms that a command executed on the devices that received it. If the selection was wrong, every receipt is clean and every device is wrong. Counts, not receipts, catch this.
Why it is wrong: the cost of the control is about 30 seconds per command while the cost of a mis-batch is about USD 6,700 at 100 units. The delay that actually hurts is measured in hours, and that comes from slow escalation paths, not from a second approver.
Why it is wrong: authentication establishes identity, separation of duties establishes that two different people considered the action. A single account with excellent credentials still produces one-person decisions, and one-person decisions on irreversible commands are the exact failure mode this control addresses.
Vendors that serve leased and instalment device fleets, LuckyMDM among them, tend to put the three irreversible commands behind the same approval path rather than treating them as ordinary operations, which is the practical reading of the standards above.
Boundary one. This control applies to commands that change device state, and it does not substitute for deciding whether the action is warranted. Two approvers agreeing to lock a unit that is current on payments is still a wrong lock. The approval path should require the triggering condition to be recorded, not just the action.
Boundary two. Very small fleets may find the overhead disproportionate. Below roughly 20 units, with one operator, the realistic version is a written rule plus a monthly self-review of the irreversible command log rather than a live second approver. The control scales with the number of people who can issue commands, not only with the number of devices.
Any person other than the requester, drawn from a defined role. Naming a single individual creates a bottleneck and a single point of absence; defining a role keeps the control available.
Use a deferred queue: the command is submitted, held, and requires confirmation from a second person before execution. If no second person exists at all, the honest fallback is a hard confirmation step showing the device identifiers and a post-hoc review of the log.
Apply it to whichever direction is irreversible in your setup. If release from the organisation record requires physical re-enrolment to reverse, it belongs in the controlled group even though it feels like a benign action.
Long enough to outlast the dispute window for that device. As a worked figure, 12 months after the unit leaves the fleet covers most scenarios; set the actual period from your contracts and internal policy.
No. It pairs with two other things: showing identifiers rather than counts on the approval screen, and reconciling receipts after batch execution. Approval without either leaves the two most common failure modes untouched.