Devices Showing “Pending” Status in Microsoft Entra ID (Hybrid/Azure AD Join)

Question

Devices Showing “Pending” Status in Microsoft Entra ID (Hybrid/Azure AD Join)

Marcos Correa 10

We are experiencing an issue in our Microsoft Entra ID tenant where multiple Windows devices are displaying a**“Pending” registration status**.

These devices are domain-joined and attempting to register or hybrid join with Entra ID, but they do not complete the registration process successfully. As a result, they are not fully recognized as compliant or properly managed devices.

Sometimes even when the device shows as 'Registered', it will not show within Intune. And\or the device would show as a duplicate within Entra.

This issue is impacting Conditional Access policies that require compliant or registered devices, potentially blocking access to services such as Outlook, Teams, and SharePoint.

Impact

Devices remain in Pending state under Entra ID > Devices
Devices are not properly recognized by Intune or compliance policies
Conditional Access policies dependent on device state may block user access to M365 services
Uncertainty around whether affected devices are:
Active
- Stale
- Or improperly registered

Observed Behavior / Symptoms

Devices appear in Entra but:

Do not fully transition from Registered → Pending → Active

Some systems show conflicting or duplicated device objects

Intune synchronization is inconsistent or does not complete

Devices may show:
AzureAdJoined = YES
DomainJoined = YES
- But still remain in Pending state
In some cases, device authentication or SSO tokens are not properly issued (PRT issues observed in troubleshooting)

Troubleshooting Performed

We have attempted the following steps:

Ran:
- dsregcmd /status
  - dsregcmd /leave
    - dsregcmd /join
      - dsregcmd /forcerecovery
      - Removed duplicate device objects from Entra
      - Re-registered affected devices
      - Restarted systems and retried enrollment
Verified domain connectivity and DC reachability
Confirmed hybrid join configuration is in place
Reviewed Conditional Access policies (including token/device-based policies)
Tested device onboarding across different network conditions (VPN / internal)

Despite these efforts, devices continue to remain in a Pending state.

Additional Context

Environment includes:

Hybrid Active Directory + Microsoft Entra ID
- Intune for device management
Issue has been observed across:
- Multiple devices
  - Multiple users
    - Different device builds/images
Internal testing suggests possible correlation with:
Device registration state inconsistencies
Token issuance / authentication flow behavior
- Conditional Access or device-based policy enforcement
Performed actions from sites below:
- https://learn.microsoft.com/en-us/answers/questions/1161747/hybrid-azure-ad-joined-device-registration-pending
- Follow step within 5.2 from the link. 0x80190190 | Intune MDM device CA Certificate | 0x800706D9

Sridevi Machavarapu 33,740 Reputation points Microsoft External Staff Moderator

2026-06-22T15:42:03.0933333+00:00
Hello Marcos Correa,

Your troubleshooting covers most of the common causes.

Since the devices show both AzureAdJoined = YES and DomainJoined = YES, the issue may be occurring after the Hybrid Join process starts.

Could you check the following on an affected device?

DeviceAuthStatus and AzureAdPrt from dsregcmd /status

Any errors in User Device Registration and DeviceManagement-Enterprise-Diagnostics-Provider event logs

Whether a valid device certificate exists in the Local Computer certificate store

Also, are there any device synchronization errors reported by Microsoft Entra Connect, and do the affected devices ever appear as managed in Intune before moving to a Pending state?

The results should help determine whether the issue is related to device registration, PRT issuance, or Intune enrollment.
Marcos Correa 10 Reputation points

2026-06-26T19:44:15.35+00:00
Hello Sridevi,

DeviceAuthStatus and AzureAdPrt from dsregcmd /status

It does not show YES to azure joined on the local machine, however sometimes other systems would show, but still have pending status.

Any errors in User Device Registration and DeviceManagement-Enterprise-Diagnostics-Provider event logs.

No errors are showing.

Whether a valid device certificate exists in the Local Computer certificate store.

No certificates were seen on the device.

