User-assigned managed identities cannot be created: every request returns 400 "Bad request" with no detail

Raghu K 0 Reputation points
2026-11-12T19:04:52.9766667+00:00

Since 12 Nov 2026, every attempt to create a user-assigned managed identity in our subscription fails with only this response:

{"error":{"code":"BadRequest","message":"Bad request."}}

What we tried (all return the same 400)

  • Clients: the Azure portal, az identity create (CLI 2.92.0), a plain REST PUT with body {"location":"eastus"}, Terraform azurerm 4.81 and azapi
  • Callers: a user with Owner on the subscription, and a service principal signed in through GitHub OIDC
  • Three different resource groups
  • Regions: eastus and eastus2
  • API versions: 2018-11-30, 2023-01-31, 2024-11-30, 2025-05-31-preview
  • Several names (letters, digits and hyphens, 14 to 22 characters), with tags and without

az deployment group validate on a template with the same resource succeeds.

What still works

  • System-assigned identities: an App Service got one on the same day.
  • The existing user-assigned identities read and list normally. The last one was created successfully on 30 Oct 2026.

What we checked

  • The Microsoft.ManagedIdentity provider is registered.
  • The "Managed Service Identity" enterprise application is enabled in the tenant (the fix from an older Q&A thread with the same symptom).
  • The directory is far below its object quota.
  • The resource groups have no locks and no Azure Policy assignments.
  • Azure Service Health shows no incident.
  • The activity log entry for each failure holds only the same "Bad request" body.
  • The Microsoft Entra audit log has no entry for the failed creates, so the request seems to be refused before a service principal is requested.
  • The subscription had 10 user-assigned identities. We deleted an unused one to test for a cap; creates still fail with 9.

About the subscription

Pay-as-you-go under a Microsoft Customer Agreement (individual billing account), active, no spending limit, Basic support only. The tenant is on the Free edition of Microsoft Entra ID.

Questions

  1. What makes the identity service answer a bare 400 for a well formed create request?
  2. Does this subscription or account type carry a restriction on user-assigned identities that we cannot see?

We have correlation ids and timestamps for the failed requests and can share them privately with a Microsoft moderator.

Microsoft Security | Microsoft Entra | Microsoft Entra ID
0 comments No comments

1 answer

Sort by: Newest
  1. AI answer

    2026-11-12T19:07:30.36+00:00

    This is not a documented Pay-as-you-go, Microsoft Customer Agreement, or Entra Free restriction; because the same valid create operation fails across clients, callers, regions, and API versions, the next actionable step is an Azure Support investigation using the failed operation’s correlation IDs.

    What the documented limits rule out

    Azure documents these limits for managed-identity creation:

    • 400 creates per 20 seconds per tenant and region.
    • 80 creates per 20 seconds per subscription and region.
    • Every managed identity counts toward the tenant’s Microsoft Entra object quota.^1^

    A throttling limit is expected to produce HTTP 429, not the persistent HTTP 400 reported here.^2^

    There is no documented subscription-tier limit of 10 user-assigned managed identities. Entra Free has a directory-object quota—normally 50,000 objects, or 300,000 with a verified domain—not a nine- or ten-managed-identity cap.^3^ Deleting one identity also does not immediately eliminate its directory footprint: managed identities are soft-deleted for 30 days.^4^ That detail does not explain this case because the directory is already far below quota.

    Your minimal REST body is also consistent with the documented resource schema: location and name are required, while properties and tags are optional.^5^

    What the bare 400 means here

    The public information does not identify the provider-side reason represented by this bare BadRequest. The evidence does narrow its location:

    • Template validation succeeding only establishes that validation/preflight accepted the deployment; deployment processing can still fail afterward.^6^
    • Identical failures through the portal, CLI, raw REST, Terraform, and AzAPI make a client-specific serialization problem unlikely.
    • Owner and service-principal failures make an ordinary caller-specific RBAC issue unlikely.
    • The enabled Managed Service Identity enterprise application rules out the resolution from the older matching report.
    • No Entra audit event is consistent with failure before directory-object creation, but it does not expose the internal Managed Identity resource-provider reason.
    • Public Azure status does not show a verified Azure-wide incident matching this date and operation.^7^

    System-assigned identity creation succeeding does not prove that user-assigned creation is healthy; these are different operations and lifecycle models. User-assigned identities are standalone resources reusable by multiple Azure resources.^8^

    Escalation package

    Open Azure portal → ? → Help + Support → Create a support request and select the affected subscription and the closest Managed Identity technical problem type. The built-in support flow includes self-help categories specifically for problems creating user-assigned managed identities. An Owner can create the request.^9^

    Include:

    1. Subscription and tenant identifiers in the private support case only.
    2. Resource provider and operation: Microsoft.ManagedIdentity/userAssignedIdentities/write.
    3. Exact UTC timestamps and correlation IDs for several failures.
    4. One failure from each region.
    5. Full request URI, API version, sanitized request body, response headers, and response body.
    6. The first observed failure date and last known successful creation date.
    7. A concise list of the already-excluded variables: clients, callers, resource groups, regions, API versions, names, tags, provider registration, enterprise application state, locks, Policy, and directory quota.
    8. The fact that validation succeeds but the actual PUT fails before an Entra audit event appears.

    Correlation IDs are specifically intended to let Support trace related deployment events.^10^

    Basic support does not include normal technical support; Microsoft documents subscription management, billing, quota adjustments, and account transfers as available without a technical plan, while technical investigation requires a support plan.^9^ Start the portal support flow anyway: if it classifies this as a service/quota or subscription-side restriction, that route may be available without upgrading. If it classifies it as technical, a paid support plan will be required.

    Do not post correlation IDs, tenant IDs, tokens, or complete traces publicly. A Q&A moderator may request identifiers privately, but only Azure Support can inspect the resource provider’s backend trace and determine whether this is an undocumented subscription entitlement, tenant state, or scoped service fault.


    References

    1. Azure subscription and service limits, quotas, and constraints
    2. Important considerations and restrictions for federated identity credentials
    3. Microsoft Entra service limits and restrictions
    4. Managed identities for Azure resources frequently asked questions
    5. Microsoft.ManagedIdentity userAssignedIdentities 2024-11-30 (deployment-language-terraform)
    6. Find error codes
    7. Azure status history | Microsoft Azure - azure.status.microsoft
    8. Manage user-assigned managed identities using the Azure portal
    9. Create an Azure support request
    10. View deployment history with Azure Resource Manager
    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.