SMS-OTP/2FA für SaaS: Sicherer Login per Einmalcode (KMU-Setup)

So sichern KMU-SaaS-Anbieter ihren Login mit SMS-OTP ab, ohne Authenticator-App-Pflicht: Deliverability in DACH, Fallback-Strategie mit WhatsApp als Primary oder Fallback, Sicherheits-Best-Practice und ein Praxis-Setup mit API, Webhook und Flow Builder. Inklusive Beispielrechnung, wann sich der Wechsel auf WhatsApp-Authentication lohnt.

Was SMS-OTP im SaaS-Login leistet

SMS-OTP ist der pragmatischste zweite Faktor im SaaS-Login: Der Anwender meldet sich mit E-Mail und Passwort an, das Backend versendet einen 6-stelligen Code per SMS, der Anwender tippt ihn in das Login-Formular. Fertig. Eine ausführliche Definition des Verfahrens steht im Glossar-Eintrag Einmalpasswort (OTP).

Der Charme für KMU-SaaS-Anbieter liegt im niedrigsten gemeinsamen Nenner. Eine SMS empfängt jedes Smartphone ohne Konfiguration. Es gibt keine App, die installiert werden muss, kein QR-Code, der gescannt werden müsste, keinen Hardware-Token, der bestellt werden muss. Das senkt die Hürde im Onboarding spürbar, gerade in Branchen, in denen die Endanwender weder Entwickler noch Power-User sind: Handwerksbetriebe, Pflegeeinrichtungen, kleine Steuerkanzleien, regionale Vereine.

Gleichzeitig ist SMS-OTP nicht das sicherste Verfahren am Markt. Eine Authenticator-App mit Zwei-Faktor-Authentifizierung nach TOTP ist phishing-resistenter, eine Passkey-Lösung sogar phishing-frei. SMS-OTP bewegt sich dazwischen und ist genau dann die richtige Wahl, wenn Reichweite und einfache Bedienung wichtiger sind als das absolute Maximum an Sicherheit.

Wann SMS-OTP die richtige Wahl ist

Die Frage ist selten: SMS oder nichts. Die ehrliche Frage lautet: Welcher Kanal passt zu welcher Zielgruppe?

SMS-OTP ist die Standard-Empfehlung, wenn ein Anbieter eine breite, heterogene Nutzerschaft adressiert und sicherstellen muss, dass auch ältere oder weniger technikaffine Anwender ohne Hürde durchkommen. Sie funktioniert auf jedem Mobiltelefon, auch ohne Datenverbindung. Der Code ist sofort sichtbar, ohne dass eine App geöffnet werden muss.

WhatsApp-OTP über ein Authentication-Template ist die wirtschaftlich attraktivere Option, sobald die Endkunden ohnehin WhatsApp aktiv nutzen, also typischerweise in B2C-Szenarien und in DACH bei Selbstständigen. Voraussetzung ist ein zugelassener Template-Typ und ein WhatsApp Business Account.

Authenticator-Apps (TOTP) sind die Wahl für sicherheitskritische Workflows mit technikaffinem Publikum, etwa Admin-Konten in einem Entwickler-SaaS. Hier zählen Phishing-Resistenz und Versandkosten von 0 € mehr als die maximale Reichweite.

Den vollständigen Kostenvergleich mit Beispielrechnungen für DACH liefert der Artikel 2FA-Kosten 2026: SMS vs. WhatsApp im DACH-Vergleich. Dieser Beitrag konzentriert sich auf das praktische Setup für SaaS-Anbieter.

Deliverability in DACH: Routen, Absender, Latenz

Eine SMS, die nicht ankommt, ist im Login-Workflow ein Totalausfall: Der Anwender steht vor einem leeren Code-Feld und springt im Zweifel ab. Deliverability ist deshalb kein technisches Detail, sondern eine Produktentscheidung.

Drei Stellschrauben bestimmen die Zustellung. Die Carrier-Route ist die wichtigste. Premium-Routen über deutsche, österreichische und schweizer Mobilfunkanbieter erreichen 97 bis 99 % Zustellrate bei 5 bis 15 Sekunden Latenz. Billige Graumarkt-Routen schaffen oft nur 80 bis 90 % und sind für OTP ungeeignet, weil jeder zehnte Anwender abspringt. Ein seriöser SMS-Versender legt offen, welche Route er nutzt und stellt für OTP automatisch die hochwertige Variante bereit.

