Encryption in Azure

Encryption at rest

When data is written to disk in an Azure storage service, Azure encrypts it before it is persisted. This applies to Azure Blob Storage, Azure Files, Azure Queue Storage, Azure Table Storage, Azure SQL Database, Azure Cosmos DB, Azure Disk Storage, and every other managed storage service. The encryption happens transparently at the storage layer — your application reads and writes data as if it were unencrypted, and the service handles the encryption and decryption.

The algorithm used for data at rest is AES-256, which is the same standard used by most modern full-disk encryption tools and is approved for classified government data in many jurisdictions. The encryption is applied to the underlying storage blocks, which means even if someone physically removed the storage media from an Azure data centre, the data would be unreadable without the encryption keys.

This default encryption uses platform-managed keys: Microsoft generates, stores, rotates, and manages the keys in its own key infrastructure. You benefit from encryption without any configuration or ongoing maintenance.

Encryption in transit

Data in transit means data moving between your application and an Azure service endpoint, between Azure services in the same region, or between Azure regions. Azure uses Transport Layer Security (TLS) to protect this traffic.

For managed services — App Service, Azure SQL, Cosmos DB, Storage accounts, Azure Cache for Redis — the service endpoint enforces TLS. Connections over plain HTTP are either redirected to HTTPS or rejected, depending on the service and your configuration. You can configure a minimum TLS version (1.2 is the current recommended minimum) on most services to prevent clients from negotiating down to older, weaker versions.

For virtual machines running your own software (a self-hosted web server, a database on a VM, an API gateway you manage), you are responsible for configuring TLS. Azure provides the infrastructure but does not automatically place a TLS certificate in front of your application. In practice, most teams place an Azure Application Gateway or Azure Front Door in front of VM-based workloads and handle TLS termination there, using certificates managed through Azure Key Vault.

Key management options

Azure gives you three levels of control over encryption keys, each with different trade-offs between convenience and control.

Platform-managed keys (PMK)

Microsoft manages the keys. They are stored in Microsoft’s key management infrastructure, rotated automatically, and you have no visibility into or control over them. This is the default for every Azure storage service and requires no action from you. It satisfies most security requirements and is appropriate for the vast majority of workloads.

Customer-managed keys (CMK)

You provide your own encryption keys, stored in Azure Key Vault. Azure services use these keys to encrypt your data, but the keys themselves live under your control. You can rotate them on your schedule, restrict access to the Key Vault, and audit every use of the keys. The trade-off is operational responsibility: if your Key Vault becomes inaccessible (deleted, misconfigured access policies, expired credentials), the encrypted data becomes inaccessible too. See Customer Managed Keys for the full detail on this option.

Customer-provided keys (CPK)

For Azure Blob Storage specifically, you can supply an encryption key on each individual API request. Azure uses the key to encrypt or decrypt that request’s data and then discards it — the key is never stored in Azure. This gives maximum control but means your application must manage and supply the key for every read and write. It is rarely used outside of highly specialised compliance scenarios.

What is automatic vs what requires configuration

The following table shows the encryption defaults for the most common Azure services and what additional steps you would take for stricter compliance requirements.

Double encryption

Double encryption, also called infrastructure encryption, adds a second layer of AES-256 encryption at the infrastructure level beneath the service-level encryption. The data is encrypted twice with two independent encryption implementations and two sets of keys. This is available for Azure Storage accounts and Azure Managed Disks.

Double encryption exists to satisfy specific compliance requirements that mandate multiple independent encryption layers, or to provide protection in the theoretically unlikely scenario that one encryption implementation is compromised. For most organisations, single-layer AES-256 encryption is more than sufficient. Enable double encryption when a specific compliance framework or your security team’s policy requires it — not as a general default.

You enable it at account or disk creation time:

# Create a storage account with infrastructure encryption (double encryption)
az storage account create \
  --name mystorageaccount \
  --resource-group my-rg \
  --location eastus \
  --sku Standard_LRS \
  --require-infrastructure-encryption true

Azure Disk Encryption for virtual machines

Virtual machine disks in Azure are encrypted at rest by default at the storage layer (Server-Side Encryption). Azure Disk Encryption (ADE) adds a second, different layer: it uses BitLocker on Windows VMs and dm-crypt on Linux VMs to encrypt the disk at the operating system level. This means the disk is encrypted before data even reaches the storage layer.

ADE is typically required for compliance frameworks that specify the disk must be encrypted at the volume level (as opposed to storage-layer encryption), or when you are moving disk images between environments and want to ensure the disk is protected regardless of what storage it lands on. ADE uses keys stored in Key Vault.

# Enable Azure Disk Encryption on a Windows VM
az vm encryption enable \
  --resource-group my-rg \
  --name my-windows-vm \
  --disk-encryption-keyvault my-vault \
  --volume-type All

Encryption and compliance

For most compliance frameworks, default Azure encryption satisfies the encryption-at-rest and encryption-in-transit requirements. PCI DSS requires AES-128 or stronger at rest (Azure’s AES-256 qualifies) and TLS 1.2 or stronger in transit (configurable on all Azure services). HIPAA requires encryption of Protected Health Information at rest and in transit (Azure’s defaults qualify). ISO 27001 requires appropriate encryption without mandating a specific algorithm.

Where frameworks differ is on key management. Some frameworks require you to maintain control of your own encryption keys — this is when customer-managed keys become a compliance requirement rather than an optional enhancement. Before implementing CMKs purely for compliance reasons, confirm that your specific framework actually requires customer control of keys, because PMK often satisfies the technical requirement with far less operational complexity.