Hybrid Join to Entra Join Migration? Don’t Miss This Microsoft Entra Token Protection Limitation

Organizations are increasingly migrating Windows devices from Microsoft Entra hybrid join to Microsoft Entra join. To avoid wiping devices and rebuilding user profiles, many customers use third-party migration solutions that preserve the existing Windows installation, user profile, applications, and settings.

Some of these migration solutions use a Windows provisioning package, commonly called a PPKG file, to join the device to Microsoft Entra ID and enroll it in Microsoft Intune.

The migration may complete successfully. The device might appear as:

• Microsoft Entra joined
• Intune enrolled
• Compliant
• Corporate-owned
• Can be Assigned to the correct user
• Able to receive configuration and security policies

However, one important security limitation can remain hidden:

Windows devices deployed using Microsoft Entra bulk enrollment do not currently support Token Protection in Conditional Access.

This limitation becomes visible only when the organization enables the Require token protection for sign-in sessions control. Users may then find that Outlook, Teams, OneDrive, Microsoft 365 Apps, or other supported native applications can no longer access Exchange Online, SharePoint Online, or Microsoft Teams.

In this Blog post i will explains what Token Protection is, how it prevents token replay, how to configure it, which applications are supported, why bulk-enrolled devices are unsupported, how to identify affected devices, and what remediation or workaround options are available.

What Is Token Protection?

Token Protection is a Microsoft Entra Conditional Access session control designed to reduce token theft and replay attacks.

After users authenticate, applications normally receive tokens that allow them to continue accessing resources without asking for the password and multifactor authentication for every request. These tokens improve the user experience, but a stolen token can potentially allow an attacker to impersonate the user until that token expires or is revoked.

Token Protection reduces this risk by requiring supported applications to use a sign-in session token that is cryptographically bound to the original device. A token stolen from one device should therefore not be usable from another device controlled by an attacker.

Token Protection is sometimes described as token binding. Its purpose is not to stop the token from being stolen in every scenario. Instead, it makes the stolen sign-in session significantly more difficult to replay from another device.

Why Token Theft Matters Even When MFA Is Enabled

Multifactor authentication protects the authentication process, but it does not automatically protect every token issued after authentication.

For example, an adversary-in-the-middle phishing attack might convince a user to authenticate and complete MFA through a malicious website. The attacker could then attempt to steal the resulting session artifact and replay it from another system.

Malware or information-stealing software running on an endpoint might also attempt to extract locally stored authentication artifacts.

When Token Protection is enforced, possession of the token alone is insufficient. The client must also prove that the request is coming from the device to which the sign-in session was bound. Microsoft recommends using Token Protection as part of a broader defense-in-depth strategy that also includes phishing-resistant authentication, endpoint hardening, device compliance, identity risk policies, detection capabilities, and network-based controls.

How Token Protection Works on Windows

On supported Windows devices, Microsoft Entra ID issues a Primary Refresh Token, or PRT, after the user signs in.

The PRT enables single sign-on to Microsoft 365, Azure, and other Microsoft Entra-integrated applications. Native applications such as Outlook, Teams, OneDrive, and Office use the Windows Web Account Manager, or WAM, to request tokens through the operating system’s authentication broker.

During device registration, Windows generates cryptographic keys, including:

• A device key
• A transport key
• A session key used as proof of possession

When supported by the device, the private keys are protected by the Trusted Platform Module. Token requests are signed using the protected session key, allowing Microsoft Entra ID to verify that the request originated from the registered device.

If an attacker copies the PRT or associated refresh token to another device, that device should not possess the protected private key needed to produce a valid signature. Microsoft Entra ID can therefore reject the replay attempt.

Token Protection does not simply check device compliance

A device can be:

• Microsoft Entra joined\Hybrid Joined\Entra Registered
• Intune managed
• Marked compliant
• Protected by BitLocker
• Onboarded to Microsoft Defender for Endpoint

…and still fail Token Protection.

Token Protection evaluates whether the sign-in session uses a supported device-bound token flow. Device compliance and token binding are related security controls, but they are not interchangeable.

Token Protection Availability

As of July 2026, following platform supported

