How to handle a remote employee’s lost or stolen laptop

It is 11pm on a Thursday. A remote employee calls in a panic – their laptop was stolen from a coffee shop that afternoon, or left in a taxi, or taken during a break-in. Everything that was on it is now with a stranger. If the laptop was properly configured, the incident is minor – remote wipe, provision a replacement, move on. If it was not, the business may be looking at a data breach, a compliance incident, a notification obligation, and a very bad week.

The difference between those two outcomes is almost entirely determined by decisions made before the incident. What controls were in place on the device. How fast the employee reports it. Whether the business has the tools and processes to respond quickly. This guide covers the immediate response when it happens, the technical controls that determine the severity, and how to close the gap this kind of incident usually reveals.

The first 60 minutes: immediate response

Speed matters more than anything else once a device is missing. The sooner access is revoked and the device is wiped, the less a thief or finder can do with it.

Step 1: Have the employee report it immediately

Not at the end of the day, not tomorrow morning, not when they feel like they have collected themselves. Right now. The employee should have a number, a chat channel, or an email address memorized for this exact scenario – an after-hours contact that gets an IT response within minutes, not hours.

The report should include: the employee’s name, what was lost (laptop, phone, badge, security key, anything else on the device), when it happened, where it happened, and whether they believe it was theft, misplacement, or something else. This information drives the urgency of the response.

Step 2: Block the user’s account and revoke sessions

This is the single highest-priority action. In the Microsoft 365 admin center, block sign-in on the user account. In Entra, revoke all sessions. These two actions together kill every active session on every device where the user is signed in – including the missing laptop.

A thief who has the unlocked laptop at that moment will find that Outlook stops loading new email, Teams disconnects, and any open cloud document becomes read-only as the session tokens expire. Anyone trying to sign back in will be blocked.

This does not depend on whether the device is online or not. It depends only on whether the user’s account is still allowed to authenticate. Cutting that off first buys time for the rest of the response.

Step 3: Initiate remote wipe via Intune

In the Intune admin center, find the missing device and initiate a wipe:

• Full wipe for a company-owned laptop. Resets the device to factory state the next time it connects to the internet.
• Selective wipe for a BYOD device. Removes company data while preserving personal content.
• Remote lock as a holding action if the device is still active. Locks the screen and requires a PIN to unlock.

The wipe command queues immediately but executes only when the device next checks in. For a laptop that is offline (powered down, disconnected from the internet), the wipe will execute the next time it powers up and connects. Some MDM platforms can also send a wake-on-LAN signal if the device is on the same network as a managed endpoint, but for devices genuinely off, it is a waiting game.

Document the wipe command with a timestamp. This is important for the audit trail if the incident becomes a compliance matter.

Step 4: Change passwords the user had access to

If the user may have reused passwords on the device (saved browser passwords, password manager not locked, credentials typed into local apps), rotate every credential they had that is not handled by your identity provider. Common ones:

• Shared SaaS tool passwords that are not SSO-integrated
• API keys or service account credentials used for development work
• Wi-Fi passwords for company networks the device knew
• Anything else that sat in the user’s memory or their password manager vault

For credentials handled by the identity provider, blocking the user in step 2 already revokes access. For everything outside that, rotate it.

Step 5: Check audit logs for unusual activity

In the last few hours before the laptop was reported missing, did anything anomalous happen?

• Large downloads from OneDrive or SharePoint
• Unusual volumes of email sent
• Changes to mailbox forwarding rules
• OAuth consents to new apps
• Unexpected sign-ins from new locations or IP addresses
• Access to sensitive files the user does not normally touch

If the loss was actually a theft, especially a targeted one, the attacker may have had an hour or two with the unlocked device before you got the call. The audit log tells you what they did during that window. If the log is clean, you are probably looking at a straightforward loss. If the log shows suspicious activity, the incident just upgraded into a potential data breach, and you need to bring in legal, management, and possibly law enforcement.

Step 6: File a police report if stolen

A police report matters for three reasons: it creates a formal record, it may help recover the device, and it is almost always required for any insurance claim. The employee files it (they are the victim of the theft); the business requests a copy for the incident file.

Step 7: Document the incident

While the response is still in motion, start the incident document. What happened, when, who did what, with what timestamps. You will be glad for this documentation later – during the post-incident review, during any regulatory conversation, and during the next employee handbook update.

What happens to the data on the device

The critical question: what was actually at risk when the laptop went missing?

The best case: everything was encrypted and sandboxed

A properly configured device had:

• Full disk encryption (BitLocker on Windows, FileVault on Mac). Without the password, the drive is unreadable. A thief who boots the machine sees a PIN or password prompt and cannot get past it. Pulling the drive out and mounting it on another computer does not help – the data is encrypted at rest.
• Screen lock after short inactivity. The thief who finds the device on standby gets a lock screen, not a logged-in session.
• MFA on every cloud service. Even if they had the password, they need the second factor. The second factor device (phone, key) is not with the laptop.
• Conditional access requiring compliant devices. The thief trying to sign in from a different device gets blocked because their device does not pass compliance checks.

