I performed an upgrade for a non-FIPS compliant signing key (P-256K) in Verified ID, but IDs are still being issued using the old key

Question

I performed an upgrade for a non-FIPS compliant signing key (P-256K) in Verified ID, but IDs are still being issued using the old key

笹川浩 40

Regarding the upgrade of the non-FIPS compliant signing key (P-256K), even after following the official procedure, the signing key used for VC signatures appears to remain the old P-256K key; thus, the upgrade does not seem to have succeeded.

Please advise on how to resolve this issue.

In light of the scheduled retirement of the non-FIPS compliant signing key (P-256K) on July 1, 2026, I performed the following procedure:

https://learn.microsoft.com/ja-jp/entra/verified-id/signing-key-upgrade#upgrading-the-signing-key

All steps were completed successfully without errors.

The execution results for "GET /v1.0/verifiableCredentials/authorities/<authorityId>" are as follows: {

"id": "8b0dd●●●",

"name": "●●●",

"status": "Enabled",

"didModel": {

"did": "did:web: ●●●.japaneast.cloudapp.azure.com",

"signingKeys": [

"https://vid-kv.vault.azure.net/keys/vcSigningKey-8b0dd●●●",

"https://vid-kv.vault.azure.net/keys/●●●a5c1b-vcSigningKey/a04315e00f304●●●ae03b619ea"

],

"recoveryKeys": [],

"updateKeys": [],

"encryptionKeys": [],

"linkedDomainUrls": [

"https:// ●●●.japaneast.cloudapp.azure.com/"

],

"didDocumentStatus": "published"

},

"keyVaultMetadata": {

"subscriptionId": "8b4e12b0-43a●●●652e055cab",

"resourceGroup": "verifiedid-resource-group",

"resourceName": "vid-kv",

"resourceUrl": "https://vid-kv.vault.azure.net/"

},

"linkedDomainsVerified": true,

"createdAtTimestamp": "2023-07-28T06:28:40.924Z"

}

Two signing keys are registered in the signingKeys array: the first points to the old P-256K signing key, and the second points to the newly created P-256 signing key.

The didDocumentStatus is set to "published," and I have confirmed that there are no discrepancies between the Key Vault and the did.json file.

Two signature verification keys are registered in the https:// ●●●.japaneast.cloudapp.azure.com/.well-known/did.json file (registered in Step 3), and they match the two signing keys in the signingKeys array mentioned above. Additionally, VCs signed with the older P-256K signing key issued in the past are being successfully verified using the contents of this did.json.

Furthermore, regarding the https:// ●●●.japaneast.cloudapp.azure.com/.well-known/did-configuration.json registered in Step 6, an inspection of the JWT contents indicates that it is signed with the newly created P-256 signing key.

[Header section only]

{

"alg": "ES256",

"kid": "did:web: ●●●.japaneast.cloudapp.azure.com#a04315e●●●-ec63-308b"

}

However, as shown in the image below, the "Verified ID | Organization settings" screen in the Azure Portal still displays the signing key identifier pointing to the old P-256K signing key.

[Signing Key Identifier] https://vid-kv.vault.azure.net/keys/vcSigningKey-8b0dd●●●

When a new VC is issued in this state, it appears to be signed using the old P-256K signing key.

[Header Content]

{

"alg": "ES256K",

"kid": "did:web:●●●.japaneast.cloudapp.azure.com#●●●vcSigningKey-8b0dd",

"typ": "JWT"

}

Has the signing key upgrade been successfully completed in this scenario?

Will the newly created P-256 signing key come into use on July 1, 2026?

If the signing key upgrade has not been successful, please advise me on any missing steps.

I am concerned that if the situation remains as is, VC issuance will fail when the old P-256K signing key is retired on July 1, 2026, thereby impacting operations.

Shubham Sharma 17,930 Reputation points Microsoft External Staff Moderator

2026-06-23T08:01:57.39+00:00
笹川浩

Thank you for reaching out to Microsoft Q&A.

It looks like you’ve followed all of the documented steps to create a new P-256 key, regenerate your DID document, deploy it, and even publish your did-configuration.json—yet new VCs are still getting signed with the old P-256K key. You’re right to be concerned, since P-256K retires July 1, 2026. Here’s what’s likely going on and how to get your authority to start using ES256 (P-256) today:

Ensure you’ve run the “synchronizeWithDidDocument” step

Merely uploading did.json and seeing didDocumentStatus: "published" from a GET call doesn’t automatically flip the signing key. You must explicitly call the Synchronize API (or click “Sync DID document” in the portal) to tell the service to start issuing with the new key.

If you haven’t done that, run the POST /v1.0/verifiableCredentials/authorities/{authorityId}/synchronizeWithDidDocument API and then verify didDocumentStatus goes to published again.

Portal UI shows the first key in your signingKeys list, not necessarily the one in use

The “Signing key identifier” field in Organization settings will still show the old P-256K key (array index 0) even after a successful sync. That’s just the way the portal surfaces your Key Vault list—it doesn’t reorder it to highlight the current key.

Test by disabling the old P-256K key in Key Vault

