Microsoft's October 7 announcement sets October 31, 2027 as the retirement date for Always Encrypted with Intel SGX enclaves in Azure SQL Database. Customers need to review affected DC-series databases and choose a supported path before that deadline. Retirement announcement.
My recommendation: start with the security requirement, then select the destination. This is not a change I would approve solely because a replacement compute configuration is available.
The Important Choice Is the Trust Boundary
Microsoft presents two paths: VBS enclaves within Azure SQL Database, or an assessment of SQL Server on Azure confidential VMs where stronger host isolation is required. VBS enclaves in Azure SQL Database do not support attestation. The options have different security properties; they are not interchangeable assurances. Migration options and security considerations.
I would ask the security owner to restate the original requirement in plain language: which actors must be prevented from accessing sensitive data during processing, and which administrative layers are trusted?
That conversation should produce a written decision, not a checkbox labelled “encryption retained.” A workload can continue to use encryption while its underlying protection assumptions change.
If a confidential-VM architecture is being considered, give it a separate design review. Compare operational ownership, recovery responsibilities, application compatibility, and the team's ability to support the target. Do not assume a VM-based destination is a like-for-like replacement for the existing managed service.
Inventory Applications, Not Only Databases
The migration guide includes discovery for standalone DC-series databases and DC-series elastic pools; every database in an affected pool needs attention. Discovery guidance.
My inventory would connect each database to its application owners, deployment pipelines, scheduled jobs, and support contacts. Include less visible clients such as reporting tasks and maintenance utilities.
For each client, record where connection settings live and who can deploy an update. A database team may complete its work while a rarely used job retains settings that no longer match the target.
I would also identify applications without a current owner early. Finding an abandoned integration during a planned review is much easier to manage than discovering it during the final cutover window.
Do Not Treat Automatic Movement as Application Readiness
Microsoft's guide says Azure will automatically move remaining DC-series databases to supported non-DC compute and enable VBS enclaves after the retirement date. It also requires application attention: review driver support, use the None enclave attestation protocol for the Azure SQL VBS path, and remove the Microsoft Azure Attestation URL. Exact connection-string keywords depend on the driver. Platform behavior and migration steps.
My conclusion is that waiting for the platform action is not a substitute for a controlled migration. The application owner still needs evidence that the selected design meets the workload's requirements.
Avoid a global search-and-replace across unrelated connection strings. Scope the change to the reviewed destination and client library, retain configuration history, and handle secrets through the existing secret-management process.
Build a Workload-Level Acceptance Test
I would choose a representative non-production workload and write the acceptance criteria before changing it. Include the operations users depend on, the expected results, acceptable response times, and the failures that require stopping the rollout.
For a hypothetical case-management application, that might mean creating a test record, finding it through the normal search experience, changing an authorized field, and confirming that an unauthorized identity cannot perform the same action.
Keep test data synthetic or appropriately sanitized. The migration review should not create an unnecessary copy of sensitive production information.
Involve the on-call team in the rehearsal. Ask how they would distinguish a connectivity problem from an encryption-related application error, and where they would find the approved recovery procedure.
Document a recovery strategy appropriate to the chosen architecture. Do not casually promise an instant rollback after data or configuration has changed. Agree on the conditions for pausing, reverting where supported, or recovering through the tested procedure.
These are planning recommendations, not a claim that I have migrated or benchmarked an SGX-dependent workload.
Practical Cloud Engineer Takeaway
Obtain security-owner agreement on the target trust boundary.
Connect affected database resources to every application that uses them.
Plan platform and client changes as one coordinated release.
Rehearse with meaningful application acceptance criteria.
Complete the migration before the retirement deadline rather than relying on automatic movement.
Who Should Care?
Azure SQL administrators, application owners, security architects, and platform teams running Always Encrypted workloads that depend on Intel SGX enclaves.
Bottom Line
There is time to make a deliberate decision. Use it to validate the security model and application behavior together, so the eventual migration is an understood change rather than a deadline-driven surprise.
Sources
Stay radical, stay curious, and keep pushing the boundaries of what is possible in the cloud.
Chriz
Beyond Cloud with Chriz
Comments