• Windows - Generally Available
• iOS and iPadOS - Preview
• macOS - Preview

Token Protection currently supports native applications only. Browser-based applications are not supported by the Token Protection session control.

On Windows, supported device states include:

• Windows 10 or later devices that are Microsoft Entra joined
• Windows 10 or later devices that are Microsoft Entra hybrid joined
• Windows 10 or later devices that are Microsoft Entra registered
• Windows Server 2019 or later devices that are Microsoft Entra hybrid joined

These general device states are supported, but there are important exceptions based on how the device identity was created.

Which Cloud Resources Can Be Protected?

Microsoft currently supports Token Protection enforcement for these cloud resources:

• Exchange Online
• SharePoint Online
• Microsoft Teams

On Windows, Token Protection can be used to protect the following resources

• Azure Virtual Desktop
• Windows 365

Note: Token Protection should not be applied to every enterprise application. Microsoft recommends selecting only the supported applications. Applying it to the entire Office 365 application group may cause unexpected sign-in or authentication failures.

Which Windows Applications Currently Support Token Protection?

Microsoft currently lists the following Windows applications as supporting protected token flows:

• Exchange Online PowerShell module
• Microsoft 365 Copilot
• Microsoft Edge, for signing in to the Edge profile only
• Microsoft Graph PowerShell when the EnableLoginByWAM option is used
• Microsoft Loop
• Microsoft Teams
• Microsoft To Do
• OneNote
• OneDrive
• Outlook
• Power BI Desktop
• Power Query extension for Excel when using the Current Channel
• Visual Studio Code
• Visual Studio when the Windows authentication broker sign-in option is selected
• Windows App
• Word
• Excel
• PowerPoint

The application must be current and must use the supported Windows broker-based authentication flow. Older or unsupported application versions can be blocked after enforcement.

Important application limitations

The following limitations also should be considered before enabling the Token Protection  policy:

• Office perpetual clients are unsupported.
• PowerShell modules that access SharePoint do not support the protected flow.
• Power Query for Excel is unsupported when the user is not on Current Channel.
• Visual Studio Code extensions accessing Exchange or SharePoint might not support protected token flows.
• Surface Hub devices are unsupported.
• Windows-based Microsoft Teams Rooms systems are unsupported.
• Browser applications are unsupported by Token Protection.

Organizations using Office LTSC or other perpetual Office releases must review this limitation carefully before enabling the policy.

How to Configure Token Protection in Conditional Access

Token Protection requires Microsoft Entra ID P1 licensing for users covered by the policy. Its always recommends beginning with a small pilot users and using report-only mode before enforcement.

Step 1: Create the Conditional Access policy

In the Microsoft Entra admin center: Go to Entra ID > Conditional Access > Policies.

Select New policy. 

Give the policy a clear name,

Under Users or agents, include the pilot group or user. 

Exclude emergency access accounts.

Step 2: Select only the supported resources

Under Target resources, select the relevant individual resources:

• Office 365 Exchange Online
• Office 365 SharePoint Online
• Microsoft Teams Services

When Windows App is deployed, We can choose:

• Azure Virtual Desktop
• Windows 365
• Windows Cloud Login

Do not select the complete Office 365 application group for this policy.

Step 3: Configure the Windows platform

Under Conditions > Device platforms:

Set Configure to Yes. Include Windows.

Step 4: Configure client applications correctly

Under Conditions > Client apps: Set Configure to Yes.

Under modern authentication clients, select only: Mobile apps and desktop clients
Do not select Browser.

Leaving Browser selected, or failing to configure the Client apps condition, can block browser-based applications that use MSAL.js, including Teams on the web.

Step 5: Enable the session control

Under Access controls > Session: Select Require token protection for sign-in sessions. Save the session control. Set the policy to Report-only. Create the policy.

Leave the policy in report-only mode until interactive and non-interactive sign-ins have been reviewed for a representative business period.

The Critical Limitation: Bulk-Enrolled Windows Devices

As of July 2026 the following device registration methods as unsupported for Token Protection:

