diff --git a/README.md b/README.md
index db275bf6..907ac08f 100644
--- a/README.md
+++ b/README.md
@@ -229,6 +229,42 @@ Nach dem Seed sind folgende Zugangsdaten verfügbar:
 > **Wichtig:** Vor dem ersten Production-Deployment Secrets rotieren –
 > siehe [Production-Deployment](#production-deployment).
 
+### Zugangsdaten auf bestehender DB neu setzen (Reseed)
+
+Nützlich z.B. auf **Staging/Test nach einem DB-Reset**, wenn Admin-/Portal-
+Passwörter randomisiert sind und man wieder **bekannte** Zugangsdaten braucht
+(etwa für einen Pentester).
+
+**Der Seed ist datenerhaltend:** Er `upsert`et nur die Rollen und den
+Admin-User (`admin@admin.com`) und synchronisiert die Rollen-Berechtigungen.
+**Kundendaten, Verträge, Bankkarten usw. werden NICHT angefasst** (das einzige
+`deleteMany` betrifft ausschließlich Rollen↔Permission-Zuordnungen). Ein
+erneuter Seed setzt also faktisch nur das Admin-Passwort neu.
+
+**Admin-Passwort deterministisch neu setzen:**
+
+```bash
+# 1) In der .env / docker-compose environment setzen:
+SEED_ADMIN_PASSWORD=<ein dir bekanntes Passwort, MIND. 25 Zeichen>
+RUN_SEED=true              # erzwingt den Seed auch bei nicht-leerer DB
+
+# 2) Container neu starten – der Entrypoint seedet erneut (upsert):
+docker compose up -d
+
+# 3) Login: admin@admin.com / <SEED_ADMIN_PASSWORD>
+# 4) Danach RUN_SEED wieder auf false (sonst re-seedet jeder Restart – harmlos,
+#    aber unnötig). SEED_ADMIN_PASSWORD kann gesetzt bleiben.
+```
+
+> ⚠️ `SEED_ADMIN_PASSWORD` **muss ≥ 25 Zeichen** sein, sonst wird es ignoriert
+> (Passwort-Policy) und der Seed generiert wieder ein Zufallspasswort (→ Logs,
+> siehe oben).
+
+**Portal-Login (Kunde):** Portal-Passwörter werden **nicht** vom Seed gesetzt.
+Nach dem Admin-Login lässt sich in der Kundenakte für einen (Test-)Kunden das
+Portal-Passwort im UI **anzeigen/neu setzen** – damit hat man wieder einen
+bekannten Portal-Zugang für Scoping-Tests.
+
 ## Production-Deployment
 
 Vor dem öffentlichen Schalten der Instanz muss in der Production-`.env`: