Skip to content

Key-Encryption Key Destruction Already Requested

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

When you see this

A platform administrator asked to destroy one of a tenant's retired key-encryption keys at the provider or HSM that holds it, and the request was refused. The key keeps its status, the provider was not asked to destroy anything, and the refusal is recorded in the audit trail as DENIED.

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 the destruction can be cancelled, which returns the key to RETIRED.

Common Causes

  • The key is PENDING_DESTRUCTION: its provider already accepted a destruction and its waiting period is running.
  • The key is DESTROYED: its provider confirmed the destruction.

Response Example

{
  "type": "https://docs.ankatech.co/errors/kek-destruction-already-requested",
  "title": "Key-Encryption Key Destruction Already Requested",
  "status": 409,
  "detail": "The destruction of this key-encryption key was already requested. Nothing was changed.",
  "instance": "/api/v3/admin/platform/tenants/8f14e45f-ceea-467a-9575-0d5b2a1f3c11/key-custody/keks/3c1f7a9e-2b44-4e0d-8f6a-91d2c7b5e0aa/destroy",
  "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. Read the lineage entry: destructionRequestedAt and destructionDueAt show the pending destruction, destroyedAt a confirmed one.
  2. Nothing else is needed: the platform confirms a pending destruction by reading the provider's state on its own.

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