Skip to content

Tenant Holds The Deployment Key

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

When you see this

A platform administrator asked to destroy one of a tenant's retired key-encryption keys, or to cancel its pending destruction, and the call was refused. The key keeps its status and the provider was not asked to change anything; a refused destruction 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 tenant is one of the deployment's bootstrap tenants. Their key-encryption keys are the deployment's own, never retired by a custody operation, and never destroyed by one.

Response Example

{
  "type": "https://docs.ankatech.co/errors/kek-destruction-deployment-kek-tenant",
  "title": "Tenant Holds The Deployment Key",
  "status": 422,
  "detail": "This tenant's key-encryption keys are the deployment's own and are never destroyed by a key custody operation. 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. Name a customer tenant's key-encryption key.

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