Die Absender-Kennung ist die zweite Stellschraube. Drei Varianten sind in DACH üblich:

• Alphanumerischer Absender (z.B. SAAS-LOGIN, bis 11 Zeichen): Die Marke erscheint als Absender, der Anwender erkennt sofort, woher die SMS kommt. Vertrauensbildend, aber in Deutschland nicht für jeden Tarif freigeschaltet.
• Short Code (5-stellige Kurznummer): Branchenstandard für Massenversand, in Deutschland teuer in der Einrichtung. Für KMU selten wirtschaftlich.
• Long Code (klassische internationale Mobilnummer): Günstig und schnell verfügbar, wirkt aber wie eine SMS von einer Privatperson und senkt das Vertrauen.

Die Faustregel für SaaS-Login lautet: Wenn Ihr Anbieter den alphanumerischen Absender für DACH unterstützt, nehmen Sie ihn. Er hebt OTP-SMS optisch klar von Spam ab.

Die dritte Stellschraube ist die Latenz. 5 bis 15 Sekunden zwischen API-Aufruf und Eintreffen der SMS sind normal. Liegt die Latenz darüber, prüfen Sie die Route. Im Login-Workflow sollten Sie zusätzlich ein Webhook-Event auf den Status \"delivered\" warten lassen, damit Ihr Backend weiß, ob die SMS tatsächlich zugestellt wurde, und nicht nur, dass sie versendet ist.

Fallback-Strategie: WhatsApp als Primary oder Fallback

Selbst die beste SMS-Route fällt gelegentlich aus. Ein einzelner Anwender im Funkloch, ein temporäres Problem beim Carrier, eine ausländische Reise mit Roaming-Sperre: Es lohnt sich, einen zweiten Versandweg vorzusehen, statt den Anwender vor die Tür zu setzen.

Die wirtschaftlich attraktivste Kombination für DACH lautet: WhatsApp zuerst, SMS als Fallback. Das WhatsApp Business API-Authentication-Template ist günstiger als die SMS und wird in Deutschland und Österreich von der Mehrheit der Endkunden aktiv genutzt. Wer kein WhatsApp hat oder die Nachricht nicht innerhalb einer von Ihnen gewählten Frist öffnet, bekommt automatisch eine SMS hinterhergeschickt. Diese Routing-Logik steuert Ihr Backend: Es ruft den bevorzugten Kanal über die API auf und schickt anhand des Zustellquittungs-Webhooks bei Bedarf den Fallback hinterher.

Für Geschäftsmodelle mit überwiegend B2B-Endkunden ist die Reihenfolge umgekehrt sinnvoll: SMS zuerst, WhatsApp als Fallback. B2B-Anwender lesen Geschäfts-SMS aufmerksamer und akzeptieren sie als formalen Kommunikationskanal, während WhatsApp eher als Privatkanal gilt.

Für Festnetznummern oder spezielle Barrierefreiheits-Anforderungen können Sie OTPs zusätzlich über ein eigenes Telefonie-Gateway zustellen lassen. Dieser Pfad läuft nicht über SendSeven, sondern parallel über Ihren Voice-Provider. Dieser Pfad ist typischerweise teurer als SMS, aber als Letztabsicherung im Workflow eine Investition wert.

Sicherheits-Best-Practice für OTP-Codes

Ein OTP-Setup wird nicht durch den Versandkanal sicher, sondern durch die Disziplin im Backend. Sechs Regeln machen den Unterschied zwischen einem ernstzunehmenden zweiten Faktor und einer Pseudo-Maßnahme, die im Audit durchfällt.

