Key Protection Backend Not Configured
URI: https://docs.ankatech.co/errors/key-protection-backend-not-configured HTTP Status: 409 Conflict
When you see this
The deployment has not finished binding the backend that protects key material, so no key can be created, imported, rotated or used. The operation was refused before anything was written — no key material was persisted and no partial state was left behind.
This is a state of the deployment, not of your request. Retrying an identical request will produce an identical response until an operator completes the setup, which is why no Retry-After header is sent.
Common Causes
- The environment was created but the key-protection backend has not been activated yet.
- The declared backend was never bound, so no key-encryption key exists for it to use.
- A tenant was assigned to a backend tier the deployment does not offer.
- The platform's internal record naming the tenant's key-encryption key is absent — never published, or lost with the cache store and not yet republished. An Admin API restart, or the tenant's next key provisioning, republishes it; the platform never guesses the key in its place.
- Assigning an Edition (
PUT /api/v3/admin/platform/tenants/{tenantId}/key-backend/edition), when the target ANKA-managed tier is not bound. The assign establishes the tenant's own key-encryption key on that tier's carrier before the Edition is written, so an unbound tier is refused at the assignment rather than at the tenant's first key create. Nothing is written: no Edition, no custody row, no audit row, no key object. - The target tier is declared on a Cloud KMS family but holds no sealed credential. The assign provisions the tenant's own key in the tier's account under the tier's credential, so a tier that was declared but never credentialled is refused here — before the capacity pre-check and before any column is written. The family itself is not a cause: a tier on
aws-kms,gcp-kms,gcp-kms-hsm,azure-kvorazure-kv-mhsmprovisions per-tenant custody exactly as a PKCS#11 tier does, and on a default deployment PROFESSIONAL (aws-kms) is assignable.
How to Resolve
- Do not retry on a timer. This condition does not clear on its own.
- If you administer the deployment, complete the setup for the declared backend and retry afterwards.
- If you do not, report the error to whoever operates the deployment — the response body carries a
correlationIdthat lets them find the corresponding server-side entry.
For API clients: this response carries the extension member
setupStatewith the valueKEY_BACKEND_UNCONFIGURED. A console or SDK can read it to route an operator into the setup flow rather than showing a generic conflict. It appears on this type only — the sibling Key Protection Backend Misconfigured deliberately omits it, because there the backend is configured and a setup wizard would have nothing to do.
Related
- Key Protection Backend Unavailable — bound, but momentarily unreachable
- Key Protection Backend Misconfigured — configured, but not usable as configured