SMS-Einmalcodes - Sicher oder Risiko? Das müssen Sie wissen

Ein Einmalcode per SMS ist bequem, weil er ohne zusätzliche App funktioniert und die Anmeldung schnell um einen zweiten Nachweis ergänzt. Genau diese Einfachheit macht ihn für Logins, Passwort-Resets und Freigaben so verbreitet, aber auch angreifbar. In diesem Beitrag ordne ich ein, wann dieser Ansatz sinnvoll ist, wo seine Grenzen liegen und welche Verfahren für Identität und Zugriff heute robuster sind.

Was ein SMS-Einmalcode im Zugriffskontext wirklich leistet

Ein SMS-Einmalcode ist technisch ein kurzer, einmalig gültiger Nachweis, der an ein Mobiltelefon gesendet wird. Im Kontext von Identität und Zugriff ersetzt er kein Passwort, sondern ergänzt es als zweiten Faktor, also als zusätzlichen Beleg für die Kontrolle über einen Kanal. In vielen Systemen ist das ein klassischer Schritt bei der Anmeldung, beim Zurücksetzen eines Passworts oder beim Freigeben sensibler Aktionen.

Ich sehe den eigentlichen Nutzen vor allem dort, wo eine Organisation die Hürde niedrig halten muss. Nutzer müssen nichts installieren, fast jedes Telefon kann SMS empfangen, und der Einstieg ist für Support-Teams leicht erklärbar. Genau deshalb taucht das Verfahren seit Jahren in Verbraucherportalen, Banken und älteren Identity-Flows auf. Für hochkritische Zugriffe ist das aber nur die halbe Wahrheit, denn ein empfangener Code beweist nicht automatisch, dass die richtige Person und nicht nur die richtige Nummer am Werk ist.

Im Idealfall ist der Code deshalb nicht einfach nur an ein Konto gebunden, sondern an die konkrete Sitzung oder Transaktion. Sonst entsteht ein zu breiter Vertrauensbereich, und der Angreifer muss nur den Code im richtigen Moment abgreifen. Von hier aus ist der Schritt zu den praktischen Abläufen klein, aber sicherheitsrelevant.

So läuft die Anmeldung mit dem Code ab

Der Standardablauf ist simpel: Zuerst gibt der Nutzer seinen Benutzernamen und sein Passwort ein. Danach fordert das System einen SMS-Code an, der an die registrierte Nummer gesendet wird. Der Nutzer tippt den Code in ein Formular ein, und der Server prüft, ob er korrekt, noch gültig und noch nicht benutzt ist.

1. Die Anwendung erzeugt einen zufälligen Einmalcode.
2. Der Code wird nur für eine kurze Zeit freigegeben, meist für wenige Minuten.
3. Er wird an die registrierte Nummer gesendet und auf dem Server an die laufende Sitzung gebunden.
4. Der Nutzer überträgt den Code manuell in das Login- oder Freigabefeld.
5. Das System akzeptiert ihn nur einmal und verwirft ihn nach erfolgreicher Prüfung.

Wichtig ist dabei die Bindung an den konkreten Vorgang. Wenn ein Code nur zeigt, dass jemand ein Telefon besitzt, ist das schwächer als ein Code, der zusätzlich an die aktuelle Sitzung, das Gerät oder sogar an eine einzelne Überweisung gekoppelt ist. Genau an dieser Stelle trennt sich saubere Implementierung von bloßer Bequemlichkeit.

Für reine Komfortzwecke reicht das Muster oft aus. Sobald aber Risikostufen, Berechtigungen oder sensible Kontodaten ins Spiel kommen, würde ich diesen Schritt nie isoliert betrachten. Das führt direkt zur Frage, warum das Verfahren so populär ist und trotzdem nicht als starke Sicherheitslinie gilt.

Warum das Verfahren bequem ist und trotzdem nicht phishing-resistent

SMS-Codes sind beliebt, weil sie auf nahezu jedem Endgerät funktionieren und wenig Reibung erzeugen. Es gibt keine zusätzliche App, keine Hardware, keine Erklärung für neue Benutzer und meist auch keine komplizierte Registrierung. Für schnelle Massenrollouts ist das attraktiv, gerade wenn Supportkosten niedrig gehalten werden sollen.

Das Problem ist die Sicherheitslogik dahinter. Ein SMS-Code schützt nur so lange, wie der Empfängerkanal unverändert vertrauenswürdig bleibt. Sobald Angreifer die Anmeldung in Echtzeit abfangen, die Telefonnummer übernehmen oder den Nutzer auf eine gefälschte Login-Seite lenken, bricht der Vorteil zusammen. Das BSI bewertet SMS-TAN im Vergleich zu anderen 2FA-Methoden kritisch, und NIST ordnet SMS-gebundene OTPs ebenfalls nicht als phishing-resistent ein.

