3 Ways to Encrypt Your Backups in Azure and Critical Best Practices 

What Is Azure Backup Encryption? 

Azure Backup Encryption is a security feature within the Azure Backup service that protects backup data both in transit and at rest. It ensures that data being transferred from a source to Azure remains confidential by using standard encryption protocols. The feature also guarantees that all backup data stored within a Recovery Services vault or a Backup vault in Azure is encrypted, preventing unauthorized access even if the physical storage is compromised. Azure Backup enforces HTTPS in transit and AES-256 at rest for all backups; you can’t turn this off.

The encryption process leverages industry-standard encryption algorithms such as AES 256-bit and allows for flexibility in key management, supporting both Microsoft-managed and customer-managed keys. Customers can integrate their backup protection with Azure Key Vault, giving them direct control over the lifecycle and rotation of encryption keys. This capability helps enterprises meet various compliance and regulatory requirements. Additionally, Azure Backup Encryption operates transparently, with minimal impact on backup and restore operations, while maintaining strong security assurances.

In this article:

• Azure Backup Encryption Levels
• 3 Ways to Encrypt Your Backups in Azure
• Key Considerations for Choosing your Azure Encryption Method
• Best Practices for Azure Backup Encryption

Azure Backup Encryption Levels 

Encryption of Data in the Recovery Services Vault

Azure Backup encrypts all data stored in the Recovery Services vault using AES 256-bit encryption by default. This default encryption applies to all workloads and is handled through platform-managed keys, requiring no setup or action from the user. In a Recovery Services vault, customer-managed keys are configured at the vault level and apply to all workloads protected by that vault.

For enhanced control, customers can opt to use customer-managed keys stored in Azure Key Vault. Customer-managed keys are configured at the Recovery Services vault level and apply to all workloads protected by that vault. In this model, a data encryption key (DEK) encrypts the backup data, and the DEK itself is protected by a customer-owned RSA key. Users must grant the Recovery Services vault access to the encryption key before backing up any data. The encryption key can be disabled or access revoked at any time.

It’s important to note that customer-managed keys must be configured when creating a new Recovery Services vault. The vault cannot contain any protected items at the time CMK is enabled. Once configured, the vault cannot be reverted to platform-managed keys.

An optional second layer of encryption, known as infrastructure-level encryption, can also be enabled. This feature provides additional protection at the storage infrastructure layer using platform-managed keys. It is only available if customer-managed keys are used for encryption at rest, enabling dual-layer encryption for backup data.

Encryption Specific to the Workload Being Backed-Up

In addition to vault-level encryption, Azure Backup supports encryption that is specific to the workload being protected.

For virtual machines, backups are supported for disks encrypted with either platform-managed or customer-managed keys. Azure Backup also supports VMs encrypted using Azure Disk Encryption (ADE), which applies in-guest encryption using BitLocker for Windows and DM-Crypt for Linux.

For SQL workloads, backups of Transparent Data Encryption (TDE)-enabled databases are supported. When restoring a TDE-encrypted database to another SQL Server, users must first restore the certificate to the destination server. Backup compression is supported for TDE-enabled databases in SQL Server 2016 and later, although at a reduced transfer size.

3 Ways to Encrypt Your Backups in Azure 

There are three ways to encrypt data in Azure Backup: using Platform-Managed Keys (PMK), using Customer-Managed Keys (CMK) in Azure Recovery Services Vault, or using CMK in Azure Backup Vault.

Using Platform-Managed Keys (PMK)

By default, Azure Backup encrypts all backup data using platform-managed keys (PMKs). These keys are automatically provisioned and managed by Microsoft, requiring no manual configuration from the user. PMKs are used to encrypt data stored in both Recovery Services vaults and Backup vaults, and they offer encryption-at-rest using AES 256-bit algorithms.

This method provides a secure, zero-maintenance encryption option for organizations that do not require advanced control over key lifecycle management. Since key rotation and management are handled by Azure, PMKs reduce administrative overhead while still complying with standard data protection requirements.

Using Customer-Managed Keys (CMK) in Azure Recovery Services Vault

For more control, you can configure Azure Backup to use customer-managed keys (CMKs) in Recovery Services vaults. These keys are stored in Azure Key Vault and allow organizations to manage encryption key lifecycles independently.

To enable CMK-based encryption, the Recovery Services vault must be assigned a system-assigned or user-assigned managed identity. This identity must have permissions to access the Key Vault—either through Azure role-based access control (RBAC) or access policies. The encryption process involves a data encryption key (DEK) secured by a customer-managed RSA key, also known as the key encryption key (KEK).

Once CMK is enabled on a Recovery Services vault, it cannot be switched back to PMK. Backup and restore operations continue to work the same as with PMK-encrypted vaults. However, to ensure restore operations work during regional failovers, key replication and access in both primary and secondary regions must be planned.

Using CMK in Azure Backup Vault

Azure Backup also supports CMK encryption in Backup vaults, offering similar key management control as Recovery Services vaults but with some additional considerations.

