Clerk compliance
★★★★★ 4.9 CE

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

Verified today·5 sources checked

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.

What it means for your security review

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.

Honest limits
  • 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)
View sources

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

FrameworkStatusEvidence to request
SOC 2 (Type 2)CertifiedAnnual audits; report typically gated to a paid tier
HIPAACompliantFor storing sensitive user data; BAA on the enterprise tier
GDPR / CCPACompliantEU and California privacy; GDPR data export supported
Third-party pen testingOngoingRegular third-party audits and penetration tests
Open-source SDKsAuditable@clerk JavaScript SDKs public on GitHub under the MIT license
Leak / brute-force defenseBuilt-inHaveIBeenPwned leak checks; automatic brute-force blocking
ISO 27001 / FedRAMPNot listedNot among the published attestations; confirm directly

Compliance evidence to request from Clerk

EvidenceTypeHow to get it
SOC 2 Type 2 reportReportThrough a Clerk commercial tier
HIPAA BAAAgreementEnterprise tier, for storing sensitive data
Third-party pen-test summaryAssessmentRegular third-party audits
Open-source SDK codeSourcePublic on GitHub (MIT), independently auditable
GDPR data export / DPADocumentDashboard 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

Verified by ComparEdgeMethod: Vendor docs, official pages, and selected independent sources
SourceWhat was checkedLast checked
Clerk OfficialOfficial product pageJuly 10, 2026
Clerk Deployment ProductionDeployment ProductionJuly 10, 2026
Clerk How Clerk Works OverviewHow Clerk Works OverviewJuly 10, 2026
Clerk User AuthenticationUser AuthenticationJuly 10, 2026
GitHub Clerk JavascriptIndependent referenceJuly 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.