Managed Tier Not Configured

URI: https://docs.ankatech.co/errors/managed-tier-not-configured
HTTP Status: 409 Conflict

When you see this

A tenant whose licensed Edition routes it to an ANKA-managed tier needs its own key-encryption key on that tier's carrier: the PKCS#11 token, or the cloud account and key ring, that the tier is configured on. This refusal says the tier cannot be addressed, so no key-encryption key can be placed on it.

The deployment's own key-protection backend is not at fault: it is bound, and tenants that inherit it are unaffected. What is missing is the configuration of the one tier named in the response. That is why this is a different problem type from Key Protection Backend Not Configured, which states that the environment has no backend and points at the deployment setup.

The refusal is raised before anything is written: no Edition is assigned, no custody row is created, no audit row is filed and no key object exists on the carrier. Retrying the same request produces the same response until the tier is configured, so no Retry-After header is sent.

Common Causes

• Assigning an Edition (PUT /api/v3/admin/platform/tenants/{tenantId}/key-backend/edition) onto a tier that was never declared, or that was declared and never bound. The assign establishes the tenant's key on the tier before the Edition is written, so an unconfigured tier is refused at the assignment rather than at the tenant's first key create.
• The tier's PKCS#11 or Cloud KMS coordinates are incomplete.
• The tier is declared on a Cloud KMS family but no console-managed credential has been established for it.
• The tier sits on a PKCS#11 token that the deployment's PKCS#11 module does not serve. On SaaS, ENTERPRISE defaults to cloudhsm when its tier was never declared.
• A key create, a cryptographic operation, a KEK rotation, a custody move or a KEK destruction reaches a tier whose configuration was removed after tenants were placed on it.

Response Example

{
  "type": "https://docs.ankatech.co/errors/managed-tier-not-configured",
  "title": "Managed tier not configured",
  "status": 409,
  "detail": "The ENTERPRISE managed key-protection tier is not configured, so it cannot hold a tenant's key-encryption key. Configure the tier, then retry.",
  "instance": "/api/v3/admin/platform/tenants/7c9e6679-7425-40de-944b-e07fc1f90ae7/key-backend/edition",
  "timestamp": "2026-11-02T15:43:25.841Z",
  "extensions": {
    "tier": "ENTERPRISE",
    "requestId": "550e8400-e29b-41d4-a716-446655440000"
  }
}

Content-Type: application/problem+json: the response follows RFC 9457 Problem Details.

The body names the tier and nothing else. Branch on extensions.tier rather than parsing detail. It carries no backend token, coordinate, credential reference, endpoint, token label, PIN path, carrier string or tenant identifier, and no setupState: the deployment setup has nothing left to do.

How to Resolve

1. Open the ANKA-managed backend tiers surface in the Admin Console and find the tier named in extensions.tier. See ANKA-managed backend^*.
2. Declare the tier on a backend this deployment can reach, complete its coordinates and, on a Cloud KMS family, establish its credential. Then bind it.
3. Retry the request. For an Edition assignment, assign the Edition again.
4. If the tier should not be offered on this deployment, assign a different Edition, or give the tenant its own BYOK backend^*, which does not use the managed tier.

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