• Microsoft Entra joined Azure Virtual Desktop session hosts
• Windows devices deployed using bulk enrollment
• Microsoft Entra joined Windows 365 Cloud PCs
• Microsoft Entra joined Power Automate hosted machine groups
• Windows Autopilot devices deployed using self-deploying mode
• Azure Windows virtual machines using the VM extension for Microsoft Entra ID authentication

The most easily overlooked entry is:

Windows devices deployed using bulk enrollment.

This matters because bulk enrollment can create a device that otherwise appears to be a normal Microsoft Entra joined and Intune-managed endpoint.

Understanding the PPKG Connection

A .ppkg file is only a container for Windows configuration settings. Provisioning packages can configure Wi-Fi, install certificates, add applications, change Windows settings, create local accounts, or perform different types of enrollment.

Therefore:

Not every device that has received a PPKG is automatically unsupported for Token Protection.

The limitation applies when the PPKG uses the Microsoft Entra bulk enrollment token to perform the Microsoft Entra join.

Windows Configuration Designer can create a provisioning package containing a bulk token. Applying the package joins the device to Microsoft Entra ID and enrolls it in Intune. Microsoft describes this as a userless enrollment process that uses a generated package_{GUID} account during bulk enrollment.

To understand more about Entra Device Bulk Enrollment refer this Microsoft article  https://learn.microsoft.com/en-us/intune/device-enrollment/windows/create-bulk-package 

How to Install a Provisioning Package in Windows

A PPKG file can be installed on a Windows 10 or Windows 11 device in multiple ways. An administrator can sign in to the device and double-click the PPKG file created using Windows Configuration Designer. Alternatively, go to Settings > Accounts > Access work or school > Add or remove a provisioning package and install it from there.

More details you can refer https://learn.microsoft.com/en-us/windows/configuration/provisioning-packages/provisioning-apply-package

End-User Experience on a Microsoft Entra Joined Device Provisioned Using a PPKG

The following policy block page is displayed when an end user tries to access a resource protected by Microsoft Entra Token Protection.

How to Identify Affected Devices

To identify the affected user and  device its recommends reviewing both interactive and non-interactive sign-in logs.

In the Microsoft Entra admin center: Go to Entra ID > Monitoring & health > Sign-in logs. Open a relevant sign-in. 

Under Basic Info, locate: Token Protection – Sign In Session

The request can appear as Bound or Unbound.

Token Protection status codes

The following status codes for unbound requests:

Status code                       Meaning

1002                  No Microsoft Entra device state was available

1003                  Device state does not satisfy Token Protection requirements

1005                  Request is unbound for another unspecified reason

1006                  Operating system version is unsupported

1008                  Client is not integrated with the platform broker, such as WAM

For bulk-enrolled devices, the most important result is: signInSessionStatusCode: 1003

Status Code1003 can indicate an unsupported device registration type or a device that was not registered using fresh sign-in credentials.

Select the Conditional Access or Report-only tab. Open the Token Protection policy. Review the session control result.

How the Limitation Affects Applications

When Token Protection is enabled, Microsoft Entra ID expects the supported native application to request access using a bound sign-in session.

A bulk-enrolled device can fail that requirement because its device registration method is unsupported. Microsoft Entra ID can then block the token request even though the user completed MFA and the device is marked compliant.

The exact impact depends on which protected resource the application is trying to access.

Outlook and Exchange Online

Outlook might be unable to acquire or refresh the token required for Exchange Online.

Users might experience:

• Repeated sign-in prompts
• Authentication failure after entering valid credentials
• Outlook remaining disconnected
• Mailbox synchronization failure
• Failure when adding a new account
• Conditional Access Policy Block page

The issue is not necessarily an Exchange Online outage or an Outlook profile problem. The Token Protection session requirement might be rejecting the unbound request.

OneDrive and SharePoint Online

OneDrive uses SharePoint Online services for business file synchronization.

Affected users might experience:

• OneDrive sign-in failure
• Existing synchronization stopping after token renewal
• “Sign in required” notifications
• Inability to synchronize SharePoint libraries
• Failure to open or save cloud files from Microsoft 365 Apps

Microsoft Teams

Teams might fail to sign in or refresh its session when accessing Microsoft Teams Services, Exchange Online, or SharePoint Online resources.

