Compliance

Encrypt Azure data at rest, including customer-managed keys

One capability across SQL databases, Storage accounts and virtual machine disks: make sure every store of data is encrypted at rest, that nothing travels unencrypted between Compute and Storage, and that the regulated workloads which need to hold their own key actually do.

14 min·10 sections·AZURE

Last reviewed 18 June 2026

Remediates Microsoft Defender for Cloud: azure-cosmos-cmk-encryption azure-linux-vm-disk-encryption-or-host azure-local-encrypted-volumes azure-machine-learning-cmk-encryption azure-sql-tde-enabled azure-storage-cmk azure-vm-disk-encryption azure-vm-encryption-at-host-enabled azure-windows-vm-disk-encryption-or-host

Encryption at rest: the basics

What does an unencrypted, or under-encrypted, Azure workload actually look like?

Encryption at rest in Azure is not one switch, and the gaps show up in distinct shapes rather than a single setting. Transparent Data Encryption can be off on a SQL database so the files and backups on disk are stored in the clear. A virtual machine can run without host-based encryption, so its temporary disk, its OS and data disk caches, and the data flowing between Compute and Storage are not all encrypted. A storage account can rely on the platform key when a regulated workload is required to hold its own customer-managed key. Each is its own Defender for Cloud recommendation, but the underlying question is the same: is this data encrypted at rest to the standard this workload actually needs?

Microsoft Defender for Cloud turns each of these into its own recommendation under the Microsoft Cloud Security Benchmark data-protection controls, which is why one data-heavy subscription can fail several encryption checks at once. 'Transparent Data Encryption on SQL databases should be enabled', 'Virtual machines should encrypt temp disks, caches, and data flows between Compute and Storage resources', and the 'enable if required' customer-managed-key recommendation on storage accounts read as separate problems on the report, but they are one job: make sure every store of data is encrypted at rest, and that the workloads which need a key you control are using one.

Most of this is nuance rather than negligence. Azure encrypts a great deal at rest by default: Storage accounts are always encrypted with 256-bit AES, and TDE is enabled by default on new SQL databases. So the gaps tend to be the edges: an older SQL database created before TDE was a default, a virtual machine that never had encryption at host turned on, or a regulated workload that needs to move from the platform key to a customer-managed key for separation of duties. The work is to find each of those edges, understand which are genuine requirements rather than defaults, and close them.

In this lesson you will learn how Azure expresses encryption at rest across SQL databases, virtual machine disks and storage accounts, how to find every workload that is under-encrypted for what it holds, and how to close the gaps without taking a regulated workload through an unnecessary key migration. The Controls this lesson covers section lists every Defender for Cloud recommendation in this capability, each linking to a deep page with the exact check and a copy-and-paste fix.

Fun fact

The encryption that was on the whole time

A surprising amount of Azure data is already encrypted at rest the moment you create the resource. Every Azure Storage account is encrypted with 256-bit AES that cannot be turned off, and Transparent Data Encryption has been enabled by default on new Azure SQL databases since 2017. So the irony of this capability is that the failures are usually not 'we forgot to encrypt' but 'we never turned it on for this one older resource' or 'this regulated workload needs a key we control and is still using the platform key'. The default does most of the work; the lesson is about the edges the default does not reach.

Finding under-encrypted workloads across a subscription

Priya is the security lead at a fintech preparing for a SOC 2 Type II audit. Defender for Cloud shows data-protection findings spread across SQL databases and virtual machines in two subscriptions that pre-date the team's current platform standards.

Rather than work the findings one by one, Priya starts by listing which SQL databases still have Transparent Data Encryption switched off, so the genuinely regulated stores can be separated from disposable development databases before anything changes.

Start by finding the SQL databases where Transparent Data Encryption is not enabled. These are the clearest at-rest gaps.

$ az sql db tde show --resource-group rg-data --server sql-fintech-prod --database payments --query status -o tsv

Disabled

# The payments database is storing files and backups in the clear.

# TDE is free to enable and is the highest-value fix in this group.

A regulated database with TDE disabled is the highest-value target in this capability. Enable it first, at zero Azure cost.

How Defender for Cloud decides a workload is under-encrypteddeep dive

Each recommendation resolves to a specific property. For SQL, Defender checks the Transparent Data Encryption state on the database: when it is Disabled, the data files, log files and backups are written to disk in the clear, so a stolen backup or disk image is readable. TDE is on by default for new databases, so a finding here almost always means an older database, a restored copy, or one created by a script that disabled it. By default TDE uses a service-managed key; a separate, stronger requirement is to protect the TDE key itself with a customer-managed key in Key Vault for separation of duties.

