Why Using a DEM Account for Windows Autopilot is a Bad Idea

In this blog (not technical this time…sorry), we’ll explore why Microsoft does NOT support Device Enrollment Manager (DEM) for Autopilot, the problems it causes, and the better alternatives to use instead.

DEM Accounts and Their Limitations

When deploying devices at scale, using a Device Enrollment Manager (DEM) account might seem like an efficient approach. However, when combined with Windows Autopilot, DEM accounts create more problems than they solve. While they are useful for enrolling devices without a primary user, their limitations make them unsuitable for scenarios where Autopilot is involved. Compliance failures, and long-term device management complications make DEM accounts not the best option for this process.

Microsoft clearly outlines that DEM accounts are ONLY intended for specific enrollment methods, such as:

• Bulk enrollment using a provisioning package
• DEM-initiated via Company Portal enrollment
• DEM-initiated via Microsoft Entra join

As you seen above, Winodws Autopilot is NOT listed as a supported enrollment method, which further reinforces that DEM accounts should not be used in a Windows Autopilot scenario!!

Why Autopilot and DEM Don’t Work Well Together

Windows Autopilot is built around the concept of assigning a primary user to a device. This ensures that compliance policies, Conditional Access, and security mechanisms function correctly. DEM accounts were never intended for this type of deployment. Instead, they are meant for bulk enrollment where devices do not need a user assigned, such as kiosks or shared workstations. Trying to use a DEM account for Autopilot is not the way to go as it will introduce multiple issues later on.

Compliance Failures Due to Missing User Association

One major problem is compliance enforcement. Microsoft Intune’s built-in compliance policies require a device to have an enrolled user. Compliance checks could eventually fail since DEM accounts do not assign the “real” user (Enrolled By)to the enrolled device.

Once a device is marked as non-compliant, Conditional Access policies block access, preventing users from signing into corporate resources. This results in unnecessary IT intervention to manually assign users and fix compliance status.

A key issue that has been widely discussed in the community is the difference between “Enrolled By” and “Primary User”. Devices enrolled with Autopilot typically assign a Primary User based on the first login, which is crucial for policy enforcement. However, DEM-enrolled devices list the Enrolled By account (the DEM account itself). This means that the moment something happens with the DEM account, you are pretty much screwed. This will lead to unexpected behavior and devices being left in a non-compliant state. Let me expand on the risks of deleting the DEM account a bit more!

Risks of Deleting a DEM Account

Beyond compliance failures, another funny issue arises when you are managing DEM accounts. Microsoft explicitly warns that deleting a DEM account after devices have been enrolled can lead to major issues. (enrolled by…)

Any devices associated with a deleted DEM account may lose their ability to sync with Intune or pass the compliance status. IT teams that rely on DEM accounts for Autopilot could find themselves with a fleet of unmanageable devices, requiring re-enrollment to restore functionality. Sounds lovely, right?

Better Alternatives to DEM Accounts for Autopilot

If your organization has been relying on DEM accounts for bulk enrollment, you may have already encountered these challenges. Fortunately, there are better alternatives that align with Autopilot’s design and ensure compliance.

One viable option is Self-Deploying Mode, which allows devices to be enrolled without user intervention, as long as TPM 2.0 with device attestation is available. This method ensures proper compliance and security policies apply without the limitations that come with DEM accounts.

Another alternative is Pre-Provisioning (formerly known as White Glove), which lets IT configure devices before handing them over to users. This guarantees that the user enrolled will be set correctly. How? Well, that’s because the device will get an UNJOIN after the Intune enrollment. The moment the real user starts using the device again, the device joins Entra again but this time with the proper user. (DON’T use the DEM account!!)

⚠ Note on Pre-Provisioning Challenges

While Pre-Provisioning (White Glove) is a great alternative to DEM accounts, it requires TPM 2.0 with attestation. If TPM attestation fails (e.g., missing EKcertificates, firmware issues, or other limitations), Pre-Provisioning will fail, requiring a fallback to User-Driven Mode.

And if you’re thinking about enroling your device into Entra and using the ‘Enroll only in device management’ option instead, don’t. This method often results in similar limitations, with devices missing proper policy enforcement and essential configurations. It’s another approach that seems convenient but ends up causing more issues in the long run. If you want to see what kind of mess this can lead to, check out this breakdown.

If you are currently using DEM accounts for Autopilot while reading this, you might be wondering what your options are. Fortunately, Microsoft provides better alternatives that align with Autopilot’s design and avoid these pitfalls.

Using Temporary Access Pass (TAP) to Fix Issues

For organizations that enrolled devices using a DEM account and are now facing compliance issues, Microsoft Entra ID’s Temporary Access Pass (TAP) provides a possible better solution. TAP allows users to sign in and complete the profile setup without requiring the user’s password or multi-factor authentication (as the MFA claim is in the TAP request). Once the user logs in, Intune recognizes them as the primary user, allowing compliance policies and Conditional Access rules to function properly.

TAP can be used to ensure the proper user is associated with the device, but it’s not an excuse for poor enrollment practices. IT admins should not use TAP as a method to configure devices for users manually! It defeats the purpose of Autopilot.

In my opinion, TAP needs to be used to ensure new employees have a temporary password they can use to log in to their new device. With it, they can set up Windows Hello for Business and MFA, go Passwordless! (No need for a password from there on)

If you don’t believe me and still think DEM accounts are excellent combined with Windows Autopilot, let’s look at Microsoft’s statement on this.

Microsoft’s Official Stance on DEM for Windows Autopilot

Microsoft explicitly states that DEM accounts are not intended for use with Windows Autopilot!.

According to Microsoft’s official documentation, DEM enrollment is only supported for bulk provisioning methods, Company Portal enrollment, or Microsoft Entra join. Autopilot is notably absent from the list of supported methods, further reinforcing that DEM accounts should NOT be used for Autopilot deployments.

Attempting to force this type of enrollment results in unnecessary troubleshooting, compliance failures, and an enrollment process that requires continuous IT intervention. It sounds good for consultants, but still…

The Struggle to Get Microsoft to Acknowledge the Issue

For those actively working to highlight the issues caused by using DEM accounts with Autopilot, the “fight” has been ongoing. Just like in the image below, where James, Johannes, and Rudy are passionately “convincing” Microsoft about the problems DEM accounts introduce, it’s been a battle to raise awareness and push for better documentation and solutions.

IT admins have long faced these challenges, repeatedly running into the same compliance failures and policy issues. Again… it’s pretty clear that if you are using Windows Autopilot, you don’t need to use a DEM Account.

Final Thoughts

Rather than struggling with compliance failures, broken Conditional Access policies, and long-term management headaches, adopting the right enrollment method from the start ensures less troubles down the road. Instead of using DEM accounts for Autopilot, organizations should start making use of the user-driven Autopilot enrollment process.

Microsoft’s own documentation seems pretty clear, DEM accounts were never meant for Autopilot. Ignoring this leads to compliance failures, broken policies, and unnecessary troubleshooting that could have been avoided from the start