Users might see:

• A sign-in loop
• Failure after successful MFA
• Teams loading without some services
• Calendar or file access issues
• Generic device compliance or authentication messages

How to Find Devices Migrated Through a Bulk-Token PPKG

Microsoft provides documented device-filter examples for Cloud PCs, Azure Virtual Desktop, Power Automate machines, Autopilot self-deploying devices, and Azure secure VMs.

However, Microsoft does not currently provide an equivalent built-in Conditional Access device-filter expression that universally identifies every Windows device joined through a bulk-token PPKG.

Organizations should therefore maintain their own migration inventory.

Useful data can include:

• Old device ID
• New Microsoft Entra device ID
• Intune managed-device ID
• Device name
• Serial number
• Migration date
• Migration tool
• Migration method
• Whether a bulk enrollment token was used
• Assigned user
• Token Protection validation result

For future migration waves, the process should automatically stamp the Microsoft Entra device object with a custom attribute indicating how the device was migrated.

The important question to ask a migration vendor is therefore not simply:

“Does your product use a PPKG?”

The more accurate questions are:

1. Does the PPKG contain a Microsoft Entra bulk enrollment token?
2. Is the new Microsoft Entra device identity created through the Windows bulk-enrollment workflow?
3. Does the join occur through a user’s fresh interactive Microsoft Entra credentials?
4. Has the resulting device state been validated against Conditional Access Token Protection?
5. Will Token Protection sign-in logs show the session as Bound or return status code 1003?

A package used only to configure the device or launch a user-driven join process might not create the same limitation. A package that performs the join through a bulk token does.

Why Customers May Discover the Issue Only Later

A device migration using a provisioning package may appear completely successful because bulk-enrolled devices can continue to use many Microsoft Entra ID and Intune capabilities.

For example, the device may:

• Register successfully in Microsoft Entra ID
• Enroll successfully in Intune
• Receive configuration profiles
• Receive compliance policies
• Be evaluated by standard device-based Conditional Access policies
• Receive applications and security baselines
• Report a compliant status in Intune

The limitation applies specifically to the Token Protection session control and does not mean that Conditional Access is completely unsupported for bulk-enrolled Windows devices.

This is why an organization may complete its device migration and operate normally for several weeks or months. The problem may become visible only when Token Protection is tested or enforced for supported Microsoft 365 applications.

Workaround 1: Exclude Bulk-Enrolled Devices Using a Device Filter

The immediate Microsoft-documented approach for unsupported device-registration categories is to exclude affected devices from the Token Protection policy using a Conditional Access device filter.

For bulk-enrolled devices, a scalable approach is to populate one of the Microsoft Entra device extension attributes.

For example:

extensionAttribute1 = TP-BulkEnrollment-Exception

Conditional Access supports extensionAttribute1 through extensionAttribute15 in device filters. Microsoft Graph can be used to update these values on the Microsoft Entra device object.

Configure the Conditional Access exclusion

Edit the Token Protection policy:

Go to Conditions > Filter for devices.Set Configure to Yes. Select Exclude filtered devices from policy. Use the following rule:
device.extensionAttribute1 -eq "TP-BulkEnrollment-Exception"

Microsoft Entra supports using administrator-managed device extension attributes in Conditional Access filters. The device must meet the documented conditions for the attribute to be available during policy evaluation, such as being Intune managed, compliant, or Microsoft Entra hybrid joined.

Security impact of this workaround

This prevents application disruption, but the excluded device does not receive Token Protection enforcement.

The exception should therefore be:

• Documented
• Reviewed regularly
• Limited to confirmed affected devices
• Removed after the device is reprovisioned through a supported method
• Compensated with other security controls

Do not broadly exclude all Microsoft Entra joined devices or all migrated users.

Workaround 2: Exclude Individual Device IDs

For a very small pilot or temporary investigation, devices can be excluded by their individual device IDs using a Conditional Access device filter.

Example:

device.deviceId -in [
    "11111111-1111-1111-1111-111111111111",
    "22222222-2222-2222-2222-222222222222"
]

