Windows Autopilot Security Risks

Enabling Windows Autopilot allows devices to be pre-registered to your organization in Microsoft servers.

As of this writing, there is very little risk in enabling Windows Autopilot within an organization.

The most recommended security concept to fight against malware for years has been to remove admin rights from end users. When Microsoft introduced Windows 10 and later Windows Autopilot, they effectively replaced the need to do traditional disk imaging. With Windows Autopilot, you can deploy a company owned computer, and transform them ( provision ) from consumer devices to enterprise devices. 

How are devices added to Microsoft servers?

Devices get added to the Microsoft device management portal  via one (or more) of the following methods:

• • Manual registration
  • OEM registration
  • Reseller, distributor, or partner registration
  • Automatic registration

If you get your devices pre-registered by the OEM (i.e. Dell, HP, Lenovo, etc)  then permissions will need to be granted authorization to access the API  which provides no delegated admin permissions to the OEM.    You will need to request the specific OEM link  to the vendor. Reseller, Distributor or Partner registration process is similar.

The User Experience Side

When a device is Window Autopilot registered, this means that when a new or recently reset device is going through the Out of Box Experience (OOBE) – as soon as the device connects to the Internet, Window 10 makes a call to Microsoft servers to see if the device has been registered to an organizations.   If the return to this query is false, then it continues with the normal process.   

On the other hand, if the device is found, then it proceeds to ask what the user credentials, which get validated against the organization’s Azure Active Directory (a requirement),  before continuing the setup process.   After successful validation, it then gets enrolled to your secure MDM infrastructure (Microsoft Intune or many others) to continue the configuration and provisioning process.

Potential Actual Risks :

• Enrolling a device in Windows Autopilot doesn’t grant or give any permissions to anything anywhere. Windows Autopilot is simply a pathway to device provisioning including a domain join and MDM enrollment. It doesn’t bypass any existing controls or enable access of any kind to anything.
• If a device is somehow (unlikely) ‘maliciously’ enrolled into Windows Autopilot, the logon process is still the blocker, and the user login will serve as the deterrent / blocker. ;
• A valid user from the organization that the device is assigned to must still login in with their credentials to initiate the process of joining the domain (on-prem AD or AAD). And, just joining a domain doesn’t give anyone access to anything as access to resources is in nearly all cases gated by the credentials of a user, not a device.

The Most Important Element:

** Protect the user authentication **

Windows Autopilot requires the use of Azure Active Directory (AAD) as the primary method of end-user authentication.

• Enforce complex passwords
• Use Multi Factor Authentication
• Use monitor and alert systems

Many organization have augmented the embedded security of AAD with thirtparty tools like OneLogin, OKTA, Auth0, Ping and the many other alternatives out there.

Update 2024/04/01: Good Article: Autopilot & The Perceived Tenant Security Risk – MSEndpointMgr

Update 2024/06/10: Digging into Windows Autopilot v2 – Out of Office Hours (oofhours.com)

Additional Reading:

• Microsoft Documentation: Windows Autopilot OEM Registration
• Windows Autopilot OEM registration process | Microsoft Learn
• Microsoft Documentation: Windows Autopilot Device Registration Overview
• Windows Autopilot and the joy of networking
• Microsoft: Windows Autopilot Known Issues Page
• Windows Autopilot Deployment Workflows