For virtual machines, the recommendation looks for encryption at host. Azure already encrypts managed OS and data disks at rest with platform-managed keys, but the temporary disk, the OS and data disk caches, and the data flowing between the VM host and Storage are only fully encrypted when encryption at host is enabled. The property is 'securityProfile.encryptionAtHost' on the virtual machine; the feature must first be registered on the subscription as 'Microsoft.Compute/EncryptionAtHost', and the machine must be deallocated to apply it. Encryption at host is the modern replacement for the older guest-based Azure Disk Encryption, which Microsoft is retiring.

For storage accounts, every account is already encrypted at rest with 256-bit AES that cannot be disabled, so the customer-managed-key recommendation is explicitly an 'enable if required' control: it is only a real gap for workloads that are obligated, by contract or regulation, to hold their own key. Configuring it points the account at a key in Azure Key Vault or Managed HSM, and the account's managed identity must be granted the 'Key Vault Crypto Service Encryption User' role so Storage can wrap and unwrap the account encryption key. Defender for Cloud evaluates all of these on a periodic cycle, so a fix does not flip the recommendation to Healthy instantly; the change is immediate but the posture catches up on the next assessment.

What is the impact of leaving data under-encrypted?

The direct impact is readable data outside the running system. A SQL database with TDE off writes its files and backups to disk in the clear, so a copied backup, an exported BACPAC, or a stolen disk image discloses the data without any need to break into the live database. A virtual machine without encryption at host leaves its temporary disk and disk caches unencrypted on the host, and data moving between Compute and Storage is not fully protected in transit at the infrastructure layer. None of this requires a sophisticated attacker; it requires only access to a copy of the storage, which is exactly what backup theft, snapshot sprawl and decommissioning mistakes produce.

The second-order impact is the gap between what you promised and what you can prove. Most data-protection commitments, in contracts, in SOC 2, in ISO 27001 and in the UK and EU data-protection regimes, are stated as 'data is encrypted at rest'. If a single regulated database has TDE off, or a regulated workload that was contractually required to use a customer-managed key is still on the platform key, the promise is broken even though almost everything else is encrypted. That single exception is what an auditor or a breach investigation finds.

On the compliance side, encryption at rest is one of the first controls every framework checks, precisely because it is concrete and verifiable. A passing set of encryption recommendations across every subscription, with the regulated workloads demonstrably on customer-managed keys, is one of the cheapest and most defensible artefacts you can hand an auditor or a security-conscious customer.

How do you close the encryption gaps safely?

Work the capability as one loop rather than chasing individual findings. The order matters: separate the free, universal fixes from the customer-managed-key exceptions before you start, so you do not put a workload through an unnecessary and chargeable key migration.

1. Inventory every workload by encryption gap

List the SQL databases with Transparent Data Encryption off, the virtual machines without encryption at host, and the storage accounts whose workloads have a genuine customer-managed-key requirement. Treat this inventory as the source of truth rather than the Defender finding count, because the three checks span different services and one workload can fail more than one.

2. Separate the free defaults from the customer-managed-key requirements

Enabling TDE and turning on encryption at host are free and should be applied broadly. Adopting a customer-managed key is only required where a contract or regulation demands that you hold your own key. Decide that distinction per workload first, because the customer-managed key is the only part of this capability that carries a recurring Key Vault cost and operational responsibility for key rotation.

3. Close the free gaps, highest sensitivity first

Enable TDE on the SQL databases, prioritising those that hold regulated data, then enable encryption at host on the virtual machines, which requires registering the feature and deallocating each machine in a maintenance window. Each change is immediate at the control plane and adds nothing to the bill.

4. Add customer-managed keys and ratchet it shut with Azure Policy

For the workloads that require it, create a Key Vault with soft delete and purge protection, grant the resource's managed identity the Key Vault Crypto Service Encryption User role, and point the resource at the key. Then assign Azure Policy to audit or deny SQL servers without TDE and to enforce the customer-managed-key requirement on the relevant workloads, so the safe configuration is enforced rather than merely encouraged.

# 1. Free, universal fix: enable Transparent Data Encryption on a SQL database.
az sql db tde set \
  --resource-group rg-data \
  --server sql-fintech-prod \
  --database payments \
  --status Enabled

# 2. Free, universal fix: encrypt VM temp disks, caches and data flows.
az feature register --namespace Microsoft.Compute --name EncryptionAtHost
az vm deallocate --resource-group rg-app --name vm-tooling-01
az vm update --resource-group rg-app --name vm-tooling-01 \
  --set securityProfile.encryptionAtHost=true
