Compliance

Harden Azure SQL encryption

One capability across Azure SQL Database and SQL Managed Instance: make sure the key that protects your data at rest is one you own and control, not just the platform default, wherever a regulated workload demands it.

14 min·10 sections·AZURE

Last reviewed 18 June 2026

Remediates Microsoft Defender for Cloud: azure-sql-mi-cmk-tde azure-sql-server-cmk-tde

Hardening SQL encryption: the basics

What does customer-managed key encryption actually change?

Every Azure SQL database is already encrypted at rest. Transparent data encryption, TDE, is on by default, and out of the box the key that protects the database, the TDE protector, is a service-managed key that Microsoft creates, stores and rotates for you. That is fine for a lot of workloads. The recommendations in this capability are about the next step up: replacing that platform key with a customer-managed key, a key you create in your own Azure Key Vault and control. This is the bring-your-own-key, or BYOK, model, and it gives you the power to revoke access to your own data by disabling the key, plus an audit trail of every time the key is used.

Microsoft Defender for Cloud raises this as two separate recommendations because Azure SQL comes in two deployment shapes that are configured differently. 'SQL servers should use customer-managed keys to encrypt data at rest' targets the logical server behind Azure SQL Database, where the protector is set on the server with 'az sql server tde-key'. 'SQL managed instances should use customer-managed keys to encrypt data at rest' targets Azure SQL Managed Instance, where the same job is done on the instance with 'az sql mi tde-key'. They read as two findings, but they are one capability: own the key that protects your data at rest.

The work is not to flip a switch on every database in the estate. Service-managed TDE is a perfectly acceptable default for most workloads, and moving to a customer-managed key adds operational responsibility: a Key Vault to keep available, a key to keep enabled, and permissions to keep granted. The job is to identify the databases and instances that a regulatory or contractual requirement says must use a customer-managed key, move those onto one cleanly, and then make sure new servers in those scopes adopt the key by default rather than slipping back to the platform key.

In this lesson you will learn the difference between service-managed and customer-managed TDE, why Azure SQL Database and SQL Managed Instance surface as two separate recommendations even though they are one capability, how to move a regulated workload onto a customer-managed key without losing access to its own data, and how to keep new servers in scope from drifting back to the platform key. 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 key you can take back

The quiet superpower of a customer-managed key is not stronger encryption: the platform key and your key use the same algorithm and are equally hard to break. It is revocability. Because the TDE protector lives in your own Key Vault, disabling or removing access to that one key makes every database it protects unreadable within minutes, without touching the databases themselves. That is why Azure forces you to enable soft-delete and purge protection on the vault before it will let you use a key for TDE: the same property that lets you revoke access on purpose would, if the key were ever deleted by accident, lock you out of your own data permanently.

Finding which SQL resources hold their own key

Priya is the security lead at a fintech preparing for a SOC 2 Type II audit. Defender for Cloud flags several Azure SQL logical servers and one managed instance as not using customer-managed keys, and her data-protection obligations say the customer-record databases must hold their own key.

Rather than assume every server needs changing, she starts by listing which servers are still on the service-managed key, so she can separate the regulated databases that genuinely need a customer-managed key from the ones where the platform key is a perfectly acceptable and documented choice.

List each logical server's TDE protector type. 'ServiceManaged' means the platform holds the key; 'AzureKeyVault' means you do.

$ for s in $(az sql server list --query "[].name" -o tsv); do echo -n "$s: "; az sql server tde-key show --server "$s" --resource-group prod-rg --query serverKeyType -o tsv; done

custrecords-sql: ServiceManaged

analytics-sql: ServiceManaged

billing-sql: AzureKeyVault

# custrecords-sql holds regulated data but is on the platform key. This is the one to move.

A server is only a finding worth acting on if a regulatory or contractual obligation says it must hold its own key. Separate those from the servers where 'ServiceManaged' is a fine, documented choice before changing anything.

How Defender for Cloud decides a SQL resource is not using a customer-managed keydeep dive

The check resolves to one property: the type of the TDE protector. For an Azure SQL logical server it is the server key type, which is either 'ServiceManaged' (the platform key) or 'AzureKeyVault' (a key in your vault). For a managed instance the same property lives on the instance. The recommendation is Healthy only when that type is 'AzureKeyVault' and the key it points at is a key you control. The two recommendations exist because Azure SQL Database and SQL Managed Instance are distinct resource types configured by different commands ('az sql server tde-key' versus 'az sql mi tde-key'), even though the underlying setting is the same idea.

