Clerk Changelog

An Organization can now have more than one enterprise connection. Previously, creating a second SAML or OIDC connection for an Organization that already had one failed with organization_already_has_sso_connection. That limit is gone across the Clerk Dashboard⁠ and the Backend API⁠.

Why this matters

Some enterprise customers use more than one identity provider (IdP). This happens after an acquisition, during a migration from one IdP to another, or when subsidiaries and contractors sign in through separate providers. Before, each connection needed its own Organization. Now every connection can point to the same Organization, each with its own domain, protocol, and settings.

Directory Sync follows

Because each enterprise connection can have its own Directory Sync, a single Organization can now be fed by several directories, and the same person can be managed by more than one of them.

Clerk tracks each directory's view of a user separately:

• A user stays active while at least one enabled directory reports them as active. Clerk deactivates the user and revokes their sessions only when every enabled directory that manages them has deprovisioned them.
• Organization membership and Role mapping follow the directories that still grant access. Deprovisioning from one directory withdraws only that directory's grant. The membership is deleted only when no directory grants it anymore.
• Disabling or deleting a directory withdraws the memberships it granted without waiting for the IdP to sync. The recalculation runs in the background. Each affected user's status is recalculated from the remaining enabled directories: they are deactivated only if every one of those has deprovisioned them, and if none remain their status doesn't change.

Get started

In the Clerk Dashboard, navigate to the SSO connections⁠ page and add a connection for an Organization that already has one. Read the Organization-level Enterprise SSO and Directory Sync docs to learn more.

Client ID Metadata Documents⁠ (CIMD) are now generally available for all Clerk applications.

A compatible client uses an HTTPS URL as its client_id. Clerk fetches the metadata document at that URL and validates the client's identity and redirect URIs. This gives MCP and other public OAuth clients a stable identity without a pre-issued client ID, client secret, or Dynamic Client Registration.

What's changed since the beta

• Available everywhere. CIMD settings now appear on the OAuth applications⁠ settings page for every application.
• Off by default. Nothing changes for your existing OAuth flows until you enable Publish CIMD support.
• Same admission controls. Explicitly allow clients by Client ID URL, choose their scopes, review implicitly allowed clients, and set Client admission to Pre-registered clients only to restrict flows to clients you've reviewed.

Get started

1. In the Clerk Dashboard, navigate to the OAuth applications settings⁠ page.
2. Under Client onboarding, enable Publish CIMD support to publish CIMD in your authorization server metadata.
3. Optionally, set Client admission to Pre-registered clients only and add the clients you trust from the Applications tab.

Read Manage OAuth clients with Client ID Metadata Documents for the full guide, including metadata requirements, PKCE, and client admission policies.

Application Logs⁠ now record delivery events for SMS messages sent by Clerk, including phone verification codes, OTPs, and password reset codes. When a user reports a missing code, these events show whether the message was accepted, delivered, rejected, or left unconfirmed.

The delivery lifecycle

Each message can generate several event types, helping you distinguish between a send failure, a delivery rejection, and an unknown outcome:

• sms.accepted — the delivery provider accepted the message (not yet proof it reached the phone)
• sms.delivered — the carrier confirmed delivery to the handset
• sms.failed — the send stopped before handoff, or the provider rejected it
• sms.undeliverable — the carrier could not deliver it after accepting it
• sms.unconfirmed — the provider reported an unknown delivery outcome

Failure events carry a normalized reason — like invalid_phone_number, destination_unreachable, or rate_limited — so a failure tells you whether to fix the number, wait out a provider limit, or adjust your own configuration. The message body, verification code, and provider identity are never included.

Filtering and search

The dedicated SMS logs view⁠ lists these events, where you can filter by a single event type like sms.failed or by the destination phone number to pull up one recipient's history. Every event for a single message shares a trace, so you can follow its whole timeline end to end.

Get started

SMS events are available on all plans as part of Application Logs. Retention varies by plan. See the pricing page for details. Open the SMS logs view⁠ to investigate SMS delivery, or Application Logs⁠ to view SMS events alongside other application events. Read the documentation to learn more.

Going forward

SMS delivery events build on Clerk's ongoing observability work alongside Admin Logs and Email Logs.

The grant provides a standards-based flow for applications that cannot open a browser or easily accept text input. CLIs, TVs, game consoles, and other devices can ask a user to approve access from a browser-capable device without entering their credentials on the original device.

What's new

• Device authorization and token polling. Clients request a device code, display a short user code and verification URL, then poll for tokens at the interval Clerk provides.
• Public and confidential clients. Public clients send only their Client ID, while confidential clients authenticate with their Client ID and Client Secret.
• Hosted user verification. Clerk's Account Portal displays the OAuth application, requested scopes, Organization selection when applicable, and equally visible approve and deny actions.
• Automatic discovery. Clerk advertises device_authorization_endpoint and urn:ietf:params:oauth:grant-type:device_code through OAuth 2.0 and OpenID Connect metadata when Device Authorization Grant is available and the verification page is reachable.

Device Authorization Grant follows RFC 8628⁠ and supports the same Clerk OAuth scopes, tokens, consent context, and Organization claims as the Authorization Code Flow. It does not use Proof Key for Code Exchange (PKCE) or redirect URIs.

See Use OAuth Device Authorization Grant to configure an OAuth application, implement device and token requests, and handle polling responses.

You can now customize how long a successful sign-in or reverification remains valid for Clerk-protected sensitive actions. Set the reverification window between 1 and 10 minutes. The default remains 10 minutes.

A shorter window can prompt users to verify their credentials more often before actions such as changing a password, adding and removing an email address, revoking a session, or deleting an account.

To configure the window, open the Sessions⁠ page in the Clerk Dashboard. Under Session lifetime, set Reverification window to the number of minutes you want, between 1 and 10.

This setting applies to sensitive actions protected by Clerk. For sensitive actions unique to your application, define the required window in your application. See the reverification guide for details.

The Clerk Dashboard now has Admin Logs⁠: an audit trail of the configuration changes made across your workspace — from the Dashboard, the Backend API, or the Platform API. Admin Logs track actions like creating OAuth applications, updating instance settings, rotating secrets, and managing Roles and Permissions, and more.

Filtering and search

The logs page shows a reverse-chronological feed of events. Each entry lists a description of what happened (e.g., "Brandon Romano created a user"), the application it happened in (when applicable), the originating IP address with a country flag (when available), and the timestamp. Select any entry to see its full details.

You can narrow the feed with filters:

• Event type — Filter by event type (e.g., oauth_application.updated, domain.created). Supports trailing wildcards (e.g., oauth_application.*).
• Instance — Filter by the instance the action targeted.
• Application — Filter by the application the action targeted.
• Actor — Filter by the actor that triggered the event.
• IP address — Filter by the IP address the action originated from.
• Time range — Scope results to a specific time window.

Get started

Admin Logs are available on the Business and Enterprise plans — see the pricing page for details. They start recording on August 24, 2026; actions before that date aren't included. Open Admin Logs⁠ in the Clerk Dashboard, or read the docs.

Going forward

Admin Logs join Application Logs and Email Logs in Clerk's ongoing observability work.