Symmetric key alter issue in SQL Server 2025

Question

Symmetric key alter issue in SQL Server 2025

Dipak Nile 0

Context: I am using SQL Server 2025 with symmetric keys protected by a certificate, and I encrypt/decrypt data using the EncryptByKey and DecryptByKey functions. I now need to migrate the symmetric key protection to Azure Key Vault. However, while implementing the encryption using Azure Key Vault for symmetric keys, I am encountering the following exception:

Command used:

OPEN SYMMETRIC KEY DAT_KEY  
   DECRYPTION BY  CERTIFICATE DB_Cert_test; 

ALTER SYMMETRIC KEY DAT_KEY    ADD ENCRYPTION BY                                                                                                               
ASYMMETRIC KEY SQLServerKeyAKV_DB_KEY;

Error:

Location:	 cmedokey.cpp:912
Expression:	 0 && "Invalid Crypto Property Type"
SPID:		 60
Process ID:	 9364
Thread ID:	 11460
Msg 3624, Level 20, State 1, Line 5
A system assertion check has failed. Check the SQL Server error log for details. Typically, an assertion failure is caused by a software bug or data corruption. To check for database corruption, consider running DBCC CHECKDB. If you agreed to send dumps to Microsoft during setup, a mini dump will be sent to Microsoft. An update might be available from Microsoft in the latest Service Pack or in a Hotfix from Technical Support.
Msg 596, Level 21, State 1, Line 4
Cannot continue the execution because the session is in the kill state.
Msg 0, Level 20, State 0, Line 4
A severe error occurred on the current command.  The results, if any, should be discarded.

I think this might be a issue with SQL Server 2025 , becuase this is working fine is old SQL versions.Already ruled out:

AKV wrap request succeeds (visible/successful on the Key Vault side).
[If run] DBCC CHECKDB clean — not corruption.

0 comments

2 answers

Your answer

Answer 1

Erland Sommarskog 134.6K MVP Volunteer Moderator

That type of error message is always a bug in SQL Server. It may be due to a user error, but a user error should result in a proper error and not an system assertion check. (An assertion check is a check that a programmer puts into the code with the meaning "This condition better be true at this point, or else we no longer know what we are doing". So if the condition is false, they abort execution to prevent further damage.)

The first thing is to check that you have the most recent Cumulative Update, which is CU5, installed. If you have not, it could be a known issue which has been fixed.

If you still get this error message with CU5, you should open a support case. You may be charged initially, but since this is a bug, you should be refunded in the end.

Dipak Nile 0 Reputation points

2026-06-02T07:44:20.8966667+00:00

Thanks @Erland Sommarskog Yes I tried in latest CU5 and it is still same error and it look like bug.
Erland Sommarskog 134.6K Reputation points MVP Volunteer Moderator

2026-06-02T21:16:22.3433333+00:00

I was able to repro the problem. (I found it was interesting to learn to have an asymmetric key in Azure Key Vault, so I set that up, and I tried the same operation as you. With the same result.)

I hope that your organisation has a support contract so that you can open a case to get a fix.

I took the liberty to report this on https://feedback.azure.com/d365community/idea/0ef94d21-c85e-f111-89e7-7c1e52d83a79 and you can vote for it. However, note that this is more to let Microsoft know, and there is no guarantee that this report leads to a fix.
Dipak Nile 0 Reputation points

2026-06-02T21:32:47.34+00:00

Thanks @Erland Sommarskog , I have voted. We dont have support contract and looking for options.
Erland Sommarskog 134.6K Reputation points MVP Volunteer Moderator

2026-06-02T21:39:31.6366667+00:00

Too bad, then you will have to find a workaround. One is to create a new symmetric key which you protect by the key in AKV (I was able to create such a key). Then you will have to decrypt and re-encrypt all data.
Akhil Gajavelly 1,830 Reputation points Microsoft External Staff Moderator

2026-06-08T06:28:09.0266667+00:00

Hi @Dipak Nile ,

Since the issue has been reproduced independently on CU5 and the workaround of creating a new AKV-protected symmetric key succeeds, there does not appear to be much more that can be done from the T-SQL side.

If opening a Microsoft support case is not an option, it may be worth monitoring future cumulative updates and the feedback item for any acknowledgement or fix from the product team. In the meantime, the suggested workaround of creating a new symmetric key protected by the Azure Key Vault asymmetric key and re-encrypting the data seems to be the safest migration path.

If you proceed with that approach, it would be helpful to know whether the workload size makes re-encryption practical or whether a phased migration strategy is needed.

Thanks,
Akhil.
Erland Sommarskog 134.6K Reputation points MVP Volunteer Moderator

2026-06-10T07:42:36.7633333+00:00

Microsoft has acknowledged the bug, and added this comment to my bug report on https://feedback.azure.com/d365community/idea/0ef94d21-c85e-f111-89e7-7c1e52d83a79:

We confirm this is a bug and does work in SQL 2022. We have filed a bug for it. We expect this to be fixed in one of the following CUs. Although the alter symmetric key is bugged, the create symmetric key should still work. E.g. CREATE SYMMETRIC KEY symclé WITH ALGORITHM = AES_256 ENCRYPTION BY ASYMMETRIC KEY Nyckel001;

Answer 2

This behavior is consistent with a product defect rather than a misuse of the T‑SQL syntax.

From the documented behavior of symmetric keys and ALTER/OPEN operations:

ALTER SYMMETRIC KEY is the correct mechanism to add a new encryption protector (certificate, asymmetric key, or password) to an existing symmetric key, and it supports ASYMMETRIC KEY as an encryptor.
OPEN SYMMETRIC KEY correctly requires that any key used to encrypt the symmetric key (certificate/asymmetric key) be opened or otherwise available first.
The error text shows an internal assertion in SQL Server (Invalid Crypto Property Type in cmedokey.cpp), which is not a user-correctable error and typically indicates a bug in the engine when handling a particular crypto configuration.
DBCC CHECKDB being clean and the fact that the same pattern works on earlier SQL Server versions further supports that this is not data corruption or a T‑SQL usage issue.

Given that:

The T‑SQL pattern is supported and aligns with the documented ALTER/OPEN SYMMETRIC KEY semantics.
The assertion is an internal engine failure, not a normal runtime error.
There is no documented restriction in the provided material that would make this ALTER operation invalid.

The next step is to treat this as a SQL Server 2025 defect and engage Microsoft Support so that the crash dump and environment details can be analyzed and a fix or workaround can be provided.

Recommended actions:

Preserve evidence
- Keep the SQL Server error logs and any dump files generated for the assertion.
- Capture the exact T‑SQL script, key definitions (CREATE SYMMETRIC KEY / CREATE ASYMMETRIC KEY / AKV provider configuration), and database compatibility level.
Log a support case with Microsoft
- Open a support ticket and provide:
  - SQL Server 2025 build number.
  - Repro steps (including the ALTER SYMMETRIC KEY statement and how the AKV-backed asymmetric key is configured).
  - Error log and dump file for the assertion.
Interim workaround options (until a fix is available)
- If possible in the environment, keep using the existing certificate-based protection for the symmetric key (no ALTER) while planning the migration.
- Alternatively, create a new symmetric key directly protected by the AKV-backed asymmetric key and migrate encrypted data to use the new key, instead of altering the existing key. This avoids the specific ALTER path that is triggering the assertion.

Because the assertion is engine-internal and not covered by configuration guidance in the available documentation, a code fix or hotfix from Microsoft will likely be required for a permanent resolution.

References:

Share via

Symmetric key alter issue in SQL Server 2025

2 answers

Your answer