In this scenario, the actual data at risk is effectively none. The laptop is a physical asset loss, not a data loss. Remote wipe is insurance against the thief finding a sophisticated way around the encryption (usually requires a password hint, social engineering, or a multi-year research project).

The worst case: nothing was configured

The laptop was running without disk encryption. Local files in Documents, Desktop, Downloads, and email caches were sitting there unprotected. Browser-saved passwords for company accounts were accessible. The user was signed into Outlook, Teams, and local SaaS apps with “remember me” checked.

In this scenario, the thief who knows what they are looking at has access to all of the above immediately. Business documents, cached email attachments, saved credentials, active sessions. The remote wipe helps when it executes, but by then the damage may already be done.

This is why the pre-incident configuration matters more than the incident response. A device that was never going to be a breach risk does not become one because it got lost. A device that was always a risk becomes an incident because it got lost.

The middle case: partial protections

Realistically, most SMB devices sit somewhere in between. Encryption on, but MFA not enforced for every service. Screen lock enabled, but saved browser passwords in the clear. Some cloud data local, some strictly in the cloud.

In this case, the assessment is specific to the device: what was actually on it, what would have been accessible to a thief with enough time to probe, and what the wipe managed to clean up before it completed. Treat it as a partial incident – likely not a breach, but worth a more careful review than the fully protected case.

Preventing the next one: the configuration that matters

Once the immediate incident is handled, the post-incident review should surface which controls were in place and which were not. The controls that reduce the severity of a lost laptop:

Full disk encryption, always

BitLocker or FileVault, enforced through the MDM, with the recovery key escrowed to Azure AD (or equivalent). Never leave encryption to user initiative – it either gets applied by policy or it gets forgotten.

Verify encryption through the compliance report, not by assuming the policy is working. Occasional hardware issues, policy conflicts, or user actions can disable encryption silently.

Screen lock with short timeout

5-10 minutes of inactivity before the screen locks. Short enough that a thief who finds a device on the table has limited window; long enough that the user is not constantly re-authenticating during normal work.

MFA on every account

Not just M365. Every business account the employee accesses should require MFA. Preferably phishing-resistant methods (Authenticator app with number matching, hardware keys) rather than SMS. When the laptop is stolen, MFA is what stops the thief from using the device’s saved credentials on other services.

Conditional access requiring compliant devices

Cloud apps should refuse to authenticate sessions from non-compliant or unmanaged devices. A thief using the stolen laptop fails compliance checks (or succeeds, briefly, but then hits the session revocation). A thief trying to use harvested credentials on a different device fails the compliance check.

Cloud-first storage

If the business-critical files were in OneDrive and SharePoint rather than on the laptop’s hard drive, the data that was at risk is a cached copy of data that still exists in the cloud – not the only copy. See cloud storage for remote teams for why Known Folder Move and SharePoint-first file placement matter here.

Password manager with auto-lock

A password manager that locks itself when the device is idle (or signs out when the user signs out) prevents a thief from accessing saved credentials even if they have the device. Browsers’ built-in password saving is worse than a real password manager for this reason – there is usually no additional lock on the browser password store.

Managed and monitored endpoints

An EDR agent that reports unusual activity, a device enrolled in Intune that can be wiped remotely, and a business with a response plan for this exact scenario. The difference between a 30-minute contained incident and a multi-week breach investigation is whether these were in place.

Device tracking

Apple’s Find My (for Macs and iPhones/iPads) and Microsoft’s Find My Device (for Windows) can sometimes locate the device. Worth enabling by default; worth trying as part of the response. Do not rely on it – encryption and wipe matter more – but a found device is preferable to a lost one.

Provisioning a replacement remotely

Once the incident is contained, the employee needs a working laptop. Remote provisioning is straightforward if the business has built the processes:

Spare device pool

A small inventory of pre-imaged laptops ready to ship overnight. For a 20-person business, 1-2 spares on the shelf is enough. For larger teams, scale proportionally. The devices rotate into the regular fleet periodically so they do not become obsolete sitting on a shelf.

Zero-touch enrollment

The replacement laptop, on first boot, auto-enrolls in Intune (Windows Autopilot) or Jamf (Apple Business Manager). The employee signs in with their work account, the device provisions itself with the right policies and apps, and they are working within an hour of the box arriving. See remote laptop onboarding for the full setup.

Files and settings restoration

If OneDrive was syncing properly before the loss, the employee signs into the new laptop and their files appear as they were. Desktop, Documents, Pictures, all recovered automatically via Known Folder Move.

Browser settings, app preferences, and saved passwords are less recoverable unless the user was using a password manager with cross-device sync. That is another reason to use one.

Identity restoration

