Ein Einmalpasswort ist eine der schlichtesten, aber immer noch nützlichen Antworten auf die Frage, ob sich jemand wirklich legitim anmeldet. Es ergänzt die Identitätsprüfung um einen Code mit kurzer Lebensdauer und kann so den Zugriff auf Konten, VPNs, Admin-Oberflächen oder Banking-Prozesse absichern. Ich zeige hier, wie die Technik funktioniert, wo sie im Alltag überzeugt, wo ihre Grenzen liegen und wann ich heute lieber auf passwortlose oder phishing-resistente Verfahren setze.
Ein Einmalpasswort stärkt Zugriff, aber ersetzt keine saubere Sicherheitsarchitektur
- Ein Einmalpasswort ist nur kurz oder nur einmal gültig und erschwert damit die Wiederverwendung abgegriffener Codes.
- Am sinnvollsten ist der Einsatz als zweiter Faktor, vor allem über eine Authenticator-App oder einen Hardware-Token.
- SMS und E-Mail sind bequem, aber deutlich anfälliger für Phishing, SIM-Tausch oder kompromittierte Postfächer.
- Bei zeitbasierten Codes sind 30-Sekunden-Fenster üblich; das ist praktikabel, aber kein vollständiger Schutz gegen Angriffe in Echtzeit.
- Für Admin-Konten, sensible Geschäftsprozesse und hochkritische Zugriffe würde ich heute Passkeys oder Sicherheitsschlüssel vorziehen.
Was ein Einmalpasswort im Zugriffskontext leistet
Technisch geht es nicht um ein dauerhaftes Geheimnis, sondern um einen Code, der nur einmal oder nur für ein enges Zeitfenster gültig ist. Dadurch wird ein abgegriffener Code schnell wertlos. Im Identitäts- und Zugriffsmanagement ist das vor allem ein Schutz gegen Wiederverwendung: Wer den Code mitschneidet, soll damit nicht später noch einmal in das Konto kommen.
Ich trenne dabei immer zwei Fragen: Wer ist die Person? und was darf sie danach tun? Das Einmalpasswort beantwortet nur den ersten Teil und auch das nur im Rahmen des gewählten Verfahrens. Berechtigungen, Rollen und Freigaben bleiben ein eigenes Thema.
Warum OTP oft als zweiter Faktor genutzt wird
Ein Einmalcode ist für sich genommen noch kein perfekter Schutz, aber er erhöht die Hürde deutlich, wenn er mit einem Passwort kombiniert wird. Dann braucht ein Angreifer nicht nur ein geheimes Wissen, sondern zusätzlich Zugriff auf ein zweites Merkmal wie ein Gerät, eine App oder einen Token. Genau deshalb taucht OTP so oft bei Kontoanmeldungen, Remote-Zugriffen und Freigabeschritten auf.
In der Praxis ist das für mich vor allem eine Frage der Risikostufe: Für einfache Nutzerkonten kann OTP schon viel bewirken, für privilegierte Zugriffe reicht es allein oft nicht. Wie das konkret umgesetzt wird, hängt vom Verfahren ab.Wie die Technik in der Praxis arbeitet
Im Betrieb sehe ich drei Muster: zeitbasierte Codes, ereignisbasierte Codes und vorab erzeugte Listen. Alle drei verfolgen das gleiche Ziel, unterscheiden sich aber stark in Bedienung, Synchronisation und Angriffsfestigkeit.
TOTP
Bei TOTP wird der Code aus einem geheimen Startwert und der Uhrzeit berechnet. Typisch sind kurze Zeitfenster von 30 Sekunden, damit der Code schnell rotiert und die Nutzererfahrung trotzdem brauchbar bleibt. Der Vorteil: Die App oder das Token kann oft auch ohne Netzverbindung arbeiten. Der Nachteil: Uhrzeit und Synchronisation müssen halbwegs stimmen, sonst entstehen unnötige Fehlermeldungen.
HOTP
HOTP arbeitet mit einem Zähler statt mit der Uhr. Jeder neue Code entsteht erst durch ein Ereignis, also zum Beispiel durch das nächste Drücken eines Tokens oder durch einen neuen Authentifizierungsvorgang. Das ist praktisch, wenn Zeit nicht sauber synchronisiert werden kann, bringt aber das Problem der Zähler- und Resynchronisationslogik mit sich.
Lesen Sie auch: Google Passwortmanager deaktivieren - So geht's richtig
Zustellcodes und vorab erzeugte Listen
Ein anderer Ansatz sind Einmalkennwörter aus einer Liste oder Codes, die per SMS oder E-Mail zugestellt werden. Das ist für viele Nutzer leicht verständlich und schnell eingeführt, aber die Sicherheit hängt dann stark am Zustellkanal. Ein kompromittiertes Postfach oder eine umgeleitete Mobilfunknummer kippt das Modell schnell.
| Verfahren | Typische Nutzung | Stärke | Grenze |
|---|---|---|---|
| TOTP | Authenticator-App, Hardware-Token | Breit etabliert, offline nutzbar | Phishing und Echtzeit-Weitergabe bleiben möglich |
| HOTP | Token mit Ereigniszähler | Unabhängig von der Uhrzeit | Zähler kann aus dem Tritt geraten |
| Look-up-Codes | Banking, Recovery, Sonderfälle | Einfach zu verteilen | Listen müssen sehr sauber geschützt werden |
| SMS oder E-Mail | Einfacher Einstieg, Übergangslösung | Niedrige Einstiegshürde | Stärker von Kanal- und Gerätekompromittierung abhängig |
Genau daraus ergeben sich die typischen Einsatzfelder. Sobald die Anmeldung an echte Identität, Zugriff und Folgerisiko gekoppelt ist, entscheidet nicht nur der Code selbst, sondern auch das Verfahren dahinter.
Wo es in Identität und Zugriff wirklich eingesetzt wird
Ein Einmalpasswort ist kein Nischenwerkzeug. Ich sehe es vor allem dort, wo ein zusätzlicher Nachweis gebraucht wird, ohne den kompletten Login-Prozess neu zu bauen.
- Privatkunden-Logins für E-Mail, Shops oder Portale: Ein Code ergänzt das Passwort und stoppt viele einfache Übernahmen von Konten.
- Step-up-Authentisierung bei kritischen Aktionen: Ein zusätzlicher Code vor einer Passwortänderung, einer Zahlungsfreigabe oder einem Gerätewechsel ist sinnvoll, weil hier das Schadenspotenzial höher ist.
- VPN und Remote Access: Für interne Zugänge ist OTP ein pragmatischer Zusatz, wenn noch kein stärkeres Verfahren ausgerollt ist.
- Admin-Konten: Als Mindestschutz besser als nur Passwort, aber bei hohen Berechtigungen würde ich weiter nachrüsten.
- Banking und Transaktionen: Hier geht es nicht nur um Login, sondern oft um die Bestätigung einzelner Vorgänge. Das ist ein gutes Beispiel dafür, wie Authentisierung und Autorisierung zusammenlaufen.
Ich halte diesen Einsatz für sinnvoll, solange klar ist, dass der Code nur eine Schutzschicht ist. Sobald ein Prozess geschäftskritisch oder missbrauchsanfällig wird, muss der zweite Faktor robuster sein als ein leicht weiterleitbarer Code.
Sicherheit und Grenzen, die man nicht wegdiskutieren sollte
Ein Einmalcode verbessert die Lage gegenüber einem nackten Passwort, aber er ist nicht automatisch phishing-resistent. Wenn ein Angreifer den Code in Echtzeit abgreift, kann er ihn oft direkt im eigenen Anmeldefenster nutzen. Genau deshalb sind SMS und E-Mail als alleinige Schutzschicht schwächer, als viele Teams annehmen.
Das BSI rät deshalb klar dazu, die Zwei-Faktor-Authentisierung nicht zu deaktivieren. Für mich heißt das aber nicht, dass jede Form von OTP gleich gut ist. Ich schaue immer auf den Kanal, das Recovery-Konzept und die Frage, ob der Code an die konkrete Sitzung gebunden ist.
- Phishing in Echtzeit: Ein gefälschter Login kann den Code direkt an den echten Dienst weiterreichen.
- SIM-Swapping: Bei SMS-Codes ist die Mobilfunknummer selbst ein Angriffspunkt.
- Mailbox-Kompromittierung: Wer das Postfach kontrolliert, kontrolliert oft auch den E-Mail-Code.
- Endpoint-Malware: Schadsoftware auf dem Gerät kann Codes mitlesen oder den Login-Prozess missbrauchen.
- Replays im Zeitfenster: Je großzügiger das Akzeptanzfenster, desto größer die Angriffsfläche.
Nach NIST gelten manuell eingegebene OTPs nicht als phishing-resistent, weil sie sich von einer gefälschten Seite in Echtzeit abfangen und weiterverwenden lassen. Darum muss man OTP immer als Schutzschicht, nicht als Endpunkt verstehen.
So setze ich OTP sinnvoll ein
Wenn ich Einmalcodes in einer Umgebung empfehle, dann nicht halbherzig. Der Nutzen steht und fällt mit einigen einfachen, aber konsequenten Regeln.
- Bevorzuge App oder Hardware-Token. SMS und E-Mail sind bequem, aber für sensible Zugriffe nicht meine erste Wahl.
- Halte das Zeitfenster knapp. Bei TOTP sind kurze Fenster üblich; zu große Toleranz macht den Schutz weich.
- Schütze die Registrierung. Der erste Faktor, mit dem ein OTP-Gerät oder eine App angebunden wird, sollte selbst schon sauber abgesichert sein.
- Plane Recovery von Anfang an. Backup-Codes, Ersatzgerät und Support-Prozess gehören fest dazu, sonst wird der zweite Faktor beim Geräteverlust zum Betriebsproblem.
- Begrenze Fehlversuche und protokolliere Änderungen. Wer Codes mehrfach falsch eingibt oder Faktoren neu bindet, sollte in den Logs sichtbar werden.
- Achte auf saubere Synchronisation. Gerade bei zeitbasierten Verfahren vermeiden gute Drift-Reserven Supportfälle, ohne das Fenster unnötig groß zu machen.
Ich sehe hier oft die eigentliche Schwachstelle: Nicht der Code selbst scheitert, sondern der Umweg um den Code herum. Deshalb ist Recovery fast genauso wichtig wie der Login.
Wann ich heute lieber Passkeys oder Sicherheitsschlüssel nehme
Für neue Zugriffe in 2026 ist meine Schwelle höher als früher. Wenn ein System Passkeys oder FIDO2-Sicherheitsschlüssel kann, nehme ich das in der Regel vor OTP, besonders für Admins, Finanzen, Support-Desks und andere Konten mit hohem Schadenpotenzial.
| Kriterium | OTP | Passkey oder Sicherheitsschlüssel |
|---|---|---|
| Phishing-Schutz | Begrenzt | Sehr hoch |
| Bedienung | Bekannt, aber oft manuell | Meist schneller und weniger fehleranfällig |
| Abhängigkeit vom Kanal | App, SMS, E-Mail oder Token | Meist direkt am Gerät oder Schlüssel |
| Recovery-Aufwand | Oft über Support und Ersatzcodes | Planung nötig, aber sauberer strukturiert |
OTP bleibt sinnvoll, wenn eine Plattform noch keine besseren Optionen bietet oder wenn ein zusätzlicher, pragmatischer Schutz gebraucht wird. Aber wenn ich eine neue Architektur entwerfe, beginne ich nicht mit Codes, sondern mit der Frage, ob die Anmeldung direkt phishing-resistent gebaut werden kann. Das spart später meist Supportaufwand und senkt das Risiko von Kontoübernahmen deutlich.
Was bei Recovery und Notfallzugriff wirklich zählt
Am Ende entscheidet selten der Einmalcode allein. Entscheidend ist, ob die Kette aus Registrierung, zusätzlichem Faktor, Wiederherstellung, Protokollierung und Notfallzugriff sauber gebaut ist. Ein gutes System scheitert in der Praxis oft nicht am Login, sondern daran, dass ein Gerät verloren geht und niemand den Ersatzprozess versteht.
Wenn ich eine Umgebung neu bewerte, frage ich deshalb zuerst nach Backup-Codes, getrennten Recovery-Wege und klaren Berechtigungen für Support und Admins. Wer das sauber definiert, kann mit OTP einen soliden Basisschutz aufbauen. Wer es nicht tut, hat schnell ein scheinbar sicheres System, das im Ernstfall unpraktisch oder angreifbar wird.
