For teams thinking about long-term cryptographic resilience, this preview is especially relevant. TDE with customer-managed keys has traditionally used asymmetric RSA-based key protectors, while broader industry guidance is increasingly focused on preparing for a post-quantum cryptographic (PQC) future and adopting cryptographic approaches that are better aligned with that transition.

This update aligns with broader security guidance, including the NSA’s CNSA 2.0 recommendations, which emphasize modern cryptographic planning for a quantum-resistant future. For organizations building crypto agility into their platforms, AES support is a practical step in that direction.

Why it matters

Preparing for a post‑quantum world

With current technology, breaking asymmetric algorithms such as Elliptic Curve and RSA-2048 using the best-known classical methods would take billions of years. Even with large-scale distributed computing, it is still considered computationally infeasible.

Asymmetric algorithms are vulnerable to Shor’s algorithm, which means a sufficiently powerful quantum computer could break RSA-2048 much faster. That said, this would require millions of stable qubits, and current quantum systems are still far from that point. AES, as a symmetric algorithm, is not affected by Shor’s algorithm and remains more resistant to known quantum attacks, including Grover’s algorithm, when used with larger key sizes such as AES-256.

The figure below highlights the difference in the estimated effort required to break RSA-2048 and AES-256. For context, the green dashed line represents the age of the universe, about 13.8 billion years.

Aligning with modern security guidance

Security guidance is moving toward stronger crypto agility and long-term resilience. By supporting AES keys for TDE protectors, Azure SQL Database gives customers a way to align data-at-rest protection with evolving security and compliance expectations.

For a broader overview of quantum computing and cryptography, see Microsoft’s post-quantum cryptography overview.

How it works (high level)

At a high level, nothing changes about the purpose of TDE: it still protects data at rest by encrypting the Database Encryption Key (DEK) with a TDE protector. What changes in this preview is the type of key you can use to protect, or wrap, the AES DEK.

• The AES DEK encrypts database data files and log files.
• The TDE protector encrypts the DEK.
• With TDE with customer‑managed keys, the TDE protector is stored in Azure Key Vault or Azure Key Vault Managed HSM.
• With this preview, the TDE protector can now be a symmetric AES key instead of an RSA key.

For background on customer-managed TDE, see the Customer-managed transparent data encryption (TDE)

Get started

If you want to try the preview, make sure the following prerequisites are in place:

• An Azure SQL Database logical server or database with customer-managed TDE enabled.
• An Azure Key Vault Premium (preview) or Azure Key Vault Managed HSM with support for AES keys.
• Soft-delete and purge protection enabled on the key store.
• The required permissions for Azure SQL Database to access the key.

You can review the full prerequisites in Microsoft Learn under requirements to configure customer-managed TDE.

The setup flow for AES keys is essentially the same as for RSA-based TDE protectors. The main difference is the type of key you create and register.

1. Create an AES key (for example, AES‑256) in Azure Key Vault Managed HSM.
2. Add the key to your Azure SQL logical server.
3. Set the AES key as the TDE protector.
4. Verify that encryption is enabled using system views.

For step-by-step configuration guidance, see Microsoft Learn on Create Azure SQL Database Logical Server Configured with User-Assigned Managed Identity and Customer-Managed TDE.

Example configuration (PowerShell)

The following example shows the basic PowerShell flow: create an AES key, register it with the logical server, and then set it as the TDE protector.

# Variables
$hsmName = "MyHSM"
$keyName = "TDE-AES-Key"
$sqlServerName = "my-sql-server"
$sqlResourceGroup = "my-sql-rg"

# Create an AES-256 HSM-backed key in MHSM
Add-AzKeyVaultKey `
  -HsmName $hsmName `
  -Name $keyName `
  -KeyType oct-HSM `
  -Size 256

# Get key URI
$key = Get-AzKeyVaultKey -HsmName $hsmName -Name $keyName

# Register the key with the SQL server
Add-AzSqlServerKeyVaultKey `
  -ResourceGroupName $sqlResourceGroup `
  -ServerName $sqlServerName `
  -KeyId $key.Id

# Set the key as the TDE protector  
Set-AzSqlServerTransparentDataEncryptionProtector `
  -ResourceGroupName $sqlResourceGroup `
  -ServerName $sqlServerName `
  -Type AzureKeyVault `
  -KeyId $key.Id

After you enable TDE with AES keys, you can verify the database encryption status by running the following query:

SELECT
  DB_NAME(database_id) AS DatabaseName,
  encryption_state_desc,
  encryptor_type
FROM sys.dm_database_encryption_keys
WHERE database_id <> 2;

If the database is encrypted, the view returns an ENCRYPTED state, or ENCRYPTION_IN_PROGRESS while encryption is still underway, with SYMMETRIC_KEY shown as the encryptor type.

Public preview notice

Transparent data encryption in Azure SQL Database with AES keys support is currently in Public Preview. Preview features are provided for evaluation purposes and are subject to the Azure Preview Supplemental Terms .

Availability is rolling out gradually across Azure regions. You may see this capability appear over time depending on your region and service deployment status. Azure SQL Database is the first SQL offering to receive this feature, with additional SQL platforms planned in the future.

Learn more

• Microsoft Learn: customer-managed transparent data encryption for Azure SQL Database
• Microsoft Learn: configure customer-managed TDE for Azure SQL Database
• Microsoft Research: post-quantum cryptography overview

Conclusion

AES key support for customer-managed TDE gives Azure SQL Database customers a practical way to strengthen their encryption strategy while preparing for long-term cryptographic change, including post quantum cryptography. Because the setup experience remains familiar, teams can evaluate this preview without rethinking how TDE works operationally.

We want your feedback

If you’re exploring this preview, now is a good time to test it in your environment and share feedback with the product group before general availability.