Entra ID External IdP: Intermittent AADSTS650051 on /adminconsent When Updating Application Permissions on Existing Enterprise App

Question

Hi Team,

We are integrating Microsoft Entra ID as an external IdP in our product, where tenant admins grant consent via a redirect-based /adminconsent flow (not manual portal-only provisioning).

We observed inconsistent behavior and want to confirm whether this is expected or a product issue.

Observations

1. The tenant already had an Enterprise Application (service principal) for our app.
2. We deleted that Enterprise Application.
3. Immediately after deletion, the first admin consent attempt failed with:

AADSTS650051: Consent action for Application 'f472xxxxxxxxxxxxd8f7579' failed due to following error: The f4726f3xxxxxxxxxxxx3d8f7579 service principal name is already present for the tenant cf59xxxxxxxxx34a11b7 ...

• Trace ID: 523ba150xxxxxxxxxebf1b800
• Correlation ID: d9582bxxxxxxxx53af90
• Timestamp: 2026-08-04 18:09:03Z

1. Even though this error is returned, the Enterprise Application appears to be present/created in the tenant.
2. After retrying /adminconsent, the flow succeeds and we receive the tenant ID in the response.

Question

Is this behavior expected due to soft-delete/eventual consistency of service principals, or is this a bug in Entra ID consent processing?

Also, is there recommended retry/backoff guidance after deleting an Enterprise Application before re-running /adminconsent?

Our goal is to update application permissions on the customer’s existing Enterprise Application after tenant admin consent.

Thanks.

Answer 1

Hello Prathyush P V,

Greetings! Thanks for raising this question in Q&A forum.

Based on the behavior you described, this is most likely related to service principal soft deletion and backend replication delays in Microsoft Entra ID. After an Enterprise Application is deleted, some directory references may still exist for a short period, which can cause the initial AADSTS650051 error even though the service principal recreation is already in progress.

1. Verify whether the deleted Enterprise Application still appears in the tenant's deleted objects or can be restored through Microsoft Entra ID.
2. After deleting an Enterprise Application, avoid immediately triggering the /adminconsent flow. Allow some time for directory replication to complete.
3. Implement retry logic with exponential backoff in your application when receiving AADSTS650051 during consent operations.
4. Check the Microsoft Entra sign-in and audit logs around the provided Correlation ID and Timestamp to confirm whether the service principal was being recreated when the error occurred.
5. If the behavior is consistently reproducible across multiple tenants, collect the Correlation ID, Trace ID, Timestamp, Tenant ID, and Application ID for further investigation.

Since the Enterprise Application is ultimately created and the subsequent /adminconsent attempt succeeds, this points more toward a transient backend consistency issue rather than a permanent configuration problem.

The next action would be to monitor whether the issue occurs consistently and, if it does, a Microsoft support engineer can review the backend logs using the correlation details to determine whether this is expected replication behavior or a product issue.

If this answer helps you kindly accept the answer which will help others who have similar questions

Best Regards,

Jerald Felix.