Azure encrypts storage, disks and managed databases at rest by default with service-managed keys. Move to customer-managed keys in Key Vault only when a policy or regulator needs you to control key lifecycle, and then protect the vault itself with role-based access, purge protection and rotation.
What does Azure encrypt by default?
Microsoft's encryption overview says Azure offers AES-256 encryption for data at rest across SaaS, PaaS and IaaS models. Managed disks, snapshots and images are encrypted by default with a service-managed key. Azure Storage encrypts data before it is stored and decrypts on retrieval. Transparent Data Encryption is on by default for newly created Azure SQL databases, and Cosmos DB encrypts user data with service-managed keys by default.
In transit, the same page says MACsec protects traffic between datacenters, that TLS 1.2 or later is required across Azure services (most completed the transition by 31 August 2025), and that HTTPS can be enforced on storage accounts through the secure transfer requirement.
What are the choices for keys?
The overview lists three server-side models and a client-side option:
- Service-managed keys: low overhead, a mix of control and convenience.
- Customer-managed keys: you control the keys, including bring your own key, and can generate new ones.
- Service-managed keys on customer-controlled hardware, also called Host Your Own Key.
- Client-side encryption: data is encrypted outside Azure, so the provider cannot decrypt it.
Cosmos DB also supports a second layer of encryption with your own keys. For SQL, Always Encrypted lets client applications encrypt data before it reaches the database, which separates people who own the data from administrators who manage the server.
The right default is the simplest model that satisfies your obligations. Customer-managed keys add a duty: if the key is deleted or the vault is unreachable, the data is unreadable. That is the point of control, and also a new way to cause an outage.
How do you protect the key store?
Microsoft's Key Vault guidance gives a concrete set of settings. Use one vault per application, region and environment, because a vault is a security boundary and sharing one enlarges the blast radius. Use managed identities so apps hold no credentials. Use Azure role-based access control and avoid legacy access policies, which the page says have known security weaknesses and lack Privileged Identity Management support. Give administrators eligible, just-in-time roles with approval and multi-factor authentication on activation.
For data protection, turn on soft delete (7 to 90 days of retention) and purge protection, and set up automatic rotation of keys, secrets and certificates. Add audit logging, alerts on access failures or secret deletion, and backups, and test restoring them. Restrict the network path: private endpoints, the firewall, or a network security perimeter, and keep clients on TLS 1.2 or 1.3.
Do not treat the vault as a database. The guidance says not to store customer content or configuration there.
A constructed example
A payments team stores card tokens in Azure SQL and is asked by an assessor whether the company controls key rotation. TDE with service-managed keys encrypts the data, but the team cannot show its own rotation schedule. They switch to a customer-managed key in a dedicated production vault, assign the SQL server a managed identity with the minimum role, enable purge protection, and configure autorotation. They also write a runbook: what happens if the key is disabled, who can re-enable it, and how a restore is tested.
What to do
- Inventory data stores and record which encryption model each uses today.
- Decide per store whether service-managed keys meet the requirement. Write down why.
- For customer-managed keys, create one vault per application and environment.
- Use RBAC and managed identities, and remove legacy access policies.
- Enable soft delete, purge protection, logging and autorotation.
- Disable public network access or restrict it with a firewall.
- Test backup and recovery, including a key disabled by mistake.
- Enforce secure transfer and TLS 1.2 or later in application settings.
- Note the retirement date for Azure Disk Encryption in the overview, 15 September 2028, and plan migration to encryption at host.
Safeguard compliance automation can track controls like these as evidence, see the framework mapping demo.
Quick check
Is data in Azure unencrypted until I turn encryption on?
No. The overview describes default encryption at rest for managed disks and storage, and TDE on new Azure SQL databases. Your choice is about who holds the keys.
What does purge protection do?
It protects Key Vault objects from deletion, accidental or malicious, even after soft delete is enabled.
Sources
Last reviewed: 18 October 2026.
