Puts the configured deployment key-protection backend into force. This is the only step of the three that reaches the backend at all: configuration records coordinates and credential proves a credential, while this operation is where the platform commits to serving what was configured.

It refuses before it reaches. A platform already bound to a different backend is a 409, evaluated first, with the credential never unsealed and no connection opened — once key material has been wrapped, re-pointing the backend orphans it permanently, and that is not recoverable by any later action. A descriptor with no sealed credential is a 422 carrying DESCRIPTOR_INVALID: nothing declined anything, so the fix is the declaration rather than the cloud account. Both refusals contact nothing, which is what makes them safe to retry.

A failure that the backend itself produced is a 422 whose extensions.reason names the cause from the closed self-test vocabulary — refused, unreachable, timed out, or a round trip that did not reproduce what it wrapped. It never carries an ARN, a resource path, a vault URL, a region, an account id or a vendor message.

On the PKCS#11 family the round trip CREATES A TEMPORARY KEY on the declared security domain, and destroys it. Stated here so it is known before a backend is declared rather than discovered later in an object listing. On a from-scratch token there is nothing to wrap under — the per-tenant keys are created by the NEXT phase — so the self-test generates one AES-256 key that is sensitive and non-extractable, resolves it by its own label, confirms from the object's own attributes that it cannot leave the token, wraps and unwraps under it, and destroys it. The label is random per invocation and sits outside the tenant key namespace; the key is destroyed on every path, including every failing one. If the destruction itself fails the activation still succeeds — an undeleted temporary object is litter, not a custody violation — and the response carries undeletedSelfTestObjectLabel so it can be removed out of band. There is no option to skip this test: it is the only observation of the backend on the whole path, and the per-tenant provisioning below performs no round trip of its own precisely because this one ran.

The two backend-facing phases are attributed separately. The round trip exercises wrap and unwrap; the per-tenant key provisioning exercises key CREATION, and its 422 names create-key as the failing capability class. A credential granted Encrypt and Decrypt but not CreateKey passes the first and fails the second, and one undifferentiated failure would send an operator to widen the wrong policy.

A partial run is reconciled, not rolled back. Keys already created on the backend stay created and their metadata rows stay committed — a rolled-back row would leave a real, billable key that nothing names. Re-run after correcting the cause: existing keys are adopted without the backend being contacted for them, and tenantKeksProvisioned reaches its full value.

An existing key is adopted only by the backend that created it. A bootstrap tenant whose key-encryption key was created by a DIFFERENT backend is a 422 under its own type, deployment-backend-kek-provider-mismatch. Nothing is adopted, nothing is provisioned and no declaration is committed, and the route out is to withdraw the declaration and then activate. Without it the platform could declare one backend while a bootstrap tenant key lived on another, which becomes permanent the moment the deployment reads as bound.

On every declarable backend family this operation also COMPLETES first-run provisioning, so a successful activation leaves the platform administrable with no further step. There is nothing left for an operator to press: the keys exist, the declaration is committed, and a separate Complete setup action would perform no work. This used to exclude the PKCS#11 family, on the ground that its three moments - declare, a host-side bind command, and POST /setup/complete - were genuinely distinct. Console-first HSM activation removes the middle one, so excluding PKCS#11 would now leave an operator who completed every console step on an unprovisioned platform. It is still deliberately NOT done when the caller is the environment HOST rather than a platform operator, because the host is admitted to this path to create key material, not to declare the platform administrable. Completion is idempotent, so re-running activation adds no second audit record.

ROOT-only (platform.bootstrap).