How to secure Azure storage with Managed identities for a web app

Introduction

Building a new app is exciting but shipping an app with poorly secured storage is a headline waiting to happen.

When developers build apps that read and write data to the cloud, the question isn't just where data lives, it's who can access it, how that access is controlled, and what happens if someone tries to tamper with critical files.

Passwords get leaked, Keys get exposed in code repositories, Shared credentials get passed around Slack until nobody knows who has access to what. These aren't hypothetical risks, they're the most common causes of data breaches in cloud applications.

This guide shows you (developers) how to do it the right way with no passwords embedded in code, no shared keys floating around, no way for even an admin to delete protected data. Just clean, auditable, role-based access backed by industry-standard encryption.

Azure Blob Storage paired with Managed Identities, Key Vault, and RBAC gives your app exactly that and it's less complicated than it sounds.

What Are We Actually Building?

A secure storage setup where:

• Your app accesses storage using an identity, not a password


• Encryption keys are stored in a dedicated vault, not in your app's config


• Access is controlled by roles, not by sharing credentials


• Test files are immutable i.e nobody can modify or delete them, not even admins


• Infrastructure is double-encrypted from the moment the account is created

Let's define some terms

• 
  Managed Identity: An automatically managed account in Azure that your app uses to prove who it is without needing a username or password stored in your code.


• 
  RBAC (Role-Based Access Control): A permission system where you assign roles (like "Reader" or "Contributor") instead of handing out keys. The right people get the right access, nothing more.


• 
  Key Vault: A dedicated Azure service for storing secrets, keys, and certificates. Instead of your app holding its own encryption keys, Key Vault holds them and only hands them out to authorised identities.


• 
  Customer-Managed Key (CMK): An encryption key that you control, stored in Key Vault, used to encrypt your storage. More control than the default Microsoft-managed key.


• 
  Infrastructure Encryption: A second layer of encryption applied at the hardware level. Your data is encrypted twice; once at the service level, once at the infrastructure level.

Step 1: Create an Encrypted Storage Account

This account has infrastructure encryption enabled i.e a second layer of encryption that cannot be turned off or changed after creation.

• In Microsoft azure portal, search for Storage accounts
  


• Click + Create
  
  


• Create a new resource group (name it app-storage-rg)
  
  


• Give the storage account a unique name (like appstorage2026)
  
  


• Go to the Encryption tab


• Check Enable infrastructure encryption
  Notice the warning: "This option cannot be changed after this storage account is created"


• Click Review + Create
  
  


• Then Create
  
  


• Wait for deployment and click Go to resource
  
  

Step 2: Create a Managed Identity

Instead of your app using a key or password, it uses a managed identity which is an automatically managed account that Azure handles for you.

• In azure portal, search for Managed identities
  
  


• Click + Create
  
  


• Select your resource group


• Give it a clear name (like app-storage-identity)


• Click Review + create
  
  


• Then Create
  
  Your app now has an identity in Azure without password, no key, no expiry to manage.

Step 3: Assign Storage Access to the Identity (RBAC)

• Go to your storage account


• Select Access Control (IAM) from the left menu


• Click Add role assignment
  
  


• Search for and select Storage Blob Data Reader
  


• Click Next
  
  


• On Members, select Managed identity
  


• Click Select members
  


• In the dropdown, select User-assigned managed identity
  


• Select the identity you created in Step 2


• Click Select
  
  


• Then Review + assign (twice to confirm)
  
  Your managed identity can now read blobs and only read blobs. It cannot delete, modify, or list account keys.

Step 4: Assign Key Vault Administrator to Your Account

Before creating a Key Vault, you need to give yourself administrator permissions on the resource group.

• Go to Resource groups and select your resource group
  
  


• Select Access Control (IAM)
  


• Click Add role assignment
  
  


• Search for and select Key Vault Administrator, then Next
  
  


• On Members, select User, group, or service principal
  


• Click Select members and search for your own user account


• Click Select
  
  


• Then Review + assign (twice)
  
  You're now authorised to create and manage keys in Key Vault.

