
Clerk Compliance & Certifications 2026
Clerk states SOC 2 and HIPAA with a BAA, but no ISO 27001 or FedRAMP. Its 60-second session tokens and domain scoping do most of the security work.
Clerk Compliance verdict
Clerk is built for developers who store user identity data, and much of its assurance is architectural.
It states SOC 2 certification and HIPAA compliance with a BAA available, plus GDPR and CCPA compliance, and regular third-party audits and penetration tests. The design does the heavy lifting.
Clerk is strong on architecture and honest about tiering. If you handle PHI, confirm the HIPAA BAA and the plan it needs before you build, and request the SOC 2 report through the right commercial tier. Then lean on the built-in controls for your own objectives. MFA spans SMS, TOTP, hardware keys and recovery codes, with brute-force and leaked-password detection, GDPR data export, plus a session model with instant revocation. The architecture closes several common threats on its own. The 60-second session token, the FAPI-domain client token and strict per-domain scoping handle token theft and subdomain takeover. Two things still need your hand. Configure the authorizedParties allowlist and a subdomain allowlist to close the default cross-subdomain surface, and keep development instances out of production, since they pass state in a querystring. Use the open-source SDKs on GitHub as the check you can actually read.
- Clerk states SOC 2 certification and HIPAA compliance, but the SOC 2 report and a signed BAA come through its paid plans.
- Security is largely architectural: a 60-second session token, domain-scoped cookies and built-in fraud defenses, rather than a long certification list.
- The independent signal here is the open-source SDKs on GitHub under MIT, not a regulator listing or a review rating.
- SOC 2
- Certified (report on paid tier)
- HIPAA
- Compliant, BAA available
- Privacy
- GDPR + CCPA, data export
- Tokens
- 60s session token, domain-scoped
- Independent
- Open-source SDKs (MIT)
This page covers Clerk's compliance posture and data handling. General capabilities and deployment mechanics live on their own pages.
Clerk certifications and the evidence behind them
| Framework | Status | Evidence to request |
|---|---|---|
| SOC 2 (Type 2) | Certified | Annual audits; report typically gated to a paid tier |
| HIPAA | Compliant | For storing sensitive user data; BAA on the enterprise tier |
| GDPR / CCPA | Compliant | EU and California privacy; GDPR data export supported |
| Third-party pen testing | Ongoing | Regular third-party audits and penetration tests |
| Open-source SDKs | Auditable | @clerk JavaScript SDKs public on GitHub under the MIT license |
| Leak / brute-force defense | Built-in | HaveIBeenPwned leak checks; automatic brute-force blocking |
| ISO 27001 / FedRAMP | Not listed | Not among the published attestations; confirm directly |
Compliance evidence to request from Clerk
| Evidence | Type | How to get it |
|---|---|---|
| SOC 2 Type 2 report | Report | Through a Clerk commercial tier |
| HIPAA BAA | Agreement | Enterprise tier, for storing sensitive data |
| Third-party pen-test summary | Assessment | Regular third-party audits |
| Open-source SDK code | Source | Public on GitHub (MIT), independently auditable |
| GDPR data export / DPA | Document | Dashboard and privacy terms |
What to verify before you rely on Clerk
- SOC 2 and HIPAA assurance is commercially gated: the SOC 2 report and a signed BAA are obtained through Clerk's higher plans rather than self-service.
- The session token cookie is deliberately not HttpOnly because client-side SDKs must read it, a documented trade-off to verify against your threat model.
- Development instances transmit session state in a querystring and must never be deployed to production, so confirm environment separation in CI/CD.
- Default cross-subdomain acceptance increases attack surface unless you configure the subdomain allowlist and authorizedParties.
Clerk Compliance FAQ
Is Clerk SOC 2 and HIPAA compliant?
Clerk states it is SOC 2 type certified and HIPAA-compliant for storing sensitive user data, and that it is GDPR and CCPA compliant with regular third-party audits and penetration tests. In practice the SOC 2 report and a signed HIPAA BAA come through Clerk's commercial plans rather than self-service. If you handle PHI, confirm the BAA and the plan it requires before you build.
How does Clerk's token model protect my users?
Through a hybrid design. Clerk pairs a stateful session record with a stateless JWT and caps the session token's lifetime at 60 seconds. A stolen token usually expires before an attacker can use it, while a background refresh keeps users signed in. The long-lived client token is HttpOnly and scoped to a separate FAPI domain, so it never appears in your app logs, and it carries a rotating anti-session-fixation value. The session token itself is scoped strictly to your domain to prevent subdomain takeover.
What account-takeover protections does Clerk include?
Several, built in. Clerk detects and blocks brute-force attacks, spots leaked passwords via HaveIBeenPwned, lets you set custom password policies, and offers MFA across SMS passcodes, authenticator apps, hardware security keys and recovery codes. It surfaces blocked fraudulent sign-ups in the dashboard. For request authorization, you can set an authorizedParties allowlist and restrict cross-subdomain requests to defend against CSRF and cookie-leaking attacks.
How can I independently verify Clerk's security?
By reading the code. Clerk's JavaScript SDKs are open source on GitHub under MIT, so the client integration, including how tokens are stored and refreshed, can be inspected rather than trusted. Beyond that, Clerk runs regular third-party audits and penetration tests, and its dashboard exposes the fraud, password-policy and session controls directly. Note that the client SDKs are open while the FAPI and BAPI backend stays a managed service.
What should I verify before relying on Clerk for compliance?
Confirm the HIPAA BAA and SOC 2 report on the plan you will actually buy, since both are commercially tiered. Check that the deliberately non-HttpOnly session token fits your threat model, and configure the authorizedParties and subdomain allowlists to close the default cross-subdomain surface. Make sure CI/CD keeps development instances out of production. Validate the current certification scope directly with Clerk, since ISO 27001 and FedRAMP are not among the published attestations.
Sources & verification
| Source | What was checked | Last checked |
|---|---|---|
| Clerk Official | Official product page | July 10, 2026 |
| Clerk Deployment Production | Deployment Production | July 10, 2026 |
| Clerk How Clerk Works Overview | How Clerk Works Overview | July 10, 2026 |
| Clerk User Authentication | User Authentication | July 10, 2026 |
| GitHub Clerk Javascript | Independent reference | July 10, 2026 |
Every fact on this Clerk page is tied to a named source and a verification date. Freshness-sensitive figures trace to the sources above; verify against the vendor before relying on them.
Explore Clerk
Every page on Clerk in one place, you are on compliance.
Snapshot, score and verdict
You are here
Hosting model, environments and rollout in your stack
Every tier and the entry price
Compared and ranked vs peers
Price and feature change history
Browse the full Identity & Access Management category
