diff --git a/docs/roadmap.md b/docs/roadmap.md
index 4743523..176981d 100644
--- a/docs/roadmap.md
+++ b/docs/roadmap.md
@@ -152,6 +152,15 @@ Fenstern geschieht.
 
 ## Später denkbar
 
+**Das Fenster der Ersteinrichtung schließen** · klein
+Heute wird das erste Konto ohne jede Legitimation angelegt und ist gleich
+Administrator. Wer die Anwendung öffentlich stellt, bevor er sein Konto
+angelegt hat, kann sie an einen Fremden verlieren. Vorschlag: ein einmaliges
+Token, das beim ersten Start ins Protokoll geschrieben wird und für die
+Ersteinrichtung nötig ist. Klein im Aufwand — und das Erste, was zu tun ist,
+falls die Anwendung je aus dem eigenen Netz herausgeht. Siehe
+[sicherheit.md](sicherheit.md).
+
 **Codes exportieren** · klein
 Eine CSV aller Codes einer Gruppe mit Name, Kurz-URL, Ziel und Scans — für
 die Übergabe an eine Druckerei oder die Ablage.
diff --git a/docs/sicherheit.md b/docs/sicherheit.md
index f527be2..62aa2b5 100644
--- a/docs/sicherheit.md
+++ b/docs/sicherheit.md
@@ -195,6 +195,44 @@ Konto nur bei **bestätigter** E-Mail-Adresse.
 
 Bewusst nicht umgesetzt, mit Begründung.
 
+**E-Mail-Verifizierung.** Es gibt keine — und sie würde derzeit auch nichts
+bringen. Die Anwendung kennt **keine Selbstregistrierung**: Es gibt nur
+`login`, `setup`, `logout` und `change-password`. Konten legt ein
+Administrator an, der die Adresse selbst einträgt. Eine Bestätigungsmail
+würde also belegen, dass eine Adresse existiert, aber niemanden hereinlassen
+und niemanden fernhalten.
+
+Dazu kommt: Es gibt **kein „Passwort vergessen" per E-Mail**. Zurücksetzen
+kann nur ein Administrator unter Verwaltung → Benutzer. Damit ist die
+unbestätigte Adresse auch kein Übernahmeweg — bei einem Reset per Mail wäre
+sie einer. Die Adresse ist hier schlicht ein Anmeldename.
+
+Nötig würde die Verifizierung in dem Moment, in dem sich Leute selbst
+registrieren dürfen. Dann allerdings zwingend, zusammen mit einem
+SMTP-Versand, Ablauffristen für die Bestätigungslinks und einem Weg für
+nicht zugestellte Mails.
+
+Zwei Stellen bleiben davon ohnehin unberührt, weil dort nicht der
+Administrator die Adresse einträgt:
+
+- **Die Ersteinrichtung.** Wer zuerst kommt, wird Administrator. Dagegen hilft
+  keine Verifizierung, sondern nur, das Fenster zu schließen — siehe unten.
+- **Die Anmeldung über einen Anbieter.** Dort bürgt der Anbieter für die
+  Adresse, und genau das prüft die Anwendung: Ein bestehendes Konto wird nur
+  bei `email_verified` verknüpft.
+
+**Das Zeitfenster der Ersteinrichtung.** Solange es keinen Benutzer gibt und
+die Anmeldung eingeschaltet ist, wird das erste Konto ohne jede Legitimation
+angelegt — und ist Administrator der Installation. Steht die Anwendung schon
+öffentlich, bevor der Betreiber sein Konto anlegt, kann ein Fremder sie
+übernehmen.
+
+Heute ist das eine Frage der Reihenfolge: erst starten, sofort das erste
+Konto anlegen, dann erreichbar machen. Sauberer wäre ein einmaliges Token,
+das beim ersten Start ins Protokoll geschrieben wird und für die
+Ersteinrichtung nötig ist. Steht als Vorschlag in der
+[Roadmap](roadmap.md).
+
 **Vollständige Content-Security-Policy für Skripte.** Bräuchte Nonces durch
 die ganze Anwendung, weil Next.js eingebettete Skripte ausliefert. Der Nutzen
 wäre echt — es ist die zweite Verteidigungslinie gegen XSS —, aber halb