Azure Managed HSM: is delegated (authorization code / user_impersonation scope) access to the data plane supported?

Question

Azure Managed HSM: is delegated (authorization code / user_impersonation scope) access to the data plane supported?

Radnai Miklós 20

We need our application to call the Managed HSM data plane (e.g. listing/using keys) acting on behalf of a signed-in Microsoft Entra user, 
so that access is constrained by that user's own Managed HSM local RBAC role assignments 

For this we are trying to use the OAuth2 authorization code flow

We've found that the first-party "Azure Key Vault Managed HSM" service principal has an empty oauth2PermissionScopes array and an empty appRoles array in our tenant: GET https://graph.microsoft.com/v1.0/servicePrincipals 
 
By contrast, the standard "Azure Key Vault" service principal exposes a populated user_impersonation delegated scope. 

Requesting the authorization code flow against Managed HSM from our own third-party app registration fails: 
  - AADSTS650053: The application '...' asked for scope 'user_impersonation' that doesn't exist on the resource '...'. Contact the app vendor.
  when requesting https://managedhsm.azure.net/user_impersonation 

The OAuth2 authorization request i mentioned:
GET https://login.microsoftonline.com/{{tenantId}}/oauth2/v2.0/authorize
  ?client_id={{clientId}}
  &response_type=code
  &redirect_uri={{redirectUri}}
  &scope=https%3A%2F%2Fmanagedhsm.azure.net%2Fuser_impersonation

Questions: 
  1. Is delegated (authorization-code-flow) access to the Managed HSM data plane supported today for third-party app registrations? If so, what scope should we be requesting, given the first-party SP exposes none? 
  2. If it isn't supported, is this by design, and is there a recommended alternative pattern for constraining access to the calling user's own permissions (rather than a fixed app-only grant)?

0 comments

Answer accepted by question author

0 additional answers

Your answer

Answer 1

Hello @Radnai Miklós

Your observation about the service principal is significant. Based on the current Managed HSM authentication and authorization documentation, I don't see a supported delegated permission such as user_impersonation exposed for third-party applications targeting the Managed HSM data plane.

Managed HSM uses Microsoft Entra ID for authentication, but its authorization model differs from standard Key Vault in an important way. The Managed HSM data plane uses Managed HSM local RBAC, independently from Azure RBAC on the control plane. Users, groups, service principals, and managed identities are security principals that can be granted data-plane access.

Therefore, the error you're seeing: "AADSTS650053 The application asked for scope 'user_impersonation' that doesn't exist on the resource" is consistent with what you're seeing in the Managed HSM enterprise application: if the resource doesn't publish that delegated permission, requesting https://managedhsm.azure.net/user_impersonation isn't a valid way to obtain a delegated Managed HSM token.

Also, don't substitute the regular Azure Key Vault user_impersonation scope. Managed HSM has its own data-plane endpoint https://<hsm-name>.managedhsm.azure.net/. Managed HSM and Key Vault vaults are different resource types with different access-control behavior.

For an application/service calling Managed HSM, the documented pattern is instead to give the application's service principal or managed identity the required Managed HSM local RBAC role. For example, Microsoft documents assigning Managed HSM Crypto User to a service principal or managed identity at /keys or at an individual /keys/<key-name> scope.

For example:

az keyvault role assignment create \
  --hsm-name <hsm-name> \
  --role "Managed HSM Crypto User" \
  --assignee <application-or-managed-identity-object-id> \
  --scope /keys/<key-name>

The important architectural consequence is that the HSM then authorizes the application identity, not the interactive user's Managed HSM local RBAC assignment. So this does not reproduce the delegated “act as this user and evaluate this user's HSM permissions” model you're looking for.

If each user's authorization must remain distinct, I would avoid giving the middle-tier application a broad HSM-wide role and then treating the user's Entra authorization as though Managed HSM enforced it. Instead, authenticate and authorize the user in your application and give the application's HSM identity only the minimum key-level permissions required for the operations the application is allowed to perform. Managed HSM supports role assignments down to /keys/<key-name>, which can help reduce the application's HSM privileges.

If the requirement specifically mandates cryptographic enforcement by Managed HSM of the interactive user's own local-RBAC identity, rather than application-side authorization followed by an app/managed-identity HSM call, I would raise that requirement with Azure Key Vault/Managed HSM Support. I could not find a currently documented delegated/OBO permission for the Managed HSM resource that would make the authorization-code pattern in the question work.

Be careful not to interpret the lack of oauth2PermissionScopes as meaning Managed HSM doesn't use OAuth/Entra tokens at all. It does. The distinction here is between Entra authentication to Managed HSM and a resource exposing a delegated OAuth permission to third-party client applications.

References:

Managed HSM access control

Managed HSM data-plane role management

Managed HSM local RBAC built-in roles

Secure access to Managed HSM

Help make this community better for everyone: If this answer helped or resolved your issue, please accept it or upvote it. If not, share more details in a comment so we can continue the discussion and find the right solution. Thank you.