Skip to content

Key-Encryption Key Destruction In Flight

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

When you see this

A platform administrator asked to cancel the pending destruction of a tenant's key-encryption key while the destruction was executing: its provider had been called and the provider's answer was not recorded yet. 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 calls no provider: the platform holds the destruction for the deployment's waiting period (30 days by default), and until it ends a cancel returns the key to RETIRED with no provider call. When the period ends the platform checks the key again and only then asks its provider or HSM to destroy it; the key becomes DESTROYED only once a read of the provider confirms it gone. Until then the destruction can be cancelled while the key object still exists, which returns the key to RETIRED.

Common Causes

  • While the waiting period runs, no provider has been called and a cancel is never refused this way.
  • When the period ends, the destruction pass records its provider call before it makes it. From then until the provider's answer is recorded, the destruction is executing, and every cancel is refused this way, however long that takes: no cancel can be recorded between a provider call and its answer.
  • On a Cloud KMS key, the answer is the provider's due date. On an HSM, it is the destruction of the object, so once it is recorded a cancel is normally refused kek-destruction-already-destroyed.
  • When the call's answer is never recorded (the provider gave no usable answer, or the service stopped during the call), the destruction pass reads the provider once the call can no longer be running: a key destroyed is recorded destroyed, a destruction scheduled is recorded with its due date, and a key the provider still holds with nothing scheduled returns the order to held and due, to be executed again with a fresh recount. From then on the cancel is no longer refused this way.

Response Example

{
  "type": "https://docs.ankatech.co/errors/kek-destruction-in-flight",
  "title": "Key-Encryption Key Destruction In Flight",
  "status": 409,
  "detail": "The destruction of this key-encryption key was sent to its provider and the provider's answer is not recorded yet. It cannot be cancelled until that answer is recorded. Nothing was changed.",
  "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. Read the lineage entry again later. Once the provider's answer is recorded (on a Cloud KMS, destructionDueAt is the provider's due date), ask for the cancel again.

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