Clerk changed two things in 2026 that matter to anyone testing an app that uses it for login. New instances now lock an account after far fewer failed sign-in attempts than before. The helper most generated code used to protect routes in middleware is deprecated in favour of checks next to the data. Here is what Clerk's own pages say and what to check.
The lockout default
Clerk's docs, verified 2026-09-21, state that new instances lock an account after ten failed sign-in attempts for a one-hour cooldown. The change was made on 2026-07-06; the previous threshold was one hundred. Failed passwords, password resets, backup codes, email and phone codes and TOTP codes (the six-digit codes from an authenticator app) all count toward the limit. The limits and duration are adjustable, with an indefinite option, and the docs state that the behaviour applies if lockout is enabled on your instance. The minimum configurable threshold is five attempts.
For the gloss: account lockout is a brake on password guessing. An attacker who can try passwords without limit will eventually land on a weak one; a lockout after a small number of failures makes that slow and noisy.
What this means for your app depends on when the instance was created. An instance created before 2026-07-06 keeps the setting it had. The check takes a minute: open the Clerk dashboard, find the user lockout settings, and read the threshold. A much higher threshold than the new default, or lockout turned off, is the thing to look for.
The related test from the outside is the one in No rate limiting on sensitive routes. Submit a wrong password, replay the request from the Network tab twenty or thirty times, and read the status column. Lockout covers the account; rate limiting (a cap on how many requests one caller can make in a period) covers the route. An app can have one without the other, and the login route is where both belong.
Where route protection belongs
The second change is about where the check for whether a person is allowed here runs. Clerk's docs state that clerkMiddleware does not protect routes on its own, advise against protecting routes in middleware, and recommend checking access as close to the data as possible. createRouteMatcher(), the helper that generated code used to list protected paths in the middleware file, is deprecated in favour of resource-based checks.
This lines up with what Next.js says about its own middleware, now renamed proxy: a page-level or middleware-level check does not cover the Server Actions and route handlers that can be called directly. A path list in middleware protects the paths on the list. It does nothing for a Server Action called by direct POST, a route added after the list was written, or a route whose path was spelled slightly differently.
Checking close to the data means the function that reads or changes a record verifies the session and the caller's right to that record, every time, no matter what ran before it. Clerk's auth() helper and authenticateRequest() exist for this. The docs state that authenticateRequest() handles signature, expiry and authorized-party validation, and that it only protects endpoints where it is called.
What to check: open the builder's code view and search the server-side files for auth( and authenticateRequest(. A route handler or Server Action that touches user data and calls neither is the warning sign. Then confirm from outside with Admin routes without any login check.
Session tokens and the manual path
Clerk's session token is a short-lived JWT (a signed token that carries who the user is) stored in a cookie. The SDK middleware validates it automatically, or you verify it manually with authenticateRequest() or the public key from Clerk's JWKS endpoint. Manual verification must check the algorithm, the signature, the exp and nbf claims and the azp (authorized parties) claim. The docs recommend setting authorizedParties against CSRF (a forged request sent from another site using your logged-in cookies).
Generated code sometimes decodes the token to read the user id and skips the signature check. That is the shape of Tokens trusted without server verification, and the pattern page describes how to test it with an edited token.
What Clerk provides
Clerk's security features cover a lot of ground. Bot sign-up protection uses CDN signals and shows a CAPTCHA when a bot is suspected. The documented limit is that the Native API setting opens a path where the CAPTCHA is bypassed, and custom flows must render the widget themselves. Webhooks (messages Clerk sends to your server when something happens) are signed and delivered through Svix, with a verifyWebhook helper; the docs say to treat the payload as unsafe until validated. The publishable key (pk_) is for the frontend and the secret key (sk_) must not be exposed through a public environment variable. Account lockout, as above, is on for new instances.
Each is a control that works where it is configured or called; the test is whether your app does so.
Where testing comes in
Clerk did its job: it lowered the default, deprecated the helper that put checks in the wrong place, and wrote down why. Confirming that your routes and actions check for themselves is a separate job. We map every API route and Server Action and call each one signed out, as a normal user and as a second user. We also replay login and reset requests in a burst to see where the app slows or blocks. The Clerk hub lists the patterns we test for on this stack, and the security package covers the full set.
What to do this week
- Read the lockout threshold in your Clerk dashboard and burst the login route: No rate limiting on sensitive routes.
- Request the admin routes signed out: Admin routes without any login check.
- Search server files for routes that touch data without
auth(: Authorization enforced only in the browser.