Setting a customer-managed key has prerequisites that the protector type alone does not capture. The server or instance needs a managed identity, that identity needs 'get', 'wrapKey' and 'unwrapKey' permissions on the key, and the Key Vault must have soft-delete and purge protection enabled before Azure will accept the key for TDE. Miss any of these and the protector cannot be set. This is why the move is a short sequence rather than a single flag, and why it should be tested on a non-production server first.

The strongest position pairs the per-resource configuration with an Azure Policy backstop. The built-in policies 'SQL servers should use customer-managed keys to encrypt data at rest' and 'SQL managed instances should use customer-managed keys to encrypt data at rest' default to an Audit effect, which keeps the recommendation visible, and can be set to Deny on the subscriptions or resource groups that hold regulated workloads so a new server cannot be created there without a customer-managed key. Scoping the Deny to the regulated landing zones, rather than the whole tenant, is what keeps the control aligned to the obligation rather than blanketing every database.

What is the impact of staying on the platform key where a customer-managed key is required?

The first impact is a direct compliance gap. Where a contract, a regulatory framework or a data-residency rule requires that the customer holds the encryption key, a database on the service-managed key does not meet that obligation no matter how strong the encryption is. The data is encrypted, but the control the obligation actually asks for, that you can revoke access to your own data independently of the provider, is not present. At audit this surfaces as a finding against the specific regulated databases, and it cannot be argued away by pointing at the platform encryption.

The second impact is loss of a real security capability. With a customer-managed key you can disable the key to make every database it protects unreadable within minutes, which is a genuine response to a suspected compromise or a contractual termination. You also get an audit trail of every key operation. On the service-managed key neither is available to you: the platform handles the key, and you cannot revoke or independently audit it. For most workloads that is fine; for the regulated ones it is the gap.

It is worth being equally clear about the inverse impact: adopting customer-managed keys where there is no obligation is its own kind of mistake. It adds a Key Vault to keep available, a key to keep enabled, and a failure mode where an accidental loss of key access takes the database offline. A passing record here is not 'every database on a customer-managed key'. It is 'the regulated databases on customer-managed keys, the rest deliberately on the service-managed key, and both choices documented'.

How do you move a regulated workload onto a customer-managed key safely?

Work this as a scoped, ordered change rather than a sweep. The order matters: get the prerequisites right before you set the protector, because a half-configured customer-managed key can leave a database unable to come online.

1. Scope to the workloads that actually require it

List each server and instance still on the service-managed key, then map it to the obligation on its data. Only the databases a contract, framework or residency rule says must hold their own key are candidates. Everything else stays on the fully-encrypted platform key as a documented decision. Do not move a server just to clear a finding.

2. Prepare the key and the identity

Create or choose an Azure Key Vault with soft-delete and purge protection enabled, which Azure requires before it will accept a key for TDE. Create an RSA key (2048 or 3072 bit). Give the server or instance a managed identity, and grant that identity 'get', 'wrapKey' and 'unwrapKey' permissions on the key. Miss any of these and the protector cannot be set.

3. Set the protector on a test resource first

Add the key to the server with 'az sql server key create' (or 'az sql mi key create' for a managed instance), then set it as the TDE protector with 'az sql server tde-key set --server-key-type AzureKeyVault' (or the 'az sql mi tde-key set' equivalent). Verify the protector type reads 'AzureKeyVault' before doing it on production, and confirm the databases stay online.

4. Backstop the regulated scope with Azure Policy

Assign the built-in customer-managed-key policies to the subscriptions or resource groups that hold regulated workloads. Keep them on Audit to stay visible, or set Deny on the regulated landing zones so no new server can be created there on the platform key. Scope the Deny to the regulated zones, not the whole tenant, so the control matches the obligation.

# Move ONE regulated Azure SQL logical server onto a customer-managed key.
# Run against a test server first and confirm databases stay online.
RG=prod-rg
SERVER=custrecords-sql
VAULT=custrecords-kv
KEY=tde-protector

# 1. Vault needs soft-delete + purge protection before Azure accepts a TDE key.
az keyvault update --name "$VAULT" --resource-group "$RG" \
  --enable-purge-protection true

# 2. Create the RSA key (2048 or 3072 bit).
az keyvault key create --name "$KEY" --vault-name "$VAULT" --size 2048

# 3. Give the server a managed identity and read its principal id.
az sql server update --name "$SERVER" --resource-group "$RG" --assign-identity
PRINCIPAL=$(az sql server show --name "$SERVER" --resource-group "$RG" \
  --query identity.principalId -o tsv)