• 6-stellig, nicht 4-stellig. Ein 6-stelliger Code hat eine Million mögliche Kombinationen, ein 4-stelliger nur zehntausend. Bei strikter Brute-Force-Sperre wäre der Unterschied theoretisch nicht groß. Praktisch erleichtern 4-stellige Codes Phishing, weil sie sich Anwender leichter merken und in Drittsysteme eintippen lassen.
• 5 bis 10 Minuten Gültigkeit. Kürzer ist nervig, wenn die SMS spät ankommt. Länger erleichtert Angriffe. 10 Minuten sind für SMS-OTP der etablierte Kompromiss.
• Einmal-Verwendung erzwingen. Auch wenn der Code zeitlich noch gültig wäre, sollte das Backend ihn nach erfolgreicher Anmeldung sofort invalidieren.
• Brute-Force-Sperre nach 3 bis 5 Fehlversuchen. Danach den OTP verwerfen und einen neuen anfordern lassen. Andernfalls könnte ein Angreifer den Code per Versuch-und-Irrtum erraten.
• Niemals Code und Login-Link in derselben Nachricht. Wer in der OTP-SMS einen anklickbaren Link mitsendet, ermöglicht ein perfides Phishing-Szenario: Ein gefälschter Login-Bildschirm fragt nach dem Code, der Anwender liefert ihn freiwillig. SMS-OTPs enthalten nur den Code, sonst nichts.
• Kanal-Bindung dokumentieren. Der OTP-Kanal sollte vom Login-Kanal getrennt sein. Wer per WhatsApp-Web auf dem Laptop eingeloggt ist und den OTP über WhatsApp empfängt, hat keine echte Zwei-Faktor-Trennung. SaaS-Anbieter sollten in der Datenschutzerklärung und im internen Sicherheitskonzept festhalten, welchen Kanal sie für OTPs nutzen und warum.

Eine vorbildliche OTP-SMS sieht so aus: \"Ihr Code: 482593. Gültig 10 Minuten. Geben Sie ihn nur in SAAS-LOGIN ein. SAAS-LOGIN\". Sechs Ziffern, ein Hinweis zur Gültigkeit, ein Sicherheitshinweis, ein Absenderkennung am Ende. Kein Link, kein Werbe-Slogan, kein Smiley.

DSGVO und Datenschutz bei OTP-Versand

OTP-Versand verarbeitet personenbezogene Daten, im Kern die Mobilfunknummer des Endanwenders. Vier Punkte gehören in jeden SaaS-Datenschutzcheck.

Rechtsgrundlage. Für den OTP-Versand zur Absicherung des Logins greift in der Regel Art. 6 Abs. 1 lit. b DSGVO (Vertragserfüllung), weil die Zwei-Faktor-Authentifizierung Teil des Vertrags zwischen SaaS-Anbieter und Kunde ist. Alternativ kommt lit. f (berechtigtes Interesse) in Betracht. Eine Einwilligung ist für reine Sicherheitsmaßnahmen nicht erforderlich und auch nicht ratsam, weil sie widerrufen werden könnte.

Auftragsverarbeitungsvertrag (AVV). Der OTP-Versand läuft über einen Dienstleister, der die Mobilfunknummer in Ihrem Auftrag verarbeitet. Sie brauchen einen AVV nach Art. 28 DSGVO. Seriöse Anbieter stellen ihn ohne Aufpreis bereit.

EU-Hosting bevorzugen. Daten von EU-Bürgern sollten in der EU verarbeitet werden. Das vereinfacht die Datenschutzfolgenabschätzung und schließt die Diskussion um den US-Cloud-Act oder das EU-US-Datenschutzrahmenwerk weitgehend aus. SendSeven hostet ausschließlich in der EU und ist eine DSGVO-konforme Plattform mit Sitz in Augsburg.

Speicherdauer. Mobilfunknummern für OTP-Zwecke sollten nicht länger gespeichert werden, als für den Login-Workflow nötig. Die Nummer selbst gehört zum Stammdatensatz des Anwenders. Der OTP-Versand-Log darf gemäß den eigenen Aufbewahrungsfristen geführt werden, üblich sind 30 bis 90 Tage für Sicherheitslogs.

SaaS-Setup mit SendSeven: API, Webhook, Flow Builder

In der technischen Umsetzung gibt es drei Bausteine, die zusammenspielen.

1. Versand-API. Ihr Backend ruft beim Login-Versuch eine REST-API auf und übergibt Empfängernummer, Code und optional die Absenderkennung. Die API antwortet sofort mit einer Message-ID. Über den SMS-Kanal oder das WhatsApp-Authentication-Template (für die WhatsApp-Variante) wird die Nachricht versendet.

