Microsoft Security | Microsoft Entra | Microsoft Entra External ID
Managing external identities to enable secure access for partners, customers, and other non-employees
Hello Mauricio Ribeiro Monteiro,
Greetings! Thanks for raising this question in the Q&A forum.
What you are hitting is a known limitation with Microsoft Entra External ID (CIAM) directories that fail during provisioning. The reason the Azure Resource Manager DELETE call keeps returning 403 is that the authorization check for this resource type is not actually enforced by ARM itself, it is enforced inside the Entra service that backs the ciamDirectories resource. Since provisioning failed before a Global Administrator identity could be fully established in that tenant, and the original Global Administrator account has since been deleted, there is no principal left that Entra will recognize as authorized to manage or remove the directory. This leaves the ARM resource stranded in a Failed provisioning state with no self-service path to delete it, since neither the portal, CLI, nor direct Graph/ARM calls can bypass that internal ownership check.
Confirm this is genuinely an orphaned resource rather than a normal deletable tenant Run az account tenant list and check whether tenant ID 94804f97-55dd-4f2b-94d6-20b6bf09d2cc appears. If it does not appear at all, this confirms the CIAM tenant itself never finished provisioning and only the ARM resource shell exists, which matches what you already found.
Rule out a self-service recovery path first Sign in to the Microsoft Entra admin center at entra.microsoft.com using the account tied to the subscription that owns the resource group, and check under Identity > Overview > Manage tenants whether the failed CIAM tenant is listed there. If it is listed and you can add yourself as Global Administrator, you may be able to complete deletion normally through Identity > Overview > Delete. Based on your description this is unlikely to work since the tenant never finished provisioning, but it takes only a minute to confirm.
Escalate through a Microsoft Support ticket rather than retrying ARM or CLI delete Since the block is inside the Entra service and not something exposed through any documented API, this requires a backend cleanup by Microsoft engineering. Open a support case tied to the subscription that owns the resource group, since support is associated with the subscription rather than requiring you to sign in through the failed tenant. Select support type Technical, service Microsoft Entra External ID (CIAM), and problem type related to directory or tenant provisioning failures.
Provide these specifics in the ticket to speed up backend routing Include the full resource ID
/subscriptions/<subscriptionId>/resourceGroups/<resourceGroupName>/providers/Microsoft.AzureActiveDirectory/ciamDirectories/<yourCiamDomain>.onmicrosoft.com
the tenant ID, the fact that ProvisioningState is Failed, that the original Global Administrator account was deleted, and that DELETE consistently returns 403 with the message about Global Administrators managing directory settings. Explicitly state that this is a stranded ciamDirectories ARM resource with no valid administrator and ask for it to be routed to the Microsoft Entra ID and CIAM engineering backend directory provisioning team, since front line support agents typically cannot action this directly and it needs internal escalation.
While waiting on the ticket The resource group containing this orphaned resource will remain undeletable, so avoid nesting other production resources in the same resource group until the CIAM directory resource is cleaned up on the backend.
If this answer helps you kindly accept the answer which will help others who have similar questions.
Best Regards,
Jerald Felix