Skip to content

Tenant's Own Key Not Destroyed

URI: https://docs.ankatech.co/errors/kek-destruction-tenant-own-key
HTTP Status: 422 Unprocessable Content

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 a key the tenant declared in its own key management service. The platform never deletes, disables or schedules the deletion of a customer's key: retiring it retires only the platform's reference.

Response Example

{
  "type": "https://docs.ankatech.co/errors/kek-destruction-tenant-own-key",
  "title": "Tenant's Own Key Not Destroyed",
  "status": 422,
  "detail": "This key-encryption key is the tenant's own key at its key management service; the platform never destroys it. 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. The tenant destroys its own key, when it chooses, with its provider's own tools, once nothing is wrapped under it.

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