Rogue hardware as trusted corporate device: Autopilot enrollment hijack

Windows Autopilot turns a hardware hash into a trusted corporate endpoint. If an attacker can import their own hardware identity, they can manufacture a managed device that blends right into your fleet.

How the attack works

The attacker imports rogue Autopilot device identities, hardware hashes for machines the organization never bought, or abuses weak enrollment restrictions. An attacker-controlled device then completes Autopilot enrollment and Entra join, appearing as a managed corporate endpoint. It receives configuration profiles, can be reported compliant, and inherits corporate trust, becoming a durable foothold that can reach device-gated resources. This is Account Manipulation, T1098, and Create Account, T1136, applied to device identity rather than a user.

Why it works

Trusted endpoints are supposed to come from hardware the organization actually owns, but device-identity import is often unrestricted and unreconciled. A rogue device that receives config, completes Entra join, and shows up in inventory looks exactly like a real corporate device, which is the entire point of the attack.

How to fix it

Do not chase sign-ins. The trust is a device identity, not a session, so blocking one login leaves the foothold intact. Remove the rogue Autopilot device identities and device objects, then tighten enrollment restrictions and device limits so only organization-owned hardware can join. For the class fix, restrict who can import device identities, reconcile every import against procurement and asset records, and alert on new device-identity imports so a rogue plant is caught the moment it happens.

Practice it

We built this as a GraphLattice Range scenario so administrators can rehearse spotting an unmatched device import, pulling the rogue identity, and locking enrollment to owned hardware.