Availability and product boundaries

This page consolidates the current limitations and product boundaries the documentation refers to, in one place. Each entry states what the limitation affects, the safe operator posture, and where in the docs it is tracked. No dates or delivery promises are made here; when a limitation is lifted, the entry is removed and the tracking page is updated.

Recovery codes cannot be generated after passkey registration

Sign-in, passkey registration, invitation delivery and acceptance, and initial sign-in are supported. Recovery-code generation is a current limitation: an operator who registers a passkey cannot currently obtain recovery codes.

What it affects: account recoverability. Losing the passkey device without recovery codes risks losing operator access.
Safe operator posture: ensure every organization has more than one owner-capable operator before relying on passkey-only access, and do not treat a passkey as the sole credential for any account you cannot afford to lose.
Tracked in: Access, passkeys, and RBAC status.

Fine-grained role and scope enforcement is not currently supported

Scoped role and scope (RBAC) enforcement is not currently supported. The published role/scope model is target design (Planned), not enforced behavior. Current limitations of the console’s access surface include:

operators may see resources outside their intended scope,
denied access can render as a blank page rather than an explicit denial notice,
actions can fail silently with no feedback,
write forms can be reachable by read-only roles,
role-replacement semantics when an operator’s role changes are not defined,
feedback when an action requires stronger (step-up) authentication is limited.
What it affects: treating any role or scope as enforced.
Safe operator posture: treat console visibility and enabled buttons as not an authorization statement; grant the fewest roles possible; verify sensitive actions were actually denied/allowed via audit evidence rather than UI feedback.
Tracked in: Access, passkeys, and RBAC status.

Most Trust Anchor source profiles are not currently supported

Of the eight enrollment source profiles, Manual Client Vault public key and OIDC JWKS are supported. Kubernetes service-account OIDC, CI OIDC, SPIFFE JWT-SVID, AWS EC2 instance identity, GCP instance identity, and Azure instance identity are selectable in the console but not currently supported.

What it affects: planning production enrollment on any profile other than the two supported paths.
Safe operator posture: use the OIDC JWKS runbook or manual Client Vault registration; treat every other profile per its row in the matrix.
Tracked in: Trust Anchor source availability.

No self-service subscription or billing upgrade

Self-service subscription/billing upgrade — including a redirect to a provider checkout — is not currently available from the console.

What it affects: growing automated source capacity or changing packages without an out-of-band commercial step.
Safe operator posture: plan capacity ahead of need using the automated source capacity panel, and arrange allowance changes through your subscription contact.
Tracked in: Settings and Billing and Trust Anchors.

Pending/publishing states can lack a terminal explanation

Some pending or publishing states in the console can persist without a terminal explanation of what they are waiting for or whether they will ever complete. This is a current limitation.

What it affects: distinguishing “still propagating” from “stuck” from the state badge alone.
Safe operator posture: do not treat a long-lived pending/publishing badge as progress; cross-check the exact distribution and acknowledgement state in the Operate cockpit and the site’s readiness on Auth Sites before concluding either way.
Tracked in: Operate and Auth Sites.

Historical revocations lack exact acknowledgement records

Historical revocation records render under “Historical revocations — exact acknowledgement not recorded”: Control retains the record, but an exact activation acknowledgement was never captured for it.

What it affects: using historical revocation rows as propagation proof.
Safe operator posture: treat historical rows as history only; for anything that must be provably revoked, rely on current selected-target revocations that reached Completed / acknowledged with an exact acknowledgement match.
Tracked in: Operate — revocation propagation.

Older audit events lack fields emitted by newer adapters

Audit events recorded by older adapter versions may lack fields that newer adapters emit. Missing historical fields are version skew, not data corruption.

What it affects: uniform field-level queries across the full audit history.
Safe operator posture: interpret each event against the adapter version that emitted it; confirm the Helm rollout actually uses the intended adapter image before expecting the newer fields (image publication alone is insufficient).
Tracked in: Audit.

Release verification is a manually run gate

The runtime acceptance gate (make v01-acceptance) is a deterministic, local-only command an operator runs by hand; a green result is the canonical health definition, but nothing runs it for you. This is a product boundary.

What it affects: assuming a deployment was automatically verified.
Safe operator posture: run the gate yourself as part of any change, and record the green result as evidence.
Tracked in: Acceptance gate.