Always Encrypted with Intel SGX enclaves migration guide

Azure SQL Database

Important

Always Encrypted with Intel Software Guard Extensions (Intel SGX) enclaves reaches the end of support on October 31, 2027. Migrate affected databases before this date. After October 31, 2027, Azure automatically moves any database that remains on the DC-series compute tier to a supported standard-series (non-DC) compute tier and enables virtualization-based security (VBS) enclaves.

This article describes the alternatives to Always Encrypted with Intel SGX enclaves and the changes required for each alternative. Review the security considerations before you choose an alternative. Intel SGX and VBS enclaves provide different protections against attacks originating from the guest operating system and the host.

Before you begin, confirm that you can view and modify the target Azure SQL logical servers, databases, and elastic pools. For PowerShell, install the Az PowerShell modules and sign in to Azure. For Azure CLI, install the Azure CLI and sign in to Azure. Inventory the applications that connect to affected databases so that you can update their drivers, connection strings, and attestation settings during migration.

Identify databases that use DC-series

Identify all standalone databases and elastic pools that use DC-series before you plan the migration. Every database in a DC-series elastic pool is affected.

Azure portal

1. In the Azure portal, go to your Azure SQL logical server.
2. On the Overview page, locate Available resources. This table lists the databases on the logical server.
3. In the Pricing tier column, select the filter, and then filter the list for DC-series.
4. Record each database in the filtered list. These databases use DC-series and Intel SGX enclaves.
5. Repeat these steps for each logical server that hosts Azure SQL databases in your environment.

PowerShell

Set $resourceGroupName and $serverName, and then run the following script. The script returns standalone DC-series databases and databases in DC-series elastic pools on the specified logical server.

$resourceGroupName = "<resource-group-name>"
$serverName = "<server-name>"

$databases = Get-AzSqlDatabase `
	-ResourceGroupName $resourceGroupName `
	-ServerName $serverName

$standaloneDatabases = $databases | Where-Object {
	-not $_.ElasticPoolName -and
	$_.CurrentServiceObjectiveName -match '(^|_)DC(_|$)'
}

$dcPoolNames = Get-AzSqlElasticPool `
	-ResourceGroupName $resourceGroupName `
	-ServerName $serverName | ForEach-Object {
		$poolResource = Get-AzResource -ResourceId $_.ResourceId -ExpandProperties
		if ($poolResource.Sku.Family -eq 'DC') {
			$_.ElasticPoolName
		}
	}

$pooledDatabases = $databases | Where-Object {
	$_.ElasticPoolName -in $dcPoolNames
}

@($standaloneDatabases) + @($pooledDatabases) |
	Select-Object DatabaseName, ElasticPoolName, Edition, CurrentServiceObjectiveName

Run the script for each logical server that hosts Azure SQL databases in your environment. If the script returns no rows, the specified server has no databases that use DC-series.

Azure CLI

Set the resource group and logical server name.

resourceGroupName="<resource-group-name>"
serverName="<server-name>"

Sign in to Azure:

az login

List standalone databases that use DC-series:

az sql db list \
    --resource-group $resourceGroupName \
    --server $serverName \
    --query "[?elasticPoolName == null && currentSku.family == 'DC'].{Database:name, ServiceObjective:currentServiceObjectiveName}" \
    --output table

Get the DC-series elastic pools on the server:

dcPoolNames=$(az sql elastic-pool list \
    --resource-group $resourceGroupName \
    --server $serverName \
    --query "[?sku.family == 'DC'].name" \
    --output tsv)

For each DC-series elastic pool returned by the previous command, list its databases:

for poolName in $dcPoolNames; do
    az sql elastic-pool list-dbs \
        --resource-group $resourceGroupName \
        --server $serverName \
        --name $poolName \
        --query "[].{PoolName:elasticPoolName, Database:name}" \
        --output table
done

Run the commands for each logical server that hosts Azure SQL databases in your environment.

Choose a migration path

Choose the migration path that meets the security and application requirements of your workload. Use the following comparison as the starting point, and review the detailed guidance for the selected path before making production changes.

