Clerk Changelog

Beginning January 18, 2027, Clerk will stop supporting CBC-mode SSL/TLS cipher suites on Clerk-managed subdomains, including clerk.example.com (Frontend API) and accounts.example.com (Account Portal). This is a breaking change for clients that can only negotiate a CBC cipher, but most applications will not be affected, since modern clients already negotiate stronger ciphers.

The change rolls out as certificates are renewed. Clerk certificates are valid for 90 days, so every affected subdomain will have moved to the new ciphers within a few months. New applications default to the new configuration starting January 18, 2027.

CBC-mode ciphers have a long history of practical attacks (POODLE⁠, BEAST⁠, and Lucky Thirteen⁠) and have been deprecated by browsers, operating systems, and the broader security community. Modern connections use AEAD⁠ cipher suites such as AES-GCM and ChaCha20-Poly1305, which avoid the entire class of padding-related attacks.

Affected cipher suites

• TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
• TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
• TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
• TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
• TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
• TLS_RSA_WITH_AES_128_CBC_SHA
• TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
• TLS_RSA_WITH_AES_256_CBC_SHA
• TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
• TLS_RSA_WITH_AES_128_CBC_SHA256
• TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384

After a subdomain rotates, clients that can only negotiate one of these ciphers will fail the TLS handshake with it. Any reasonably modern client (current browsers, mobile operating systems, and server runtimes) already prefers AEAD ciphers and is unaffected.

If you need continued CBC support, contact support@clerk.com.

You can now control the identifier Clerk sends to your identity provider (IdP) when a member starts a SAML sign-in. Configure the Login hint section on each SAML connection in the Clerk Dashboard⁠:

• Email address sends the member's email address. This is the default for named SAML providers.
• Custom attribute sends the value of a custom attribute that you select on the connection. Use this when your IdP identifies members with an employee ID, username, or another value instead of their email address.
• Off sends no login hint.

Custom SAML connections don't send a login hint until you select Email address or Custom attribute. Existing named SAML connections keep their email-address behavior unless you change the setting.

For setup steps and details about custom attributes, see the SAML login hint documentation.

When we released the CLI and then shipped clerk deploy, the goal was a single tool that both developers and agents could use to run Clerk end to end. CLI 2.0 pushes further into day-to-day workflows: testing webhooks and debugging as a specific user, all without leaving your terminal.

Test webhooks locally with clerk webhooks

A new command group gives you a self-contained, local webhooks toolkit — no linked project and no Platform API required:

• clerk webhooks listen: opens a relay tunnel and forwards deliveries to your local handler. Pass --token to pin a stable, shareable URL you can reuse across restarts.
• clerk webhooks verify: verifies a webhook signature offline (HMAC-SHA256), from a saved delivery or explicit header values — no network calls.
• clerk webhooks token: generates a relay token you can pipe straight into listen.

Debug as any user with clerk impersonate

clerk impersonate (alias clerk imp) creates a short-lived sign-in URL that logs you in as another user, so you can reproduce a report from their exact session. Target a user by ID or email, add --open to launch the URL straight away, and every impersonation is stamped with your account for auditing.

Run clerk imp with no arguments to pick a user interactively.

A refreshed interactive experience

Prompts, lists, and spinners have a new visual style, and interactive commands now end by clearly reflecting success, failure, or a paused cancellation — so it's always obvious how a run finished.

Built for agents

Every command in 2.0 respects the CLI's agent contract: stable error codes, stdout for data and stderr for UI, and no hidden interactive prompts in non-TTY contexts. clerk webhooks token prints a bare token to stdout so it pipes cleanly, and clerk impersonate resolves the target instance explicitly rather than silently defaulting.

Get started

Update to the latest CLI, then try any of the new commands:

See the CLI docs for the full command reference.

Just-in-time (JIT) provisioning can now be disabled per enterprise connection. By default, Clerk creates a user account the first time someone signs in through a SAML connection. With JIT provisioning disabled, sign-ins only succeed for users who already exist in your instance - anyone else is rejected instead of being auto-created. This is useful when your identity provider handles authentication but a separate system, such as Directory Sync (SCIM) or an internal admin flow, decides who gets an account.

