Fix "User is not authorized to read secrets" in Key Vault variables

Saving a Secret environment variable fails with "User is not authorized to read secrets". Give you and Dataverse the Key Vault Secrets User role, switch the vault to Azure RBAC, and check the network.

Azure + Power PlatformFix a problem6 min read

Checked against Microsoft Learn 11 Oct 2026 · 7 sourcesPosted by the Maker DeskHow we write guides

You create an environment variable of type Secret that points at Azure Key Vault, select Save, and Power Apps answers "This variable didn't save properly. User is not authorized to read secrets from" followed by the secret's full path. Power Platform checks, as it saves, that both you and Dataverse can read that secret. The message means one of those checks failed, and the fix is almost always a missing role, the vault's permission model or its firewall.

When it happens

The same check runs in three places, so the error can appear in any of them:

creating a new environment variable with Data Type set to Secret and Secret Store set to Azure Key Vault;
changing the Key Vault reference of an existing one;
importing a solution that contains one, for example into a test or production environment.

The path in the message tells you exactly which subscription, resource group, vault and secret Power Platform tried to read. Copy it: you'll need the vault name and resource group below. Behind the message, Key Vault refused the getSecret action with a 403 (Forbidden), which is a permissions answer, not a sign that the secret is missing.

Work through it

Do the steps in order and try saving again after each one. Role changes can take a few minutes to apply, so wait before deciding a step didn't work. You need the Owner or User Access Administrator role on the vault to add role assignments.

Give Dataverse the Key Vault Secrets User role

Dataverse reads the secret on your behalf, so its own identity needs permission to read secret values.

In the Azure portal, open the key vault and select Access control (IAM).
Select Add, then Add role assignment.
On Role, choose Key Vault Secrets User.
On Members, choose Select members and search for Dataverse. If several Dataverse identities appear, select them all.
Select Review + assign.

Microsoft's setup page adds a check: open each Dataverse entry in the vault's role assignments, and keep the one whose application ID is 00000007-0000-0000-c000-000000000000. Remove the others from this vault.

Done

Give yourself the same role

The person who creates, changes or imports the variable needs Key Vault Secrets User on the vault too. Repeat the steps above and choose that user under Members. In a pipeline that imports solutions, that's the identity the pipeline signs in with.

Done

Switch the vault to Azure RBAC

Power Platform checks Azure role assignments, even when the vault uses the older Vault access policy model. On such a vault the check can fail although the access policies look right.

Give every user and app that reads this vault an Azure role first, matching what its access policy allowed. Access policies stop applying once the vault switches, so anything you skip loses access.
In the key vault, open Settings > Access configuration.
Under Permission model, choose Azure role-based access control and save.
Check that you and Dataverse both have Key Vault Secrets User, then test the apps that use the vault.

Changing the permission model needs the Contributor or Owner role on the vault.

Done

Register the Microsoft.PowerPlatform resource provider

Power Platform can only work with resources in a subscription that has its resource provider registered.

In the Azure portal, open Subscriptions and select the vault's subscription.
Select Resource providers and search for Microsoft.PowerPlatform.
If it shows NotRegistered, select it and choose Register.

Done

Check the network and the tenant

Firewall: if the vault allows only selected networks, add the Power Platform IP address ranges for your region (see Sources). The Allow trusted Microsoft services to bypass this firewall option doesn't cover Power Platform.
Private endpoint: with Virtual Network support for Power Platform, the vault's private endpoint must be in the same region as the environment, in the subnet delegated to Power Platform, with private DNS integration on. If your enterprise policy delegates subnets in two regions, create an endpoint in each. Virtual Network support needs a Managed Environment.
Tenant: the vault must be in the same Microsoft Entra tenant as the environment. A vault in another tenant can't be used; move the secret to a vault in the right tenant.

Done

Check everything with the Azure CLI

These commands only read settings, so they're safe to run first. Replace the vault and resource group names, then compare the output with the comments.

bash

vault="kv-contoso-flows"
rg="rg-power-platform"
scope=$(az keyvault show --name "$vault" --resource-group "$rg" --query id -o tsv)

# Azure RBAC on? Expect: true
az keyvault show --name "$vault" --resource-group "$rg" --query properties.enableRbacAuthorization

# Who can read secret values? Expect your account and Dataverse in the list.
az role assignment list --scope "$scope" --role "Key Vault Secrets User" \
  --query "[].{who:principalName, type:principalType}" -o table

# Resource provider registered? Expect: Registered
az provider show --namespace Microsoft.PowerPlatform --query registrationState -o tsv

# Firewall? "Deny" means only the networks listed on the vault get in.
az keyvault show --name "$vault" --resource-group "$rg" --query properties.networkAcls.defaultAction

If something is missing, these make the changes. Run the role assignments before switching the permission model.

bash

dataverse=$(az ad sp show --id 00000007-0000-0000-c000-000000000000 --query id -o tsv)
me=$(az ad signed-in-user show --query id -o tsv)

az role assignment create --role "Key Vault Secrets User" \
  --assignee-object-id "$dataverse" --assignee-principal-type ServicePrincipal --scope "$scope"
az role assignment create --role "Key Vault Secrets User" \
  --assignee-object-id "$me" --assignee-principal-type User --scope "$scope"

az provider register --namespace Microsoft.PowerPlatform
az keyvault update --name "$vault" --resource-group "$rg" --enable-rbac-authorization true

Why Key Vault Reader isn't enough

Older setup instructions asked for Key Vault Reader. That role can see that a secret exists and read its details, but not its value. Key Vault Secrets User is the role that reads secret contents, and Power Platform now checks for it. If your vault was set up with the old instructions, add Key Vault Secrets User for you and for Dataverse; you can keep or remove Key Vault Reader.

Where the secret can be used

Once it saves, the environment variable holds a reference to the secret, not the secret itself. You can use it in Power Automate flows and custom connectors. Other parts of Power Platform, and the Dataverse API, don't return it, and it doesn't appear in a flow's dynamic content list. Microsoft suggests a separate vault for each environment, so a problem in one can't expose the others.

Sources

"User is not authorized to read secrets" error when saving environment variables, Microsoft Learn
Use environment variables for Azure Key Vault secrets, Microsoft Learn
Migrate to Azure RBAC from access policies, Microsoft Learn
Plan for Azure RBAC as the default access control model in Key Vault, Microsoft Learn
Provide access to Key Vault keys, certificates, and secrets with Azure RBAC, Microsoft Learn
Power Platform URLs and IP address ranges, Microsoft Learn
Resource providers and resource types, Microsoft Learn

Did this fix it?

Comments

No comments yet. Share what worked for you.