2. Webhook für Zustellquittung. Wenige Sekunden später meldet ein Webhook den finalen Status: \"delivered\" (zugestellt), \"failed\" (gescheitert) oder \"undeliverable\" (nicht zustellbar, etwa weil die Nummer ungültig ist). Ihr Backend hört auf diesem Webhook und kann reagieren: bei \"failed\" automatisch den Fallback-Kanal anwerfen, bei \"undeliverable\" den Anwender bitten, eine andere Nummer zu hinterlegen.

3. Fallback-Routing im Backend. Die Reihenfolge der Kanäle steuert Ihr eigenes Backend: Es ruft zuerst den bevorzugten Kanal über die API auf, wartet auf das Zustellquittungs-Webhook und schickt bei \"failed\" oder ausbleibender Quittung den OTP über den Fallback-Kanal hinterher. So behalten Sie die volle Kontrolle über Timeouts und Reihenfolge. Für nachgelagerte Schritte, etwa eine Benachrichtigung an Ihr Team bei wiederholtem Fehlversand, lässt sich anschließend ein Flow anhängen.

Beispielrechnung: Wann sich der Wechsel auf WhatsApp lohnt

Die Kostenfrage ist für jedes SaaS mit nennenswertem Login-Aufkommen relevant. Eine schlanke Beispielrechnung zeigt, ab wann sich der zusätzliche Aufwand für ein Authentication-Template lohnt.

Ausgangslage: Ein DACH-SaaS hat 1.000 Logins pro Tag und versendet pro Login einen OTP. Auf SMS-Basis kostet das bei 0,10 € pro Nachricht 100 € pro Tag, also rund 3.000 € pro Monat. Wer den OTP-Versand komplett auf WhatsApp-Authentication umstellt und durchschnittlich 0,055 € pro Nachricht bezahlt, kommt auf rund 1.650 € pro Monat. Die Ersparnis liegt bei rund 1.350 € pro Monat oder etwa 45 %.

Aber: Die Umstellung ist kein 100-%-Tausch. Realistisch sind die Endkunden in zwei Lager geteilt. Etwa 60 bis 80 % nutzen WhatsApp aktiv und erhalten den Code dort. Die restlichen 20 bis 40 % bekommen den OTP weiterhin per SMS als Fallback. Mit dieser realistischen Mischung sinkt die Ersparnis auf rund 600 bis 900 € pro Monat, was bei 1.000 Logins pro Tag immer noch deutlich mehr ist als der Verwaltungsaufwand für das zweite Template.

Die Wirtschaftlichkeitsschwelle liegt damit bei ungefähr 500 Logins pro Tag. Darunter rechnet sich der zusätzliche Setup-Aufwand für das Authentication-Template kaum. Darüber spart jeder Tag, an dem WhatsApp läuft, gegenüber reinem SMS-Versand. Den ausführlichen Kostenvergleich für andere Lastprofile finden Sie im Vergleichsartikel 2FA-Kosten 2026: SMS vs. WhatsApp im DACH-Vergleich.

Weiterlesen: vertiefende Artikel

Dieser Artikel hat das SMS-OTP-Setup für SaaS-Anbieter in den Mittelpunkt gestellt. Die folgenden Beiträge vertiefen angrenzende Themen rund um SMS, Sicherheit und das WhatsApp-Authentication-Verfahren.

• SMS für Unternehmen 2026: Service-Benachrichtigungen, 2FA und Marketing richtig nutzen
• SMS-Terminerinnerungen: Terminausfälle reduzieren mit 24-Stunden-Vorlauf
• SMS-Marketing-Kampagnen DSGVO-konform aufsetzen
• SMS vs. WhatsApp: Welcher Kanal wann passt
• 2FA-Kosten 2026: SMS vs. WhatsApp im DACH-Vergleich

Den SMS-Kanal selbst stellen wir auf der SMS-Kanalseite vor, das visuelle Routing zwischen Kanälen im Flow Builder.

Häufig gestellte Fragen

Ist SMS-OTP sicher genug für ein SaaS-Produkt?