# 4. Grant the identity the exact key permissions TDE needs.
az keyvault set-policy --name "$VAULT" --object-id "$PRINCIPAL" \
  --key-permissions get wrapKey unwrapKey

# 5. Add the key to the server and set it as the TDE protector.
KID=$(az keyvault key show --name "$KEY" --vault-name "$VAULT" \
  --query key.kid -o tsv)
az sql server key create --server "$SERVER" --resource-group "$RG" --kid "$KID"
az sql server tde-key set --server "$SERVER" --resource-group "$RG" \
  --server-key-type AzureKeyVault --kid "$KID"

# 6. Backstop the regulated scope: assign the built-in policy by display name
#    (look up the definition id at runtime, never hardcode the GUID).
PID=$(az policy definition list \
  --query "[?displayName=='SQL servers should use customer-managed keys to encrypt data at rest'].name" \
  -o tsv)
az policy assignment create --name require-cmk-sql --policy "$PID" \
  --scope "/subscriptions/<regulated-subscription-id>"

Quick quiz

Question 1 of 5

Defender for Cloud flags an Azure SQL server and a SQL managed instance for not using customer-managed keys. What is the most accurate way to think about these two findings?

Keep learning

Go deeper on how Azure SQL expresses customer-managed transparent data encryption across the logical server and managed instance.

You can now treat Azure SQL encryption as one scoped capability rather than two findings to clear: every database is already encrypted, the question is who holds the key, and the answer should be a deliberate scope. Identify the workloads under an obligation to hold their own key, move exactly those onto a customer-managed key in a vault protected by soft-delete and purge protection, leave the rest on the documented platform key, and backstop the regulated scope 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

Hardening SQL encryption: the cost and risk view

A low, bounded cost that buys revocable control over regulated data, scoped to the workloads that need it

Unlike most storage hardening, this capability does carry a small, predictable Azure cost, and it is worth being precise about it. The customer-managed key lives in an Azure Key Vault, which charges per key operation and, if you choose a hardware-security-module-backed key or a Managed HSM, carries a higher fixed cost than a software-protected key in a standard vault. None of this is large, but it is a real line, and it scales with how many servers and instances you point at customer-managed keys.

Because the cost is real, the right framing is to scope rather than to blanket. Not every database needs a customer-managed key. The ones that do are the regulated workloads where a framework, a contract or a data-residency obligation requires that the customer holds the encryption key. Map each failing recommendation to whether that obligation actually applies, adopt customer-managed keys where it does, and document the rest as a deliberate decision to stay on the service-managed key, which is still fully encrypted.

The value on the other side of the ledger is control you cannot get from the platform key: the ability to revoke access to your own data by disabling the key, and a usage audit trail. For a regulated workload, that revocable control is often the difference between passing an audit and failing it, which makes the small Key Vault charge an easy trade where the obligation exists.

This lesson is for the finance partner who sees a customer-managed-key finding on the security report and wants to know whether it is a must-fix or a nice-to-have, and what it costs. It covers the small but real Key Vault charge, why this control should be scoped to regulated workloads rather than applied to every database, and how to turn the recommendation into a deliberate, documented decision either way.

Fun fact

The key you can take back

How a finance partner frames the customer-managed-key decision

Priya is the finance partner supporting the SOC 2 push. The security report lists five SQL servers and one managed instance not using customer-managed keys, and the instinct from the platform team is to move all of them onto Key Vault keys to clear the findings. The finance question is sharper: which of these are actually obliged to hold their own key, and what does each one cost to run there? A software-protected key in a standard vault is a few key operations a month; a Managed HSM key is a meaningfully larger fixed monthly cost. Moving all six when only two are regulated would add recurring spend and operational load for no compliance benefit.

Priya asks the team to map each server to the data it holds and the obligation that attaches to it. Two databases hold customer records under a contract that requires customer-held keys: those move to customer-managed keys today, and the small Key Vault charge is a budgeted line. The rest hold internal analytics with no such obligation, and the service-managed key, which still encrypts every byte, stays in place as a documented decision. The finance pack reads: 'Two regulated workloads move to customer-managed keys at a small, bounded Key Vault cost; four stay on the platform key by deliberate choice; the deciding factor is the obligation on the data, not the finding count.'

Why this is a scoped spend, not a free fix

