Wenn ChatGPT texten kann, ist SMS nicht mehr Out‑of‑Band: Ein Sicherheits‑Playbook für CTOs

Ihr Produkt behandelt SMS und E‑Mail weiterhin als „Out‑of‑Band“‑Kontrollkanäle. Diese Annahme ist soeben gestorben. ChatGPT kann jetzt über Apple Messages Texte senden. Assistenten lesen ohnehin Benachrichtigungen, durchsuchen Posteingänge und befolgen appübergreifende Anweisungen. Wenn ein Agent die Nachricht sehen und senden kann, ist sie nicht Out‑of‑Band — sie ist automatisiert In‑Band mit einer neuen Angriffsfläche.

Wenn Sie auf einen großen Vendor‑Move gewartet haben, bevor Sie SMS‑2FA und E‑Mail‑basierte Freigaben außer Betrieb nehmen: Das ist er. In diesem Beitrag gebe ich Ihnen ein konkretes Entscheidungsframework, um zu erfassen, wo Sie auf „Out‑of‑Band“ bauen, Ihr Exposure zu bewerten, seit Assistenten texten können, und binnen eines Quartals ein sichereres Authentifizierungs‑ und Autorisierungsmodell zu liefern.

Was sich geändert hat: SMS und E‑Mail sind jetzt standardmäßig automatisierbar

Zwei relevante Signale sind kürzlich gelandet:

• ChatGPT hat eine Apple‑Messages‑Integration erhalten. Das ist Mainstream‑Zugriff auf OS‑Ebene auf einen Kanal, dem die meisten Consumer‑Apps für OTPs und Freigaben noch vertrauen.
• Assistenten lassen sich zur Datenexfiltration bewegen, selbst wenn Filter das „eigentlich“ blockieren sollten — inklusive über verschleierte oder verschlüsselte Prompt‑Injection. Wenn ein Modell bösartige Anweisungen befolgt, ist Ihr vermeintlich Out‑of‑Band verschickter Code nur ein weiteres Token zum Kopieren und Einfügen.

Kombinieren Sie das mit jahrelangem Plattform‑Drift — OTP‑Previews auf dem Sperrbildschirm, Benachrichtigungs‑Zusammenfassungen, E‑Mail‑„Smart Reply“, geräteübergreifende Synchronisierung — und die Sicherheitsgrenze, von der Sie dachten, sie umgebe SMS und E‑Mail, hat nie wirklich gehalten. Jetzt ist sie vollständig porös.

Bedrohungsmodell‑Update: Vom menschlichen zweiten Faktor zur skriptbaren Pipeline

So verschlechtern sich Ihre aktuellen Kontrollen in Gegenwart von Assistenten auf OS‑Ebene, die Nachrichten lesen und senden können:

• SMS‑OTPs: Agenten können Vorschauen und vollständige Nachrichten lesen und teils sogar ohne Nutzereingriff antworten. Ein kompromittierter Assistent = geerntetes OTP.
• E‑Mail‑Magic‑Links: Wenn ein Assistent Ihren Posteingang verwaltet, wird „Klicken Sie auf den Link“ zur trivialen Automatisierung. Click‑Blocking‑Heuristiken retten Sie nicht vor First‑Party‑Automatisierung.
• Telefon/IVR‑Rückrufe: Mit Text‑to‑Speech und Call‑APIs können Agenten Anrufe tätigen und navigieren. Anrufer‑ID ist fälschbar; „Voice‑Verifikation“ ist Theater gegen geklonte Stimmen.
• Push‑Freigaben: Wenn Ihre Push‑Benachrichtigung nur „Genehmigen/Ablehnen“ ist, kann ein Agent mit Benachrichtigungszugriff schneller auf Genehmigen tippen, als Ihr Nutzer es bemerkt.

Sicherheitsleitlinien haben hier schon gewarnt. NIST SP 800‑63B klassifiziert SMS für OTP als eingeschränkt wegen SIM‑Swap, Abfangen und Malware‑Risiko. Das war, bevor Assistenten Nachrichten in Ihrem Namen weiterleiten konnten. Heute sind SMS und E‑Mail nur noch Prozess‑Transport — und alles, was diesen Transport steuern kann, kann auch Ihre Kontrollen steuern.

Entscheidungsframework: Töten Sie Out‑of‑Band‑Annahmen in 4 Schritten

