Skip to content

Key-Encryption Key Carrier Not Bound

URI: https://docs.ankatech.co/errors/kek-destruction-carrier-not-bound
HTTP Status: 409 Conflict

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 key was created on a managed tier that has since been bound to another key management service, account, key ring or vault, so the tier's credential no longer addresses the key.

Response Example

{
  "type": "https://docs.ankatech.co/errors/kek-destruction-carrier-not-bound",
  "title": "Key-Encryption Key Carrier Not Bound",
  "status": 409,
  "detail": "The key management service the key-encryption key is held on is not the one its managed tier is bound to now, so the platform cannot reach the key. 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. Bind the tier back to the key management service that holds the key, or destroy the key with the provider's own tools and record the outcome with your operations team.

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