1 answer

Your answer

Sridevi Machavarapu 33,740 Reputation points Microsoft External Staff Moderator

2026-06-22T15:42:03.0933333+00:00

Hello Marcos Correa,

Your troubleshooting covers most of the common causes.

Since the devices show both AzureAdJoined = YES and DomainJoined = YES, the issue may be occurring after the Hybrid Join process starts.

Could you check the following on an affected device?

DeviceAuthStatus and AzureAdPrt from dsregcmd /status

Any errors in User Device Registration and DeviceManagement-Enterprise-Diagnostics-Provider event logs

Whether a valid device certificate exists in the Local Computer certificate store

Also, are there any device synchronization errors reported by Microsoft Entra Connect, and do the affected devices ever appear as managed in Intune before moving to a Pending state?

The results should help determine whether the issue is related to device registration, PRT issuance, or Intune enrollment.
Marcos Correa 10 Reputation points

2026-06-26T19:44:15.35+00:00

Hello Sridevi,

DeviceAuthStatus and AzureAdPrt from dsregcmd /status

It does not show YES to azure joined on the local machine, however sometimes other systems would show, but still have pending status.

Any errors in User Device Registration and DeviceManagement-Enterprise-Diagnostics-Provider event logs.

No errors are showing.

Whether a valid device certificate exists in the Local Computer certificate store.

No certificates were seen on the device.

Answer 1

Hello Marcos Correa,

Thanks for confirming those details.

No certificate in the Local Computer store combined with AzureAdJoined = NO and a clean event log tells us the device is not failing the join, it is never successfully completing the registration request at all. Normally a failed join leaves errors behind, so a silent failure with no logged errors usually points to one of these:

Check whether the Automatic-Device-Join task is actually running, not just present

Task Scheduler > Task Scheduler Library > Microsoft > Windows > Workplace Join > Automatic-Device-Join Task

Right click the task and check the History tab and Last Run Result. If it shows "The operation completed successfully" but no certificate was created afterward, the task is exiting early without actually attempting registration, which usually means it cannot reach the registration endpoint at all rather than reaching it and failing.

Test connectivity to the device registration endpoints from the affected device

Since there are no errors logged, this is worth ruling out directly rather than assuming connectivity is fine. From the device, confirm there is no SSL inspection, proxy authentication prompt, or firewall block on:

https://login.microsoftonline.com
https://device.login.microsoftonline.com
https://enterpriseregistration.windows.net
https://login.windows.net

SSL inspection in particular is a common silent blocker. It lets the TLS handshake complete so nothing looks broken at the network layer, but it breaks the certificate based device authentication so the registration request never lands.

Verify the Service Connection Point (SCP) details are correct

On a domain controller or RSAT machine:

Get-ADObject -SearchBase "CN=Device Registration Configuration,CN=Services,CN=Configuration,DC=yourdomain,DC=com" -LDAPFilter "(objectClass=serviceConnectionPoint)" -Properties keywords | Select-Object -ExpandProperty keywords

Confirm the Tenant ID and Tenant Name in the keywords match your actual Entra tenant. A stale or incorrect SCP will cause the join task to silently target the wrong tenant.

Check domain controller time sync

Hybrid join authentication is sensitive to clock skew. If your DCs are off from true time by more than a few minutes, certificate issuance will fail without always generating a client side error.

Run with verbose tracing instead of relying on the standard event logs

dsregcmd /debug /leave

then restart and either wait for the scheduled task or run:

dsregcmd /debug /join

The debug output is much more verbose than what lands in Event Viewer and will usually surface the actual failure reason, for example tenant discovery failure, certificate enrollment failure, or a network timeout, even when the standard logs stay clean.

Once you have the debug output from step 5, that will tell us definitively whether this is a connectivity issue, an SCP/tenant mismatch, or a certificate enrollment failure on the device side, and we can narrow the fix from there. If you find this answer is helpful please accept and help the community.

Best Regards,

Jerald Felix.