1) Inventarisieren Sie, wo Sie von „Out‑of‑Band“ abhängen

Erstellen Sie eine zweispaltige Liste mit Business‑Owner und technischem Owner. Gesucht ist jeder Ort, an dem ein Akteur außerhalb Ihrer authentifizierten Sitzung eine sicherheitssensitive Änderung auslösen kann:

• Authentifizierung: SMS‑OTP, E‑Mail‑OTP, E‑Mail‑Magic‑Links, Telefon‑Rückrufe, Authenticator‑App‑TOTP.
• Autorisierung: Zahlungsfreigaben, Empfänger hinzufügen, Schlüsselrotation, Rollenänderungen, Geräteeinschreibung, Bestätigung von Datenexporten.
• Support/Recovery: Passwort‑Resets via E‑Mail oder SMS, Kontoentsperrungen via Telefon‑Ticket, KYC‑Re‑Verifikation per E‑Mail‑Link.

Pro Eintrag erfassen Sie Kanal/Kanäle, Fallback‑Pfad/Pfade und das dem Nutzer angezeigte Artefakt (OTP, Link, Freigabe‑Button etc.). Rechnen Sie in einem typischen B2C‑SaaS mit 12–30 unterschiedlichen Flows; im B2B weniger, dafür mit höherem Blast‑Radius.

2) Klassifizieren Sie Kanalkontrolle und Assistenten‑Exposition

Bewerten Sie jeden Flow in drei Dimensionen (Hoch/Mittel/Niedrig):

• Sichtbarkeit für Assistenten: Kann ein Mainstream‑OS‑Assistent das standardmäßig lesen? (OTP auf dem Sperrbildschirm, E‑Mail‑Vorschau, Messages‑Integration, Benachrichtigungsinhalte.)
• Aktuierung durch Assistenten: Kann ein Assistent in diesem Kanal senden/genehmigen/antworten?
• Stärke der Nutzerverifikation: Weist der Nutzer den Besitz eines privaten Schlüssels in sicherer Hardware nach, oder beantwortet er nur eine Challenge, die jede App sehen kann?

Wenn ein Flow hohe Sichtbarkeit + mittlere/hohe Aktuierung + niedrige Verifikationsstärke aufweist, behandeln Sie ihn als kompromittiert. Jedes „aber der Nutzer muss tippen“‑Argument ist obsolet, sobald ein Modell tippen kann.

3) Wählen Sie einen kryptografischen Ersatz, nicht einen weiteren Kanal

Ersetzen Sie Kanalvertrauen durch Schlüsselvertrauen. Ihre Optionen:

• WebAuthn (FIDO2) mit residenten Schlüsseln: Hardware‑gestützt, phishing‑resistent, funktioniert auf Desktop und Mobile. Verwenden Sie credProtect und verlangen Sie User Verification (UV). Bevorzugen Sie für Consumer‑Flows gerätegebundene Plattform‑Authenticatoren gegenüber Roaming‑Schlüsseln; erlauben Sie Roaming‑Schlüssel für Admins.
• App‑gebundene Attestierung für Freigaben: Auf Mobile Apple App Attest und Android Play Integrity zur Attestierung Ihrer App verwenden; in der App Transaktionssignatur durchführen mit im Klartext angezeigtem „Was Sie signieren“ (Betrag, Empfänger, Aktion), das an eine Signatur gebunden wird. Außerhalb des Browsers OS‑seitig bereitgestellte Secure Elements (Secure Enclave/StrongBox) über Plattform‑APIs nutzen.
• Push mit transaktionsspezifischer kryptografischer Challenge: Wenn Sie Push nutzen müssen, senden Sie niemals ein blindes „Genehmigen“. Senden Sie eine signierte Challenge, die die kritischen Felder enthält, und fordern Sie eine hardware‑gestützte Assertion als Antwort. Speichern und auditieren Sie die Assertions.

Ersetzen Sie SMS nicht durch E‑Mail oder umgekehrt. Sie bekämpfen nicht Kanalzuverlässigkeit. Sie eliminieren Kanalvertrauen vollständig.

4) Schaffen Sie Fallbacks ab, die das Loch wieder öffnen

Die meisten Kompromittierungen passieren über den Weg des geringsten Widerstands: „Hat nicht funktioniert? Nutze SMS.“ Schaffen Sie das ab oder schotten Sie es ab:

