Identity SSO and Plan Availability
Technical disclosure. Use your browser’s print command to save this complete version as PDF.
This statement answers which authentication capabilities a buyer can rely on. It is based on the QCM production source reviewed on 19 October 2026. Commercial plan names do not create an authentication capability that has not been implemented and validated.
| Capability | Current availability | Plan treatment |
|---|---|---|
| QCM email and password login | Available; the reviewed authentication provider is Credentials. | Standard QCM account access. |
| Workspace roles and membership | Available; server-side checks for owner, admin, editor and viewer. | Applies to provisioned workspaces. |
| Session expiry and revocation | Available; inactivity policy and server-side session controls. | Applies to QCM sessions. |
| Additional privileged verification | Implemented for designated sensitive actions. | Scope depends on the action; not universal MFA. |
| Customer SAML 2.0 SSO | Not available in the current QCM service. | Not included in any current QCM plan. |
| Customer OIDC federation | Implemented and protocol-tested; requires customer-specific IdP configuration and acceptance. | Corporate OIDC option expressly included in a business service order. |
| SCIM provisioning | Not implemented. Existing users and memberships are provisioned explicitly. | Not included in current plans. |
First party identity and corporate SSO
Customer corporate OIDC federation is implemented using Authorization Code, PKCE, state and nonce. Issuer and subject are explicitly bound to an existing QCM user and active workspace membership; email matching and automatic account creation are not permitted. The protocol test exercises signed test tokens and verifies rejection of invalid state, nonce, issuer and unknown identity. It is distinct from the Qedara first-party identity handoff.
Buyer decision and change control
Availability: operator-assisted Corporate OIDC SSO can be included in a business service order. It is not automatically included in an existing subscription or an unverified Enterprise price tier. Activation requires the customer administrator to configure its identity provider, supply the client configuration securely, approve user bindings and complete a live acceptance test for that connection. No customer IdP connection is represented as already activated.
SSO can be required for explicitly bound users; their password sign-in and credential sessions are then refused. Binding changes revoke existing sessions. Administrators must remove active memberships when access ends. Emergency recovery is an authenticated operator procedure, not a self-service bypass. SAML, SCIM, automatic domain-wide enforcement and universal MFA are not claimed; MFA policy belongs to the configured IdP.