The user account was blocked during the response. Unblock it once the incident is contained and the user has the new device. Verify their identity before unblocking – you do not want to give the account back to someone who called in pretending to be the employee during a coordinated attack.

Compliance and notification obligations

Depending on your industry and jurisdiction, a lost or stolen laptop may trigger notification requirements even if no breach actually occurred.

HIPAA

If the laptop contained ePHI (electronic protected health information) and the encryption was not in place or cannot be verified, HHS considers the data “exposed” and notification obligations apply. If encryption was verified and the recovery key was not on the device, the data is typically considered protected and no notification is required. See HIPAA cybersecurity requirements for the framework.

State data breach notification laws

Most US states require notification when personal information is exposed to unauthorized access. The thresholds and definitions vary by state. For a thoroughly encrypted device with no evidence of compromise, notification is usually not required. For an unencrypted device, it usually is.

Contractual obligations

Clients, partners, or vendors may have specific notification requirements in your contracts with them. Review what you agreed to, separately from what the law requires.

GDPR and international

For businesses with EU customers or employees, GDPR notification timelines are tight (72 hours to notify the supervisory authority if there is a risk of harm). Other jurisdictions have their own rules.

The consistent theme: encryption is the biggest single factor in whether a loss requires notification. A verifiably encrypted device with no evidence of compromise usually does not. An unencrypted one usually does. This is one of the most compelling practical arguments for enforcing encryption fleet-wide.

The insurance angle

Cyber insurance policies often cover lost-laptop scenarios, but the coverage depends on the specifics.

• Hardware replacement is typically covered by commercial property insurance, not cyber policy
• Notification costs, legal costs, and credit monitoring (if required by law) are typically covered by cyber policy
• Business interruption from the incident may be covered by either, depending on cause
• Claims often require that the security controls the business claimed on the application were actually in place (encryption, MFA, backup, etc.)

If you have cyber insurance, notify the carrier per the policy requirements – usually within a specific window, with specific information.

Common mistakes after a lost laptop

• Waiting to report. Employees often hope they will find it, rather than report it immediately. Make the reporting culture clear: report first, search after. An employee who waited four hours to report because they were looking has cost the business most of the containment window.
• Assuming encryption was on without verifying. The response should include checking the compliance reports for that specific device. “Encryption was probably enabled” is not the same as “encryption was verifiably enabled 30 minutes before the loss.”
• Not rotating shared credentials. Focus on M365 access, forget that the employee had five shared SaaS accounts in their password manager. Rotate all of them.
• Skipping the audit log review. The assumption that “they just lost it in a taxi” may be right 95% of the time. The other 5% is where audit logs show exfiltration and you need to pivot fast.
• Not updating the onboarding process after. Every incident reveals gaps. If the incident happened because the device did not have MFA enforced on some secondary service, fix that for every other employee.
• Failing to communicate with the employee. The employee whose laptop was stolen is also a victim. They need reassurance, a replacement device, and clarity about what happens next. Handling this badly makes a minor incident feel like a disciplinary action.
• Forgetting the compliance review. If the business is regulated, the incident kicks off a required review process. Do not skip it because the incident “seemed contained.”

How this fits into broader IT practice

Handling lost devices well is a specific application of endpoint management and remote IT support. The tooling – Intune for wipe, Entra for session revocation, EDR for anomaly detection, audit logs for forensics – is the same tooling that supports the rest of a remote-first operation. The lost-laptop scenario is a stress test: if the normal operations are working, the incident response is mostly pulling the right levers in sequence.

Businesses that do not have the tooling in place treat each incident as a one-off scramble. The scramble takes a full day, involves reactive phone calls to vendors, and usually ends with a partially contained incident and a set of unanswered questions. Businesses that do have the tooling treat it as a 30-minute response with clear steps and a documented outcome.

How Sequentur handles this for clients

For clients on our managed IT support for remote and hybrid teams, lost or stolen devices are handled through our standard incident response. When a client calls in the incident, our team executes the response sequence – block the account, revoke sessions, initiate wipe, rotate shared credentials, audit the logs, and document the outcome. The client’s manager receives a summary, and if compliance obligations apply, the documentation is ready for whatever review process follows.

On the proactive side, the configuration that limits the severity of this kind of incident is what we put in place during onboarding: Intune compliance policies enforcing encryption, conditional access requiring compliant devices, MFA on every service, known folder move for OneDrive. When a lost device happens on a managed client, the response is short because the groundwork is already there.

For clients who do not yet have this configuration, the initial setup is typically scoped as a project rather than bundled into ongoing managed IT. A proper deployment of Intune policies, conditional access, identity configuration, and response playbooks takes real design work and is best handled as an engagement with clear milestones. Once deployed, the ongoing operation transitions into managed IT.

If your remote fleet is one lost laptop away from a breach investigation, schedule a call and we will walk through what a resilient setup looks like for your team.