The encryption keys must reside in Azure Key Vault or a managed HSM and must be RSA or RSA-HSM keys of sizes 2,048, 3,072, or 4,096 bits. The Backup vault’s managed identity—system-assigned or user-assigned—needs permissions (Get, Wrap, Unwrap) to access these keys.

CMK applies to storage and archive tiers within the Backup vault but does not cover the operational tier. Once enabled, encryption settings can’t be reverted to PMKs. Additionally, Backup vaults encrypted with CMKs can’t be moved across subscriptions or resource groups.

Maintaining access to the Key Vault and the encryption keys is critical. Revoking access or disabling the managed identity will break backup and restore operations. Soft delete should be enabled on the Backup vault to protect backup items from accidental deletion. Purge protection should be enabled on the Azure Key Vault to prevent permanent deletion of the customer-managed key.

Private endpoints and network-restricted Key Vaults are not currently supported when using user-assigned identities with CMK encryption in Backup vaults.

Related content: Read our guide to Azure backup services

Tips from the Expert

Catalin Voicu

Catalin is a seasoned Systems Engineer at N2W with extensive experience spanning cloud technologies and enterprise IT. He bridges the gap between complex infrastructure challenges and practical, customer-focused solutions. With a deep understanding of AWS and the full spectrum of IaaS, PaaS, and SaaS, he brings clarity to the cloud—sometimes with a dash of Romanian trivia to keep things interesting.

Linkedin

• Implement geo-redundant encryption awareness: Even with geo-redundant storage (GRS), understand that encrypted backup data is replicated in its encrypted state. If using CMKs, ensure key availability in both primary and secondary regions. Plan for key replication or coordinated recovery strategies to avoid restore failures during regional disasters.
• Pre-stage key version changes during maintenance windows: Key rotation may seem transparent, but it can delay backup or restore if dependent services haven’t picked up the new version. Stage key updates during planned maintenance windows and test with dummy backups to ensure no downstream impact, especially in high-throughput environments.
• Monitor vault encryption drift via policy scanning: Use custom Azure Policy definitions to flag Recovery Services or Backup vaults that deviate from expected encryption configs (e.g. use of platform-managed keys instead of CMKs). Integrate into your CI/CD pipeline or Azure governance dashboard to prevent config drift.
• Map encryption configurations to regulatory zones: Tag vaults with compliance zones (e.g., “PCI”, “HIPAA”, “Internal”) and ensure that vault encryption (CMKs, infrastructure encryption) aligns with each zone’s regulatory obligations. This approach helps automate audits and is useful in shared environments with mixed compliance levels.
• Use conditional access and just-in-time (JIT) access for key vault admins: Protect these roles using Azure AD Conditional Access policies and JIT access via Privileged Identity Management (PIM). This ensures access is only granted when necessary and tightly controlled.

Key Considerations for Choosing your Azure Encryption Method 

When deciding between platform-managed keys (PMKs) and customer-managed keys (CMKs) for Azure Backup, several factors should guide your choice.

• Control and Compliance Requirements: PMKs offer simplicity, with Azure handling key management automatically. This is suitable for workloads with standard compliance needs. However, if your organization must meet strict regulatory requirements (e.g., HIPAA, PCI), CMKs provide enhanced control over key lifecycle, rotation, and auditing. CMKs also allow mapping encryption configurations to compliance zones, helping enforce consistent data protection standards across environments.
• Operational Complexity: CMKs require setup and ongoing management of Azure Key Vault, including assigning permissions to managed identities and ensuring key availability. Backup and restore jobs depend on uninterrupted access to these keys. Misconfigurations—such as expired keys, revoked permissions, or deleted identities—can cause failures. PMKs eliminate these risks, making them preferable in environments where simplicity and low maintenance are priorities.
• Key Availability and Disaster Recovery: With CMK-enabled backups, especially when using geo-redundant storage, it’s critical to ensure that encryption keys are available in both primary and secondary regions. Failing to replicate keys or plan for cross-region restore scenarios can lead to recovery failures. PMKs, managed by Azure, are resilient to such issues by default.
• Reversibility and Vault Portability: Once a vault is configured to use CMKs, it cannot be reverted to PMKs. Additionally, Backup vaults encrypted with CMKs cannot be moved across subscriptions or resource groups. This imposes constraints on future reorganization or migration plans. PMK-based vaults are more flexible in this regard.
• Tier Coverage and Feature Support: CMKs protect data in storage and archive tiers, but not the operational tier. If operational data must also be protected, this limitation may affect your encryption strategy. Furthermore, CMKs are not supported with certain features, such as private endpoints when using user-assigned managed identities. These nuances must be reviewed before choosing CMKs.
• Security Governance and Access Control: Organizations using CMKs must apply strict governance to Key Vault access. Conditional Access policies and just-in-time access (via Azure PIM) are recommended to protect key administrators. Regular policy scans should be used to detect configuration drift and ensure encryption settings align with organizational standards.

Best Practices for Azure Backup Encryption 

1. Always Enable Soft Delete and Purge Protection

