Windows - Security - Remote Wipe

What the Windows remote wipe Worklet does

This Automox Worklet™ executes an irreversible factory reset on a Windows endpoint by invoking the doWipeMethod on Microsoft's MDM_RemoteWipe CIM class. The Worklet opens a CIM session against the root\cimv2\mdm\dmmap namespace, locates the MDM_RemoteWipe instance with ParentID './Vendor/MSFT' and InstanceID 'RemoteWipe', and calls the wipe method against that instance. Once invoked, the wipe begins immediately and cannot be cancelled from the endpoint or the console.

The wipe operation destroys every user account, file, installed application, registry hive, and system configuration on the endpoint. BitLocker-protected volumes are removed along with their recovery keys, so any data the attacker has not already exfiltrated becomes unreadable. The endpoint reboots into the Windows Out-of-Box Experience and runs the "Resetting this PC" sequence, leaving the hardware in the same state it had when it shipped from the manufacturer.

Read the warning before you run this Worklet. The action is permanent. There is no undo. Files are not recoverable through standard forensic tools after the wipe completes. The Automox agent is removed along with everything else, so a recovered endpoint has to be re-enrolled with your organization installation key before it can receive policy again.

Why remote wipe is the last-mile response for lost laptops

The window between "my laptop is missing" and "someone is reading our customer data" is measured in hours, not days. A lost or stolen Windows endpoint carries cached Entra ID and Active Directory tokens, browser-saved credentials, OneDrive caches, VPN client configurations, and signed email archives. It also carries every local copy of the customer records the user happened to be working on. BitLocker protects the disk at rest, but a thief with a logged-in laptop or a forgotten screen lock bypasses that protection entirely. Regulatory frameworks including HIPAA, PCI-DSS, GDPR, and SOC 2 require a documented response for lost endpoints, and "we asked the user to mark it as lost" is not a control.

Lost-laptop and offboarding response is bounded by how soon the wipe instruction reaches the endpoint. Targeted from the Automox console, this Worklet carries the doWipeMethod call to a specific Windows endpoint as soon as it next checks in, whether the laptop is on the corporate network, on a coffee-shop Wi-Fi, or on a tethered hotspot. The agent runs the wipe regardless of whether the user cooperates, and the act of wiping resets the endpoint to factory state before any local data or cached corporate credentials can be exfiltrated. FixNow compatibility means the policy can be triggered against a single named endpoint rather than scheduled against a group.

How the Windows remote wipe sequence works

1. Evaluation phase: The evaluation script always exits with code 1 and performs no detection logic. This is intentional. A remote wipe is never the result of automated drift detection. The Worklet is wired so that remediation only runs when a human operator explicitly executes the policy or triggers FixNow against a known endpoint.

2. Remediation phase: The remediation script calls New-CimSession to open a local CIM connection, builds a CimMethodParametersCollection with a single empty String parameter named param, and uses Get-CimInstance to locate the MDM_RemoteWipe instance in root\cimv2\mdm\dmmap. The script then invokes doWipeMethod against that instance through $session.InvokeMethod, which hands control to the Windows MDM bridge. The bridge schedules an immediate reboot, the endpoint reboots into Windows RE, the "Resetting this PC" routine runs, and the firmware returns to a clean OOBE state.

Operational requirements before you run a remote wipe

• Windows 10, Windows 11, or Windows Server with the MDM bridge WMI provider (the root\cimv2\mdm\dmmap namespace and MDM_RemoteWipe class must be present).

• PowerShell 5.0 or later (the script depends on New-CimSession and the Microsoft.Management.Infrastructure type).

• Local administrator privileges on the target endpoint. The Automox agent runs as SYSTEM, which satisfies this on a managed Windows host.

• A dedicated Automox group that contains only the endpoints you intend to wipe. Add devices to that group manually, one at a time, to prevent a misconfigured scope from wiping the wrong fleet.

• The Worklet must not be attached to a scheduled policy. Run it manually or through FixNow against a specific endpoint.

• Automox install and reboot notifications disabled on the policy so the end user does not receive a warning popup that tips off the holder of a stolen laptop.

• A change ticket and approving signature on file. Tie the policy execution to that ticket in your incident-response runbook.

• Out-of-band credential revocation prepared in parallel – disable the Entra ID or Active Directory account, revoke MFA tokens, and rotate any service credentials the user could have cached locally. The wipe destroys the local copies, but a credential the attacker already exfiltrated remains valid until you revoke it.

Expected endpoint behavior after the remote wipe completes

Within seconds of the script exiting on the agent, the endpoint reboots and shows the "Resetting this PC" progress screen. The reset takes roughly 30 to 60 minutes depending on disk size, encryption state, and storage speed. On NVMe SSDs the operation usually finishes in under 40 minutes; on older spinning disks with full BitLocker decryption it can run closer to 90.

When the reset finishes, the endpoint lands at the Windows OOBE first-run screen and prompts for language, region, network, and a new local or Entra ID account. All user data is gone: documents, browser caches, saved passwords, application data, Outlook archives, OneDrive sync caches, Teams logs, BitLocker volumes, and any malware that was resident on the system. The disk has been wiped and any reattachment of the BitLocker recovery key from your console will fail because the volume identifier no longer exists.

The Automox agent is removed during the wipe and the endpoint disappears from the console group within the next sync cycle. Mark the endpoint as decommissioned in your asset inventory. If the endpoint is recovered and you want to manage it again, install the Automox agent fresh using the organization installation key. Then add the endpoint back to the appropriate production policy group – never back to the remote wipe group.

Capture the Automox activity log entry for the wipe execution and attach it to the incident ticket. The activity log shows the exit code from the InvokeMethod call, the timestamp the agent received the policy, and the executing user context. That record is the evidence auditors expect when they ask how a lost-laptop event was contained.