Skip to content

Key-Encryption Key Already Destroyed

URI: https://docs.ankatech.co/errors/kek-destruction-already-destroyed
HTTP Status: 409 Conflict

When you see this

A platform administrator asked to cancel the pending destruction of a tenant's key-encryption key, and the cancel was refused. Nothing was changed.

A tenant key-encryption key is destroyed at its provider or HSM, never only in the platform's records. A destruction request moves a RETIRED key to PENDING_DESTRUCTION, and the key becomes DESTROYED only once a read of the provider confirms it gone. Until then a destruction can be cancelled while the key object still exists, which returns the key to RETIRED.

Common Causes

  • The provider's waiting period ended and the key no longer exists.
  • The key is on an HSM (its lineage entry's carrierFamily is PKCS11): it is destroyed at once, so it is normally already gone when the destruction request answers. Only when the HSM gave no answer to the destruction can the object still be on the token; a cancel that finds it there succeeds and returns the key to RETIRED.

This refusal changes nothing: the key stays PENDING_DESTRUCTION until the destruction poll records it DESTROYED. The platform also cancels at the provider by itself when a cancel was recorded while a destruction request's provider call was still running. When that second cancel finds the key already destroyed, the key's entries move from RETIRED to DESTROYED, audited kek-destruction.confirmed-out-of-band, so the platform never shows a key RETIRED that its provider no longer holds.

Response Example

{
  "type": "https://docs.ankatech.co/errors/kek-destruction-already-destroyed",
  "title": "Key-Encryption Key Already Destroyed",
  "status": 409,
  "detail": "The provider has destroyed the key-encryption key; its destruction can no longer be cancelled.",
  "instance": "/api/v3/admin/platform/tenants/8f14e45f-ceea-467a-9575-0d5b2a1f3c11/key-custody/keks/3c1f7a9e-2b44-4e0d-8f6a-91d2c7b5e0aa/cancel-destruction",
  "timestamp": 1793696400,
  "extensions": {
    "requestId": "9c41e7a2-5b08-4d3f-a6e1-2f7c90b4d815"
  }
}

Content-Type: application/problem+json — the response follows RFC 9457 Problem Details.

How to Resolve

  1. Nothing can bring the key back. The destruction poll records the key DESTROYED at its next pass. Only while destructionDueAt still equals destructionRequestedAt does it wait until the request is more than 170 seconds old.

For full schema definitions, examples, and interactive testing, see the Developer Hub Reference.