Skip to main content

​
Turning a key off

Disable

POST /v1/keys/{key_id}/disable refuses every crypto operation with 409 KMS_KEY_DISABLED while leaving the material intact. This is the reversible move: stop a suspected-compromised key now, keep the ability to read historical ciphertext after re-enabling.

Schedule deletion

POST /v1/keys/{key_id}/schedule-deletion starts a countdown. recovery_window_days is 7 to 30, defaulting to 7. The key refuses crypto operations for the whole window, then the material and the record are destroyed.
Open the key from KMS. Disable and Enable are in the header. Schedule key deletion sits in the Danger zone on the Settings tab: it takes a Recovery window (days) and makes you type the key’s name back before Schedule Deletion is accepted.
Deletion destroys the key material and makes ciphertext encrypted under it permanently unreadable. Basaltic refuses to schedule deletion while platform resources or retained encrypted data still use the key. Data encrypted directly through the KMS API and stored outside Basaltic is not tracked; check those dependencies before scheduling deletion.
​
timestamp | null
When deletion was requested. Null for active keys and keys whose deletion was scheduled before request times were recorded.
​
timestamp
The deadline for cancelling deletion. Existing deadlines are preserved.
​
integer, 7–30 | null
The chosen window, defaulting to 7 on scheduling. Null for active keys and historical pending deletions whose chosen window is unknown.
KMS mirrors AWS KMS’s 7-day minimum because its deletion affects every ciphertext protected by the key. Secrets permits 1 day because its deletion is limited to that secret. Both maximums are 30 days.

​
Cancelling

A key inside the window shows Cancel Deletion in its header, where Disable or Enable would otherwise be.
Cancelling exits the window at any point before scheduled_purge_at.
A cancelled key comes back disabled, not enabled. Nothing starts working again until you explicitly call enable. The window was entered because someone wanted the key gone; recovering it should not silently restore traffic to it. This deliberately matches AWS KMS; restoring a secret, by comparison, puts it straight back into service. Cancellation clears all three deletion fields.
Two consequences of how quota is accounted are worth knowing before you rely on cancelling:
  • Scheduling a deletion releases the key’s quota immediately, so you can create a replacement inside the same limit without waiting out the window.
  • Cancelling therefore has to take that quota back, and fails with 403 QUOTA_EXCEEDED if your account is now at its limit. If you created a replacement key, free a slot before you cancel.
A key in pending_deletion no longer reserves its name, so a new key can be created with the same one right away. Because a KMS CRN is built from the name (crn:kms:<region>:<account>:key/<name>), the old key and the new key then share a CRN, and an IAM policy naming it matches both. Give the replacement a different name if that distinction matters to your policies.
Deletion destroys every material version of the key. Rotation does not shorten the deletion window or remove historical material.