az vm start --resource-group rg-app --name vm-tooling-01

# 3. Only where required: customer-managed key on a storage account.
az storage account update \
  --name stbankingprod \
  --resource-group rg-data \
  --encryption-key-source Microsoft.Keyvault \
  --encryption-key-vault "https://kv-banking-cmk.vault.azure.net" \
  --encryption-key-name sa-cmk

echo "TDE on, host encryption on, CMK applied to the one regulated store."

Quick quiz

Question 1 of 5

Defender for Cloud shows findings for TDE on SQL databases, encryption at host on virtual machines and a customer-managed-key recommendation on storage. What is the most efficient way to think about them?

Keep learning

Go deeper on how Azure expresses encryption at rest across the services in this capability.

You can now treat encryption at rest as one capability rather than a scatter of findings: inventory the SQL databases, virtual machines and storage accounts that are under-encrypted for what they hold, apply the free fixes (TDE and encryption at host) broadly, reserve customer-managed keys for the workloads that genuinely require them, and ratchet the estate shut with Azure Policy. The Controls this lesson covers section below links every recommendation in this group to its deep page and fix.

Back to the library

Encryption at rest: the cost and risk view

A low-cost capability that closes a data-protection gap auditors and regulators look for first

Encryption at rest is one of the cheaper controls in the security report, because Azure already does most of it for free. Enabling Transparent Data Encryption on a SQL database costs nothing in Azure spend. Turning on encryption at host for a virtual machine is also free; the only cost is the engineering time to deallocate and restart the machine. The real, bounded cost sits in the customer-managed-key exceptions: a regulated workload that adopts a customer-managed key needs an Azure Key Vault or Managed HSM to hold it, which carries a small recurring charge plus a per-operation cost for key wrap and unwrap.

Frame each failing recommendation by the data behind it, not as a compliance checkbox. A SQL database holding regulated customer records with TDE off carries a very different expected loss from an empty development database, yet both surface as a single red finding. Map the failures to the sensitivity of the data and decide which workloads genuinely require a customer-managed key, because that is the only part of this capability that moves the bill.

The arithmetic is one-sided. The remediation is mostly free, plus a small, bounded Key Vault charge for the workloads that need their own key. The downside of leaving data under-encrypted is the documented cost of failing a data-protection requirement at audit, or of a stolen disk or backup being readable: regulatory findings, breach notification, forensics and the loss of a contract that required encryption at rest in the first place.

This lesson is for the finance partner who sees a cluster of encryption findings on the security report and wants to know what the right response is and what it actually costs. It covers why most of these controls are free to fix, which exceptions carry a real Key Vault cost, and how to turn a list of red findings into a plan ordered by the sensitivity of the data behind each one.

Fun fact

The encryption that was on the whole time

How a finance partner frames the encryption decision

Priya is the finance partner supporting the platform team's SOC 2 push. The security report lands with nine data-protection findings spread across SQL databases and virtual machines in two older subscriptions. The instinct is not to wave through a blanket remediation budget; it is to ask what is actually behind each red finding and which parts cost anything. Enabling Transparent Data Encryption on a database, and turning on encryption at host for a virtual machine, both cost nothing in Azure spend, so the spend question is narrow: only the regulated workloads that are required to adopt a customer-managed key add a Key Vault charge, and that charge is small and bounded.

Priya asks the team to map each failing resource to the data sitting behind it. Two SQL databases hold regulated payment records with TDE off, three virtual machines without host encryption run internal tooling, and the contract with one banking customer requires that their data be encrypted under a key the company controls rather than the platform key. The list is reframed by sensitivity: the two payment databases are free TDE flips to do today, the three virtual machines are free host-encryption changes that need a maintenance window, and the one banking workload is a discrete, budgeted line for a Key Vault plus customer-managed key. The finance pack reads: 'Eight findings close at no incremental spend; one contractually required workload needs a small, bounded Key Vault for a customer-managed key; the rest is engineering time, not budget.'

Why encryption at rest belongs on the risk register

The cost model here is unusually favourable. The great majority of encryption findings cost nothing in Azure spend to fix, because Azure already does the encryption; enabling TDE or host encryption is a configuration change, not a new charge. The only spend is the Key Vault that holds a customer-managed key for the workloads that genuinely require one, and that is a small recurring cost plus a modest per-operation charge for key wrap and unwrap, both of which are easy to forecast.

