Entra ID Join blocking: impact on Intune and Windows Autopilot

Many blogs, security audit tools, and consulting firms recommend disabling device join to Microsoft Entra ID.

However, this setting can lead to major side effects.

This article sheds light on a critical configuration often overlooked by administrators.

A common recommendation… but rarely understood

This recommendation is almost systematic in security audits performed by external firms or automated tools.

Example from Tenable:
https://www.tenable.com/indicators/ioe/entra/USERS-ALLOWED-TO-JOIN-DEVICES

The issue? These tools rely on a "pure security" logic, without understanding the functional impact on Microsoft 365 /Intune.
And this point is rarely challenged by internal IT or security teams.

Where is this option configured?

This setting is available in the Entra portal:
Microsoft Entra ID > Devices > Device Settings
Lien direct :
https://entra.microsoft.com/#view/Microsoft_AAD_Devices/DevicesMenuBlade/~/DeviceSettings/menuId/Overview

The setting is called Users may join devices to Microsoft Entra (By default, set to All).

Scope of this setting

Before diving into the impact, it's important to understand the scenarios this setting applies to.

The Users may join devices to Microsoft Entra ID setting only applies to Microsoft Entra Join scenarios on Windows 10 or later.

It does not apply in the following cases:

• Hybrid joined devices (Microsoft Entra hybrid join)
• Azure VMs joined to Microsoft Entra ID (Microsoft Entra Join for VMs)
• Windows Autopilot Self-Deployment scenarios

In these situations, the join operation is performed without user context, making the setting ineffective.

What happens if you block it?

If you disable this option (None), no user will be able to join a device to Entra ID — including during the Windows Autopilot User-Driven process.

In practice, the user will encounter error 801c03ed just after signing in, making the enrollment fail and the device unusable:

Error:

Confirm you are using the correct sign-in information and
that your organization uses this feature. You can try to do
this again or contact your system administrator with the
error code 801c03ed.

Additional problem information:
Server error code: 801c03ed
Correlation ID xxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
Timestamp: 06-12-20251329:25Z
Server message: Administrator policy does not allow user <tenantID>\<UserID> to device join
More information: https://www.microsoft.com/aadjerrors

Il existe aussi des recommandations pour n'autoriser que certains comptes IT (Selected : choisir des comptes IT) pour faire l’enrôlement, cela n’a pas d’intérêt non plus. En effet, dans un processus Windows Autopilot user-driven, c’est bien l’utilisateur final (celui à qui on remet l'appareil) qui réalise la jonction durant Autopilot et non pas l'admin.

Some recommendations suggest allowing only selected IT accounts to perform the join operation (by setting Selected and choosing IT users).
This approach is also pointless. In a Windows Autopilot User-Driven process, it's the end user (the one receiving the device) who performs the join during Autopilot, not the admin.

Limitations of Conditional Access policies

There is a Conditional Access policy type with User actions = Register or join devices.

Unfortunately, this policy cannot be used to block device registration or join operations.

It can only be used to require multifactor authentication. Microsoft clearly states this in their documentation:

Only "Require multifactor authentication" can be used in policies created for the "Register or join devices" user action.

For more details, refer to the official Microsoft documentation: : https://aka.ms/userActions

Key takeaways

• Never disable this option without fully understanding the impact on Windows Autopilot onboarding. If you use Autopilot User-Driven, you have no choice to leave the setting on All or manually select all end users who will receive a device via Autopilot.
• If you choose to disable it, make sure you’re not using Windows Autopilot in User-Driven mode.