--- title: "The security questionnaire, and where the answers are" summary: "The sign-in questions of a corporate security questionnaire, answered for EAuth, each with the clause or page behind it, including our no." author: "Samuel Krauss" author_title: "Founder" publisher: "Elchi Studios" published: 2026-10-03 updated: 2026-10-03 url: https://elchi.dev/en/journal/the-security-questionnaire-and-where-the-answers-are language: en tags: ["eauth","security","enterprise","gdpr"] words: 1461 --- # The security questionnaire, and where the answers are *By Samuel Krauss, Founder. Published 3 October 2026.* > The sign-in questions of a corporate security questionnaire, answered for EAuth, each with the clause or page behind it, including our no. The first large customer sends a spreadsheet: a column for your answer, a column for evidence, and a good share of the rows about how people sign in. If you built sign-in yourself, this is where you find out what you did not build. If you use EAuth, most rows have an answer already. This is the list, with the clause of the EAuth terms or the page of the documentation that backs each answer. The terms are versioned and every version stays published (14.3), so the clause you cite does not change under you. ## Where is the data stored, and by whom? In Switzerland and the European Economic Area only; the data processing agreement says so (Annex B.14). Since 3 October 2026 EAuth runs on our own cluster: eight servers at five hosting providers in four countries. The three database nodes are in Frankfurt, Nuremberg and Paris, the application runs in Geneva and Amsterdam, the two edges where TLS ends are in Falkenstein and Amsterdam, and a watcher runs in Geneva. No third party's proxy sits in front of them. Mails, meaning address confirmations, password resets and invitations, go out through a mail delivery service, which sees the recipient's address and the text of the mail. Evidence: Annex B, the data processing agreement, which needs no separate signature. The terms commit us to announcing a new sub-processor 30 days before it starts, and you may terminate if you object (8.5, B.8). ## How are passwords stored? Argon2id, 64 MiB of memory, three iterations, two lanes, a 16-byte random salt per password, with the parameters in each stored hash so they can be raised later without a reset. Refresh tokens, authorization codes, API keys, invitations and recovery codes are stored as SHA-256 digests only, and so are the links that confirm an address or reset a password. Token signing keys are encrypted with AES-256-GCM under a key that is never in the database. Evidence: Annex C.1, and the security page's table of how credentials are stored. ## Are email addresses verified? Yes, before any application sees the account. Since 3 October 2026 no application gets an account whose address has not been confirmed. A person who registers is stopped on the way back with a page that sends a new link, and the link leads back to the sign-in; an application asking silently, with `prompt=none`, gets `interaction_required`. So `email_verified` is true in every ID token from a sign-in. An address counts as confirmed by the link, by a password reset sent to it, or by an organisation's identity provider vouching for it. Evidence: the quickstart in the documentation. ## Is multi-factor authentication available? Is it required for administrators? Available for every end user: an authenticator app with recovery codes, and passkeys. Whether your users must have a second factor is your application's setting, and an organisation can require it of its members. On our side, every role that can change content or credentials must use a second factor, and the dashboard checks that on every request, not only at sign-in. Evidence: Annex C.2. ## How are sessions protected? Refresh tokens rotate on every use, and a rotated token presented again revokes the whole chain, since the legitimate client and a thief cannot both hold the newest one. Authorization codes live sixty seconds, work once, and are bound to the client, the redirect URI and the PKCE challenge; PKCE with S256 is required on every request. Access tokens live 15 minutes by default. Administrative sessions are checked against the database on every request, so revoking one takes effect at once. Evidence: Annex C.3, and the security page's "What is enforced". ## How do you protect against brute force? Every attempt is counted before it is checked, per address and per account, and the counters fail closed: if the store behind them is unreachable, the sign-in page refuses rather than lets requests through. Five wrong passwords for one account from one address, or twenty from anywhere, pause it for up to fifteen minutes. Second-factor codes allow five wrong in fifteen minutes and twenty in a day. A browser that signed in to the account before keeps an allowance of its own, so an attacker cannot lock the owner out by guessing. Evidence: the security page, with the numbers, and Annex C.4. ## Is there an audit trail? Every change to an application's credentials and settings goes to an audit log with the actor's account and email address: creating an application, rotating its secret, changing its settings, webhooks, the team, organisations and their single sign-on, imports and exports of accounts, deleted accounts, and an account taken over by single sign-on. A database trigger refuses any change to an entry, and refuses to delete one younger than twelve months. Evidence: Annex C.5. ## How long do you keep what? Sessions and refresh tokens until they expire, and a revoked one until it would have expired, so a stolen copy presented later is still recognised. Authorization codes an hour past their sixty seconds. Confirmation and reset links a week after they were used or expired, invitations 30 days. The token-request log and the audit log twelve months, webhook deliveries 30 days. An account is deleted 30 days after its owner asks; one not signed in to for 24 months is written to twice, 30 days apart, and deleted 30 days after the second mail unless it signs in. A sweep removes what is due once an hour. Evidence: the security page, "How long things are kept", and terms 7.4 and 7.5. ## Can we leave? Yes, with the password hashes. The console exports an application with its accounts, organisations, roles, webhooks and settings as JSON at any time, without asking us. The hashes are in their original form, Argon2id or whatever format they were imported in, so your users keep their passwords at the next provider. Passkeys are bound to the sign-in domain and cannot move, and second-factor secrets and the service's own secrets are not exported, so people set those up again. Evidence: terms 7.2 and 7.3. ## What happens when EAuth is down? Access tokens already issued keep working until they expire, 15 minutes by default, since your application checks them against our public keys without asking us. After that refreshes fail, and new sign-ins fail until EAuth is back. The terms say this in as many words (4.7), and that there is no service level agreement or availability commitment (4.1). If minutes of lockout are not acceptable, we can raise your access token lifetime, or you run EAuth on your own servers (4.8, section 11). What makes an outage less likely: two application nodes and two edges in different countries, and three database nodes with synchronous replication, so a write is confirmed only once both replicas have it. The status page at status.elchi.dev shows the current state; measured availability is published there once a full month has been measured, and not before. An outage longer than 30 minutes gets a note with its cause in this journal (4.9). ## Do you support single sign-on for our identity provider? SAML 2.0 per organisation, taking requests by HTTP redirect as Entra ID, Okta and Google Workspace do. Signatures are checked by a maintained library against the certificate you configured, every answer must belong to a request from the same browser and is accepted once, and the asserted address must be in the organisation's verified domain. Answers a provider sends unasked are refused. There is no SCIM: accounts appear at the first sign-in. Evidence: docs.elchi.dev/enterprise-sso. ## Has there been an independent security audit? No. The terms say so (9.2, Annex C.6), and when an audit is done, the result is published whatever it says. There is no SOC 2 report or ISO 27001 certificate either. If a questionnaire needs a yes here, we cannot give one today, and I would rather you knew that from us than from the auditor you hire. ## How are we told about changes? A material change to the terms gets 30 days' notice by mail and in the changelog (14.1), a new sub-processor 30 days (8.5), and a change that breaks integrations 90 days, unless a security problem needs a shorter period (2.3). Every notice mail is recorded, so the notice period can be shown to have been given. The move of the issuer from auth.elchi.dev to eauth.me on 3 October 2026 needed no notice: on that day every application registered with EAuth belonged to Elchi Studios (2.4). Evidence: those clauses, and docs.elchi.dev/changelog. ## What goes in the evidence column The clause with the version: "EAuth terms 1.7, Annex C.1". A security team can check a versioned clause against the published text, and the answer stays true for the version you cited. A link to a features page proves only that somebody wrote it. ## Sources 1. [EAuth Terms of Service](https://elchi.dev/legal/eauth-terms), Elchi Studios, read 2026-10-03 2. [Security, EAuth documentation](https://docs.elchi.dev/security), Elchi Studios, read 2026-10-03 3. [RFC 9700: Best Current Practice for OAuth 2.0 Security](https://www.rfc-editor.org/rfc/rfc9700.html), IETF, read 2026-10-03 4. [RFC 7636: Proof Key for Code Exchange by OAuth Public Clients](https://www.rfc-editor.org/rfc/rfc7636.html), IETF, read 2026-10-03 5. [RFC 9207: OAuth 2.0 Authorization Server Issuer Identification](https://www.rfc-editor.org/rfc/rfc9207.html), IETF, read 2026-10-03