Key Destruction

Applies to: the Key Management SDK, the Key Management CLI and the Admin Console
Version: 3.4.0

A key, or one version of it, is destroyed in three steps that no single principal can complete alone:

1. Request. A workload (through the Key Management SDK or CLI) or a person (in the Admin Console) requests the destruction. The request opens a quorum request; nothing about the key changes yet.
2. Approval. A person other than the requester approves the request in the Admin Console, after authenticating again. The approval schedules the destruction.
3. Execution. When the cooling-off period ends, the platform destroys exactly the approved material on its own. No caller runs the destruction.

1. Requesting a destruction

Both answer 202 Accepted with the quorum request and its Location, whether or not the tenant has a quorum approval policy: with no policy one approval is needed, and an enabled policy can require more. The SDK returns a QuorumRequestReceipt; the CLI prints the pending JSON and exits 0.

A version whose destruction would leave the key with no version outside a destruction is the destruction of the key: it is requested as the key's request, which needs admin.keys.mark-for-destruction and an ARCHIVED key.

The request is refused under a support-access impersonation session (403).

1.1 The cooling-off period

The request may name coolingOffDays, from 7 to 365. When it does not, the value comes from the first of:

1. the tenant lifecycle policy's destruction.coolingOffDefaultDays;
2. the deployment lifecycle policy's destruction.coolingOffDefaultDays;
3. the platform default, 30 days.

The period is counted from the approval, not from the request.

2. Approval

Approval and rejection are made in the Admin Console, by a person other than the requester, after the approver authenticates again. A break-glass session never decides a request. The Key Management SDK and CLI have no approve or reject operation; they read their own requests and withdraw them.

The request is approved for the key's versions as they stood when it was made. If a version is restored, added or destroyed before the approval, the request ends FAILED (quorum-target-changed) and a new request is needed.

On approval:

• every version the destruction covers becomes PENDING_DESTRUCTION, and the key reads PENDING_DESTRUCTION;
• a destruction order is scheduled for the approval instant plus the cooling-off period (eligibleFrom).

A key's destruction absorbs the orders its versions already wait in: those orders end CANCELLED with supersededBy naming the key's order. Absorbing never brings a version's destruction forward. The key's order runs at the later of its own eligibleFrom and the eligibleFrom of every order it absorbed.

While the destruction waits, no new encryption or signature uses the key, and decryption and verification of historical data remain available where the tenant's lifecycle policy allows them.

3. Execution

The platform's destruction executor looks for due orders every KEY_DESTRUCTION_EXECUTOR_POLL_INTERVAL (default PT5M, from PT1M to PT1H) and once at every start of the service. For a due order it destroys exactly the versions the approval covered:

• the private material is erased from the platform's active storage;
• the versions become DESTROYED, and for a key-level order the key becomes DELETED_LOGICAL, its terminal state;
• the key's metadata, public key and audit trail are kept;
• the order ends EXECUTED.

When the versions are no longer the approved ones, or cannot be erased, nothing is destroyed: the order ends FAILED with a reason, and it is never retried. Cancel the destruction and request it again.

3.1 A Key ID is never reused

A destroyed key's Key ID stays its own forever within the tenant. Creating or importing a key with a Key ID that any key of the tenant has ever held, destroyed keys included, is refused with 409 key-id-retired.

4. Cancelling

Cancelling restores every version of the cancelled order to the status it had before the approval, and a key reads ARCHIVED again. A later destruction needs a new request and a new approval.

Cancelling a version whose destruction was scheduled with the whole key cancels the key's order as a whole.

5. Destruction orders

GET /api/v3/admin/tenants/{tenantId}/keys/{kid}/destruction-orders (scope admin.keys.read; sdk.destruction().orders(kid), ankasecure-km destruction orders --kid <kid>) lists, newest first, what each approval scheduled:

A destruction request still waiting for approval is not an order yet; read it through the quorum request. A destroyed key keeps its orders.

6. Alerts

Both are platform alert conditions, routed to the platform's alert destinations.

Version: 3.4.0
Last updated: 2026-10-26