Zurück zum Blog
Privacy and security

Identitätsprüfung im Kundensupport-Chat: Ein Leitfaden für risikobasiertes Design

Ein praxisnaher Rahmen, um festzulegen, was Supportteams im Chat klären müssen, wie viele Nachweise sie anfordern sollten und wann ein Fall in einen sichereren, menschlich begleiteten Prozess überführt wird.

Support-Spezialist prüft einen risikobasierten Ablauf zur Identitätsprüfung im Kundenchat

Warum die Identitätsprüfung in Nachrichten einen risikobasierten Ansatz braucht

Die Identitätsprüfung im Kundensupport ist keine universelle Frage mit einer universellen Antwort. Eine Kundin, die nach Öffnungszeiten fragt, stellt ein völlig anderes Risiko dar als jemand, der eine Adressänderung, die Offenlegung einer Kontohistorie oder eine folgenreiche Kontoaktion verlangt.

Ein Chatkanal erleichtert das Stellen von Fragen und das Erfassen von Antworten. Diese Bequemlichkeit ist kein Nachweis dafür, dass die Person im Gespräch geschützte Informationen erhalten oder eine sensible Änderung vornehmen darf. Richten Sie das erforderliche Sicherheitsniveau am möglichen Schaden einer falschen Entscheidung aus: Preisgabe privater Informationen, unbefugte Änderung, finanzieller Verlust, Verlust einer Dienstleistung oder Schaden für einen Kunden.

Wählen Sie den am wenigsten aufdringlichen Weg, der die Aktion sicher ermöglicht. Anfragen mit geringem Risiko sollten einfach bleiben. Anfragen mit höherem Risiko sollten in einen stärkeren authentifizierten Prozess oder einen dokumentierten, menschlich begleiteten Wiederherstellungsprozess überführt werden. Gleichen Sie ein unklares Risikomodell nicht dadurch aus, dass Sie im Chat routinemäßig mehr personenbezogene Daten erheben.

  • Beginnen Sie mit dem gewünschten Ergebnis, nicht mit einer Standardliste von Identitätsfragen.
  • Erhöhen Sie das Sicherheitsniveau mit dem möglichen Schaden einer falschen Entscheidung.
  • Trennen Sie die normale Supportbearbeitung von der Kontowiederherstellung und der Bearbeitung vermuteter Identitätsvortäuschung.
  • Behandeln Sie Datenminimierung, Barrierefreiheit und Eskalation als Anforderungen des Workflows, nicht als optionale Verbesserungen.
Warum die Identitätsprüfung in Nachrichten einen risikobasierten Ansatz braucht

Trennen Sie drei Entscheidungen, die Teams oft als „Prüfung“ bezeichnen

Das Wort „Prüfung“ verdeckt oft drei unterschiedliche Entscheidungen. Sie zusammenzufassen führt am einen Ende zu unnötiger Datenerhebung und am anderen zu gefährlicher Selbstsicherheit.

Die Identitätsfeststellung beantwortet die Frage: „Wer ist diese Person?“ Sie umfasst das Erheben, Validieren und Prüfen von Informationen, um ein Sicherheitsniveau für eine behauptete Identität zu schaffen. Sie ist nicht für jedes Supportgespräch erforderlich.

Authentifizierung beantwortet die Frage: „Kann diese Person die Kontrolle über ein an das Konto gebundenes Authentifizierungsmerkmal nachweisen?“ Sie kann den Zugang zu einem Konto bestätigen, beweist aber nicht jedes reale Merkmal, jede Beziehung oder jede Berechtigung, die die Person beansprucht.

Autorisierung beantwortet die Frage: „Darf diese authentifizierte Person diese konkrete Aktion ausführen?“ Selbst ein authentifizierter Kontoinhaber kann möglicherweise keine Rückerstattung genehmigen, die Daten eines anderen Nutzers ändern, für eine Organisation handeln oder eine Aktion mit hoher Auswirkung durchführen. Die Autorisierung sollte für jede geschützte Anfrage mit einer standardmäßigen Ablehnung geprüft werden.

  • Identitätsfeststellung: Schaffen Sie bei Bedarf Sicherheit über eine behauptete Identität.
  • Authentifizierung: Stellen Sie die Kontrolle über ein an das Konto gebundenes Authentifizierungsmerkmal fest.
  • Autorisierung: Bestätigen Sie die Berechtigung für die angeforderte Aktion, das Konto, das Objekt und den Kontext.
  • Fallbearbeitung: Erheben Sie nur die Informationen, die zum Verstehen und Lösen des Problems erforderlich sind; sie sind nicht automatisch ein Identitätsnachweis.
