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 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
- 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
- Name a customer tenant's key-encryption key.
Related Errors
- Tenant's Own Key Not Destroyed (422) - The key-encryption key is the tenant's own key at its key management service, which the platform never destroys
- Key Held On The Deployment Backend (422) - The key-encryption key is on a Cloud KMS deployment backend, in the customer's account
For full schema definitions, examples, and interactive testing, see the Developer Hub Reference.