Typische Schwachstellen sind deshalb weniger spektakulär als viele denken:

• Abhängigkeit vom Mobilfunknetz statt von einem kryptografisch gebundenen Anmeldeverfahren.
• Empfang auf einem allgemeinen Endgerät, das zugleich für Browser, Messenger und Apps genutzt wird.
• Hohe Angriffsfläche für Social Engineering, weil Nutzer den Code aktiv weitergeben müssen.
• Verzögerungen und Zustellprobleme, die im Alltag zu Supportfällen führen.

Damit ist SMS nicht automatisch nutzlos. Es ist nur das falsche Werkzeug, wenn ein System wirklich widerstandsfähig gegen Phishing und Kontoübernahmen sein soll. Genau dort setzen die häufigsten Angriffe an.

Die wichtigsten Angriffe auf SMS-gebundene Codes

Der größte Denkfehler ist oft, dass ein Angreifer die SMS irgendwie technisch „abfangen“ müsse. In der Praxis läuft vieles viel banaler: Der Code wird vom Nutzer selbst auf einer manipulierten Seite eingegeben oder an eine kompromittierte Nummer geliefert. Das ist der Unterschied zwischen theoretischem Schutz und realem Missbrauch.

Smishing und Echtzeit-Phishing

Smishing ist schlicht SMS-Phishing. Der Nutzer bekommt eine Nachricht mit einem Link, landet auf einer gefälschten Seite und gibt dort Login-Daten plus Einmalcode ein. Wenn die Fake-Seite live mit dem echten Dienst spricht, reicht der Code sofort für den Zugriff. Das ist einer der Gründe, warum ich SMS-Codes nie als phishing-resistent bezeichnen würde.

SIM-Swapping und Nummernübernahme

Beim SIM-Swapping bringt ein Angreifer den Mobilfunkanbieter dazu, die Nummer auf eine andere SIM umzuziehen. Danach kommen Anrufe und SMS nicht mehr beim Opfer an, sondern beim Angreifer. Das ist besonders gefährlich, wenn die Telefonnummer als Wiederherstellungsweg oder als Backup-Faktor dient.

Schadsoftware auf dem Smartphone

Auch ein kompromittiertes Gerät ist ein Problem. Wenn Malware Benachrichtigungen mitliest, Nachrichten weiterleitet oder Inhalte auf dem Bildschirm ausliest, ist der Code nicht mehr geschützt. Das ist kein Massenangriff im klassischen Sinn, aber bei gezielten Konten durchaus realistisch.

Lesen Sie auch: Kerberos - Was es ist & wie es Ihre IT sichert

Weiterleitungen, Nummernwechsel und Recycling

Rufumleitungen, alte Nummern, neu vergebene Anschlüsse und schlecht gepflegte Kontodaten sind unspektakuläre, aber wirksame Fehlerquellen. Wer sich nur auf die Telefonnummer verlässt, überträgt Vertrauen auf einen Kanal, dessen Besitz sich ändern kann. Für Identität und Zugriff ist das ein schwacher Anker.

Je sensibler der Zugriff wird, desto klarer zeigt sich deshalb: Ein SMS-Code ist eher ein Mindestschutz als ein modernes Zielbild. Die praktische Frage lautet also nicht, ob er funktioniert, sondern wo er noch vertretbar ist und wo nicht.

Wann ich SMS-Codes noch akzeptabel finde und wann nicht

Ich würde SMS-OTP nur dort akzeptieren, wo das Risiko begrenzt ist und es eine bessere Option entweder noch nicht gibt oder organisatorisch nicht durchsetzbar ist. Für einfache Nutzerkonten, einen temporären Fallback oder einen niedrigrangigen Zusatzschritt kann das pragmatisch sein. Als dauerhafte Lösung für privilegierte Konten, Admin-Zugriffe oder kritische Freigaben ist es aus meiner Sicht zu schwach.

• Akzeptabel bei niedrigem Risiko, wenn die SMS nur als Übergangslösung dient.
• Akzeptabel als Fallback, wenn Nutzer sonst vollständig ausgesperrt wären.
• Grenzwertig bei Passwort-Resets, weil der Wiederherstellungsweg nicht schwächer sein sollte als die reguläre Anmeldung.
• Nicht geeignet für privilegierte Administrator-Konten und kritische Zugriffe auf Produktionssysteme.
• Nicht geeignet für finanzielle Transaktionen, wenn der Code nicht an die Transaktion selbst gebunden ist.