Trennen Sie drei Entscheidungen, die Teams oft als „Prüfung“ bezeichnen

Klassifizieren Sie Anfragen nach möglichem Schaden, bevor Sie Eingabeaufforderungen gestalten

Eine einfache Klassifizierung von Anfragen gibt Mitarbeitenden und Automatisierungen eine einheitliche Grundlage für die Weiterleitung. Außerdem verhindert sie, dass Kunden mit geringem Risiko einer aufwendigen Prüfung unterzogen werden, die kaum zusätzlichen Schutz bietet.

Definieren Sie Kategorien anhand der Ergebnisse, die Ihr Team offenlegen oder durchführen kann, und dokumentieren Sie anschließend Beispiele und Ausnahmen. Die folgenden Kategorien sind ein Ausgangsmodell; die passenden Schwellenwerte hängen von Ihrer Dienstleistung, Ihrer Kundengruppe und geltenden Verpflichtungen ab.

  • Allgemeine Informationen: öffentliche Richtlinien, Produktinformationen, Servicezeiten und nicht kontospezifische Fehlerbehebung. Allein zur Beantwortung dieser Fragen sollte keine Kontoprüfung erforderlich sein.
  • Kontospezifische Informationen: Salden, Bestelldetails, private Nachrichten, Kontohistorie, Kontaktdaten oder Servicestatus. Verwenden Sie vor der Offenlegung einen authentifizierten Kontoweg.
  • Kontoänderungen: Änderungen an Kontaktdaten, Präferenzen, Zugriffseinstellungen, Lieferdetails oder verknüpften Nutzern. Fordern Sie einen stärkeren Weg und prüfen Sie, ob die authentifizierte Partei für diese konkrete Änderung autorisiert ist.
  • Maßnahmen mit hoher Auswirkung: Kontowiederherstellung, Änderungen an Sicherheitseinstellungen, zahlungsbezogene Maßnahmen, Schließung, erhebliche Serviceänderungen oder Handlungen mit schwerwiegenden Folgen für Kunden. Verwenden Sie einen bewusst gestalteten Prozess mit hohem Sicherheitsniveau und geschulter menschlicher Prüfung, wenn Unklarheiten bestehen bleiben.

Wenden Sie Datenminimierung auf jeden Chat-Schritt an

Bevor Sie eine Eingabeaufforderung formulieren, legen Sie ihren genauen Zweck fest: Welche Entscheidung ermöglicht diese Antwort, und welche Mindestinformationen werden dafür benötigt? Datenminimierung verlangt, dass Informationen für den genannten Zweck angemessen und relevant sind, aber auf das Notwendige begrenzt bleiben.

Fordern Sie von Kunden nicht mehr Nachweise, als die angeforderte Aktion erfordert. Ein Mitarbeiter kann beispielsweise nicht sensible Angaben benötigen, um einen Fall zu finden, während das System vor der Offenlegung kontospezifischer Informationen einen authentifizierten Kontoweg verlangen sollte. Die Aufforderung, ein Dokument, das vollständige Geburtsdatum oder andere sensible Daten zu senden, sollte niemals ein standardmäßiger Ersatz für einen gestalteten Prüfweg sein.

Machen Sie unzulässige Eingaben im Ablauf sichtbar. Kunden sollten darauf hingewiesen werden, keine Passwörter, Codes zur Kontowiederherstellung oder andere wiederverwendbare Geheimnisse in einem Supportgespräch zu senden. Falls sie dennoch sensible Informationen senden, folgen Sie einem dokumentierten Verfahren zur Eindämmung, anstatt diese Informationen zu wiederholen oder in zusätzliche Aufzeichnungen zu kopieren.

  • Dokumentieren Sie für jedes Feld seinen Zweck, ob es erforderlich ist, wer es einsehen kann und wie lange es aufbewahrt wird.
  • Verwenden Sie validierte Antworten nur für Informationen, die tatsächlich zur Weiterleitung oder Bearbeitung des Falls erforderlich sind.
  • Vermeiden Sie die Erhebung von Zugangsdaten, Wiederherstellungscodes und anderen wiederverwendbaren Geheimnissen im Chat.
  • Behandeln Sie eine Gesprächsantwort auf persönliche Fragen nicht als universelle Identitätsprüfung.
  • Prüfen Sie Vorlagen und Agenten-Makros auf Anfragen, die Informationen „für alle Fälle“ erheben.

