CAI Technology
Book a demo
Menu ☰
cai-auth · · 13 min read

Why a Romanian law firm cannot use Auth0 — and what we built instead

Schrems II plus the CLOUD Act make Auth0 and Okta a compliance problem for law firms handling attorney-client data. Here is the legal analysis and our sovereign alternative.

CAI Technology · Last reviewed: 4/30/2026
Why a Romanian law firm cannot use Auth0 — and what we built instead

Why a Romanian law firm cannot use Auth0 — and what we built instead

In the winter of 2024, a Bucharest law firm with 40 attorneys received a major contract from a German automotive corporation. The contract came with a single hard clause, written in capitals on page 14: “Our case data must not pass through any American server. Period.”

The firm used, like the vast majority of Romanian law firms, Microsoft 365 for email and collaboration plus Auth0 for SSO into internal applications. Both solutions stored and processed data on infrastructure owned by US-based providers. And from the moment the Court of Justice of the European Union invalidated Privacy Shield through the Schrems II ruling (case C-311/18, 16 July 2020), transferring personal data to the United States became a serious legal issue, not a technical decision.

This article explains why a regulated law firm cannot use Auth0 or Okta, what the CLOUD Act actually means for attorney-client privilege, and what we built as a sovereign alternative in CAI-AUTH.

TL;DR

Schrems II — what the Court ruled in 2020

Case C-311/18 Data Protection Commissioner v Facebook Ireland and Maximillian Schrems was decided on 16 July 2020 by the Grand Chamber. The Court invalidated Commission Decision 2016/1250 (Privacy Shield) with a clear technical-legal argument: US surveillance law, especially Section 702 FISA and Executive Order 12333, allows authorities to access transferred data without giving data subjects redress equivalent to the rights guaranteed by the EU Charter of Fundamental Rights.

Key quote, paragraph 184: “the limitations on the protection of personal data arising from the domestic law of the United States on the access and use by US public authorities […] are not circumscribed in a way that satisfies requirements that are essentially equivalent to those required under EU law.”

In practice: if you transfer personal data to a US processor or to an EU processor controlled by a US parent, you need supplementary measures that compensate for the deficit in protection. That is the rule. The European Data Protection Board explained what supplementary measures means through Recommendations 01/2020, adopted on 18 June 2021.

The EDPB recommendations require a six-step process:

  1. Know your transfers.
  2. Identify the transfer instrument used (SCC, BCR, derogation).
  3. Assess the law of the third country.
  4. Identify and adopt supplementary measures.
  5. Take procedural steps for implementation.
  6. Re-evaluate periodically.

At step 4, the EDPB demands effective technical measures: end-to-end encryption with keys held only by the EU exporter, pseudonymisation, or split-processing models. For an IdP like Auth0, this is fundamentally incompatible. The IdP needs to read passwords and credentials in clear to verify them. You cannot encrypt JWT tokens against the entity that issues them.

The CLOUD Act — what it is, why it matters

The Clarifying Lawful Overseas Use of Data Act (H.R. 4943, 2018) is a US federal law that allows US authorities (FBI, NSA, similar agencies) to compel a US provider to hand over data it stores, regardless of where the data physically sits. Including in the EU.

That means: if the law firm uses Auth0 (part of Okta Inc., NASDAQ: OKTA, San Francisco HQ) and the FBI issues a National Security Letter to Okta, Okta is bound by US law to comply. Worse — the same NSL usually contains a gag order prohibiting the provider from notifying the customer.

For a law firm, this is a material problem. Article 31 of the Romanian Bar Statute (Law 51/1995) provides that “the lawyer is bound to keep professional secrecy concerning any aspect of the matter entrusted to them.” What happens when, through a third party (Auth0), authentication data and case metadata can be requisitioned without notification? UNBR has not yet published guidance specifically on this point, but the deontological logic suggests the lawyer’s responsibility extends to the choice of infrastructure they use.

Why SCCs alone do not solve the problem

Many IT integrators propose Standard Contractual Clauses, updated through Commission Decision 2021/914, as a simple fix. Auth0 and Okta sign SCCs. The argument runs: “we have SCCs, we are fine.”

The argument fails for two reasons:

First. SCCs are private agreements. They do not modify US law. The CLOUD Act applies whether or not Okta has signed an SCC with an EU customer — the supremacy of US national law over private contract is the rule.

Second. Schrems II itself clarified that SCCs remain a valid instrument only when combined with a concrete assessment of the third country and adequate supplementary measures. For the US, the EDPB has indicated that supplementary measures must be technical, not merely contractual. See EDPB Recommendations 01/2020 — paragraph 79.