• Entfernen Sie SMS als Fallback, wo Sie WebAuthn einsetzen. Wenn Sie es für eine Minderheit beibehalten müssen, isolieren Sie diese Nutzer in eine eingeschränkte Risikostufe mit niedrigeren Transaktionslimits.
• Verabschieden Sie E‑Mail‑Magic‑Links für Admin‑Rollen und hochwertige Konten. Erzwingen Sie WebAuthn oder In‑App‑Signaturen.
• Ersetzen Sie Telefon‑Recovery durch verifizierte Geräte‑Recovery‑Kits: vorgenerierte einmalige Wiederherstellungscodes offline aufbewahren oder sekundäre FIDO‑Anmeldedaten vorab einschreiben.

Designänderungen, die Sie dieses Quartal brauchen

Authentifizierung

• Machen Sie WebAuthn zum Standard‑Erstfaktor für neue Sign‑ups. Behandeln Sie es nicht als „Power‑User“‑Einstellung. Speichern Sie nur user‑verifizierende Anmeldedaten (UV = erforderlich). Testen Sie geräteübergreifend synchronisierte Passkeys und bieten Sie für hochsichere Rollen eine Opt‑out‑Möglichkeit für ausschließlich gerätegebundene Keys.
• Koppeln Sie Legacy‑OTP an Gerätestatus: Wenn OTP auftaucht (Bestandsnutzer), fordern Sie zusätzliche Gerätesignale (App Attest/Play Integrity) und Sitzungsbindung an, bevor Sie es akzeptieren.
• Blockieren Sie OTP in Benachrichtigungen: Für Mobile‑Apps unter Ihrer Kontrolle OTP‑Inhalte in Benachrichtigungen unterdrücken. Das ist keine Lösung, senkt aber das Risiko von Drive‑by‑Ernte.

Autorisierung (Freigaben und Step‑Up)

• Transaktionssignatur statt Ja/Nein: Zeigen Sie die genaue Aktion an (z. B. „Zahlen Sie 4.200 $ an ACME LLC, US‑123456789, heute“) und verlangen Sie eine hardware‑gestützte Signatur über diesen Payload. Speichern Sie sie. Machen Sie sie im Audit‑Trail sichtbar.
• Rollen‑ und Berechtigungsänderungen erfordern WebAuthn oder In‑App‑Signatur. Niemals per E‑Mail‑Link freigeben.
• Datenexport erfordert kryptografisches Step‑up und ein kurzlebiges, einmal nutzbares Token, das an Sitzung und Gerät gebunden ist.

Support und Wiederherstellung

• Agent‑sichere Recovery‑Kits: Stellen Sie bei der Einschreibung 8–12 gedruckte Einmal‑Recovery‑Codes bereit. Erlauben Sie die Einschreibung von 2–3 sekundären FIDO‑Credentials. Deaktivieren Sie SMS‑Reset vollständig nach erfolgreichem Passkey‑Setup.
• Keine Freigaben über E‑Mail/Telefon: Der Support kann nur einen In‑App‑, attestierten Recovery‑Flow initiieren. Wenn ein Nutzer nur E‑Mail hat, verlangen Sie eine cool‑down‑Periode (24–72 Stunden), bevor der Zugang wieder aktiviert wird.
• Hochrisiko‑Änderungen erfordern zwei unterschiedliche Schlüssel (z. B. zwei Admins oder Admin + Compliance), nicht zwei Kanäle.

„Aber Regulatoren verlangen Out‑of‑Band“ — Lesen Sie das Kleingedruckte

Viele Standards verweisen auf „Out‑of‑Band“ als Mitigation. Nur wenige bestehen 2026 noch darauf, dass es SMS oder E‑Mail sein muss. Was Auditoren wollen, ist unabhängige Verifikation und Manipulationsnachweis:

• PCI DSS, FFIEC und SOX ist wichtig, dass der Genehmiger wirklich der Genehmiger ist — und dass Sie es später beweisen können. Hardware‑gestütztes WebAuthn mit UV, plus transaktionsspezifische Signaturen und unveränderliche Logs erfüllen das Prinzip besser, als SMS es je konnte.
• NIST SP 800‑63B rät explizit von SMS‑OTP als Hochsicherheitsfaktor ab. Nutzen Sie das zur Begründung Ihres Migrationsplans.