Against that small, bounded cost sits the documented downside of failing a stated encryption commitment: a SOC 2 or ISO 27001 finding that delays or loses a deal, a contractual breach with a customer who required encryption at rest, or a regulatory notification and forensics bill if an unencrypted backup is exposed. The finance role is to attach the data sensitivity and the contractual obligation to each failing resource, so the work is prioritised by what is actually at risk rather than by the order the report lists it, and so the one genuinely chargeable item, the customer-managed key, is budgeted as a clear line.

What finance can do about the encryption gap

Finance cannot flip a TDE switch, but it owns the framing that turns a scatter of red findings into a plan with almost no incremental Azure spend and a clearly bounded set of customer-managed-key exceptions. Three levers.

1. Separate the free fixes from the chargeable customer-managed keys

Make explicit that the overwhelming majority of encryption findings cost nothing in Azure spend: enabling Transparent Data Encryption and turning on encryption at host are configuration changes, not new charges. The only recurring cost is the Key Vault, or Managed HSM, that holds a customer-managed key for the workloads contractually or legally required to use one, plus a small per-operation charge for key wrap and unwrap. Budget those as discrete lines and treat everything else as engineering time, so nobody can claim the whole capability is a spending decision.

2. Order the work by data sensitivity, not by finding count

A SQL database holding regulated payment records with TDE off and an empty development database both show up as a single red finding, but the consequence of leaving each open differs enormously. Ask the team to map each failing resource to the data behind it and the commitments attached to that data, then prioritise the regulated stores first. The metric that belongs on the cost-and-security review is the count of encryption findings weighted by data sensitivity and contractual obligation, not the raw total.

3. Tie every customer-managed key to a named requirement

A customer-managed key carries a recurring cost and an ongoing operational responsibility for key rotation and availability, so it should never be adopted by default. Require that each customer-managed key maps to a specific, recorded contract clause or regulatory obligation. The distinction between 'this customer's contract requires a key we control' and 'we turned it on everywhere just in case' is what keeps the Key Vault bill proportionate and the posture defensible at audit.

Quick quiz

Question 1 of 5

A security report shows nine encryption findings across SQL databases and virtual machines. As the finance partner, what is the right starting assumption about their Azure-spend cost to remediate?

Keep learning

Go deeper on how Azure expresses encryption at rest across the services in this capability.

You have finished the finance view of encryption at rest. You know the cost model is one-sided: enabling TDE and encryption at host is free in Azure spend, only the contractually required customer-managed keys carry a small, bounded Key Vault cost, and the downside of leaving a gap is a failed audit, a breached contract or a regulatory notification. Next time a cluster of encryption findings lands, you will order them by data sensitivity, ring-fence the customer-managed-key workloads against named requirements, and budget only the part that actually moves the bill.

Back to the library

Encryption at rest: the headline

Whether every store of data in the estate is encrypted to the standard the business has committed to

Encryption at rest is the control that customers, auditors and regulators ask about first, because it is the simplest promise to make and the easiest to break by omission. A database with encryption off, or a virtual machine whose temporary disk and caches are not encrypted, is a commitment you have made on paper that the estate is not keeping in practice.

The leadership question is not 'do we encrypt?' Azure encrypts most things by default. It is 'is every store of regulated data encrypted to the standard we promised, including the workloads that are contractually required to hold their own key?' The defensible end state is that TDE is on everywhere, virtual machines encrypt their temporary disks and caches by default, and the workloads that need a customer-managed key are using one, enforced by policy rather than by memory.

This is rarely a cost decision. The default encryption is free and host-based encryption is free; only the customer-managed-key exceptions carry a small, bounded charge. It is a governance decision about whether the encryption promise is kept by design or only by everyone remembering to turn it on.

A short read for the leader who needs to know what an unencrypted database or virtual machine reveals about the estate, why closing the gap is a governance decision rather than a budget one, and what a defensible encryption posture looks like when an auditor or a regulated customer asks.

Fun fact

The encryption that was on the whole time

What it looks like when encryption is kept by design, not by memory

During contract renewal, a large enterprise customer's security team asked the fintech to attest that all of their data was encrypted at rest, including under a key the fintech itself controlled. The honest answer at the time was uncomfortable: most data was encrypted because Azure does it by default, but nobody could prove that every database had Transparent Data Encryption on, that every virtual machine encrypted its temporary disks and caches, or that the customer's specific workload used a customer-managed key.

The team's response was to stop treating encryption as a per-resource detail and start treating it as a posture. They listed every SQL database with TDE off and every virtual machine without host encryption, enabled both across the estate at no Azure cost, moved the one contractually-bound workload onto a customer-managed key in a dedicated Key Vault, and then assigned Azure Policy to audit for TDE and deny the creation of any SQL server without it. The next time a customer asked, the answer had changed from 'we believe so' to 'yes, here is the policy that enforces it and the evidence that it passes.' That shift, from relying on the default and people's memory to making encryption a stated, enforced posture, is the confidence signal this capability delivers, and almost all of it costs nothing in Azure spend to reach.