Most security hardening on Azure costs nothing in cloud spend, which makes this capability unusual: the customer-managed key carries a small but real recurring charge for Key Vault operations, and a larger fixed charge if a Managed HSM is required. That changes the finance role from 'approve a free remediation' to 'make sure the spend lands only where an obligation justifies it'. Pointing every server at a customer-managed key to clear findings would grow the bill and the operational surface with no compliance return on the unregulated workloads.

The cost on the other side is the audit gap. For a regulated database, failing to hold your own key can mean a failed control, a contractual breach, or a blocked deal where a customer's security review requires customer-managed keys. Against that, the remediation is a small Key Vault charge and some engineering time. The finance job is to attach the obligation to each failing server, fund the customer-managed key precisely where the obligation exists, and record the rest as a deliberate decision to stay on the cheaper, equally-encrypted platform key.

What finance can do about the SQL encryption gap

Finance cannot set a TDE protector, but it owns the framing that keeps this control scoped to where an obligation justifies the spend, rather than blanketed across the estate to clear findings. Three levers.

1. Tie the spend to the obligation, not the finding count

Make explicit that a customer-managed key is a small but real recurring cost, larger if a Managed HSM is required, and that it should be funded only where a contract, framework or residency rule actually requires customer-held keys. A server on the service-managed key is still fully encrypted, so an unregulated finding is a documented decision, not a cost. Budget the customer-managed keys as discrete lines tied to named regulated workloads.

2. Track the Managed HSM premium separately

A software-protected key in a standard vault is cheap; a Managed HSM key carries a meaningfully larger fixed monthly cost. If a workload's obligation specifically requires HSM-backed keys, that premium is justified and should be a named line. If it does not, a standard-vault key meets the customer-managed-key requirement at a fraction of the cost. Make sure nobody reaches for a Managed HSM by default when a standard vault suffices.

3. Require a documented decision either way

Every SQL server in scope should carry a recorded answer: customer-managed key because of a named obligation, or service-managed key by deliberate choice. The distinction between 'we evaluated this and chose the platform key because nothing requires otherwise' and 'we never looked' is exactly what makes the posture defensible at audit, and it is the artefact that lets finance show the spend was scoped, not blanketed.

Quick quiz

Question 1 of 5

Unlike most Azure hardening, this control is not free. As the finance partner, what is the right starting assumption about its cost?

Keep learning

Go deeper on how Azure SQL expresses customer-managed transparent data encryption across the logical server and managed instance.

You have finished the finance view of hardening SQL encryption. You know this is the unusual control that carries a real, if small, recurring cost, so the job is to fund the customer-managed key precisely where an obligation justifies it, track any Managed HSM premium separately, and record every server's choice either way. Next time a customer-managed-key finding lands, you will ask which obligation attaches to the data before approving any spend, rather than treating a clean report as the goal.

Back to the library

Hardening SQL encryption: the headline

Whether you, or only Microsoft, hold the key to your most sensitive databases

Every Azure SQL database is encrypted at rest already. The question this capability answers is a sharper one: for the databases that hold your most sensitive or most regulated data, do you hold the key, or does the platform hold it for you? A customer-managed key means you can revoke access to your own data at any moment by disabling the key, and you have an auditable record of its use.

The leadership decision is one of scope, not of universal coverage. Moving every database to a customer-managed key would add cost and operational burden for no benefit on workloads that do not require it. The defensible position is that the regulated workloads, the ones where a contract or a framework demands customer-held keys, are on customer-managed keys with their Key Vault protected against accidental deletion, and that this is a documented, deliberate scoping rather than an accident of which databases happened to be configured when.

This is a small, bounded cost decision rather than a free one. The right question is not 'is everything on a customer-managed key?' It is 'are the workloads that must hold their own key actually holding it, and can we prove it?'

A short read for the leader who needs to know the difference between 'our data is encrypted' (always true on Azure SQL) and 'we hold the key' (true only where you have chosen a customer-managed key), why that distinction matters for regulated data, and what a defensible, scoped end state looks like.

Fun fact

The key you can take back

What it looks like when key control is scoped on purpose, not by accident

During audit preparation the auditor asked a pointed question about the customer-record database: who holds the encryption key, and can the company prove it can revoke access? At the time the honest answer was that it depended on which database, because some workloads had been set up with customer-managed keys and others had been left on the platform default with no record of why.

The team's response was to stop treating the customer-managed-key finding as a box to tick on every server and start treating it as a scoping decision tied to the data. They identified the databases under a contractual or regulatory obligation to hold their own key, moved exactly those onto customer-managed keys in a Key Vault protected by soft-delete and purge protection, and recorded the remaining servers as a deliberate choice to stay on the fully-encrypted service-managed key. When the auditor returned to the question, the answer had changed from 'it depends' to 'the regulated databases hold their own key, here is the audit trail of its use, and the scoping of which databases require it is documented.' That shift, from an accidental mix to a deliberate, provable scope, is the confidence signal this capability delivers.

