Azure is pushing everyone from Key Vault Access Policies to RBAC, and their ‘Action required’ warnings are causing headaches. Here’s my real-world guide on why this is happening and three ways to fix it without taking down your services.

That Annoying Azure Key Vault Warning: A DevOps Guide to Not Breaking Prod

It was 2 AM on a Tuesday, and the on-call pager was screaming. A routine deployment had just knocked over our entire payments API. The cause? A newly provisioned Key Vault that our CI/CD service principal, sp-prod-cicd-runner, suddenly couldn’t read from. The logs were useless, just ‘Forbidden’. It took us an hour to figure out that a subtle change in how Azure Resource Manager (ARM) provisions Key Vaults had left our new vault in a permission-less limbo. If you’ve seen the “Action required: Transition Azure Key Vault access policies to Azure RBAC…” warning, you’re staring down the barrel of that same gun. Let’s disarm it.

So, Why Is This Happening Now?

Let’s get straight to it. For years, Key Vault had its own quirky permission system called “Access Policies”. It worked, but it was a special snowflake in the Azure ecosystem. Every other service was standardizing on Azure Role-Based Access Control (RBAC), which is more granular, consistent, and integrates with fancy tools like Privileged Identity Management (PIM).

Microsoft is finally pushing everyone to use RBAC for Key Vaults too. The problem—and the reason for my 2 AM incident—is that when you create a Key Vault now using Infrastructure as Code (like Bicep or Terraform), Azure doesn’t default to the old Access Policies anymore. It doesn’t default to RBAC either. It defaults to… nothing. It creates the vault in a state where you must explicitly choose one or the other. This “explicit choice” model is what’s causing the warnings and, if you’re not careful, breaking your pipelines.

The Three Fixes: From Band-Aid to Brain Surgery

I’ve seen teams handle this in a few ways, depending on how much time they have and how much they care about technical debt. Here are the three main plays.

Solution 1: The ‘Just Make It Go Away’ Fix (Keep Access Policies)

This is the quickest way to silence the warning and ensure your existing pipelines don’t break. You’re essentially telling Azure, “Hey, I know RBAC is the new hotness, but I want to keep using the old Access Policies for now.” You do this by explicitly setting a property in your IaC.

In your Bicep file for the Key Vault, you just add one line: enableAccessPolicies: true.

resource keyVault 'Microsoft.KeyVault/vaults@2022-07-01' = {
  name: 'kv-prod-weu-01'
  location: resourceGroup().location
  properties: {
    sku: {
      family: 'A'
      name: 'standard'
    }
    tenantId: tenant().tenantId
    // THIS IS THE FIX. EXPLICITLY ENABLE THE OLD MODEL.
    enableAccessPolicies: true
    accessPolicies: [
      // Your existing access policies go here...
      {
        tenantId: tenant().tenantId
        objectId: 'your-service-principal-object-id'
        permissions: {
          secrets: [
            'get'
            'list'
          ]
        }
      }
    ]
  }
}

Warning: This is a band-aid. You’re acknowledging the problem but kicking the can down the road. It works, it’s fast, but you should create a backlog ticket to migrate to RBAC later. This is technical debt.

Solution 2: The ‘Do It Right’ Fix (Migrate to RBAC)

This is the path Microsoft wants you to take, and honestly, it’s the correct long-term solution. You’re ripping out the old Access Policies and replacing them with standard Azure role assignments. It’s more work upfront but makes managing permissions much cleaner in the long run.

The process has two parts:

1. Update your Key Vault definition to use the RBAC permission model.
2. Create separate `roleAssignment` resources for each principal that needs access.

Here’s how that looks in Bicep:

// --- Part 1: Update the Key Vault Resource ---

resource keyVault 'Microsoft.KeyVault/vaults@2022-07-01' = {
  name: 'kv-prod-weu-01'
  location: resourceGroup().location
  properties: {
    sku: {
      family: 'A'
      name: 'standard'
    }
    tenantId: tenant().tenantId
    // SET the permission model to RBAC
    enableRbacAuthorization: true
    // REMOVE the entire accessPolicies array and enableAccessPolicies property
  }
}

// --- Part 2: Create a Role Assignment ---
// (You'll need one of these for each user/app/identity)

// Built-in Role Definition ID for 'Key Vault Secrets User'
var keyVaultSecretsUserRoleId = '4633458b-17de-408a-b874-0445c86b69e6'

// The Object ID of your Web App's Managed Identity or a Service Principal
var webAppPrincipalId = 'your-principal-object-id'

resource assignWebAppSecretReaderRole 'Microsoft.Authorization/roleAssignments@2022-04-01' = {
  name: guid(keyVault.id, webAppPrincipalId, keyVaultSecretsUserRoleId)
  scope: keyVault // Assign the role at the Key Vault scope
  properties: {
    roleDefinitionId: resourceId('Microsoft.Authorization/roleDefinitions', keyVaultSecretsUserRoleId)
    principalId: webAppPrincipalId
    principalType: 'ServicePrincipal' // Or 'User', 'Group'
  }
}

Pro Tip: Before you delete your old accessPolicies block, take a screenshot or copy it somewhere. You’ll need that list of Object IDs to create your new role assignments. Don’t try to do it from memory.

Solution 3: The ‘Nuke and Pave’ Fix (For Non-Prod Only)

Sometimes, especially in a dev or test environment, the fastest way to fix a misconfigured resource is to burn it to the ground and start over. If your Key Vault doesn’t contain any irreplaceable secrets and can be easily repopulated, this is a viable, clean option.

1. Destroy: Delete the problematic Key Vault from your non-prod environment.
2. Update: Modify your IaC code to use the RBAC model from the start (as shown in Solution 2).
3. Redeploy: Run your deployment pipeline to create a fresh, correctly configured Key Vault.

SERIOUS WARNING: Do not, under any circumstances, do this in a production environment. Deleting a Key Vault is irreversible and you will lose all secrets, keys, and certificates within it. This is for dev/test sandboxes ONLY where data loss is acceptable.

Look, we’ve all been burned by a cloud provider changing the defaults. This is one of those times. The move to RBAC is a good one for the platform, even if the transition is a little rocky. Pick the fix that saves your bacon today, but make a plan to get to RBAC across the board. Now go fix it before you get that 2 AM page.

-Darian

Darian Vance

Lead Cloud Architect & DevOps Strategist

With over 12 years in system architecture and automation, Darian specializes in simplifying complex cloud infrastructures. An advocate for open-source solutions, he founded TechResolve to provide engineers with actionable, battle-tested troubleshooting guides and robust software alternatives.

🤖 Frequently Asked Questions