Disable JIT provisioning

Open a SAML connection in the Clerk Dashboard⁠ and turn off Create users during sign-in in the connection's settings. The same control is available on the Backend API as a disable_jit field when updating a SAML connection or enterprise connection.

When JIT provisioning is disabled, a sign-in attempt by someone without an existing account fails with a saml_jit_provisioning_disabled error that includes the attempted email address, so blocked attempts are easy to diagnose. Existing users are unaffected and continue to sign in normally, including the first time they sign in through the SAML connection.

Compatibility

JIT provisioning remains enabled by default, so existing connections keep provisioning users exactly as before. Connections that previously had JIT provisioning disabled through the internal exception are migrated to the new setting automatically — their behavior is unchanged, it's just visible and editable in the Dashboard now.

Starting today, you can add or remove account credits from Users and Organizations directly from the Clerk Dashboard and APIs.

Sometimes you want to adjust what a customer owes without changing their subscription. Maybe you're offering a one-time discount, issuing a service credit, or resolving a billing issue. Account credits make these kinds of adjustments simple while keeping subscription pricing unchanged.

Credits are stored on a customer's account and automatically applied toward future charges. If the available credit exceeds the amount of the current invoice, the remaining balance stays on the account and is automatically used for future recurring charges.

Flexible account adjustments

Account credits give you a straightforward way to make account-level billing adjustments without creating custom pricing or modifying Plans.

For example, you might:

• Offer a one-time courtesy credit after a service interruption.
• Grant promotional credits to early customers.
• Apply a manual discount for a specific customer. (Note: customers can use their credits however they would like to).
• Resolve billing issues by crediting part or all of an upcoming invoice.

Whenever a customer is billed, Clerk automatically applies any available credit balance before charging their payment method. Any unused credit remains on the account until it's fully consumed.

Built directly into Clerk Billing

Account credits can be managed from the Clerk Dashboard or through the Backend API, giving you the flexibility to automate credit adjustments or handle them manually.

Each User or Organization displays its current credit balance, and every adjustment immediately updates the amount available for future billing.

Every credit adjustment is recorded in a ledger, giving you a complete history of credits that were added or removed from an account. Whether you're issuing promotional credits automatically through your application or making manual adjustments from the Dashboard, you always have an audit trail of how a customer's balance changed over time.

Get started with Account credits

• Open a User or Organization in the Clerk Dashboard.
• Open the Actions menu.
• Select Adjust credit balance.
• Enter the amount of credit to add or remove.
• Save your changes.

The updated balance will automatically be applied to the customer's next eligible charge, with any remaining credit carrying forward to future recurring invoices.

By default, enterprise SSO connections are configured by your team in the Clerk Dashboard. For every customer that needs SSO, someone on your side creates the connection, exchanges metadata with the customer's IT admin, tests it, and activates it. As your enterprise motion scales, that becomes a bottleneck. Self-serve SSO lets you delegate that configuration to your customers' IT admins, without giving them Dashboard access.

How it works

When you enable self-serve SSO for an Organization, a Security tab appears in that Organization's <OrganizationProfile />. An admin with the org:sys_entconns permission can set up the connection end-to-end from there:

• Domains: Add one or more domains and verify ownership of each with a DNS TXT record.
• Connection: Pick an identity provider and supply its configuration, with setup instructions embedded inline. Okta, Google Workspace, Microsoft Entra ID, and custom SAML are supported.
• Test: Run a test sign-in to confirm the connection works end-to-end.
• Activate: Turn the connection on once the test passes.

The connection is scoped to the Organization it's configured in and behaves like any other enterprise connection once it's live: users with a matching email domain sign in through the configured provider.

Get started

Self-serve SSO is available to applications using Organizations and is enabled per Organization. In the Clerk Dashboard⁠, select an Organization, open its Settings, and turn on Allow this organization to set up enterprise SSO under Organization permissions. The Security tab then surfaces wherever your app renders <OrganizationProfile />.

For setup details and requirements, refer to the self-serve SSO documentation.