Windows Autopilot Security Configuration: How to Provision Endpoints Securely at Zero Touch
Retool's new app builder is where AI-generated code ships safely
Building apps with AI is easy. Getting them to production safely is another story.
Autopilot is designed for operational efficiency -- devices ship to users without IT handling them. The security challenge is ensuring that efficiency does not come at the cost of a policy gap between when the user first turns on the device and when security baseline policies are fully applied. The Enrollment Status Page, BitLocker pre-provisioning, and Autopilot profile settings together ensure that security controls are in place before the user can access corporate data.
Configure the Autopilot Deployment Profile
Location: Intune admin center > Devices > Windows > Windows Enrollment > Windows Autopilot Deployment Profiles
Create a new profile (User-Driven mode for standard laptops):
- Deployment mode: User-Driven
- Join type: Azure AD joined (for cloud-only) or Hybrid Azure AD joined (for on-premises AD)
Security-relevant profile settings:
- Skip AD connectivity check: Disabled for Hybrid AAD join (the device must reach a DC during provisioning)
- Apply device name template: Enabled -- specify a naming convention (e.g.,
CORP-%RAND:5%). Consistent naming helps identify rogue devices and simplifies management. - Language: Set to your default -- prevents user from changing region during OOBE (reduces attack surface of OOBE-bypass techniques)
- Automatically configure keyboard: Yes
- Convert all targeted devices to Autopilot: Yes (registers existing devices when they next enroll)
OOBE customization to reduce social engineering risk:
- Privacy settings: Hide (prevents users from changing privacy settings during OOBE, which some social engineering attacks use to disable telemetry required by security tools)
- Change account options: Hide (prevents adding a local account during OOBE)
- User account type: Standard User (critical -- the provisioned account should be a standard user, not local admin)
- This means the Autopilot-provisioned user is not in local Administrators
- IT access is via LAPS or a separate domain admin account
- This is the most important security setting in the Autopilot profile
Configure the Enrollment Status Page to Block Access Until Secured
The ESP blocks the user from accessing the Windows desktop until assigned policies and apps have applied.
Location: Intune > Devices > Windows > Windows Enrollment > Enrollment Status Page
ESP settings for security:
- Show app and profile configuration progress: Yes
- Block device use until all apps and profiles are installed: Yes (critical)
- Block device use until these required apps are installed if they are assigned to the user/device: Add your required apps:
- Microsoft Defender for Endpoint (or your EDR agent)
- Corporate VPN/ZTNA client
- Certificate enrollment (if using certificate-based authentication)
- BitLocker enforcement policy
- Allow users to reset device if installation error occurs: No (prevents circumventing ESP by triggering a reset)
- Allow users to use device if installation error occurs: No (prevents bypassing ESP on failure)
- Show custom message when installation error occurs: Yes -- provide a helpdesk number
Why ESP matters for security: Without ESP enforcement, the user gets to the Windows desktop before your security baseline, EDR agent, and certificate policies have applied. There is a window -- potentially hours -- where the device is in corporate Azure AD but not yet secured. With ESP blocking, the user cannot access the desktop until all required security components are installed.
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
Control Device Registration to Prevent Rogue Enrollment
Restrict who can register Autopilot devices:
Location: Intune > Devices > Windows > Windows Enrollment > Device Registration
- Set: Allow users to register their personal devices: No (prevents personal devices from Autopilot-enrolling into corporate)
Restrict who can upload hardware hashes: Autopilot device registration requires uploading a hardware hash CSV. Restrict this operation:
- Intune > Tenant Administration > Roles -- create a custom role with only the 'Create: Autopilot devices' permission
- Assign this role only to your device deployment team, not to all IT staff
Require device naming convention and monitor for unexpected registrations:
# Review all Autopilot-registered devices in the tenant
# Intune > Devices > Windows > Windows Autopilot Devices
# Or via PowerShell:
Install-Module WindowsAutopilotIntune -Scope CurrentUser
Connect-MSGraph
Get-AutopilotDevice | Select-Object serialNumber, model, managedDeviceName, deploymentProfileName
# Export and compare against your known hardware inventory
# Devices registered that don't match your procurement records are unexpected
Monitor for Autopilot re-enrollment events:
# Entra ID Audit Logs > Category: DeviceManagement
# Operation: Add Autopilot Device
# Initiated by: (who uploaded the hash)
# If the initiator is not your device deployment team, investigate
# Also monitor: Device reset events (Intune wipe/reset) on registered devices
# A reset on a device not in your active deployment queue may indicate re-enrollment attempt
Enable BitLocker Pre-Provisioning
BitLocker should be active before the user logs in for the first time, not after. Autopilot BitLocker pre-provisioning (previously called 'Windows Autopilot White Glove') encrypts the OS drive during the device phase of ESP, before user provisioning.
Configure BitLocker policy in Intune: Endpoint Security > Disk Encryption > Create Policy > Windows > BitLocker
Key settings for Autopilot:
- OS drive encryption: Required
- BitLocker OS drive settings:
- Startup authentication required: Yes
- Compatible TPM startup: Allowed
- Compatible TPM startup PIN: Blocked (for full zero-touch; use PIN for high-security scenarios)
- Recovery options:
- Recovery key: Allowed
- Recovery password: Required
- Omit recovery options from setup wizard: Yes (escrow to Azure AD automatically)
- Save BitLocker recovery information to Azure AD: Required
- Store recovery information in Azure AD before enabling BitLocker: Required (device cannot encrypt until the recovery key is safely stored)
Verify BitLocker is active before user access: With the Intune BitLocker policy and ESP blocking until the BitLocker policy applies, the device cannot be handed to a user unless the drive is encrypted and the recovery key is escrowed in Azure AD. If the device is lost in transit, the data is protected.
The bottom line
Autopilot security configuration checklist: set User Account Type to Standard User (not admin) in the Autopilot profile, configure the Enrollment Status Page to block desktop access until EDR, certificate, and BitLocker policies apply, restrict the Autopilot device registration permission to the deployment team, require BitLocker with Azure AD key escrow before enrollment completes, and monitor Entra ID audit logs for unexpected device registrations. The Autopilot profile User Account Type setting is the single most impactful security choice -- it determines whether every new corporate endpoint starts as a least-privilege device or a local admin machine.
Frequently asked questions
What is the Autopilot re-enrollment attack and how do I prevent it?
The re-enrollment attack targets the Autopilot registration process. If an attacker obtains a device's serial number, model, and 4K hardware hash (which can be extracted from a stolen device, leaked from a vendor portal, or found in exposed IT asset management systems), they can register the device in your Autopilot tenant. When the device is reset (factory reset or Autopilot reset), it will receive your corporate Autopilot profile and potentially corporate credentials. Prevention: restrict hardware hash upload to a small group, monitor Entra audit logs for Add Autopilot Device events not initiated by your team, use Tenant Lock (linked enrollment) in the Autopilot profile to prevent enrollment into any tenant except yours, and require multi-factor authentication for the accounts authorized to upload device hashes.
Should I use user-driven mode or self-deploying mode for corporate laptops?
User-driven mode for standard corporate laptops. Self-deploying mode is for shared devices, kiosks, and conference room machines where no specific user identity is associated with the device during provisioning. User-driven mode requires the user to sign in with their Azure AD account during provisioning, which ties the device to the user's identity and ensures policy targeting works correctly (per-user apps and policies apply to the correct person). Self-deploying mode authenticates via device certificate only -- if the TPM certificate is compromised or the device is stolen, the device will auto-enroll with no human verification.
Does Autopilot support on-premises Active Directory domains?
Yes, via Hybrid Azure AD Join mode. In this mode, Autopilot provisions the device, joins it to Azure AD (cloud), and then separately joins it to on-premises AD using an Intune Connector for Active Directory installed on a domain member server. The device ends up in both Azure AD and on-premises AD, can receive Group Policy from on-premises AD and MDM policies from Intune. Requirements: the provisioning machine must have line-of-sight to a domain controller during the device phase of ESP (requires VPN or that the DC is reachable from the network where provisioning happens). Cloud-only Azure AD join (not hybrid) has fewer requirements and is recommended for new environments.
What happens if Enrollment Status Page fails and the user cannot complete provisioning?
The user sees an error message with the custom support number you configured. They should call IT, who can investigate via Intune: Devices > select the device > Device Installation Status to see which app or policy is failing. Common failures: required app not compatible with the device, certificate enrollment failure (DC unreachable during hybrid join), VPN client installation failure, or ESP timeout (the default timeout is 60 minutes; increase it for environments with slow application installation). Do not enable 'Allow users to use device if installation error occurs' as a fix -- diagnose the actual failure. If a user is truly blocked, IT can either resolve the policy issue or perform a targeted unenrollment and re-enrollment from Intune.
Can Autopilot be used to provision devices for users in remote locations without IT on-site?
Yes, that is one of Autopilot's primary design goals. The device is pre-registered with Autopilot by the vendor or IT (using the device's hardware hash), shipped directly to the user, and the user powers it on and signs in with their Azure AD credentials. The device downloads policies, applications, and certificates automatically over the internet. No IT technician is required on-site. For Hybrid Azure AD Join scenarios where on-premises domain join is needed, the device must have connectivity to a domain controller during provisioning -- typically via the corporate VPN, which must be installed before the domain join step. For cloud-only Azure AD join environments, the entire process works over any internet connection with zero on-site IT involvement.
How do I secure the Autopilot provisioning process against device impersonation or enrollment hijacking?
Autopilot device registration uses the hardware hash (a cryptographic fingerprint of the device's hardware) to bind a physical machine to an Autopilot profile. Device impersonation would require an attacker to know a target device's hardware hash before it is enrolled and register a different device with that hash -- Microsoft validates hash uniqueness and device-specific signatures that make this impractical. The higher-risk scenario is unauthorized enrollment: someone obtaining or cloning a hardware hash and enrolling an attacker-controlled device into your Autopilot program. Mitigations: restrict who can register devices in Autopilot (use the device enrollment restriction policy in Intune to allow only IT-approved registration methods), require that Autopilot profiles configure a specific user assignment (the device is locked to the intended user, not open to any organizational account), and enable Enrollment Status Page with the 'Block device use until all apps and profiles are installed' setting to ensure the device fully configures before the user can access it.
Sources & references
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, daily, no spam.
Unsubscribe anytime. We never sell your data.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals every morning.
Win a $2,495 Black Hat pass.
Full-access to Black Hat USA 2026 in Las Vegas. Subscribe free to enter.