As a quick proof, disable the old P-256K key (in the same vault) so it can’t be used. Then call Synchronize again (or wait a few minutes for the service to refresh). Issue another VC—it should now be signed with ES256 (P-256).

Once you confirm that, you can plan to leave the P-256K key disabled (or removed) so that after July 1, 2026 no new tokens ever fall back to it.

When July 1, 2026 arrives, P-256 is automatically your only choice

Any authority that hasn’t disabled P-256K will simply stop issuing VCs if it tries to use the old key. After that date, the service will only accept FIPS-compliant curves—so new VCs will default to your P-256 key. Better to validate the setup now rather than finding out in production.

So in short: double-check you ran the synchronize call, ignore the portal’s “first key” display, and disable the old key to force a switch. Once that’s done and tested, you’re all set well before the 2026 deadline. References:

https://learn.microsoft.com/entra/verified-id/signing-key-upgrade#upgrading-the-signing-key

https://learn.microsoft.com/entra/verified-id/signing-key-upgrade#post-upgrade-considerations

https://learn.microsoft.com/entra/verified-id/how-to-rotate-keys#rotate-the-signing-keys

If the answer is helpful, kindly upvote it. If you have extra questions about this answer, please click "Comment".
Shubham Sharma 17,930 Reputation points Microsoft External Staff Moderator

2026-06-24T07:42:42.6733333+00:00

笹川浩

Following up to check if the resolution provided was helpful. Let us know if you need any further assistance.
Sina Salam 31,456 Reputation points Volunteer Moderator

2026-06-28T16:36:33.9+00:00
Hello 笹川浩,

Welcome to the Microsoft Q&A and thank you for posting your questions here.

I understand that you performed an upgrade for a non-FIPS compliant signing key (P-256K) in Verified ID, but IDs are still being issued using the old key.

In addition to @Shubham Sharma this issue is already beyond normal self-service Recovery Services vault deletion.

A Recovery Services vault cannot be deleted while it still contains protected items, backup data, soft-deleted backup data, protected servers, or backup management server registrations.

The error means the MABS/Azure Backup Server container has already entered an unregister workflow but has not been fully removed from the Azure Backup backend. Since the MABS server is already decommissioned and repeated portal/PowerShell deletion attempts still fail, do not keep retrying the same delete operation. The resolution is to raise an Azure technical support request via your Azure Portal or Priority Customer Support (PCS) and ask Microsoft Azure Backup support to clear the orphaned/deferred MABS container registration from the backend for all affected vaults.

The best is to remove visible backup dependencies where possible, then have Microsoft Azure Backup support clear the stuck backend MABS container state, then delete the vaults and cancel the subscription if no longer needed.

Use the below resources for the official steps and validation:

Delete a Recovery Services vault: https://learn.microsoft.com/azure/backup/backup-azure-delete-vault

Configure and manage soft delete in Azure Backup: https://learn.microsoft.com/azure/backup/backup-azure-enhanced-soft-delete-configure-manage

Secure by default with soft delete: https://learn.microsoft.com/azure/backup/secure-by-default

Manage immutable vault operations: https://learn.microsoft.com/azure/backup/backup-azure-immutable-vault-how-to-manage

Create an Azure support request: https://learn.microsoft.com/azure/azure-portal/supportability/how-to-create-azure-support-request

Cancel and delete an Azure subscription: https://learn.microsoft.com/azure/cost-management-billing/manage/cancel-azure-subscription

I hope this is helpful. Please! Do not hesitate to let me know if you have any other questions, steps or clarifications.

Please do not close the thread by upvoting and accepting the answer if any part of it is helpful.
笹川浩 40 Reputation points

2026-07-02T01:06:48.53+00:00
I followed the steps below to upgrade the non-FIPS signing key, and all steps were completed without any errors. https://learn.microsoft.com/en-us/entra/verified-id/signing-key-upgrade#upgrading-the-signing-key

When I issued a VC after upgrading the non-FIPS signing key, three [OperationName=KeySign] entries were recorded in the Key Vault AuditEvent log. (Image attached)

In those logs, two [KeySign] operations were first executed by the [Verifiable Credential Service Request], followed by one [KeySign] operation executed by the [Verifiable Credentials Service].

The first two [KeySign] operations executed by the [Verifiable Credential Service Request] appear to have been signed using [ES256] with the newly upgraded signing key.

On the other hand, the last [KeySign] operation executed by the [Verifiable Credentials Service] appears to have been signed using the old non-FIPS signing key with [ES256K].

As a result, the VCs that were actually issued were signed using an old non-FIPS signing key.

Note, that since we need to continue verifying previously issued VCs, the old non-FIPS signing key must be kept in Key Vault without being disabled.

[Question 1] Even after upgrading the signing key, an old non-FIPS signing key is still being used. Is this a problem? Does this mean the signing key upgrade was successful?

[Question 2] According to Microsoft's announcement, non-FIPS signing keys will be discontinued at July 1, 2026. Why are they still being used? When will non-FIPS signing keys actually be discontinued? KeyVault-AuditEvent-KeySign.png
Moosa Khan 695 Reputation points Microsoft External Staff Moderator

