Your client calls. A laptop is gone from an employee's car, or never came back from a conference, or an employee has stopped answering messages entirely. The device is enrolled in your console. You can see it. You could lock it in about fifteen seconds.
And you probably shouldn't. Not yet.
This is the part of managed device security that nobody writes about. Every guide on tracking a stolen laptop assumes one owner: the device belongs to the company, IT works for that company, and IT decides. The sequence is clean because the authority is clean.
You don't have that. The laptop belongs to your client. The data on it belongs to your client, or more precisely to your client's customers, patients, or case files. The employee whose privacy you're about to affect has never heard of you. Unlike an internal IT team, your authority to act comes from a contract, and contracts have signatories, escalation paths, and business hours.
So the hard part of a stolen client laptop isn't the wipe. It's having the authority to press the button, and being able to prove afterward that you had it. This article covers how that authority gets established, what the first hour looks like across a multi-tenant fleet, and what you hand the client when it's over.
What changes when the device isn't yours
The technical actions are identical. Locate, lock, wipe, document. What changes is who is allowed to trigger each one, and who answers for it afterward. That single shift, from owning the device to operating it on someone else's behalf, changes the sequence more than any tool does.
Under most data protection regimes, your client is the data controller: they decide what data gets collected and why. You are the data processor: you handle that data on their instructions. Under GDPR this is Article 28 territory, and it means your instructions come from them, in writing, in advance. Under HIPAA the same relationship is a Business Associate Agreement. The vocabulary differs. The operational consequence is the same: you don't get to improvise.
This catches MSPs in a specific way. In-house IT can make a judgment call in the middle of the night and defend it the next morning, because the person making the call and the person carrying the risk work for the same organization. When you make that call, you are acting on data you don't own, affecting an employee you don't employ, on behalf of an organization that will be the one notifying regulators.
Consider an MSP whose client roster includes law firms, investment advisers, and medical practices. Every one of those clients has a notification obligation the MSP does not have, and a definition of "sensitive" that differs by vertical. The same missing laptop is a routine hardware replacement at one client and a reportable exposure at another. You cannot know which without knowing what was on the device, and you cannot decide the response without the controller in the loop. The frameworks your clients answer to shape that decision more than your own policies do.
There's a second wrinkle that catches teams off guard. Disabling the user's account feels like containment, but it isn't complete. As one US-based MSP put it: "Even after disabling a user's account, employees can still delete data stored locally due to cached credentials." Identity containment closes the front door. The data sitting on the disk is a separate problem, and it's the one that needs device-level action.
Who can actually approve a wipe?
This is the question nobody asks until the phone is already ringing. A wipe on a client-owned device needs authorization from someone at the client with contractual authority to order destruction of their data. That means a named approver defined in your service agreement, not whoever answers the phone.
Without that name written down in advance, you are choosing between acting without authority and waiting while data sits exposed.
Here's where most MSPs discover their gap. The service agreement says you'll "provide device security services." It doesn't say who at the client can order a remote wipe, what happens when that person is unreachable, or how long you wait before acting on your own judgment.
That ambiguity is fine right up until the moment it isn't.
The people who handle this well treat it as an onboarding task, not an incident task. When a new client comes on, you're already collecting admin credentials and network details. Add three things to that same conversation. First, the primary approver: who can authorize a lock, a wipe, or a factory reset, with a name, a role, and a phone number that works outside business hours. Second, a named alternate, because the primary will be unreachable eventually and an escalation path with one name in it is not an escalation path. Third, the timeout: if neither responds within a defined window, what are you authorized to do on your own?
Most clients will accept "lock the device and preserve evidence, but don't wipe" as a standing pre-authorization, because locking is reversible and wiping isn't. That third item is the one that saves you. A pre-authorized reversible action lets you contain the situation immediately while the irreversible one waits for a human. You are never stuck choosing between paralysis and overreach.
Document the authorization when it happens: who approved, at what time, through which channel. A chat screenshot is thin evidence. An email or a ticket with a timestamp is defensible. If the client later asks why their employee's laptop was erased, the answer needs to be a record, not a recollection.
Quick win: Open your three largest client contracts this week and search them for the word "wipe." If the named approver isn't there, you have an authorization gap on your highest-value accounts. Fixing it is a one-paragraph amendment.
The first hour, client by client
The order of operations differs from single-tenant IT in one important way: your first move is a phone call, not a console action.
- Confirm and classify: what happened, whose data, and whether it's theft, loss, or an unreturned device
- Reach the approver: start the authorization chain, log every attempt with a timestamp
- Contain identity while you wait: account disable, token revocation, VPN kill, MFA backup codes
- Verify encryption status: BitLocker or FileVault state from your console
- Preserve before you destroy: location history, last check-in, anything the device generated
- Act on the authorization and only within its scope
Confirm and classify. Before touching anything, establish what happened and whose data is involved. Was it stolen, lost, or is this an employee who has stopped responding? Those three have different legal shapes, and the third is an unreturned-device matter rather than a theft. Check what the device held: which files synced offline, which applications cached data, whether credentials were saved in the browser. Your client's obligations depend entirely on this answer.
Reach the approver. Start the clock on the authorization chain you defined at onboarding. If the primary doesn't answer within your agreed window, go to the alternate. Log every attempt with a timestamp. That log later demonstrates that the delay was communication, not negligence.
Contain identity while you wait. Account disable, token revocation, VPN session kill, MFA backup code invalidation. This is usually within your standing authority because it's reversible and it's your job. It also buys real time.
Verify encryption status. Pull the BitLocker or FileVault state from your console. If encryption was enforced and the recovery key is under your control rather than exposed, the data has a meaningful layer of protection and the urgency of the wipe decision changes. This is often the single fact that turns a panicked client conversation into a calm one.
Preserve before you destroy. Location history, last check-in, any evidence the device generated. Once you wipe, that's gone. If there's any chance of recovery or a police report, capture it first. Exposed credentials from that device are their own follow-up, which is where credential monitoring across client fleets earns its place.
Then act on the authorization, and only within its scope.
One more thing worth saying plainly to clients: tell the employee not to fire off a personal erase command from their own iCloud or Google account the moment they realize the laptop is missing. It feels responsive. It destroys the audit trail and the recovery option in the same click, and it happens more often than you'd expect.
Quick win: Write this six-step sequence into a template ticket in your PSA today. When an incident lands, your tech opens the template instead of improvising, and every client gets the same defensible order of operations.
Lock, wipe, or wait, and who makes that call?
Every minute you spend deciding is a minute the data spends somewhere you can't see. Locking is yours to make if you've pre-authorized it, because it's reversible and preserves evidence. Wiping belongs to the client, because it destroys their data permanently. Waiting is legitimate only when encryption is confirmed and the device is offline.
The decision isn't really about which action. It's about matching the irreversibility of the action to the authority behind it.
Speed matters once the decision is made, and this is where tooling shows its limits. An MSP serving legal, investment, and healthcare clients tested Microsoft Intune in 2026 and found that a remote wipe took 34 minutes to initiate. Not to complete. To start.
Sit with that number for a second. You've reached the approver, you have documented authorization, the client is on the phone waiting, and your platform spends more than half an hour thinking about it. Every minute is data sitting on a disk somewhere you can't see, and a client watching you be unable to deliver the thing they're paying for.
That's why response speed belongs in your service agreement as an actual number, not a vague "rapid response" claim. If a device is online, the action should begin in seconds. If it's offline, it should fire the moment it reconnects. Whether that action is a lock or a full factory reset, the number you can honestly promise is the one your platform actually hits, and promising a number you can't hit is worse than promising nothing.
What do you hand the client afterward?
Most device incidents don't end with a dramatic recovery, and the laptop usually stays gone. What the client needs is a document they can put into their own incident record: what happened, when you were notified, what actions you took, who authorized each one, and what evidence exists.
That record is what lets them satisfy their own regulator, insurer, or board. Producing it is the part of the service they actually remember, because what they are left holding is either a coherent account of a handled situation or a shrug.
An IT consultant described a case involving a former employee who claimed he'd returned his laptop during offboarding. The device checked in. Timestamped photos showed him using it at home. He was told to bring it over within the hour or hand it to the police when they arrived. As the consultant put it: "He wisely chose to return it."
No search. No investigation. Just proof, handed to the one person who could resolve the situation. Evidence closes cases faster than searching does, and evidence is something you can produce reliably even when recovery isn't.
Your incident report to the client should cover five things:
- Timeline: when the loss was reported, when you responded, when each action fired. Timestamps, not narrative.
- Authorization record: who approved what, and through which channel.
- Device state at last contact: encryption status, last known location, last check-in.
- Actions taken and their confirmations a wipe ordered but never confirmed is a different fact from one that completed.
- What the client still needs to do their notification obligations are theirs; you feed the decision, you don't make it.
Keep it to a page. The person reading it is going to forward it to their compliance officer or their insurer, and neither of them wants your prose.
Quick win: Build this report as a template now, while nothing is on fire. Fill it in from a past incident as a dry run. If you can't populate a field from your existing tooling, you've found a visibility gap before it costs you a client conversation.
How multi-tenant platforms close this gap
Everything above assumes you can act per client without touching anyone else's fleet, and that you can produce a record afterward. That's a tooling requirement, not a process one, and it comes down to three capabilities working together: tenant separation, consent-scoped tracking, and a per-action audit trail.
Three capabilities carry the weight. Tenant separation means each client's devices, actions, and audit logs stay in their own boundary, so an action for one client is impossible to fire against another. Consent-scoped tracking means you're not monitoring client employees continuously, only locating a device once it's been declared lost. An audit trail per action means the report writes itself from what your console already recorded.
That middle one deserves attention, because it's the difference between a service and a surveillance problem. Hamza C., an MSP reviewing Prey on G2 in 2023, described it directly: "As an MSP, the portal gives us the options to manage separate customer accounts with ease. For further privacy for the user, the system allows us to only track devices at the time when declared lost or stolen."
That's the answer to the objection you'll eventually hear from a client's HR team or works council. You are not watching their people. You are able to locate a specific device once its owner has told you it's missing.
The remote actions matter too, particularly on Windows, where a full remote factory reset is rarer than vendors imply. Mel A., an IT consultant, noted in the same G2 review set: "The best feature is the ability to 'factory reset' a Windows PC. I have never been able to initiate the process for a client remotely before finding Prey." If that capability isn't in your stack, there are client conversations you can't have.
If you're still deciding what sits underneath the service, the MDM comparison for MSPs covers the selection criteria, and the difference between an MDM and an RMM shapes what you can realistically promise.
Making it repeatable across every client
An incident response that only works when your senior tech is awake isn't a service. It's a personal favor with an invoice attached.
The MSPs who make this profitable treat the runbook the way they treat deployment: as something cloned, not built. When a new client onboards, the authorization chain gets captured alongside the admin credentials. The template ticket gets attached to their profile. The default policy set copies over. Nothing about incident response gets designed on the day of the incident.
This is also where the service becomes something you can price and defend. You're not selling geofencing. You're selling a defined response with a named authority chain, a documented sequence, and a report at the end. That's a service description a client can evaluate, and it's what separates a device security offering from a reseller relationship. If you're building the commercial side of this, packaging and pricing a device security service covers the tiers and margin math.
One caution as fleets grow: resist the urge to automate the destructive action. Automated locks on geofence exit or missed check-in are reasonable, because they're reversible. An automated wipe on a client-owned device removes the human authorization step that this entire article is about. Keep the confirmation in the loop. The friction is the point.
Quick win: Add "device incident approvers" to your client onboarding checklist. Every client onboarded from here forward has the chain defined on day one, and you can backfill the existing roster at each renewal.
Bringing it together
The technical capability to wipe a device remotely has been solved for years. What hasn't been solved, and what nobody hands you in a product demo, is whether you're allowed to use it on a device that belongs to someone else.
That's the actual work: establishing authority before you need it, acting within it when you do, and producing evidence that you did. The wipe is fifteen seconds. Everything that makes those fifteen seconds defensible happens during onboarding, in a contract, on a template.
If you do one thing after reading this, pull your client list and check how many have a named wipe approver on file. The number is usually lower than MSPs expect, and it's the cheapest gap you'll ever close.
Frequently asked questions
Can an MSP remotely wipe a client's device without their permission?
Generally no. The client is the data controller and the MSP is the processor, which means destructive actions on client data require the client's documented instruction. The practical exception is a standing pre-authorization written into the service agreement, and even then most clients only pre-authorize reversible actions like remote lock. Wiping is typically reserved for an explicit, logged approval.
Who is liable if an MSP wipes the wrong device?
Liability usually follows authorization. If the MSP acted on a documented instruction from a named client approver, responsibility largely sits with the client's decision. If the MSP acted on its own judgment without that instruction, it carries the exposure directly. This is why timestamped authorization records matter more than the technical accuracy of the action.
How do MSPs track client laptops without monitoring employees?
By scoping tracking to declared incidents rather than running it continuously. Platforms built for multi-tenant use allow location to be activated only once a device has been reported lost or stolen, which keeps the MSP out of ongoing employee monitoring. This distinction is worth stating explicitly to clients, because it's usually the first objection their HR team raises.
What should an MSP give the client after a device is stolen?
A single-page incident record containing the timeline, the authorization trail, the device's state at last contact, the actions taken with their confirmations, and what the client still needs to handle on their side. The client typically forwards this to their compliance officer or insurer, so it should read as a record rather than a narrative.
How fast should a remote wipe actually start?
If the device is online, the action should begin within seconds; if it's offline, it should execute on the next reconnection. Platform performance varies significantly here. One MSP testing Microsoft Intune in 2026 measured 34 minutes just to initiate a remote wipe, which is the kind of gap that turns into a difficult client conversation mid-incident.
Can a stolen laptop be tracked after a factory reset?
Usually not by software installed on the device, since a full reinstall removes the agent along with everything else. This is a limitation shared by every software-based tracking tool. In practice most opportunistic thefts don't begin with a wipe, which is why the window immediately after the loss is the one that matters operationally.