Wählen Sie eine Prüfmethode, die zur Aktion passt

Für geschützte Kontoinformationen und Änderungen besteht das sicherere Muster darin, Kunden zu einem etablierten authentifizierten Kontoprozess zu leiten, statt sie ihre Identität über Chatnachrichten nachweisen zu lassen. Der Chat kann erklären, warum dieser Schritt erforderlich ist, und für nicht sensible Fehlerbehebung verfügbar bleiben.

Bei verlorenem Zugang verwenden Sie einen dokumentierten Wiederherstellungsweg, der auf einer Risikoanalyse beruht. Die Wiederherstellung kann einen genehmigten Prozess zur Kontowiederherstellung, eine erneute Identitätsfeststellung, einen Wiederherstellungskontakt oder eine anwendungsspezifische Interaktion mit einem Mitarbeiter umfassen. Die zentrale operative Regel lautet, die normale Schwelle nicht zu senken, nur weil der Kunde sie im Chat nicht erfüllen kann.

Wenn eine Wiederherstellung erfolgreich ist, benachrichtigen Sie nach dem Wiederherstellungsereignis den Abonnenten oder eine angemessene benannte Person, damit möglicherweise betrügerische Wiederherstellungen erkannt werden können. Ermutigen Sie Kunden, sofern Ihr Kontodesign dies unterstützt, mehr als einen unabhängigen Authentifizierungsweg vorzuhalten, um die Abhängigkeit von außergewöhnlichen Wiederherstellungswegen zu verringern.

  • Nutzen Sie öffentliche Chatinformationen für öffentliche Fragen.
  • Verwenden Sie für kontospezifische Offenlegungen einen authentifizierten Kontoweg.
  • Prüfen Sie Kontorolle, Beziehung und Berechtigung bei Änderungen, die ein authentifizierter Nutzer anfordert.
  • Nutzen Sie für Ausnahmefälle einen separaten, dokumentierten Prozess für hohe Auswirkungen oder Wiederherstellungen.
  • Fordern Sie niemals ein Passwort oder einen Wiederherstellungscode als Nachweis in einer Chatnachricht an.

Gestalten Sie einen sicheren, verständlichen Nachrichtenablauf

Ein sicherer Ablauf sollte auch verständlich sein. Erklären Sie, was das Team tun muss, warum der Schritt notwendig ist, was der Kunde nicht senden sollte und was geschieht, wenn er ihn nicht abschließen kann. Eine klare Erklärung verringert versehentliches Oversharing und lässt eine Ablehnung wie eine Schutzmaßnahme statt wie eine Sackgasse wirken.

Ein praktisches Muster lautet: Anfrage klassifizieren, Zweck erklären, den passenden Weg anbieten, den resultierenden Status validieren, die autorisierte Entscheidung treffen und den minimalen operativen Kontext dokumentieren. Vermeiden Sie die Offenlegung geschützter Details, während ein Kunde noch versucht, die Prüfung zu bestehen.

Bieten Sie eine barrierefreie Alternative an. Authentifizierung sollte einen Test kognitiver Fähigkeiten nicht zum einzigen verfügbaren Weg machen. Hilfe- und Wiederherstellungsoptionen sollten in allen WebChat-Abläufen einheitlich verfügbar sein, damit Kunden sie bei einem fehlgeschlagenen Versuch finden können.

  • Verwenden Sie einfache Sprache: „Zum Schutz Ihres Kontos müssen Sie den sicheren Kontoweg zur Anmeldung nutzen, bevor wir dieses Detail besprechen können.“
  • Formulieren Sie ein klares Verbot: „Senden Sie hier weder Ihr Passwort noch einen Code zur Kontowiederherstellung.“
  • Erklären Sie die Alternative: „Wenn Sie sich nicht anmelden können, wählen Sie Hilfe beim Kontozugriff oder bitten Sie um einen Support-Spezialisten.“
  • Behalten Sie, wo möglich, denselben Ort für Hilfe und dieselbe Formulierung über verschiedene Einstiegspunkte hinweg bei.
  • Bestätigen Sie nur, was sicher bestätigt werden kann; legen Sie keine Kontodaten offen, solange die Entscheidung ungeklärt ist.