Setzt ein bestimmter Regulator „Out‑of‑Band“ immer noch mit „Senden Sie eine SMS“ gleich, dokumentieren Sie, warum dieser Kanal nun automatisierbar ist, und schlagen Sie kryptografisches Out‑of‑Band vor: ein zweites, unabhängig attestiertes Gerät mit eigenem Schlüssel oder ein zweiter Administrator mit separater Anmeldedatenbasis.

Erkennung und Reaktion: Gehen Sie davon aus, dass Assistenten im Loop sind

Selbst mit kryptografischen Kontrollen müssen Sie Missbrauchsmuster erkennen, die zu Assistenten‑Vermittlung passen:

• Fingerprints, die auf assistentengesteuerte Flows hindeuten: Wiederholt nahezu sofortige Freigaben nach Zustellung der Benachrichtigung; identische Cursor‑Geschwindigkeits‑/Gestenprofile; untypische 24/7‑Taktung.
• Agent‑Egress‑Signaturen: Bekannte Assistenten‑IP‑Pools, TLS‑Fingerprints oder Referer‑Muster. Nicht pauschal blockieren, aber risikobewerten und Step‑up verlangen.
• Köder mit verschlüsselter Payload: Wenn der Assistent eines Nutzers angewiesen wird, Daten zu entschlüsseln oder weiterzuleiten, sehen Sie Schübe von Copy‑Paste‑Verhalten. Begrenzen Sie die Rate von OTP‑Versuchen und entschärfen Sie Sperrbildschirm‑Vorschauen.

Bauen Sie Tripwires in Ihren Auth‑ und Freigabe‑Services: Wenn verdächtige Signale auslösen, stufen Sie Sitzungen herab und erzwingen Sie vor sensiblen Aktionen einen user‑verifizierenden WebAuthn‑Check.

Governance: Ihr Audit‑Trail muss das „Was“ Ihrer Signatur erfassen

Audits mit „Nutzer hat um 10:03 genehmigt“ sind in Streitfällen wertlos. Speichern Sie:

• Die exakte kanonische Payload, die der Nutzer gesehen hat (normalisierter Betrag, Währung, Gegenpartei‑ID),
• Die attestierte App/das attestierte Gerät, das sie anzeigte,
• Die kryptografische Signatur über diese Payload sowie Key Handle/Credential ID,
• Alle Delegationen oder den Kontext einer Doppel‑Freigabe.

Legen Sie das in ein Write‑Once‑Log (WORM oder Append‑Only‑Store) und machen Sie den Abruf zu einem First‑Class‑Produktfeature für Ihr Risk‑Team. So werden Post‑Mortems von Schuldzuweisungen zu evidenzbasierter Triage.

30‑60‑90‑Tage‑Plan

Tage 0–30: Die Blutung stoppen

• Deaktivieren Sie OTP‑Previews auf dem Sperrbildschirm in Ihren Mobile‑Apps; entfernen Sie OTP‑Inhalte aus Benachrichtigungen.
• Liefern Sie WebAuthn für alle Nutzer als sichtbare, empfohlene Option; machen Sie es für Mitarbeitende und Admins verpflichtend.
• Entfernen Sie E‑Mail‑Link‑Freigaben für Admin‑Aktionen. Verlangen Sie In‑App‑Bestätigung mit WebAuthn.
• Instrumentieren Sie assistentenähnliches Verhalten in Auth‑Logs; fügen Sie einfache Tripwires und manuelle Prüfungen für hochwerte Events hinzu.

Tage 31–60: Ersetzen, nicht flicken

• Machen Sie WebAuthn zum Standard bei Sign‑up und bei Re‑Authentifizierungen. Bieten Sie eine kurze SMS‑Übergangsphase nur, wo unvermeidbar, mit gedeckelten Rechten.
• Implementieren Sie Transaktionssignaturen in Mobile und Web für Zahlungen, Datenexport, Schlüsselrotation und Rollenänderungen.
• Starten Sie Recovery‑Kits und die Einschreibung sekundärer Anmeldedaten. Entfernen Sie telefonbasierte Resets für Mitarbeitende/Admins.

Tage 61–90: Konsequent abschalten