Enabling soft delete and purge protection on your Recovery Services or Backup vaults prevents accidental or malicious deletion of backup data. Soft delete retains deleted backup data for a configurable period, allowing you to recover data if a removal action was not intended. Purge protection further ensures that even privileged users cannot override retention policies to permanently erase data, which is essential for defense against ransomware and insider threats.

Both features work together to provide a robust safety net, particularly in regulated industries where data retention and recoverability are key compliance points. Enforcing these settings across all vaults in your organization’s Azure environment should be a default policy. Regular auditing of these configurations should be included in standard IT governance processes to identify gaps and ensure ongoing protection for all backup data.

2. Rotate and Log Encryption Keys

Regularly rotating encryption keys minimizes the risk from key exposure or compromise. Azure Key Vault supports automatic key rotation, but it is important to verify that the rotation frequency aligns with your organizational policies and regulatory requirements. Rotation procedures should be scheduled and not left to manual execution, as human error can introduce gaps in security coverage. Securely log every key operation, including creation, update, deletion, and access, for audit and incident response purposes.

Maintaining a robust key management and logging process ensures traceability in case of security incidents and supports compliance needs. Logs should be accessible only to authorized personnel and preserved according to your retention policies. Integrate monitoring and alerting on unauthorized or unusual key activities to quickly detect potential attacks or misconduct.

3. Use Separate Vaults for Critical Workloads

Segmenting critical workloads into dedicated Recovery Services or Backup vaults reduces the blast radius of any incident affecting backup data. Isolating backups for high-priority services ensures that an issue—such as accidental deletion, a compromised account, or a misconfigured policy—in one vault does not impact unrelated services. This approach provides an extra layer of defense and simplifies the enforcement of stricter backup and access controls for sensitive workloads.

Separate vaults also allow organizations to enforce unique encryption and retention settings per workload. This makes it easier to meet varying compliance mandates and aligns backup practices with the organization’s internal data classification standards. Regularly review which workloads share vaults, and move critical backups into isolated vaults as necessary to maintain security best practices.

4. Avoid Hard-Coded Secrets in Applications

Embedding secrets such as encryption keys, passwords, or SAS tokens directly into application source code exposes organizations to significant security risk. Attackers commonly scan public repositories and application binaries for such secrets, and any leak can compromise the security of backup data or other resources. Instead, use managed identities or secure application configuration services to fetch secrets at runtime, ensuring they are never stored within codebases.

Azure provides several options, such as Azure Key Vault and managed identities for Azure resources, to handle secret management securely. By abstracting secret access away from code and implementing role-based access controls, you minimize exposure and simplify security management. Enforce policies and conduct code reviews to check for hard-coded secrets before deploying new or updated applications.

5. Enforce Least Privilege Access for Key Management

Applying the principle of least privilege to key management minimizes the number of users and services with access to create, modify, or use encryption keys. Assign only those permissions strictly necessary for backup operations, preventing unauthorized activities and reducing the impact of breached accounts. In Azure, use built-in roles and custom role-based access controls (RBAC) to enforce granular permissions tied to key management activities within Azure Key Vault.

Regular reviews of access policies are crucial to ensuring that outdated or excessive permissions are removed. Automate access reviews where possible and require multi-factor authentication for privileged accounts. Maintaining tight control over key management access reduces the attack surface and is a basic but crucial component of a secure Azure Backup deployment.

Azure Backup Encryption Methods Comparison:

Encrypted Cloud Backup in Azure with N2W

N2W provides policy based backup and disaster-recovery automation for both AWS and Azure customers. N2W operates as a snapshot-based backup layer that sits on top of Azure’s native encryption infrastructure, working alongside whatever disk encryption you’ve already configured.

How N2W Protects Your Azure Backups

Encryption

Azure uses AES-256 to protect backup data via data encryption keys (DEKs), which are in turn protected by key encryption keys (KEKs) stored in Azure Key Vault. N2W supports both platform-managed keys (PMKs), which require no configuration and are on by default, and customer-managed keys (CMKs), where your RSA keys stored in Azure Key Vault control encryption end-to-end.

When N2W snapshots a CMK-encrypted disk, the snapshot automatically inherits the disk’s encryption without any extra steps needed. The backup data remains protected under your Azure Key Vault key throughout. If needed, N2W also lets you apply a different Disk Encryption Set (DES) at recovery time, giving you flexibility to change which key protects the restored data.

Immutability

Beyond encryption, N2W adds an additional protection layer in the form of immutable backups, using the highest standard of protection to guard backups from tampering or deletion. When a policy is enabled for Immutable Backups, a “Delete” lock type is assigned for a specific retention period, preventing any modifications or deletions during that window. For Storage Account Repositories, N2WS places a Lease on every stored object — a leased object cannot be deleted or modified until the Lease is explicitly cancelled, adding a further safeguard against accidental or malicious removal.

Access Control

Beyond protecting the data itself, N2W integrates with Azure’s role-based access control system to enforce secure access policies aligned with compliance standards. As part of the platform setup, organizations configure a custom IAM role in Azure, giving administrators precise control over who can interact with backup resources and ensuring access privileges follow the principle of least privilege.

Learn more about N2W for Azure Backup and Recovery