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.

Source-profile availability depends on the provider and deployment

Manual Client Vault public keys and generic OIDC JWKS are documented common paths. A GitHub Actions CI OIDC source has also been observed serving an active workload in the current deployment. Other selectable provider profiles need their own verified source revision, policy, proof, and release evidence before they can be called ready for a tenant.

What it affects: assuming a selectable source or one serving provider example establishes support for every provider and tenant.
Safe operator posture: use the OIDC JWKS runbook or manual Client Vault registration as common first paths; verify provider-specific readiness against the selected source and runtime before using it.
Tracked in: Trust Anchor source availability.

Checkout return is not new-site entitlement

The current console can present guarded provider checkout and customer portal actions. Their availability depends on the tenant and subscription state. A completed browser return does not itself prove that new-site capacity is active.

What it affects: attempting to create a new Auth Site before the provider event has been reconciled into the canonical subscription and effective Feature Grants.
Safe operator posture: check the Billing grant and tenant-wide Auth Site capacity panels after the normal owner flow; never infer a free slot from an existing grandfathered site.
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.