Behandeln Sie den Nachrichten-Kontext als Kontext, nicht als Berechtigungsnachweis

Eine Nachricht aus einem vertrauten Verlauf oder von einer bekannten Telefonnummer kann ein nützlicher Kontext sein, ist aber kein ausreichender Nachweis für eine sensible Anfrage. Ein Gerät kann gemeinsam genutzt werden, eine Nachricht kann weitergeleitet werden, eine Telefonnummer kann sich ändern, und der Zugriff auf ein Gespräch begründet nicht automatisch die Berechtigung für ein Konto oder eine Aktion.

Wenn ein Kunde eine neue Nummer oder verlorenen Zugang meldet, aktualisieren Sie den sensiblen Kontodatensatz nicht allein aufgrund der Chat-Anfrage. Leiten Sie den Fall über das relevante authentifizierte Änderungs- oder Wiederherstellungsverfahren weiter. Legen Sie ebenso keine Kontodetails gegenüber jemandem offen, der Informationen aus einer weitergeleiteten Nachricht zitieren kann.

Bei Vertretern Dritter sind zwei Entscheidungen nötig: Stellen Sie die relevante Identität oder authentifizierte Beziehung der Person fest und bestätigen Sie dann die Berechtigungen, die für die konkrete Aktion gelten. Eine pauschale Behauptung wie „Ich verwalte dieses Konto“ ist keine Autorisierungsentscheidung.

  • Gemeinsam genutztes Gerät: Leiten Sie aus einem geöffneten Gespräch nicht auf die alleinige Kontrolle über das Konto.
  • Weitergeleitete Nachricht: Behandeln Sie kopierten Kontext nicht als Berechtigungsnachweis.
  • Neue Telefonnummer: Nutzen Sie den genehmigten Änderungs- oder Wiederherstellungsweg, bevor Sie Kontaktdaten ändern.
  • Vertreter Dritter: Validieren Sie die relevante Beziehung und die Berechtigung nach dem Prinzip der geringsten Rechte für die konkrete Anfrage.
  • Unklare Beziehung oder Berechtigung: Lehnen Sie die geschützte Aktion ab und eskalieren Sie den Fall.

Legen Sie kanalspezifische Erwartungen fest, ohne Kanalverhalten und Teamkontrollen zu verwechseln

WebChat und WhatsApp sind Einstiegspunkte für Nachrichten, keine vollständige Autorisierungsrichtlinie. Ihre Organisation bleibt dafür verantwortlich festzulegen, welche Anfragen in welchem Kanal bearbeitet werden dürfen, welche Nachweise akzeptiert werden, wie sensible Fälle übergeben werden und was Mitarbeitende offenlegen oder ändern dürfen.

In Hinweisen für WhatsApp sollten Sie Kunden daran erinnern, keine Zugangsdaten oder sensiblen personenbezogenen Informationen als Reaktion auf unerwartete Anfragen weiterzugeben. Dies ist ein Hinweis zur Kundensicherheit und keine Behauptung, dass ein Nachrichtengespräch allein Identität oder Berechtigung nachweist.

In webchat.vip kann ein gemeinsamer Posteingang Teams dabei helfen, WebChat- und WhatsApp-Gespräche über Mitarbeitende, Abteilungen, Weiterleitung, Zeitpläne, Service-Level, Vorlagen und Tags hinweg zu organisieren. Konfigurieren Sie diese operativen Werkzeuge anhand Ihrer Richtlinie; lassen Sie nicht zu, dass ein Weiterleitungslabel oder eine Kanalkennung Authentifizierung oder Autorisierung ersetzt.