Why this is a scoping decision the board should own

The reason this reaches leadership is not the cost, which is small, but the scoping judgement, which is real. Hold your own key on the regulated databases and you can revoke access and prove it to an auditor or a customer. Fail to, and you carry a control gap on exactly the data most likely to be examined. Blanket the whole estate with customer-managed keys instead, and you add cost and a new outage failure mode for no benefit on the workloads that never needed it.

This is the rare control where both inaction and over-action are mistakes, and the right answer is a deliberate scope. The leadership move is to require that the workloads under an obligation to hold their own key do so, with their Key Vault protected against accidental deletion, and that the scoping of which workloads those are is a documented decision rather than an accident of configuration history.

The leadership move on SQL encryption

The executive handle is not to approve a customer-managed key on every database; it is to require that the workloads under an obligation to hold their own key do so, on the record, and that the scoping is deliberate.

1. Set the scope, then a deadline to reach it

Ask the team to identify the databases under a contractual or regulatory obligation to hold their own key, and give a date by which exactly those are on customer-managed keys in a vault with soft-delete and purge protection. The goal is not universal coverage; it is that the regulated scope holds its own key and the rest are a documented decision to stay on the platform key.

2. Ask for proof, not assurance

The proof is not a verbal 'the important ones are covered'. It is the TDE protector type reading 'AzureKeyVault' on the regulated servers and instances, the Key Vault showing soft-delete and purge protection enabled, and the customer-managed-key policy assigned to the regulated scope. Because Defender for Cloud assesses on a periodic cycle, ask for that evidence with lead time before any audit.

3. Guard against over-reach as well as under-reach

Make clear that blanketing every database with a customer-managed key is not the win. It adds cost and a new outage failure mode where a lost key takes a database offline. The leadership requirement is a deliberate scope: customer-managed keys where an obligation demands them, the platform key where it does not, and the line between the two written down and owned.

Quick quiz

Question 1 of 5

An auditor asks who holds the encryption key for your customer-record database and whether you can prove you can revoke access. What end state lets you answer cleanly?

Keep learning

Go deeper on how Azure SQL expresses customer-managed transparent data encryption across the logical server and managed instance.

Two takeaways. Every Azure SQL database is encrypted already, so this control is about whether you, or only the platform, hold the key, and that matters only where an obligation demands customer-held keys. And the defensible end state is a deliberate scope: customer-managed keys on the regulated workloads with their vault protected against accidental deletion, the platform key everywhere else by documented choice, and proof you can produce on demand rather than an accident of configuration history.

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.

Azure SQL Database

SQL servers should use customer-managed keys to encrypt data at rest Low Relying on platform-managed keys removes the control and separation of duties some compliance regimes demand

Azure SQL Managed Instance

SQL managed instances should use customer-managed keys to encrypt data at rest Low Without a customer-managed TDE key you lose control over the protector and HSM-backed key separation

Part of the learning path Encrypt across Azure

Harden Azure SQL encryption

Hardening SQL encryption: the basics

The key you can take back

Finding which SQL resources hold their own key

How Defender for Cloud decides a SQL resource is not using a customer-managed keydeep dive

What is the impact of staying on the platform key where a customer-managed key is required?

How do you move a regulated workload onto a customer-managed key safely?

1. Scope to the workloads that actually require it

2. Prepare the key and the identity

3. Set the protector on a test resource first

4. Backstop the regulated scope with Azure Policy

Quick quiz

Keep learning

Hardening SQL encryption: the cost and risk view

The key you can take back

How a finance partner frames the customer-managed-key decision

Why this is a scoped spend, not a free fix

What finance can do about the SQL encryption gap

1. Tie the spend to the obligation, not the finding count

2. Track the Managed HSM premium separately

3. Require a documented decision either way

Quick quiz

Keep learning

Hardening SQL encryption: the headline

The key you can take back

What it looks like when key control is scoped on purpose, not by accident

Why this is a scoping decision the board should own

The leadership move on SQL encryption

1. Set the scope, then a deadline to reach it

2. Ask for proof, not assurance

3. Guard against over-reach as well as under-reach

Quick quiz

Keep learning

Controls this lesson covers

Azure SQL Database

Azure SQL Managed Instance

Related compliance lessons