”Then we use self-hosted Keycloak”

This is the correct first reaction from a senior DevOps engineer. Keycloak is open-source, written in Java, supported by Red Hat, supports OIDC, SAML, and WebAuthn. It runs on the customer’s infrastructure. Done — data does not leave for a third party.

It works, partly. But for a law firm that wants to use authentication as a commercial differentiator (German clients asking for “post-quantum” in 2027+ RFPs), vanilla Keycloak has visible limits:

  1. No post-quantum cryptography. Keycloak signs JWT tokens with classical algorithms a sufficiently large quantum computer will break. NIST has published post-quantum signature standards. Keycloak does not natively support post-quantum signatures in 2026.
  2. Minimal per-client branding. Keycloak realms allow theme-level customisation, but not a consent page branded for each tenant.
  3. No documented audit pack. PSD3, DORA, NIS2, EU Health Data Space — Keycloak does not ship sectoral compliance documents. You write them yourself, as the integrator.
  4. No native supply-chain attestation. Sigstore, Cosign, Rekor, CycloneDX SBOMs — these are not part of the Keycloak release process out of the box.

This is not a critique of Keycloak — it is a solid product for general cases. But for a firm that wants to deliver “MFA compliant with NIS2 plus post-quantum-ready” to a German automotive client, it is not enough.

What we built — CAI-AUTH

CAI-AUTH is the OIDC IdP we built as a concrete answer to the 2024 case. A few key technical choices:

Effective sovereignty. The whole stack runs on our EU-resident infrastructure or on the customer’s own infrastructure (on-premise deployment for customers with strict requirements — a ministry, a NIS2 critical operator). There is no dependency on Google Cloud, AWS, Azure, or Cloudflare for sensitive data. Where we use a CDN, it is for public static assets only.

Post-quantum cryptography in production today. JWT access tokens are signed with a hybrid post-quantum scheme (Patent Pending) — classical fallback combined with a post-quantum signature. If one of the algorithms falls — classical or post-quantum — the other resists. Verification requires both signatures to be correct.

Full OIDC surface. Nine public endpoints (RFC 6749, RFC 8414, RFC 7517, RFC 7636, RFC 8628, RFC 7662, RFC 7009, OIDC Core 1.0, RFC 9068), four grant types (authorization_code with PKCE, client_credentials, refresh_token with OAuth 2.1 rotation, RFC 8628 device_code), real-time revocation via jti blocklist.

Native anti-phishing. Our CAI-CR challenge-response protocol binds every signature to three elements: who you are (public key), where you are signing in (FQDN), what you are doing (action hash). WebAuthn binds who and where. We add the action, so an attacker who steals a “login” session cannot reuse it for a “transfer.”

18-document audit pack. PSD3, PCI-DSS 4.0.1, DORA Article 19 live webhook, SWIFT CSP v2026, EBA RTS on SCA, HIPAA, EU Health Data Space (Reg. 2025/327), break-glass, NIAP Protection Profile, DoD STIG, air-gap deployment kit, SLSA Level 3, Nix reproducible builds, PKCS#11 HSM, NFC HCE, BLE proximity, FIDO2 Hybrid Transport, anti-relay proximity proof.

Transparent supply chain. Five CycloneDX SBOMs, Cosign signatures, public Rekor transparency log. Anyone can verify that the downloaded binary corresponds to the published source code.

What it meant in practice for the firm

The 2024 law firm migrated its MFA from Auth0 to CAI-AUTH in three weeks:

The German auditor approved. The contract was signed in March 2024.

Operational conclusion

For a regulated Romanian law firm, choosing an IdP is not a purely technical decision. It is a compliance decision covering:

Auth0 and Okta are excellent products from a purely technical perspective. But the legal architecture of US data transfer, combined with the CLOUD Act, makes them unsuitable for attorney-client data. Self-hosted Keycloak is a major improvement, but lacks post-quantum cryptography and a documented sectoral audit pack.

CAI-AUTH was built specifically for this gap: regulated EU customers who want effective sovereignty, modern cryptography, and audit-ready compliance documentation.

Next steps

If you run a law firm, a notary office, or a similar regulated entity and you are evaluating replacing Auth0/Okta — the CAI-AUTH page carries the migration plan and the compliance documents. Or write to contact for a 30-minute technical discussion with our team.

Related reading: On-premise SIEM with local LLM (how to keep security log confidentiality).

References

We start with a 30-minute conversation.

Free AI-readiness audit for companies with 50+ employees. We reply within 24 hours.

Open contact form →