• Entfernen Sie SMS‑OTP aus Hochrisiko‑Märkten und ‑Rollen. Wo vorgeschrieben, in eine separate Policy‑Domain mit reduzierten Limits und erweitertem Monitoring isolieren.
• Aktivieren Sie UV‑erforderliche residente Schlüssel und blockieren Sie Non‑UV‑Credentials in Consumer‑Flows.
• Finalisieren Sie die Audit‑Ablage für signierte Payloads mit WORM‑Eigenschaften und Self‑Service‑Abruf für Risk/Compliance.

Trade‑offs, die Sie bewusst tragen sollten

• Heute etwas mehr Reibung für weniger Incidents morgen. Die WebAuthn‑Einschreibung verlängert das Onboarding um eine Minute. Das ist günstiger als eine support‑begünstigte Account‑Übernahme (ATO).
• Gerätegebundene vs. synchronisierte Passkeys. Gerätegebunden ist stärker, erhöht aber das Lockout‑Risiko. Für Consumer synchronisierte Passkeys mit starkem Recovery erlauben; für Admins gerätegebunden bevorzugen.
• Verschiebung der Supportkosten. Sie werden mehr Recovery‑Kit‑ und Sekundär‑Key‑Workflows handhaben. Schulen Sie den Support und bieten Sie Self‑Service‑Wege. Die Netto‑Betrugskosten sinken dennoch.
• Legacy‑Partner. Manche Fintech‑ und Identity‑Anbieter drängen weiterhin auf SMS‑Flows. Eskalieren Sie jetzt oder planen Sie den Exit. Ihre Nutzer sollten nicht die Risikohaltung Ihrer Vendoren erben.

Und B2B? Ihre Admins sind die Kronjuwelen

Auch wenn Ihr Produkt nicht Consumer‑facing ist, können Ihre Admins SSO‑Domainänderungen, SCIM‑Rollen, API‑Token‑Scopes genehmigen und Kundendaten exportieren. Behandeln Sie alle Admin‑Freigaben als Signatur‑Events, nicht als Klicks. Erzwingen Sie WebAuthn mit UV‑erforderlichen Keys, das Vier‑Augen‑Prinzip für irreversible Änderungen und Sitzungsbindung an attestierte Geräte.

Brazil/LatAm Hinweis: Warten Sie nicht auf Carrier

Wenn Sie in Lateinamerika tätig sind, wissen Sie bereits, dass SMS‑Zustellung und SIM‑Sicherheit je Markt variieren. Früher war das ein operativer Schmerz; heute ist es eine Sicherheits‑Haftung. Die gute Nachricht: WebAuthn funktioniert überall auf iOS und Android, und hardware‑gestützte Keys sind allgegenwärtig. Nearshore‑Teams können Ihnen beim Refactoring der Flows ohne Zeitzonen‑Schmerz helfen (6–8 Stunden Überschneidung mit den USA), aber die architektonische Richtung ist dieselbe: Kryptographie statt Kanälen.

Die neue Regel

Wenn ein Assistent es sehen oder senden kann, ist es In‑Band. Das ist in Ordnung — solange Ihre Sicherheit nicht vom Kanal getrieben wird, sondern vom Schlüssel. Verlegen Sie Ihre Kontrollen dorthin, beweisen Sie, was signiert wurde, und es ist Ihnen egal, wer den Posteingang liest.

Wichtigste Erkenntnisse

• OS‑Assistenten können Texte und E‑Mails lesen und senden. SMS/E‑Mail sind nicht mehr Out‑of‑Band — behandeln Sie sie als automatisierbar In‑Band.
• Ersetzen Sie Kanalvertrauen durch Schlüsselvertrauen: WebAuthn mit UV‑erforderlichen residenten Schlüsseln und expliziter Transaktionssignatur.
• Schaffen Sie Fallbacks ab, die Risiko re‑einführen (SMS, E‑Mail‑Links, Telefonfreigaben), oder isolieren Sie sie mit engen Limits und Monitoring.
• Speichern Sie signierte „Was Sie freigegeben haben“‑Payloads mit WORM‑Eigenschaften für beweistaugliche Audits.
• Erkennen Sie assistentenähnliches Verhalten und verlangen Sie kryptografisches Step‑up bei verdächtigen Flows.
• Regulatoren wollen Unabhängigkeit und Assurance, nicht speziell SMS. Kryptografische Freigaben erfüllen die Intention besser als Legacy‑OOB.