Self-hosted, EU-only IAM in 2026

There is a category of architectural decision that looks optional right up until it isn't. Storing identity data — user sessions, tokens, authentication events — with a US-incorporated SaaS vendor is one of them.

For most EU companies, the problem became concrete in July 2020. The Court of Justice of the European Union ruled in Schrems II that Privacy Shield was invalid. US surveillance law — FISA 702, Executive Order 12333 — made structural guarantees impossible. Standard Contractual Clauses could still work, but only with a transfer impact assessment that survives auditor scrutiny.

Three years later, the EU-US Data Privacy Framework partially restored the transfer mechanism. Schrems III is already filed. The cycle continues.

What GDPR Chapter V actually requires

GDPR Chapter V governs transfers of personal data to third countries. Article 44 is the baseline: a transfer may only happen when adequacy, SCCs, binding corporate rules, or specific derogations apply.

For identity data — email addresses, authentication logs, session metadata — "transfer" happens when your IAM vendor processes a login. The user's IP, the timestamp, the browser fingerprint, the email address: all personal data under GDPR. If the vendor's servers are in the US and the company is subject to FISA, Chapter V applies every time someone logs in.

The simplest path to Chapter V compliance is not a better transfer mechanism. It is not transferring.

What self-hosted means in practice

Self-hosted does not mean running your own Keycloak on a server under someone's desk. It means the identity infrastructure runs in infrastructure you control, in EU jurisdiction, under your data processing agreement — not the vendor's.

With Thoryn's authorization hub, the topology looks like this:

The hub is a Spring Boot application. You deploy it to your own Kubernetes cluster. Vault Transit holds the signing keys in your Vault instance. Tokens never leave your infrastructure.

The OIDC discovery endpoint your applications call:

{
  "issuer": "https://auth.your-company.eu",
  "authorization_endpoint": "https://auth.your-company.eu/oauth2/authorize",
  "token_endpoint": "https://auth.your-company.eu/oauth2/token",
  "jwks_uri": "https://auth.your-company.eu/oauth2/jwks"
}

That issuer URL resolves to your cluster. The JWKS contains your keys, managed by your Vault instance. The token claims are signed in your infrastructure, by your keys, and verified by your resource servers without ever calling home.

The EU AI Act angle

The EU AI Act adds a second vector. High-risk AI systems — which include biometric identification — require detailed audit logs of every access decision. If your IAM vendor holds those logs, your audit trail is subject to the vendor's data retention policy, their subprocessor list, and their response time to regulator requests.

Self-hosted IAM means the audit trail is yours. Every authentication event, every token issuance, every scope grant is in your database, under your retention policy, exportable on your schedule.

How federation works without PII leaving the hub

The Thoryn hub follows a strict federation pattern: the hub issues tokens but never stores user profiles. Passwords, email addresses, and authentication history live with the federation member — either your own identity service or an external IdP like Entra ID or Okta.

What the hub stores is minimal:

• The authorization code (10-second lifetime, deleted on exchange)
• The refresh token family root (a UUID, not a user identifier)
• OAuth client configuration

No email addresses. No password hashes. No session tables with user data. GDPR data subject access requests for user data go to the federation member, not the hub.

The trade-off is intentional. A bug in the hub's authorization logic is a security incident. A bug in the hub's authorization logic plus a user table is a breach.

Getting there

If you are evaluating a move off a US-hosted IAM SaaS, the checklist is short:

1. Map where identity data currently lives. Include authentication logs, not just the user record.
2. Identify which transfers require a Chapter V basis. Logins are transfers.
3. Run a transfer impact assessment for your current vendor. Document what you find.
4. Evaluate whether the basis survives the next Schrems ruling.

If you want to understand what a self-hosted, EU-only setup looks like for your stack, talk to us. We can walk through the deployment topology and what it takes to migrate from a US-hosted provider.

The decision is worth making before a regulator makes it for you.