Jeder WebChat-Kanal kann ein installierbares, anpassbares und mehrsprachiges Widget verwenden. Halten Sie Sicherheitshinweise, den barrierefreien Hilfeweg und die Eskalationsformulierung in allen Widget-Sprachen konsistent und validieren Sie Übersetzungen mit derselben Sorgfalt wie den primären Ablauf.

  • Definieren Sie kanalgeeignete Grenzen für Offenlegungen und Änderungen.
  • Trennen Sie das vom Anbieter gesteuerte Kanalverhalten von Ihren eigenen Supportverfahren und Kontokontrollen.
  • Verwenden Sie genehmigte Vorlagen für Warnungen vor der Weitergabe von Geheimnissen und Erklärungen zum sicheren Weg.
  • Stellen Sie sicher, dass die Eskalationsoption in jeder unterstützten Sprache leicht zu finden ist.
  • Schulen Sie Mitarbeitende darin, aus Bequemlichkeit niemals eine schwächere Identitätsprüfung zu improvisieren.

Häufig gestellte Fragen

Was ist Identitätsprüfung im Kundensupport?

Sie umfasst die Kontrollen, mit denen ein Supportteam das erforderliche Sicherheitsniveau feststellt, bevor es eine Anfrage bearbeitet. In der Praxis sollten Teams zwischen Identitätsfeststellung, Authentifizierung des Kontozugriffs und Autorisierung für eine konkrete Aktion unterscheiden, statt alle drei als dieselbe Prüfung zu behandeln.

Sollten Supportmitarbeitende Kunden bitten, Passwörter oder Wiederherstellungscodes im Chat zu senden?

Nein. Passwörter und Wiederherstellungscodes sind wiederverwendbare Geheimnisse und sollten in einem Supportgespräch nicht angefordert werden. Leiten Sie Kunden stattdessen zum etablierten sicheren Konto- oder Wiederherstellungsweg.

Reicht eine WhatsApp-Nachricht von einer bekannten Nummer aus, um eine Kontoänderung zu autorisieren?

Nein. Der Besitz eines Nachrichtengesprächs oder einer Telefonnummer darf nicht mit der Berechtigung für eine sensible Anfrage gleichgesetzt werden. Nutzen Sie den dokumentierten authentifizierten und autorisierten Prozess für die jeweilige Änderung.

Was sollte geschehen, wenn ein Kunde die Prüfung nicht bestehen kann?

Schwächen Sie die normale Prüfschwelle im Chat nicht ab. Stellen Sie den vorgesehenen Wiederherstellungs- oder Eskalationsweg bereit, erklären Sie den nächsten Schritt klar und übergeben Sie unklare oder folgenschwere Fälle an geschulte Mitarbeitende.

Wie kann Automatisierung bei Abläufen zur Identitätsprüfung helfen?

Automatisierung kann nicht sensible Falldetails erfassen, Sicherheitshinweise anzeigen, das Anfragerisiko klassifizieren, geeignete Antworten validieren und Fälle übergeben. Sie sollte keine unbelegten Entscheidungen über Identität oder Autorisierung treffen; sensible oder unklare Fälle benötigen einen Weg zur menschlichen Eskalation.

Was sollten Supportteams zu einer Prüfentscheidung protokollieren?

Protokollieren Sie den minimalen operativen Kontext, der zur Untersuchung und Prüfung der Entscheidung erforderlich ist, etwa Anfragekategorie, genutzter Weg, Ergebnis, Eskalation und autorisierte Aktion. Vermeiden Sie, unnötig sensible Informationen, Geheimnisse oder übermäßige personenbezogene Daten aufzuzeichnen.

Quellen und weiterführende Literatur

Primäre und maßgebliche Referenzen zur Prüfung der faktischen Grundlage dieses Leitfadens.

  1. NIST SP 800-63-4: Digital Identity Guidelines — National Institute of Standards and Technology
  2. NIST SP 800-63A-4: Identity Proofing Overview — National Institute of Standards and Technology
  3. NIST SP 800-63B-4: Authentication and Authenticator Management — National Institute of Standards and Technology
  4. Authorization Cheat Sheet — OWASP Foundation
  5. Authentication Cheat Sheet — OWASP Foundation
  6. Regulation (EU) 2016/679, Article 25: Data Protection by Design and by Default — EUR-Lex / European Union
  7. Data Minimisation Guidance — Information Commissioner's Office
  8. Web Content Accessibility Guidelines (WCAG) 2.2 — W3C Web Accessibility Initiative
  9. Accessible Authentication (Minimum): Understanding Success Criterion 3.3.8 — W3C Web Accessibility Initiative
  10. Message Privately and Safely — WhatsApp Help Center