Microsoft has announced that Always Encrypted with Intel SGX enclaves in Azure SQL Database will retire on October 31, 2027. The reason is not policy. It is silicon: SGX enclaves run on DC-series virtual machines, and that hardware generation is being phased out of Azure.
If you run encrypted databases on DC-series compute, you have about a year to move. Doing nothing is technically possible, but it has a catch that compliance teams should know about before, not after, it happens.
What Always Encrypted with enclaves actually does
Always Encrypted keeps column data encrypted end to end: the client encrypts, the server stores ciphertext, and the SQL engine never sees plaintext. That breaks something, though. You cannot run LIKE queries, sort encrypted columns, or rebuild an index on ciphertext.
Secure enclaves solve that. A small protected memory region inside the SQL process can perform rich operations on sensitive data while the host stays blind to it. With SGX, that region is enforced by the CPU itself, backed by remote attestation through Microsoft Azure Attestation. It is the strongest data-in-use protection Azure SQL Database has offered to date.
Why it is going away
SGX is a hardware feature, and the DC-series VMs that carry it are aging out. That constraint shaped everything awkward about the offering: DC-series counts physical cores rather than logical ones, caps at 40 cores, does not support serverless, and is unavailable on standard-series Gen5 hardware or the DTU purchasing model. You paid for exotic silicon whether or not your threat model needed it.
Microsoft has quietly been steering confidential compute in Azure away from single-vendor enclave silicon for a while. This retirement is the visible step of that shift for Azure SQL.
VBS enclaves: the default replacement
The recommended replacement is Virtualization-Based Security (VBS) enclaves. These run in a software-isolated region anchored in the Hypervisor rather than in special CPU features. Three practical differences matter:
- VBS enclaves work on standard-series compute, so no DC-series pricing and no physical-core cap.
- No attestation setup. SGX required a Microsoft Azure Attestation provider with role separation and an attestation URL in every connection string. VBS needs none of that.
- They are available across all Azure SQL Database offerings, in every region except Jio India Central.
For most workloads this is a simplification. You drop an entire operational component, the attestation service, and keep the enclave queries working.
The part that should worry compliance teams
After October 31, 2027, Azure will automatically move any database still sitting on DC-series compute to a standard-series tier and enable VBS enclaves. Your workload keeps running. Your encrypted columns stay encrypted. Nothing breaks.
What changes is the security boundary. SGX protected data in use against the host operating system itself. VBS protects against high-privileged users such as DBAs, but it does not attest and does not defend against sophisticated host-level attacks. Microsoft is straightforward about this: the migration guide says that if your threat model requires isolation from the host OS, evaluate SQL Server on Azure Confidential VMs instead, where Host Guardian Service attestation is optional but available.
An automatic, silent downgrade of that boundary is exactly the kind of thing that sails through a compliance review until someone asks what changed. If your attestations or control mappings reference SGX, the honest answer after October 2027 would be “the platform decided we no longer need it.” Better to make that decision yourself and document it.
What the migration actually involves
This is a configuration migration, not a re-encryption exercise. Always Encrypted keys and ciphertext survive untouched. Microsoft’s announcement post lays out the steps:
- Inventory every database and elastic pool running on DC-series compute. The migration guide includes PowerShell and Azure CLI scripts for discovery, and the portal can filter by pricing tier.
- Move affected databases to a supported standard-series tier.
- Set the preferredEnclaveType database property to VBS.
- Update client drivers to versions that support VBS without attestation.
- Update connection strings to use the None enclave attestation protocol and remove the Azure Attestation URL.
Then validate. Run enclave-enabled queries against encrypted columns, exercise DML and index operations, and test failover, since every replica in the group has to support secure enclaves. Performance should improve on standard-series hardware for most workloads, but test anyway. Migrations that skip the replica check are the ones that page someone at 3am later.
Decide the threat model first
Two paths leave this retirement. Most teams should migrate to VBS enclaves and enjoy deleting their attestation infrastructure. Teams whose compliance posture genuinely depends on hardware-rooted isolation from the host should look at Confidential VMs now, because that evaluation involves sizing, attestation architecture, and budget conversations that will not resolve themselves in a week.
Both beat the default outcome, which is a year from now: your database moves itself, the boundary quietly weakens, and nobody wrote it down. A year is enough time to do this properly. Start with the discovery script, count how many databases you actually have on DC-series, and let that number pick your path.