2026-07-16T20:15:23.8+00:00

Hello 笹川浩,

Following up to see if the information provided was helpful please let me know if you have questions.
Moosa Khan 695 Reputation points Microsoft External Staff Moderator

2026-07-21T00:19:02.1766667+00:00

Hello 笹川浩,

Following up to see if the information provided was helpful please let me know if you have questions.

2 answers

Your answer

Shubham Sharma 17,930 Reputation points Microsoft External Staff Moderator

2026-06-24T07:42:42.6733333+00:00

笹川浩

Following up to check if the resolution provided was helpful. Let us know if you need any further assistance.
笹川浩 40 Reputation points

2026-07-02T01:06:48.53+00:00

I followed the steps below to upgrade the non-FIPS signing key, and all steps were completed without any errors. https://learn.microsoft.com/en-us/entra/verified-id/signing-key-upgrade#upgrading-the-signing-key

When I issued a VC after upgrading the non-FIPS signing key, three [OperationName=KeySign] entries were recorded in the Key Vault AuditEvent log. (Image attached)

In those logs, two [KeySign] operations were first executed by the [Verifiable Credential Service Request], followed by one [KeySign] operation executed by the [Verifiable Credentials Service].

The first two [KeySign] operations executed by the [Verifiable Credential Service Request] appear to have been signed using [ES256] with the newly upgraded signing key.

On the other hand, the last [KeySign] operation executed by the [Verifiable Credentials Service] appears to have been signed using the old non-FIPS signing key with [ES256K].

As a result, the VCs that were actually issued were signed using an old non-FIPS signing key.

Note, that since we need to continue verifying previously issued VCs, the old non-FIPS signing key must be kept in Key Vault without being disabled.

[Question 1] Even after upgrading the signing key, an old non-FIPS signing key is still being used. Is this a problem? Does this mean the signing key upgrade was successful?

[Question 2] According to Microsoft's announcement, non-FIPS signing keys will be discontinued at July 1, 2026. Why are they still being used? When will non-FIPS signing keys actually be discontinued? KeyVault-AuditEvent-KeySign.png
Moosa Khan 695 Reputation points Microsoft External Staff Moderator

2026-07-16T20:15:23.8+00:00

Hello 笹川浩,

Following up to see if the information provided was helpful please let me know if you have questions.
Moosa Khan 695 Reputation points Microsoft External Staff Moderator

2026-07-21T00:19:02.1766667+00:00

Hello 笹川浩,

Following up to see if the information provided was helpful please let me know if you have questions.

Answer 1

hi 笹川浩 & thx for sharing urs issue here at Q&A portal,

from what you've shared, it looks like the upgrade completed only partially. The DID document has been updated correctly, the new P-256 key is present in the signingKeys array, didDocumentStatus is published, and the did-configuration.json JWT is already being signed with ES256. That suggests the DID publication side of the migration succeeded. The concerning part is that newly issued VCs are still being signed with ES256K, and the Azure Portal continues to show the old signing key identifier. If newly issued credentials still reference the original P-256K key, then the issuer hasn't switched to the new signing key yet.

I'm not really aware of any customer-facing operation that forces that final switchover. Based on the current behavior, I wouldn't assume the service will automatically start using the new key on July 1. Given the retirement of P-256K, I'd recommend opening a Microsoft support case before that date and asking the Verified ID team to verify the signing key state on the backend.

When opening the case, include the authority ID, the output from GET /v1.0/verifiableCredentials/authorities/{authorityId}, the DID document, the did-configuration.json JWT showing ES256, and an example of a newly issued VC that is still signed with ES256K. That should give the product team enough information to determine whether this is an incomplete migration or a backend issue preventing the issuer from switching to the new signing key.

rgds,

Alex

&

If my answer was helpful pls mark it and additional thx if u follow me at Q&A portal

and at my blog https://ctrlaltdel.blog/

Answer 2

Hello 笹川浩,

Thank you for the additional details and the Key Vault audit logs.

Based on the information shared, the signing key upgrade appears to have completed successfully from a configuration perspective:

The new P-256 signing key is present in the signingKeys collection.
The DID document is published and contains both verification keys.
The did-configuration.json JWT is signed using the new P-256 key (alg: ES256).

However, the audit logs and issued VC headers indicate that credential issuance is still using the legacy P-256K signing key (alg: ES256K).

Since the old key must remain available to support validation of previously issued credentials, disabling or deleting the legacy key is not a viable option in this scenario.

At this point, the behavior suggests that the Verified ID issuance service is still referencing the legacy signing key despite the successful key upgrade configuration. We recommend engagement with the Product Group to verify:

Whether the signing key upgrade has been fully applied on the service side.
Whether any additional synchronization or backend processing is required.
The expected timeline and behavior for migration away from legacy P-256K signing keys after the retirement date.

Could you also confirm whether newly issued credentials are still consistently showing alg: ES256K after re-running the synchronization process and validating the latest published DID document?

We will review further once we have confirmation from the Product Group regarding the expected post-upgrade issuance behavior.

Thanks,
Moosa Khan