This method becomes difficult to maintain at scale, and Conditional Access filter rules have a maximum length. Extension attributes are generally easier to operate for a migration population.

Compensating Controls for Excluded Devices

A Token Protection exception should not leave the device with only password and standard MFA controls.

Microsoft always recommends a defense-in-depth token protection strategy that includes device, identity, application, and network controls.

For excluded bulk-enrolled devices, consider enforcing:

• Require a compliant device
• Deploy Microsoft Defender for Endpoint
• Require phishing-resistant authentication
• Use sign-in and user risk policies
• Consider network-based enforcement

Complete list CA policy controls, Refer here Mastering Microsoft Entra ID Conditional Access Policies: A Comprehensive Guide  

Workaround 3: Can dsregcmd /forcerecovery Fix the Device?

The dsregcmd /forcerecovery command can be used as a possible recovery option, but it should not be treated as a guaranteed fix for Token Protection.

To run this command, the user must have local administrator rights, or an administrator must sign in to the device and execute it.

dsregcmd /forcerecovery

During the recovery process, the user must authenticate using their Microsoft Entra ID credentials.

The following conditions should also be met:

• The user must be permitted to join devices to Microsoft Entra ID.
• The user must be included in the Intune automatic enrollment scope.
• Intune enrollment restrictions must allow the device to enroll.
• Restrictions that block personal Windows device enrollment must not prevent the recovery process.

Note: I do not recommend treating dsregcmd /forcerecovery as a guaranteed method for converting a bulk-enrolled device into a Token Protection-supported device. Although the workaround was successful during my testing, it should be validated carefully in a lab or pilot environment before being used in production.

Recommended Validation Steps

Test the process on a lab or pilot device first.

After completing the recovery:

1. Use fresh user credentials during authentication.
2. Sign out of Windows and sign back in.
3. Confirm that the device remains Microsoft Entra joined.
4. Verify that the device is still enrolled and managed in Intune.
5. Validate Outlook, Teams, OneDrive, and Microsoft 365 Apps.
6. Review both interactive and non-interactive sign-in logs.
7. Confirm that Token Protection reports the session as Bound.
8. Verify that Token Protection status code 1003 is no longer generated.

A successful Microsoft Entra join alone does not confirm that the issue has been resolved. The final acceptance test must verify that the application sign-in session is successfully bound by Token Protection.

Recommended Long-Term Remediation

The most reliable long-term solution is to create the Microsoft Entra device identity using a supported device registration method instead of bulk enrollment.

Possible deployment approaches include:

• User-driven Microsoft Entra join during Windows setup (Autopilot Device Preparation)
• Windows Autopilot user-driven deployment
• Standard interactive Microsoft Entra join using the user’s credentials
• Microsoft Entra hybrid join, where hybrid join remains part of the organization’s intended design

Windows Autopilot self-deploying mode should not be used for devices that must support Token Protection because this deployment method is currently unsupported for Token Protection.

For existing devices, permanent remediation may require one of the following approaches:

• Controlled unjoin and rejoin
• Windows Autopilot user-driven deployment\Device Preparation
• Windows reset or wipe followed by supported enrollment
• A vendor-supported migration process that creates the device identity using fresh user authentication instead of a bulk enrollment token

Items to Assess Before Rejoining the Device

Before performing an in-place unjoin and rejoin, evaluate the potential impact on:

• Existing Windows user profiles
• Windows Hello for Business
• BitLocker recovery key escrow
• Microsoft Entra LAPS
• Intune enrollment and management
• Device compliance status
• User and device certificates
• VPN and Wi-Fi profiles
• Microsoft Defender for Endpoint device identity
• Primary user and device ownership
• Application assignments
• Existing Conditional Access access

The migration or recovery process should be tested carefully to ensure that device management, user access, and security configurations continue to work as expected.

Final Thoughts

Token Protection helps prevent token replay by binding sign-in sessions to the device.

However, Windows devices joined through bulk enrollment are currently unsupported and may fail with status code 1003, even when they are Microsoft Entra joined, Intune managed, and compliant.

Always validate migrated devices in report-only mode and confirm the Token Protection status shows Bound before enabling enforcement.