Top 5 Encryption Best Practices for Azure Backups

Backup data contains a copy of everything your production systems hold: customer data, financial records, personal information, credentials. A backup that is less securely encrypted than the production system it protects is a weaker point in your security posture. For regulated businesses, an unencrypted or inadequately encrypted backup is a compliance finding under UK GDPR, PCI DSS, FCA requirements, and ISO 27001.

These five practices cover the controls that matter.

1. Verify encryption at rest is active and understand what it covers

Azure Backup encrypts backup data at rest by default using Microsoft-managed keys (MMK) and AES-256 encryption. This applies to all Recovery Services vaults without any configuration required. Before making more complex decisions, confirm that the default encryption is active on all your vaults.

Navigate to Recovery Services vault > Properties > Backup Encryption. Confirm the encryption type shows as "Platform Managed Keys" (the default) or "Customer Managed Keys" (if you have configured CMK). If the status is not showing as encrypted, investigate immediately.

The default MMK encryption covers data stored in the vault. It does not extend to: - Data in transit between the protected resource and the vault (covered by TLS in transit, separately) - The source VM or data source itself (covered by disk encryption on the protected resource, separately) - Snapshots stored outside the vault (instant recovery snapshots stored on the disk temporarily before transfer)

Understanding the scope of each encryption layer matters for compliance evidence: the backup encryption covers the data at rest in the vault; disk encryption covers the source; TLS covers transit. You need all three documented.

2. Use Customer Managed Keys for regulated workloads

Microsoft-managed keys (the default) are rotated automatically by Microsoft. For most workloads, this is appropriate and simpler to manage.

Customer Managed Keys (CMK) give you control over the encryption key lifecycle: you generate the key, you store it in Azure Key Vault, and you control rotation and revocation. If a regulator or auditor asks "who controls the key that encrypts your backup data?", CMK allows you to answer "we do."

CMK is relevant for workloads under PCI DSS (which requires the business to control cryptographic keys), HIPAA (similar requirements for PHI), and certain FCA interpretations of operational resilience requirements. It is also relevant if your organisation's security policy mandates customer-controlled keys.

To enable CMK on a Recovery Services vault: 1. Create an encryption key in Azure Key Vault (RSA 2048 or RSA 3072 recommended for CMK use) 2. Assign the vault's managed identity the Key Vault Crypto Officer role 3. In the Recovery Services vault Properties > Backup Encryption, select "Customer Managed Key" and select the Key Vault and key

Once CMK is configured, the vault's data encryption keys (DEKs) are wrapped using your customer key. Revoking or deleting the customer key renders the backup data inaccessible. For this reason, key management under CMK must be treated with the same rigour as the backup data itself.

3. Enable encryption for transport: verify TLS is enforced end to end

Data in transit between the protected source and the Recovery Services vault travels over TLS. For Azure VMs backed up to a vault in the same region, this traffic stays within the Microsoft network. For on-premise backups via the MARS agent, data traverses the internet over TLS.

Enforce TLS 1.2 as the minimum version: - For Recovery Services vaults, the vault endpoint enforces TLS 1.2 by default on all connections - For the MARS agent (used for on-premise Windows Server backups), ensure the agent is at version 2.0.9083.0 or later, which enforces TLS 1.2 - For Azure Backup Server (MABS), ensure the server's TLS configuration enforces TLS 1.2 on outbound connections to the vault

For network security groups or proxy configurations in front of backup traffic, verify that TLS inspection is not breaking the backup agent's certificate validation. TLS interception by a proxy requires the inspection certificate to be trusted by the backup agent.

4. Encrypt instant recovery snapshots with disk encryption

Instant recovery (used for quick restore operations on Azure VMs) stores a snapshot of the protected disk in the resource group before transferring data to the vault. These snapshots are stored temporarily in the subscription and are not covered by the vault's encryption: they use the source disk's encryption.

If your Azure VMs use Azure Disk Encryption (ADE) with BitLocker (Windows) or dm-crypt (Linux), the snapshots inherit that encryption. If your VMs use Platform Managed Disk encryption (server-side encryption), the snapshots are also encrypted at rest.

Confirm that every VM included in backup has disk encryption enabled. Navigate to the VM > Disks > Check the Encryption column. Platform-managed encryption is the minimum; ADE provides additional protection with keys under your control.

For VMs discovered via Azure Backup that do not have disk encryption enabled, flag them for remediation. An unencrypted source disk means an unencrypted instant recovery snapshot, even if vault encryption is active.

5. Use immutable vaults and soft delete together

Encryption protects data from being read without the key. Immutability and soft delete protect backup data from being deleted or modified by an attacker who has compromised credentials.

Soft delete on a Recovery Services vault retains deleted backup data for 14 days in a soft-deleted state before permanent deletion. An attacker who obtains Backup Contributor permissions and deletes backup items cannot immediately eliminate the recovery capability: the data persists for 14 days and can be restored. Enable soft delete on all vaults; it is free.

Immutable vaults (available on Recovery Services vaults) prevent modification of the vault's backup policy for a configurable period. Once locked, the backup retention settings cannot be reduced, ensuring that an attacker who gains access cannot shorten the retention window to limit recovery options. Lock the immutability setting to prevent it from being disabled; an unlocked immutable vault can be made mutable again by a sufficiently privileged account.

Together: encryption protects the content of backup data; immutability and soft delete protect the existence of backup data. A complete backup security posture needs both.

Where Critical Cloud comes in

Backup encryption and the evidence that it is correctly configured are what regulators ask for when they conduct operational resilience assessments. We configure and operate Azure Backup for regulated businesses with encryption, immutability, soft delete, and RBAC controls in place from the start, and produce the documentation trail that satisfies FCA, PCI DSS, and ISO 27001 audit requirements. See how Critical Support works.