Why this is a board-level risk

Encryption at rest is the promise the business has almost certainly already made, to customers, to auditors and to regulators. The risk is not that the estate is wholly unencrypted; Azure prevents that by default. The risk is the single exception: the one regulated database with encryption off, or the one contractually-bound workload still on the platform key, that turns a confident attestation into a finding or a breach disclosure.

The cost of closing the gap is essentially engineering time plus a small, bounded charge for the customer-managed keys that specific workloads require. The cost of the gap being found is a lost contract, a failed audit or a regulatory notification. This is the rare class of control where the risk of inaction is reputational and contractual while the cost of action is small, which is exactly the trade leadership should be quickest to approve.

The leadership move on encryption at rest

The executive handle is not to approve each fix individually; it is to require that encryption at rest is a stated, enforced posture and that the workloads which must hold their own key demonstrably do, on the record.

1. Set a deadline to reach an enforced end state

Ask for a date by which the estate is inventoried, TDE is on across every SQL database, encryption at host is on across the virtual machines, the contractually-bound workloads are on customer-managed keys, and Azure Policy audits or denies SQL servers without TDE. A backstop that no individual resource can quietly override is the difference between believing the estate is encrypted and being able to prove it.

2. Ask for proof, not assurance

The proof that this is closed is not a verbal 'Azure encrypts everything anyway.' It is a passing set of encryption recommendations across every subscription, plus evidence that the policies are assigned and that the named regulated workloads are on customer-managed keys. Because Defender for Cloud assesses on a periodic cycle, ask for that evidence with lead time before any audit or customer review rather than the morning of.

3. Treat customer-managed keys as named, owned commitments

Holding your own key is a commitment, not a default: it carries operational responsibility for rotation and availability, and a lost or unavailable key can make data inaccessible. The leadership requirement is that each customer-managed key maps to a specific contract or regulation, has an owner, and sits in a Key Vault with purge protection. The goal is not a customer-managed key on everything; it is one on exactly the workloads that need it.

Quick quiz

Question 1 of 5

A regulated customer asks you to attest that all their data is encrypted at rest, including under a key you control. What end state should you be looking for as the defensible answer?

Keep learning

Go deeper on how Azure expresses encryption at rest across the services in this capability.

Two takeaways. Encryption at rest is the rare control where the risk of inaction is contractual and reputational while the cost of action is essentially engineering time, so it is the trade you should be quickest to approve. And the defensible end state is not 'Azure encrypts everything anyway'; it is TDE and host encryption enforced by Azure Policy, with the workloads that must hold their own key demonstrably on customer-managed keys, so the encryption promise is kept by design rather than by memory.

Back to the library

Controls this lesson covers

One capability, many Microsoft Defender for Cloud recommendations. This lesson is the shared playbook; each control below keeps its own deep page with the exact check, severity and a copy-and-paste fix.

Encrypt Azure data at rest, including customer-managed keys

Encryption at rest: the basics

The encryption that was on the whole time

Finding under-encrypted workloads across a subscription

How Defender for Cloud decides a workload is under-encrypteddeep dive

What is the impact of leaving data under-encrypted?

How do you close the encryption gaps safely?

1. Inventory every workload by encryption gap

2. Separate the free defaults from the customer-managed-key requirements

3. Close the free gaps, highest sensitivity first

4. Add customer-managed keys and ratchet it shut with Azure Policy

Quick quiz

Keep learning

Encryption at rest: the cost and risk view

The encryption that was on the whole time

How a finance partner frames the encryption decision

Why encryption at rest belongs on the risk register

What finance can do about the encryption gap

1. Separate the free fixes from the chargeable customer-managed keys

2. Order the work by data sensitivity, not by finding count

3. Tie every customer-managed key to a named requirement

Quick quiz

Keep learning

Encryption at rest: the headline

The encryption that was on the whole time

What it looks like when encryption is kept by design, not by memory

Why this is a board-level risk

The leadership move on encryption at rest

1. Set a deadline to reach an enforced end state

2. Ask for proof, not assurance

3. Treat customer-managed keys as named, owned commitments

Quick quiz

Keep learning

Controls this lesson covers

Azure Cosmos DB

Azure Local

Azure Machine Learning

Compute

SQL

Storage

Virtual Machines

Related compliance lessons