MFA zu einer Prototyp‑App hinzufügen, ohne Anmeldungen zu unterbrechen

Warum MFA bei Prototyp‑Logins so oft Probleme macht

MFA in eine Prototyp‑App einzuführen ist nicht „nur ein zusätzlicher Bildschirm“. Es ändert die Regeln dafür, wer sich einloggen kann, was passiert, wenn etwas schiefgeht, und wie viele Randfälle dein Login‑Flow abdecken muss.

Prototyp‑Codebasen haben oft fragile Authentifizierung: gemischte Sessions und Tokens, keine klare Quelle der Wahrheit für den Nutzer und Abkürzungen wie übersprungene E‑Mail‑Verifikation oder wiederverwendete Einmal‑Codes. MFA macht diese Abkürzungen schnell sichtbar. Eine kleine Unstimmigkeit (TOTP‑Zeitabweichung, doppelte Benutzer‑Einträge oder ein Rennen zwischen „Passwort prüfen“ und „Session erstellen") kann echte Nutzer aussperren.

„Anmeldungen nicht kaputtmachen“ bedeutet mehr als „der Happy Path funktioniert“. Menschen müssen sich weiterhin auf älteren Geräten und Browsern anmelden können, es muss einen sicheren Weg zurückgeben, falls der zweite Faktor verloren geht, und deine Support‑Last darf nicht wegen massenhaft „Ich bin ausgesperrt“-Tickets explodieren.

Bevor du etwas änderst, miss deine Ausgangswerte, damit du sehen kannst, ob MFA geholfen oder geschadet hat. Verfolge ein paar Kennzahlen über mehrere Tage: Anmeldeerfolgsrate, Abbrüche pro Schritt (Passwort eingegeben, Code‑Eingabe angezeigt, Code akzeptiert), Lockout‑Ereignisse und abgeschlossene Passwort‑Resets sowie die mittlere Zeit bis zur Anmeldung.

Entscheide auch, wen du zuerst schützen willst. MFA sofort für alle zu erzwingen erhöht Reibung und Support. Ein sichererer Startpunkt sind Hochrisiko‑Konten wie Admins, Abrechnungszugriff und alle, die Sicherheitseinstellungen ändern können. Das liefert echte Daten, ohne dein gesamtes Login in einen Alarmzustand zu versetzen.

MFA‑Grundlagen und wo es in deinem Login‑Flow sitzt

MFA (Mehrfaktor‑Authentifizierung) bedeutet, dass du dich mit zwei unterschiedlichen Arten von Nachweisen identifizierst. Üblich ist ein Passwort (etwas, das du weißt) plus ein Code oder Geräte‑Bestätigung (etwas, das du hast). Der „zweite Faktor“ ist diese zusätzliche Prüfung. „Step‑up‑Auth“ bedeutet, MFA nur bei risikoreichen Aktionen zu verlangen, z. B. beim Ändern einer E‑Mail oder beim Anzeigen von Abrechnungsdaten. „Recovery“ ist die Notfalloption, falls du den Faktor verlierst.

Der sicherste Ort, MFA in einer Prototyp‑App einzufügen, ist nachdem der erste Login‑Schritt erfolgreich war. So bleibt dein bestehender Passwort‑ oder OAuth‑Flow intakt.

Wo MFA im Flow sitzt

Bei Passwort‑Logins: Der Nutzer gibt E‑Mail und Passwort ein, du prüfst sie, und dann prüfst du, ob MFA aktiviert ist. Falls ja, forderst du TOTP oder eine Passkey‑Bestätigung an, bevor du die vollständige Session erstellst.

Bei OAuth‑Logins (Google, GitHub usw.): Du schließt den Provider‑Callback ab, verbindest oder erstellst den Nutzer und setzt dann MFA durch, bevor du dein Session‑Cookie oder Token ausgibst.

Die Kernidee: Logge dich nicht „halb ein“ und hoffe, du kommst wieder raus, wenn MFA scheitert. Entscheide genau, wann ein Nutzer vollständig authentifiziert ist, und mache MFA zu einem Teil dieser Entscheidung.

Was sich in deiner Datenbank ändert

Halte MFA‑Daten getrennt von Passwort‑Daten und behandle sie als sensibel.

Du brauchst typischerweise ein einfaches Aktiviert‑Flag und einen Einschreibungszeitstempel, die gewählte Methode (TOTP, Passkey, keine) und methodenspezifische Metadaten sowie das Minimum an Material, das du zur Verifikation zukünftiger Challenges brauchst (z. B. ein verschlüsseltes TOTP‑Secret oder Passkey‑Credential‑IDs). Füge Hashes der Wiederherstellungscodes hinzu (nicht im Klartext), ein Feld pro Code für „verwendet“, und optional ein Feld wie last_mfa_verified_at, wenn du Step‑up‑Regeln durchsetzen willst.

Was du zum Troubleshooting loggen solltest

Gute Logs ermöglichen das Debuggen von Lockouts, ohne Geheimnisse preiszugeben. Logge Ereignisse wie „MFA‑Challenge erstellt“, „MFA‑Verifikation fehlgeschlagen“ und „Wiederherstellungscode verwendet“ sowie Nutzer‑ID, Zeitstempel, IP und User‑Agent. Logge nie TOTP‑Codes, Secrets, rohe Wiederherstellungscodes oder komplette OAuth‑Tokens.

TOTP oder Passkeys für eine Prototyp‑App wählen

Wenn du MFA zu einem Prototyp hinzufügst, ist die Wahl oft zwischen TOTP (Authenticator‑Codes) und Passkeys (biometrische oder gerätebasierte Anmeldung). Beide funktionieren, fallen aber unterschiedlich aus.

TOTP ist das klassische „6‑stellige Zahl eingeben“. Nutzer scannen einen QR‑Code mit einer Authenticator‑App und geben dann einen Code beim Login ein. Auf deiner Seite speicherst du ein geteiltes Secret pro Nutzer (verschlüsselt) plus ein paar Audit‑Felder wie Aktivierungs‑ und letztes Nutzungsdatum. Häufige Fehlerursachen: Nutzer verlieren ihr Telefon, Gerätezeit ist nicht synchron, sie melden sich zweimal an und überschreiben das Secret, oder deine App erlaubt versehentlich das Einloggen, ohne den zweiten Faktor zu prüfen.

Passkeys wirken einfacher. Nutzer bestätigen mit Face ID, Fingerabdruck oder Geräte‑PIN. Du speicherst einen öffentlichen Schlüssel und eine Credential‑ID, kein geteiltes Secret. Die Fehler verschieben sich: Abhängigkeit vom Gerät (kein Zugriff), verwirrende geräteübergreifende Einrichtung oder „funktioniert auf Laptop, nicht auf Handy“, wenn Passkeys nicht wie erwartet synchronisiert werden.

Eine praktische Regel ist einfach: Wähle TOTP, wenn vorhersehbarer geräteübergreifender Zugriff nötig ist (Admins, Support, B2B‑Tools) und du nicht von modernen Geräten ausgehen kannst. Wähle Passkeys, wenn du das glatteste Consumer‑Login willst und akzeptieren kannst, dass Recovery extra Aufmerksamkeit braucht. Unterstütze beide, wenn deine Nutzer gemischt sind, aber konzentriere die UI: Empfehle eine Standardoption („Verwende Passkeys auf diesem Gerät“) und biete die andere klar als Fallback an („Verwende stattdessen eine Authenticator‑App“).

Beispiel: Ein Zwei‑Personen‑Startup mit einem internen Admin‑Panel könnte zuerst TOTP wählen (funktioniert überall) und später Passkeys hinzufügen, ohne die Richtlinie für Admin‑Konten zu ändern.

Enrollment‑Flow, der Lockouts vermeidet

Das größte Risiko bei der Einrichtung ist, MFA zu früh zu aktivieren. Wenn du das „MFA aktiviert“‑Flag umlegst, bevor der Nutzer beweist, dass es funktioniert, kann ein Prototyp‑Login‑Flow sie in einer Schleife einsperren: „Code eingeben“, aber kein funktionierender Authenticator, eine Passkey‑Abfrage, die nie erscheint, oder eine Session, die verloren geht.

Ein sicheres Muster ist, Enrollment wie einen Test zu behandeln und MFA erst nach erfolgreicher Verifikation zu aktivieren. Diese eine Regel verhindert die meisten Lockouts.

Ein lockout‑sicheres Enrollment‑Muster

Halte den Flow linear und nachsichtig. Starte die Einrichtung, während der Nutzer frisch eingeloggt ist (aktive Session). Lass ihn den Faktor einrichten (TOTP‑QR scannen oder Passkey erstellen) und verifiziere ihn sofort einmal (TOTP‑Code eingeben oder Passkey‑Bestätigung). Zeige danach die Wiederherstellungscodes und fordere eine explizite Bestätigung wie „Ich habe sie gespeichert“. Erst dann markiere MFA als aktiviert und zeige einen klaren Erfolgsbildschirm.

Gute Texte reduzieren Support‑Tickets. Sei konkret: „Scanne diesen QR‑Code in Google Authenticator oder 1Password. Gib dann den 6‑stelligen Code zur Bestätigung ein. Wenn du diesen Tab vor der Bestätigung schließt, wird MFA nicht aktiviert.“

Randfälle, die du vorher behandeln solltest

TOTP fällt oft wegen Zeitabweichung aus. Wenn ein Code abgelehnt wird, sag den Nutzern, sie sollen die Zeit ihres Telefons auf automatisch stellen, und erlaube einen zweiten Versuch, bevor ein Neustart erforderlich ist.

Passkeys können scheitern, wenn das Gerät fehlt oder die Abfrage blockiert wird. Biete während der Einrichtung einen Backup‑Pfad an: „Du kannst jetzt keinen Passkey benutzen? Nutze stattdessen eine Authenticator‑App.“ Stelle sicher, dass Wiederherstellungscodes funktionieren, selbst wenn das Passkey‑Gerät verloren geht.

Wiederherstellungscodes: Einrichtung, Speicherung und Regeneration

Wiederherstellungscodes sind die Notfalloption, wenn MFA versagt: Telefon weg, Authenticator‑App gelöscht oder Passkey nicht verfügbar. Sie sind Ersatzschlüssel, nicht die tägliche Anmeldemethode. Zeige sie direkt nach erfolgreichem MFA‑Enrollment und mach deutlich, dass jetzt der Moment ist, sie zu sichern.

Halte die Anzahl so klein, dass Leute sie wirklich speichern. Zehn Einmal‑Codes sind ein gängiger Kompromiss für einen Prototyp: reichen für ein paar schlechte Tage, ohne zu lang zu werden, sodass Nutzer sie ignorieren. Biete Kopieren und Herunterladen an, aber fordere vor dem Anzeigen oder Regenerieren der Codes eine starke Überprüfung (Passwort oder aktuelles MFA).

Der größte Fehler ist, Wiederherstellungscodes im Klartext zu speichern. Speichere nur gehashte Versionen (wie Passwörter) und führe ein klares verwendet vs. unbenutzt‑Feld, damit jeder Code einmal funktioniert und dann verfällt.

Ein sicheres Speicher‑Modell ist einfach: Generiere 8–10 zufällige Codes, speichere jeden als Hash plus ein used_at‑Timestamp (null bis zur Nutzung), rate‑limite Versuche und sperre das Recovery‑Formular vorübergehend nach wiederholten Fehlschlägen. Logge die Nutzung eines Wiederherstellungscodes als Sicherheitsereignis.

Regeneration sollte strikt sein. Wenn ein Nutzer neue Wiederherstellungscodes erzeugt, invalidiere sofort alle alten, auch unbenutzte. Warne deutlich: „Deine vorherigen Codes funktionieren jetzt nicht mehr.“ Erlaube Regeneration nur nach einer starken Prüfung (aktuelles MFA oder eine kürzlich verifizierte Anmeldung), damit jemand mit gestohlenem Passwort nicht heimlich die Codes ersetzt.

MFA phasenweise ausrollen mit klaren Fallback‑Pfaden

Alles auf einmal durchzusetzen führt meist zu einer Welle von Lockouts. Ein phasenweiser Rollout senkt das Risiko und zeigt, wo echte Nutzer hängen bleiben.

Ein Plan, der für die meisten kleinen Apps passt:

• Opt‑in: Nutzer nach dem Login zur Aktivierung aufrufen, mit klarer Überspringen‑Option.
• Pflicht für Admins und Mitarbeiter: Schütze zuerst Hochrisiko‑Konten.
• Pflicht für alle: Erst wenn Enrollment und Wiederherstellung langweilig stabil laufen.
• Step‑up‑only: MFA nur bei risikoreichen Aktionen verwenden (E‑Mail ändern, Daten exportieren, Abrechnung einsehen), selbst wenn der Login passwortbasiert bleibt.

Jede Phase braucht einen sicheren Fallback, sonst wird der Support überflutet. Ziel: mindestens zwei Rückwege – eine Selbstbedienungs‑Option und eine menschliche Option.

Fallback‑Pfade, die Lockouts verhindern

Plane diese, bevor du etwas durchsetzt. Wiederherstellungscodes sind das Minimum. Ein Backup‑Faktor hilft ebenfalls (TOTP plus Passkey oder zwei Passkeys). Wenn du supportgestützte Resets anbietest, definiere klare Identitätsprüfungen und eine Abkühlzeit, bevor MFA entfernt wird. Eine kurze Schonfrist nach der Einrichtung kann falsche Lockouts reduzieren, aber halte sie eng begrenzt (z. B. „einmal überspringen“), damit sie nicht zur dauerhaften Umgehung wird.

Feature‑Flags und Kommunikation

Nutze Feature‑Flags: zuerst intern, dann kleine Kohorten (5 %, 20 %, 50 %). Beobachte Enrollment‑Abschlussraten, MFA‑Challenge‑Fehlschläge und „kann nicht auf Konto zugreifen“‑Tickets.

Sag den Nutzern kurz, was sich ändert und was zu tun ist. Eine kurze In‑App‑Nachricht ist besser als eine lange Ankündigung: „Nächste Woche wirst du nach einem zusätzlichen Code gefragt. Sichere jetzt deine Wiederherstellungscodes."

Resets und Kontoänderungen MFA‑sicher gestalten

Der einfachste Weg, MFA auszuhebeln, ist, sie über Kontoänderungen zu umgehen. Behandle Resets und Profiländerungen als Sicherheitsereignisse, nicht als einfache Form‑Updates.

Passwort‑Reset sollte MFA nicht deaktivieren

Passwort‑Resets sind angreiferfreundlich, weil Postfächer kompromittiert werden können. Nach einem erfolgreichen Reset lass MFA an und fordere beim nächsten Login eine Step‑up‑Prüfung. Wenn du erlaubst, MFA zurückzusetzen, mache daraus eine separate Aktion, die nach dem Setzen des neuen Passworts eine MFA‑Challenge (oder einen Wiederherstellungscode) erfordert.

Gute Regel: Ein Passwortwechsel kann beim Wiedererlangen von Zugriff helfen, sollte aber nicht die Macht geben, MFA zu entfernen.

Schütze risikoreiche Kontoänderungen mit Step‑up‑Checks

Manche Änderungen sollten immer eine zusätzliche Verifikation verlangen, z. B. E‑Mail‑Änderungen, neue Geräte‑Enrollments, Entfernen oder Ersetzen von MFA‑Methoden, Telefonnummernänderungen (falls SMS als Backup genutzt wird) und Änderungen an Auszahlungs‑ oder Abrechnungsdaten.

Wenn ein Nutzer seine E‑Mail ändert, sende eine Bestätigung an die alte E‑Mail und halte die alte Adresse aktiv, bis die Änderung bestätigt ist. Falls die alte E‑Mail nicht zugänglich ist, verlange Wiederherstellungscodes und eine kurze Support‑Prüfung.

Sessions, „Dieses Gerät merken“ und Tokens

„Dieses Gerät merken“ ist in Ordnung, aber begrenze es. Setze klare Zeitlimits (oft 14–30 Tage), zwinge bei risikoreichen Aktionen zur erneuten Authentifizierung, und mache Widerruf vorhersehbar: globales Sign‑out nach Passwortwechsel, erneute Prüfung oder Widerruf von Sessions, wenn MFA aktiviert oder ersetzt wird, und eine einfache „aktive Sessions“-Liste mit Widerrufsbutton.

Für API‑Tokens und Integrationen entscheide, ob sie an eine Nutzersession gebunden sind (dann sollte MFA die Erstellung und Scope‑Änderungen absichern) oder langfristige Schlüssel (dann verlasse dich auf enge Scopes, Ablaufzeiten und Rotation statt MFA bei jedem Aufruf zu erzwingen).

Häufige Fehler, die zu Lockouts und Support‑Chaos führen

Die meisten MFA‑Probleme sind nicht mathematisch. Sie entstehen, weil die „Was, wenn ich mich nicht anmelden kann?“‑Wege nie fertiggedacht wurden.

Fehler 1: MFA aktivieren, bevor Recovery funktioniert

Teams bringen die MFA‑Abfrage, lassen aber Wiederherstellungscodes ungetestet, unauffindbar oder auf Mobilgeräten kaputt. Das Ergebnis sind sofortige Lockouts.

Teste Recovery End‑to‑End mit einem frischen Konto und einem „Telefon verloren“‑Szenario: Codes generieren, einen nutzen, neu generieren und bestätigen, dass alte Codes nicht mehr funktionieren.

Fehler 2: Secrets wie normale Daten behandeln

TOTP‑Seeds und Wiederherstellungscodes sind keine normalen Benutzerdaten. Wenn sie im Klartext gespeichert, in Logs kopiert oder später nochmal angezeigt werden, kann ein Leak Account‑Übernahmen ermöglichen.

Speichere nur das Nötigste, schütze es wie ein Passwort und zeige Wiederherstellungscodes nach der Einrichtung nicht wieder an. Nutzer müssen sie bei Bedarf neu generieren.

Fehler 3: „Support kann das einfach umgehen"

Ein manueller MFA‑Bypass wirkt hilfreich, bis er der leichteste Weg ist, in Konten zu kommen. Wenn ein Bypass nötig ist, mache ihn zeitlich begrenzt, erfordere Prüfungen und hinterlasse eine prüfbare Audit‑Spur.

Fehler 4: Schwache TOTP‑Handhabung

TOTP‑Fehler kommen oft von Zeitdrift, Wiederverwendung und fehlenden Rate‑Limits. Ein Code zweimal zu akzeptieren oder zu breite Zeitfenster zuzulassen, erleichtert Brute‑Force und Replay.

Halte es einfach: erlaub ein kleines Zeitfenster, blockiere Code‑Wiederverwendung innerhalb dieses Fensters, rate‑limite Versuche, nutze temporäre Sperren (keine permanenten Sperren) und zeige klare Fehler für „falsch“ vs. „abgelaufen“.

Fehler 5: Annehmen, Passkeys verhalten sich überall gleich

Passkeys können auf überraschende Weise scheitern: Gerätewechsel, unterschiedliche Browser‑Unterstützung oder Nutzer ohne synchronisierte Credentials. Wenn deine App Passkeys verlangt, aber keinen Backup‑Plan hat, sperrst du echte Menschen aus.

Behalte einen klaren Fallback (TOTP oder Wiederherstellungscodes) und teste auf mindestens einem iOS‑Gerät, einem Android‑Gerät und einem Desktop‑Browser.

Schnelle Checkliste vor dem Rollout von MFA

Eine langweilige Gewohnheit spart später Ärger: Stell sicher, dass du sehen kannst, was passiert, und es schnell rückgängig machen kannst.

Pre‑Launch‑Checks (damit du schnell wiederherstellen kannst)

Stelle sicher, dass du die MFA‑Änderung zurückrollen kannst (Feature‑Flag, Konfigurationsschalter oder schnelles Deploy). Schalte Audit‑Logs für Schlüsselerereignisse wie Enrollment, Verifikation, Fehler, Lockout, Wiederherstellungs‑Code‑Nutzung und Deaktivierung ein. Sichere die User‑Tabelle (und MFA‑bezogene Tabellen) und übe das Wiederherstellen auf eine sichere Kopie. Verifiziere, dass dein Error‑Tracking Auth‑Fehler mit genug Details erfasst, um zu debuggen, ohne Secrets oder Codes zu loggen. Teste Session‑Widerruf, sodass alte Sessions neu geprüft oder ausgeloggt werden, wenn MFA‑Einstellungen sich ändern.

Dann teste Benutzerpfade End‑to‑End. Hör nicht bei „Code akzeptiert“ auf. Folge dem vollen Weg bis zum ersten Bildschirm nach dem Login.

Nutzer‑Szenarien und Sicherheitschecks

Spiele ein paar Szenarien durch:

• Ein neuer Nutzer richtet MFA ein und meldet sich dann auf einem zweiten Gerät an.
• Ein bestehender Nutzer aktiviert MFA, loggt sich aus und wieder ein mit „Dieses Gerät merken“ an/aus.
• Verlorenes Telefon: ein Wiederherstellungscode funktioniert einmal, dann regeneriert der Nutzer Codes und richtet neu ein.
• E‑Mail‑Änderung und Passwort‑Reset‑Flows erfordern MFA (oder eine sichere Step‑up) bevor sie wirksam werden.
• Missbrauchsresistenz: Rate‑Limits für Passwort‑Versuche und MFA‑Code‑Versuche plus temporäre Sperren, die das Konto nicht dauerhaft bricksen.

Bereite dich auf das erste Support‑Ticket vor mit einem kurzen Skript: was zu fragen ist, was in den Logs zu prüfen ist und wann zu eskalieren.

Beispiel‑Rollout für eine einfache Prototyp‑App

Stell dir eine kleine SaaS‑Prototyp vor: Nutzer melden sich mit E‑Mail und Passwort an, es gibt ein Admin‑Bereich für Abrechnung, Nutzerverwaltung und Support‑Tools. Du willst mehr Sicherheit, darfst aber niemanden aussperren.

Beginne damit, die risikoreichsten Konten zuerst zu schützen (Admins), und erweitere auf alle, wenn der Flow langweilig zuverlässig läuft.

Phase 1: Optionales TOTP für Admins

Aktiviere TOTP zunächst nur für Admins und freiwillig. Platziere die Aufforderung in den Admin‑Einstellungen, nicht mitten im hektischen Login.

Ein einfacher Ablauf: Admin richtet TOTP ein, sieht einmalig Wiederherstellungscodes, bestätigt einen TOTP‑Code, und das nächste Login verlangt Passwort plus TOTP. Falls TOTP fehlschlägt, bringt ein Wiederherstellungscode wieder rein.

Stelle sicher, dass es immer einen Weg zurück gibt. Wenn ein Admin MFA nicht abschließen kann, sollte er sich mit Passwort anmelden und temporären Supportkontakt haben können, statt hart blockiert zu werden.

Phase 2: Passkeys für reguläre Nutzer, TOTP als Backup

Sobald Admins stabil sind, biete Passkeys regulären Nutzern als einfachen Weg an. Halte TOTP als Backup für Leute, die Passkeys nicht nutzen können (ältere Geräte, geteilte Rechner).

Rolle es vorsichtig aus: Zuerst „Passkey hinzufügen“ nach dem Login anbieten, später MFA standardmäßig für neue Anmeldungen aktivieren.

Ein echter Fehler, sauber gehandhabt

Ein Nutzer verliert sein Telefon und hat keinen TOTP‑Zugang. Er meldet sich mit E‑Mail und Passwort an, wählt „Wiederherstellungscode verwenden“ und kommt rein. Direkt danach forderst du ihn auf, einen neuen Passkey (oder neues TOTP) zu registrieren und Wiederherstellungscodes zu regenerieren. Entferne die alte MFA‑Methode erst, nachdem die neue bestätigt ist.

Nächste Schritte und wann du Hilfe holen solltest

Wenn du MFA ohne kaputte Logins willst, starte mit einem kurzen Plan, den dein Team teilt: Wer bekommt MFA zuerst, wie meldet sich jemand an, wenn MFA versagt, und wie sieht Erfolg aus (weniger riskante Logins, nicht mehr Support‑Tickets).

Führe einen kleinen internen Rollout mit echten Accounts, echten Geräten und echten Bedingungen durch (neues Telefon, verlorenes Telefon, Zeitdrift, Privacy‑Modus im Browser). Halte das Pilotprojekt klein genug, dass du jedes Scheitern beobachten und schnell beheben kannst.

Schreibe ein paar Dinge vorher fest, bevor du etwas umlegst: Umfang Phase 1, Fallback‑Optionen, was du loggst und überprüfst, wer resetten oder überschreiben darf und welchen Nachweis er braucht, und wann die Durchsetzung startet (plus wie Nutzer gewarnt werden). Nach dem Rollout beobachte frühzeitig Reibung. Spitzen bei „ungültiger Code“ deuten oft auf Zeitdrift, verwirrenden Text oder falsches Enrollment‑Gerät hin. Spitzen bei Wiederherstellungs‑Code‑Nutzung können darauf hindeuten, dass Passkey‑ oder TOTP‑Enrollment nicht hält.

Hol dir Hilfe, wenn du wiederholt Lockouts siehst, unklare Zuständigkeiten für Reset‑Workflows existieren oder Anzeichen dafür da sind, dass deine Auth‑Logik fragil ist (hardcodierte Secrets, inkonsistente Sessions oder merkwürdige Umgehungen). Wenn du ein AI‑generiertes Prototype geerbt hast, kann FixMyMess (fixmymess.ai) ein kostenloses Code‑Audit durchführen, um die Lockout‑Risiken und die genauen Stellen zu identifizieren, an denen dein aktueller Auth‑Flow MFA umgehen oder brechen kann, bevor du sie für alle durchsetzt.