Sign-in for a Swiss web app without a US cloud

If you build a web application in Switzerland and let a provider handle sign-in, your users' email addresses and password hashes live wherever that provider lives. For most of the well-known ones that is a US company, under US law, on servers you do not choose. That is not automatically a problem. It is a question your data protection notice has to answer, and one a corporate customer will ask in the security questionnaire before signing.

We run EAuth, an OpenID Connect provider, from Switzerland, at eauth.me. This post is the checklist I would use to judge any sign-in provider, ours included, with what EAuth does on each point. That includes the one point where our answer is not "Europe only".

Where the servers are, and who runs them

Ask for the servers and the companies behind them, not for a badge. Since 3 October 2026 EAuth runs on our own cluster: eight servers at five providers in four countries.

• Two entrances, where the encrypted connection from a browser ends: Hetzner in Falkenstein and UpCloud in Amsterdam. When one fails, the other takes the traffic.
• Two application nodes, both serving sign-ins at the same time: Infomaniak in Geneva and Scaleway in Amsterdam.
• Three PostgreSQL nodes: Tavuru in Frankfurt, Hetzner in Nuremberg and Scaleway in Paris. Replication to both replicas is synchronous, so a change counts as written only once all three hold it.
• A watcher at Infomaniak in Geneva, which checks the others from outside.

Profile pictures and logos sit in object storage at Infomaniak, with a nightly copy at Scaleway. No third party's proxy sits in front of any of this: the connection from a browser ends on an entrance we run, and from there it travels over our own encrypted network between the nodes. Every connection uses TLS 1.3 and nothing older, and the domains send HSTS with preload.

Two DNS services see name lookups and nothing else: Cloudflare holds our zones, and ClouDNS answers the one name that points to whichever entrances are healthy. Neither sees a request or a sign-in.

The exception: mail

EAuth sends mail: the link that confirms an address, the password reset, invitations, the notice that a passkey was added. That mail goes out through Resend, a US company. Our sending is set to its EU region, which Resend places in Ireland, but its own documentation says account data stays in the United States whatever the region. So the recipient's address and the text of each mail pass through a US company.

Since 3 October this is not a corner case. No application gets an account whose address has not been confirmed, so every new account receives at least one mail through Resend. I would rather you read that here than find it in a questionnaire answer.

What is stored, and how

Ask what the database holds and in which form. EAuth stores password hashes with Argon2id (64 MiB of memory, three iterations), refresh tokens, codes and recovery codes only as SHA-256 digests, and signing keys and third-party credentials encrypted with AES-256-GCM under a key that is not in the database. A dump of it yields ciphertext and digests.

Sessions record the browser and the platform, "Firefox on Windows", never the raw User-Agent header, and the country as two letters, never an IP address. The rate limits hold an address only for the length of their window. The full list of what is processed and for how long is Annex A of the terms: seven rows in a table.

What you can take with you

This is where most providers are weakest. Ask: if I leave, do my users have to reset their passwords?

With EAuth the answer is no. The console exports an application with its users, organisations and settings as JSON, at any time, without asking us, and the export contains the password hashes in their original form: Argon2id for anybody who has signed in with us, or the hash they were imported with if they have not. A provider that accepts Argon2id can import them and your users sign in as before. The same works in the other direction: EAuth imports Argon2id, bcrypt, scrypt and PBKDF2-SHA256, and replaces each with Argon2id the next time the person signs in.

I consider being able to leave a feature. A provider that keeps your users' hashes hostage is not offering a service, it is offering a lease.

What the contract says

A data processing agreement under Art. 28 GDPR and the Swiss FADP is not an extra document to negotiate. It is Annex B of the EAuth terms, and it applies as soon as you have an account. The terms say that data is processed only in Switzerland and the European Economic Area, what is kept and for how long, that every version of them stays published with its date, that a material change gets 30 days' notice, that adding a sub-processor gets 30 days' notice too, and that no independent security audit has been performed yet. That last sentence is in there because the alternative is letting you assume otherwise.

Read the transfer clause next to the mail paragraph above. The mail's dispatch region is in the EU; the company that runs it is not, and that is the gap I named.

What the technology has to do anyway

Data location does not replace the basics. Whatever provider you choose, it should require PKCE on every authorization request, match redirect URIs exactly, rotate refresh tokens on every use and end the whole chain when a rotated token is presented again, offer passkeys and a second factor, and count every password attempt per address and per account before it is checked. It should also refuse to hand your application an account whose email address nobody has confirmed: an unconfirmed address is a name anyone could type. EAuth does each of these, and email_verified in its ID tokens is always true. Annex C of the terms lists the measures as implemented, with their numbers.

The limits

The limits are the same for every application: 25 applications per account, 20 redirect URIs per application, and 120 token requests a minute per application, which a developer raises in the console to 600. Above that, ask, and we raise it. There is no service level agreement: clause 4.1 of the terms says so in one sentence, because a figure we cannot stand behind is worse than none.

What is not done

EAuth has not been audited by an independent party. The status page at status.elchi.dev is up, and the cluster's measured availability goes on it once a full month has been measured; until then there is no number to quote, and I will not quote one. Both will be reported here when they are, whatever the result.