The phone is gone. In its app drawer sits a logged-in console that can remote-control, restart and wipe your company's computers. The next thirty minutes decide whether this is an embarrassment or an incident.
Every admin who runs a fleet from a phone should have this routine written down before it is needed. It has four moves, in a deliberate order: cut the account off from the server side, reset what the phone knew, wipe the device itself, then review the records. Speed matters, but order matters more — skipping to the wipe while the account is still live leaves the real door open.
From any computer, sign in to the Endpoint Central web console (or have a fellow admin do it) and deal with the account, not the phone. Disable the lost phone's user account or, at minimum, change its password immediately — either way, the credentials the app holds stop working. If your build shows active sessions for the user, end them. This step comes first because it works even if the phone is offline, destroyed or in another country: the server simply refuses the account from that moment on. Everything after this is cleanup; this step is the actual rescue.
The Endpoint Central account is the crown jewel, but a working admin phone holds more: the VPN profile that reaches the office network, the email account, chat apps where users send screenshots of errors. Change the VPN credential or revoke that device's VPN access. Force a sign-out on the email account from its web settings. Work through the phone's roles one by one — anything that could reach the company gets its credential rotated or its session revoked. It feels thorough because it is; a lost admin phone is a small breach and deserves a small breach response.
Use the phone platform's own tools — Find My Device on Android or Find My on iPhone — to locate it. If recovery looks realistic and quick, lock it with a message. If there is any real doubt, wipe it remotely and accept the loss of whatever personal data was not backed up. The order against Move One is deliberate: platform wipe commands need the phone to check in, and thieves switch phones off. Your server-side account kill works regardless, which is why it went first. If the phone was also enrolled in your own Endpoint Central MDM, its lock and wipe actions are a second route to the same end.
Once the doors are closed, look backwards. Endpoint Central keeps an audit trail of admin actions — review your account's activity for the window between the loss and the account kill. In the overwhelming majority of cases you will find nothing, and that nothing is worth having in writing. Then rebuild: new phone or recovered phone, fresh app install, sign in with the (new) password, re-enable two-factor authentication if it is in use. Finally, write down what the incident taught you — a weaker screen lock, a missing routine, a slow step — and fix that one thing while the lesson is fresh.
The full video shows the app's reach across a live fleet. That reach is exactly why this routine exists.
▶️ Watch Full VideoThe app signs in with your account credentials, so once the password is changed or the account is disabled on the server, the phone's stored login stops being useful. Kill any active sessions too, and the door is fully closed.
After. The account kill works instantly from the server side even if the phone never comes back online. A remote wipe needs the phone to check in, and a switched-off phone cannot receive it — so account first, device second.
Yes, and cheap at the price. You will re-enable an account and set a new password; the audit review gives you written proof that nothing happened in the gap. Skipping the routine because the phone turned up is how real incidents hide.