Migration path	Use this option when	Attestation
Azure SQL Database with VBS enclaves	You want to remain on Azure SQL Database and VBS enclaves meet your security requirements.	VBS enclaves in Azure SQL Database don't support attestation.
SQL Server on an Azure confidential VM with VBS enclaves	You require a hardware-enforced boundary that helps protect the guest operating system from host operator access.	Host Guardian Service (HGS) attestation is optional.

Migrate a single database to VBS enclaves

Use this path to retain enclave-enabled capabilities in Azure SQL Database.

1. Select a supported standard-series (non-DC) hardware configuration that meets the performance and availability requirements of your workload.
2. Move the database to the selected hardware configuration.
3. Enable VBS enclaves for the database. Enabling VBS enclaves sets the preferredEnclaveType database property to VBS.
4. Review the client driver requirements for VBS enclaves without attestation, and update your application driver if necessary.
5. Update each application connection to use the None enclave attestation protocol, and remove the Microsoft Azure Attestation URL. The exact connection-string keywords depend on the client driver.
6. Complete the post-migration validation.

Migrate an elastic pool to VBS enclaves

All databases in an elastic pool inherit the enclave configuration of the pool. Use this path to retain enclave-enabled capabilities for databases in an Azure SQL elastic pool.

1. Select a supported standard-series (non-DC) configuration that meets the performance and availability requirements of the pool. For information about changing pool configuration, see Manage an elastic pool in Azure SQL Database.
2. Enable VBS enclaves for the elastic pool. Enabling VBS enclaves sets the preferredEnclaveType pool property to VBS.
3. Review the client driver requirements for VBS enclaves without attestation, and update your application drivers if necessary.
4. Update each application connection to use the None enclave attestation protocol, and remove the Microsoft Azure Attestation URL. The exact connection-string keywords depend on the client driver.
5. Complete the post-migration validation for every database in the pool.

Migrate to SQL Server on an Azure confidential VM

Consider this path if you require a hardware-enforced boundary that helps protect the guest operating system from host operator access. Azure confidential VMs encrypt VM memory and provide different security properties from Intel SGX enclaves. Evaluate these differences against your security and compliance requirements.

1. Deploy SQL Server to an Azure confidential VM.
2. Choose whether to use enclave attestation:
   • Plan for Always Encrypted with secure enclaves in SQL Server without attestation.
   • Plan for Host Guardian Service attestation.
3. Configure Always Encrypted with VBS enclaves on the SQL Server instance by following the guidance for the attestation option you selected.
4. Plan the migration of your database, logins, keys, application connectivity, and dependent resources.
5. Choose a data migration option based on your database size, network configuration, downtime requirements, and supported database objects. Common options include:
   • Azure Data Factory: Use a copy activity with the Azure SQL Database connector as the source and the SQL Server connector as the sink. ADF treats the Always Encrypted columns as binary or ciphertext values and moves them without needing access to the Column Master Key.
   • Smart Bulk Copy: Use Smart Bulk Copy to copy schema and data from Azure SQL Database to SQL Server. Review the tool's prerequisites and limitations before migration.
   • BACPAC: Consider a BACPAC for smaller databases whose objects are supported by data-tier applications. Always Encrypted data remains encrypted during export and import, and the BACPAC includes the Always Encrypted key metadata. For more information, see Export and import databases using Always Encrypted, Export a BACPAC file, and Import a BACPAC file to create a new database.
6. Update application connection strings for the SQL Server instance and the selected attestation option.
7. Complete the post-migration validation.

Validate the migration

Before you move the workload to production:

1. Verify that applications can connect with Always Encrypted enabled.
2. Run representative queries that use encrypted columns, including queries that require enclave computations if the target environment uses secure enclaves.
3. Verify that inserts, updates, deletes, and index operations on encrypted columns behave as expected.
4. Test application performance and adjust the target compute configuration if necessary.
5. Test your business continuity, disaster recovery, and failover procedures. All database replicas must support secure enclaves if the workload uses enclave-enabled operations.
6. Monitor the application for enclave, attestation, and query errors before completing the cutover.

Related content

• Always Encrypted with secure enclaves documentation
• Tutorial: Getting started using Always Encrypted with secure enclaves
• Configure and use Always Encrypted with secure enclaves