Gerade im Reset-Prozess wird der Unterschied sichtbar: Wenn ich eine Identität über den Wiederherstellungsweg zurückgebe, darf dieser Weg nicht leichter kompromittierbar sein als der eigentliche Login. Sonst wird aus einem Notfallmechanismus ein Einfallstor. Daraus ergibt sich fast automatisch die Frage nach besseren Alternativen.

Welche Alternativen für Identität und Zugriff heute besser funktionieren

Wenn ich neue Systeme plane, beginne ich nicht mit SMS, sondern mit Verfahren, die stärker an das Gerät, den Browser oder den kryptografischen Besitz gebunden sind. Besonders wichtig ist dabei die Frage, ob ein Angreifer den zweiten Faktor auf einer gefälschten Seite abfangen und wiederverwenden kann. Genau dort trennen sich gute von nur bequemen Lösungen.

Für die Praxis bedeutet das: TOTP ist oft schon ein deutlicher Schritt nach vorn, weil der Code lokal in einer Authenticator-App entsteht und nicht über das Mobilfunknetz läuft. Passkeys und WebAuthn gehen noch weiter, weil sie mit Public-Key-Kryptografie arbeiten und sich deutlich besser gegen Phishing schützen. Hardware-Schlüssel bleiben für besonders sensible Rollen die robusteste Wahl, auch wenn sie etwas mehr Disziplin beim Rollout verlangen.

Ich würde die Reihenfolge deshalb so lesen: erst phishing-resistente Verfahren, dann komfortable, aber stärkere Alternativen, und SMS nur dort, wo Verfügbarkeit wichtiger ist als Strenge. Bleibt SMS dennoch im Stack, sollte die Umsetzung sauber sein.

So setze ich SMS-Codes sauber um, wenn sie unvermeidbar bleiben

Wenn ich ein System nicht sofort von SMS lösen kann, versuche ich wenigstens die Angriffsfläche klein zu halten. Dabei helfen keine großen Theorien, sondern klare Regeln im Detail. Die wichtigsten davon sind erstaunlich banal, aber genau deshalb oft wirksam.

• Kurze Gültigkeit: In vielen Umgebungen arbeite ich mit 3 bis 5 Minuten, nicht länger.
• Nur einmal verwendbar: Ein Code darf nach erfolgreicher Prüfung sofort verfallen.
• Versand begrenzen: Nach 2 bis 3 Wiederholungen setze ich eine Abkühlphase, damit kein Missbrauch durch Dauerzustellung entsteht.
• Versuche begrenzen: Fünf Fehlversuche sind ein brauchbarer Startpunkt, danach sollte ein weiterer Schutzmechanismus greifen.
• Code an Sitzung oder Transaktion binden: Sonst kann ein abgefangener Code an anderer Stelle landen.
• Klare Anti-Phishing-Nachricht: Die SMS sollte ausdrücklich sagen, dass der Code niemals weitergegeben werden darf und dass der Support ihn nie abfragt.
• Änderungen an der Nummer überwachen: SIM-Wechsel, Gerätewechsel und neue Weiterleitungen sollten Warnsignale auslösen.
• Code niemals in URLs oder Logs: Das klingt selbstverständlich, wird aber in der Praxis immer noch zu oft falsch umgesetzt.

Worauf ich 2026 bei Identität und Zugriff zuerst setze

Für neue Systeme würde ich 2026 klar priorisieren: Passkeys oder WebAuthn für den Standard-Login, TOTP oder Hardware-Schlüssel als starke Ergänzung und SMS nur als Fallback oder für sehr niedrige Risikostufen. Das ist nicht nur sicherer, sondern auf Dauer auch einfacher zu erklären, weil sich der Zugriff an das Gerät und den echten Anmeldevorgang bindet statt an einen austauschbaren Nachrichtenkanal.

Für bestehende Umgebungen lautet meine praktische Faustregel: SMS nicht verteufeln, aber auch nie zum Zielzustand erklären. Je sensibler die Identität, je wertvoller der Zugriff und je höher der Schaden bei Übernahme, desto weniger Platz sollte der SMS-Code im Design haben. Wer das sauber trennt, baut ein deutlich robusteres Zugriffskonzept auf.

Wenn du willst, kann ich daraus im nächsten Schritt auch eine kürzere Version für eine Landingpage, eine FAQ-freie Blogfassung oder eine technischere Version für IT-Entscheider machen.