Azure Arc doesn't support user-assigned managed identity?

Question

Azure Arc doesn't support user-assigned managed identity?

Gowtham K 51 MVP

According to Microsoft documentation, we began implementing the system-assigned managed identity on Azure Arc-enabled machines. Based on new requirements, we are now looking to use a user-assigned managed identity. However, it's not working. Nowhere in the documentation mention the limitation of using a user-assigned managed identity on Azure Arc-enabled machines. Do we have any workarounds for implementing the user-assigned managed identity in Azure Arc-enabled machines?

Suchitra Suregaunkar 8,070 Reputation points Microsoft External Staff Moderator

2026-01-14T07:26:43.0966667+00:00

Hello Gowtham K

Please let us know if the suggested resolution helped/ addressed your concern. If it did, we’d appreciate your feedback on the proposed resolution as it helps others with similar issues.

We’re happy to continue assisting and work with you toward the right solution.

Thanks,

Suchitra.

Answer accepted by question author

1 additional answer

Your answer

Suchitra Suregaunkar 8,070 Reputation points Microsoft External Staff Moderator

2026-01-14T07:26:43.0966667+00:00

Hello Gowtham K

Please let us know if the suggested resolution helped/ addressed your concern. If it did, we’d appreciate your feedback on the proposed resolution as it helps others with similar issues.

We’re happy to continue assisting and work with you toward the right solution.

Thanks,

Suchitra.

Answer 1

Hello Gowtham K

Thank you for posting your query on Microsoft Q&A portal.

User-assigned managed identities (UAMI) are not supported on Azure Arc‑enabled servers today. Only system‑assigned managed identity (SAMI) is supported for Azure Arc–enabled machines.

This limitation is real, even though it is not clearly stated in the public documentation. Internal sources confirm this.

1. Azure Arc documentation explicitly states that only system-assigned MI is supported

In Identity and access management with Azure Arc-enabled servers, the Microsoft documentation says:

“Arc-enabled servers require a system-assigned managed identity.” [Identity a...soft Learn | Learn.Microsoft.com]

No mention of user-assigned MI support.

2. SQL Server enabled by Azure Arc also clarifies the same

“Only system-assigned managed identities are supported.” [Managed id...soft Learn | Learn.Microsoft.com]

3. Internal Microsoft incident confirms UAMI is not supported

In an Azure Arc / Geneva monitoring Sev‑3 incident:

“User Assigned Managed Identity is not applicable for Azure Arc servers,” and the team had to migrate to resource-type–based ACLs instead. [RE: [PROD]...d Identity | Outlook]

These internal notes reaffirm the product limitation.

Why UAMI Doesn’t Work on Arc Machines

Azure Arc uses the Hybrid Instance Metadata Service (HIMDS) to issue tokens. HIMDS currently supports only the system-assigned identity created when the Arc agent is onboarded.

Unlike Azure VMs, Arc-enabled machines cannot attach UAMIs in the resource identity blade, because:

✔ There is no identity blade ✔ There is no mechanism to inject multiple identities into HIMDS ✔ HIMDS has no current support for selecting a specific UAMI

Current Workarounds / Alternatives

Although UAMI is not supported, there are practical alternatives depending on your scenario.

1. Use System-Assigned MI + RBAC Scoping (recommended)

You can scope the SAMI of the Arc machine to exactly the same RBAC permissions you intended to use with a UAMI:

Assign roles at resource, resource group, or subscription level.
Use this as a least‑privilege identity.

This is the only supported method for Arc machines today.

2. For Geneva Monitoring / custom agents – use Resource-Type ACLs

This was the workaround used internally:

“Since UAMI is not applicable for Arc servers, we had to use resource-type-based ACLs (providers/Microsoft.HybridCompute/machines).” This works for Geneva monitoring and other custom workloads where the token verifier supports resource-type identities.

3. Use Service Principal (App Registration) where technically allowed

Not ideal, but sometimes acceptable for:

Legacy automation
Agents that cannot use SAMI

Azure Arc's HIMDS supports token issuance only for SAMI, so apps requiring UAMI must authenticate using a service principal until support is added.

Hope this helps you get closer to a solution! Let me know if you have any further questions!

Suchitra Suregaunkar 8,070 Reputation points Microsoft External Staff Moderator

2026-01-14T07:35:10.75+00:00

Hello Gowtham K

If the suggested resolution resolved the issue, kindly consider marking the answer as Accepted and upvoting it. This helps other community members who may encounter a similar issue in the future.

Thanks,

Suchitra.
Siva shunmugam Nadessin 5,700 Reputation points Microsoft External Staff Moderator

2026-01-14T20:55:40.2133333+00:00

Hello Gowtham K,

As you have upvoted it don't forget to

this can be beneficial to other community members.

Answer 2

Azure Arc does have limitations regarding user-assigned managed identities. Currently, the documentation indicates that user-assigned managed identities are not supported for certain functionalities within Azure Arc-enabled machines. Specifically, the creation of federated identity credentials is not supported on user-assigned managed identities in certain regions. This might be the reason you are experiencing issues with implementing a user-assigned managed identity.

As for workarounds, the documentation does not provide specific alternatives for using user-assigned managed identities on Azure Arc-enabled machines. It is advisable to continue using system-assigned managed identities, which are fully supported and can be utilized to authenticate to Azure resources without the limitations associated with user-assigned identities.

References:

Share via

Azure Arc doesn't support user-assigned managed identity?

1 additional answer

Your answer