SMS-OTP ist als zweiter Faktor neben Passwort deutlich sicherer als ein reines Passwort-Login und für die meisten KMU-SaaS-Anwendungen ausreichend. Wer höchste Sicherheit braucht (Admin-Konten, sensible Daten), sollte zusätzlich oder alternativ eine Authenticator-App oder Passkeys anbieten. Wichtig sind eine 6-stellige Codelänge, eine kurze Gültigkeit von 5 bis 10 Minuten und eine Brute-Force-Sperre nach drei bis fünf Fehlversuchen.

Wie schnell kommt eine OTP-SMS in DACH an?

Über Premium-Routen zu deutschen, österreichischen und schweizer Mobilfunkanbietern liegt die Latenz typischerweise zwischen 5 und 15 Sekunden. Die Zustellrate erreicht 97 bis 99 %. Billige Graumarkt-Routen sind für OTP ungeeignet, weil sie nur 80 bis 90 % Zustellrate liefern und höhere Latenzen aufweisen. Ein seriöser Anbieter macht transparent, welche Route genutzt wird.

Was kostet eine OTP-SMS im DACH-Raum?

Eine OTP-SMS kostet in Deutschland, Österreich und der Schweiz typischerweise 0,085 bis 0,100 € netto. Die WhatsApp-Authentication-Variante kostet etwa 0,0496 bis 0,0706 €, eine TOTP-Authenticator-App ist kostenfrei pro Code, erfordert aber höheren Onboarding-Aufwand. Bei SendSeven beginnt der Einstieg ab 9 €/Kanal/Monat im Pay-as-you-go-Tarif.

Soll ich Long Code, Short Code oder alphanumerischen Absender für OTP nutzen?

Wenn Ihr Anbieter den alphanumerischen Absender für DACH unterstützt, ist er die beste Wahl, weil Ihre Marke direkt im Absenderfeld erscheint und sich von Spam abhebt. Short Codes sind teuer in der Einrichtung und für die meisten KMU nicht wirtschaftlich. Long Codes wirken wie SMS von einer Privatperson und senken das Vertrauen, sind aber günstig und schnell verfügbar.

Wie baue ich eine Fallback-Logik zwischen WhatsApp und SMS auf?

Die wirtschaftlich attraktivste Variante ist: WhatsApp-Authentication zuerst, SMS als Fallback. Die Reihenfolge steuert Ihr Backend: Es ruft den bevorzugten Kanal über die API auf, hört auf das Zustellquittungs-Webhook und schickt bei Status \"failed\" oder \"undeliverable\" oder ausbleibender Quittung die SMS hinterher. So behalten Sie die volle Kontrolle über Timeouts und Reihenfolge.

Welche Rechtsgrundlage gilt für OTP-Versand nach DSGVO?

In der Regel greift Art. 6 Abs. 1 lit. b DSGVO (Vertragserfüllung), weil die Zwei-Faktor-Authentifizierung Teil des Vertrags zwischen SaaS-Anbieter und Kunde ist. Alternativ kommt lit. f (berechtigtes Interesse) in Betracht. Eine Einwilligung ist nicht erforderlich. Sie brauchen einen Auftragsverarbeitungsvertrag nach Art. 28 DSGVO mit Ihrem Versand-Anbieter und sollten EU-Hosting bevorzugen.

Darf ich in der OTP-SMS einen Login-Link mitsenden?

Nein. Eine OTP-SMS darf ausschließlich den Code und einen knappen Sicherheitshinweis enthalten. Ein anklickbarer Link in der OTP-SMS ermöglicht ein perfides Phishing-Szenario: Ein gefälschter Login-Bildschirm fragt nach dem Code, der Anwender liefert ihn freiwillig. Die saubere Trennung von Code und Login-Eintrittspunkt ist Teil des Sicherheitskonzepts und gehört in jeden internen Audit.

Ab welcher Login-Last lohnt sich der Wechsel von SMS auf WhatsApp-Authentication?

Die Wirtschaftlichkeitsschwelle liegt bei ungefähr 500 Logins pro Tag. Darüber spart der Wechsel auf WhatsApp-Authentication (mit SMS als Fallback) im DACH-Raum monatlich mehrere hundert Euro Versandkosten. Darunter rechnet sich der zusätzliche Setup-Aufwand für das Authentication-Template kaum. Bei sehr hoher Last und reinem WhatsApp-Versand sind Ersparnisse von rund 45 % gegenüber reinem SMS-Versand realistisch.