Step 5: Create a Key Vault

Key Vault is where your encryption keys live and it is separate from your app, storage, locked down with its own access control.

• Search for Key vaults
  
  


• Click + Create
  
  


• Select your resource group


• Give it a unique name (like app-keyvault-2026)
  
  


• On the Access configuration tab, ensure Azure role-based access control (recommended) is selected


• Click Review + create
  
  


• Then Create
  
  


• After deployment, click Go to resource
  
  


• On the Overview blade, confirm both Soft-delete and Purge protection are enabled
  
  Why Soft-delete and Purge protection matter: These prevent accidental or malicious deletion of keys. If a key is deleted, soft-delete holds it for 90 days. Purge protection means nobody (not even you) can permanently delete it during that window. Your encrypted data stays recoverable.

Step 6: Create a Customer-Managed Encryption Key

• In your Key Vault, go to Objects → Keys
  


• Click Generate/Import
  
  


• Give your key a name (like storage-encryption-key)


• Keep all other settings as default


• Click Create
  
  
  

Step 7: Give the Identity Permission to Use the Key

Before linking the key to your storage, the managed identity needs permission to use it for encryption operations.

• Go to Resource groups → your resource group → Access Control (IAM)


• Click Add role assignment
  
  


• Search for and select Key Vault Crypto Service Encryption User then Next
  
  


• On Members, select Managed identity
  


• Click Select members → choose User-assigned managed identity
  


• Select your managed identity


• Click Select
  
  


• Then Review + assign (twice)
  
  

Step 8: Configure Storage to Use Your Key Vault Key

• Go back to your storage account


• Navigate to Security + networking → Encryption
  


• Select Customer-managed keys
  


• Click Select a key vault and key
  
  


• Choose your Key Vault and the key you created


• Confirm your selection
  
  


• Ensure Identity type is set to User-assigned
  


• Click Select an identity and choose your managed identity


• Click Add, Then Save
  
  

Step 9: Create an Immutable Container for Testing

Developers need a container where files can't be changed or deleted not even by an admin. This is critical for testing environments where file integrity must be guaranteed.

• In your storage account, go to Data storage → Containers
  


• Click + Container
  


• Name it hold
  


• Keep the defaults and click Create
  
  


• Upload any test file to the container
  
  


• Go to Settings → Access policy
  


• In the Immutable blob storage section, click + Add policy
  


• Set Policy type to Time-based retention
  


• Set the Retention period to 5 days


• Click Save
  
  

Test if it works:

• Try to delete the file you uploaded
  
  


• You should get "Failed to delete blobs due to policy"
  
  That error is the right result. The file is protected for 5 days

Step 10: Create an Encryption Scope

The developers require an encryption scope that enables infrastructure encryption.

• In your storage account, go to Security + networking → Encryption
  


• Select the Encryption scopes tab


• Click + Add
  


• Give it a name (like secure-scope)


• Keep Encryption type as Microsoft-managed key
  


• Set Infrastructure encryption to Enable
  


• Click Create
  
  

Apply it to a new container:

• Go to Data storage → Containers
  


• Click + Container
  


• Give it a name (securencrypt)


• In the Advanced section, select your encryption scope


• Click Create
  
  Every blob in this container now gets its own dedicated encryption layer on top of the account-level encryption.

Common issues

• 
  Identity does not have the correct permissions" when saving encryption: Role assignments take 1-2 minutes to propagate across Azure. Wait, then try again.


• 
  Failed to delete blobs due to policy: This is correct behaviour. The immutable policy is working as intended. Wait for the retention period to expire, or test with a shorter period.


• 
  Managed identity not appearing in dropdown: Make sure you created a User-assigned managed identity, not a system-assigned one. They appear in different drop-downs.


• 
  Key Vault key not visible when selecting for storage encryption: Confirm you assigned the Key Vault Crypto Service Encryption User role to the managed identity, not just the administrator role.

What part of this took longest to configure in your environment? The RBAC roles, the Key Vault setup, or the immutable policy? Share in the comments. It helps other developers know where to slow down.