Do you support our identity provider — SAML SSO, SCIM provisioning, MFA enforcement? I will not run another password silo.?

The full executive answer

Yes, and by design we never built a password silo to begin with. All authentication is delegated to Clerk, a dedicated identity platform: at the enterprise tier that gives you SAML single sign-on against your existing identity provider — Okta, Entra ID, whatever you run — and SCIM provisioning, which is the standard (RFC 7644) for your IT team to create, update and deactivate our accounts automatically from your directory. Joiner-mover-leaver flows are driven by your HR-connected directory, not by anyone remembering to click deactivate in our admin panel. MFA policy rides your IdP's enforcement.

Under the hood this matters for security, not just convenience: every API request is authorised from the verified identity token — the organisation a user belongs to is derived server-side from their authenticated session, never from anything the client sends. So SSO is not a login veneer; it is the root of the tenant-isolation chain. We also have SSO-provisioning logic in the codebase that maps your directory groups onto our roles — admin, contributor, viewer — so access follows your org chart.

Session controls — deactivation, subscription-state gating, role checks — are enforced in our standard API middleware on every one of the 414 endpoints, which aligns with OWASP ASVS chapter 3 session-management requirements. Happy to have your identity team run a provisioning and deprovisioning test in the pilot.