Passkeys und MFA mit Keycloak: passwortlos ins Kundenportal

Dein B2B-Portal kann noch so sorgfältig gebaut sein – die Passwörter deiner Nutzer sind es nicht. Die FIDO Alliance macht Passwörter für rund 80 Prozent aller Datenlecks verantwortlich: abgefischt per Phishing-Mail, wiederverwendet über Dutzende Dienste, durchprobiert per Credential Stuffing. Ein Kundenportal erbt dieses Risiko mit jedem einzelnen Login-Feld.

Dazu kommt ein stiller Kostenblock: der Passwort-Reset. Gartner schätzt seit Jahren, dass 20 bis 50 Prozent aller Helpdesk-Anrufe auf vergessene Passwörter entfallen; Forrester bezifferte die Kosten großer Organisationen auf rund 70 US-Dollar pro Reset. Selbst wenn deine Zahlen niedriger liegen: Jeder Reset ist ein Kunde, der in diesem Moment nicht bestellt, sondern wartet.

Und Phishing zielt längst nicht mehr nur auf Konzerne: Gefälschte Portal-Logins sind Standardwerkzeug im Angriff auf den Mittelstand, gestohlene B2B-Zugänge werden gehandelt. Ein Passwortfeld im Kundenportal bleibt damit ein dauerhaft offenes Einfallstor – egal wie gut der Rest der Anwendung gehärtet ist.

Für genau dieses Problem gibt es inzwischen einen Industriestandard: Passkeys. Läuft dein Portal auf Keycloak, hast du die nötige Technik bereits im Haus. Dieser Artikel klärt drei Fragen: Was sind Passkeys? Was kann Keycloak Stand September 2026? Und wie sieht ein Stufenmodell aus, das deine Nutzergruppen mitnimmt, statt sie zu überfordern?

Ein Passkey ist eine passwortlose Anmeldung: Statt einer Zeichenkette, die man wissen und geheim halten muss, besitzt das Gerät des Nutzers einen kryptografischen Schlüssel. Beim Login bestätigt er sich so, wie er sein Smartphone entsperrt – per Fingerabdruck, Gesichtserkennung oder PIN. Technisch steckt dahinter WebAuthn, seit 2019 ein W3C-Standard, plus die FIDO2-Spezifikationen der FIDO Alliance.

Der Kernunterschied zum Passwort: Es gibt nichts mehr, was ein Angreifer stehlen könnte. Der geheime Schlüssel verlässt das Gerät nie, und er antwortet nur der Domain, für die er angelegt wurde. Eine täuschend echte Phishing-Kopie deines Portals läuft ins Leere. Deshalb gelten Passkeys als phishing-resistent – nicht bloß als phishing-erschwerend wie ein SMS- oder App-Code.

Wichtig für die Einordnung: Ein Passkey ist nicht nur bequemer, er ist im Kern bereits Mehr-Faktor. Das Gerät ist der Besitz-Faktor, die Entsperrung per Biometrie oder PIN der zweite. Die passwortlose Anmeldung schafft die MFA also nicht ab – sie baut sie in einen einzigen Handgriff ein.

Zwei Bauformen solltest du kennen. Synchronisierte Passkeys liegen im Schlüsselbund des Nutzers (iCloud-Schlüsselbund, Google Passwortmanager, 1Password) und wandern automatisch auf neue Geräte. Gerätegebundene Passkeys stecken in Hardware-Keys wie einem YubiKey und verlassen ihn nie. Erstere sind die bequeme Wahl für Portalkunden, letztere die harte Währung für Admin-Zugänge.

Zur Verbreitung: In einer FIDO-Umfrage von 2024 gaben 53 Prozent der Befragten an, Passkeys auf mindestens einem Konto aktiviert zu haben. Deine Portalnutzer kennen das Verfahren von Google, PayPal oder ihrem Apple-Konto – wer Passkeys im Unternehmen einführt, bringt also keinen Exoten mit, sondern holt einen vertrauten Komfort ins B2B.

Vorab zur Einordnung: Was Keycloak als Open-Source-IAM grundsätzlich leistet, liest du im Überblick Was ist Keycloak?. Hier geht es allein um die Frage, wie ausgereift die passwortlose Anmeldung dort ist. Die kurze Antwort: ausgereift.

WebAuthn beherrscht Keycloak seit Jahren als Zwei-Faktor- und Passwordless-Verfahren. Passkeys im heutigen Sinne liefen ab Version 23 (Ende 2023) als Preview-Feature mit. Den Schritt zur Produktionsreife dokumentiert die Ankündigung zu Keycloak 26.4 vom September 2025: Seitdem ist die Passkey-Integration offiziell supported.

Die Entwicklung geht weiter: Version 26.7 vom Juli 2026 brachte die Discoverable-Credential-Einstellung nach aktueller WebAuthn-Spezifikation und verbesserte damit die Kompatibilität mit iCloud-Schlüsselbund, Google Passwortmanager und 1Password. Stand heute (Keycloak 26.7) sind Passkeys, WebAuthn und Recovery-Codes als unterstützte Features standardmäßig aktiv.

Die für Kunden wichtigste Neuerung heißt Conditional UI: Der Browser schlägt den Passkey direkt im Anmeldefeld vor, so wie ein Passwortmanager gespeicherte Zugangsdaten anbietet – ein Fingertipp, fertig. Daneben bleibt die Modal UI erhalten, das klassische Dialogfenster, das vor allem Hardware-Keys mit PIN- oder Biometrie-Abfrage bedient.

Erfreulich unspektakulär ist der Umbau: Den Standard-Browser-Flow musst du nicht anfassen. Du aktivierst Passkeys in der WebAuthn-Passwordless-Policy des Realms und bietest die Registrierung als Required Action an. Ein neuer Conditional-Authenticator überspringt zudem die Abfrage des zweiten Faktors, wenn sich ein Nutzer bereits per Passkey angemeldet hat – doppelte Sicherheit ohne doppelte Hürde.

Für die Kaufentscheidung heißt das: Passkey-Fähigkeit ist bei Keycloak kein Aufpreis-Feature und kein Add-on-Tarif, sondern Teil der Standardausstattung – inklusive Conditional UI, Policies und Admin-Werkzeugen. Die Frage ist nicht mehr, ob die Technik reif ist, sondern wie du sie einführst.

Passkeys sind der Zielzustand, aber kein Portal springt an einem Tag dorthin. Dazwischen liegt klassische Multi-Faktor-Authentifizierung – und die beherrscht Keycloak in voller Breite:

Dazu kommen Brute-Force-Schutz, Session-Policies und Step-up-Authentifizierung: Keycloak kann für kritische Aktionen eine stärkere Anmeldung verlangen als für den normalen Portalzugriff – etwa eine Passkey-Bestätigung vor der Freigabe einer Großbestellung. Welche Protokolle das Richtung Anwendungen transportieren, sortiert der Beitrag SAML vs. OIDC.

Alle Nutzer über einen Kamm zu scheren wäre bequem, aber falsch: Ein Einkäufer, der monatlich bestellt, hat ein anderes Risikoprofil als der Admin deines Realms. Ein Stufenmodell, das sich in unseren Portal-Projekten bewährt hat – ausdrücklich eine Einschätzung, kein Dogma:

Portalkunden: Das Passwort bleibt vorerst, der Passkey wird nach dem Login aktiv angeboten. OTP steht sicherheitsbewussten Kunden freiwillig offen. Ziel ist Komfortgewinn, nicht Umerziehung.

Backoffice und Mitarbeiter: MFA-Pflicht ab dem ersten Tag – OTP als Minimum, Passkey als die bequemere Alternative, die sich erfahrungsgemäß von selbst durchsetzt.

Admins und Schlüsselrollen: gerätegebundene Hardware-Keys plus Recovery-Codes im Tresor. Cloud-Synchronisation ist hier bewusst unerwünscht: Der Schlüssel zum Identitätssystem gehört nicht in einen geteilten Schlüsselbund.

Der Hebel für die Umsetzung heißt Required Actions: Du legst je Gruppe fest, ob die Passkey-Registrierung angeboten, empfohlen oder verpflichtend ist. So wird aus der Sicherheitsrichtlinie ein konfigurierbarer Prozess statt eines Projekts pro Änderung.

Technisch bildest du diese Stufen über Authentication Flows mit Bedingungen ab – je Rolle, je Client, je Kontext. Wie das Portal dahinter per SSO an ERP und Warenwirtschaft hängt, zeigt der Artikel Kundenportal-SSO mit ERP-Anbindung.

So weit die Technik. Über Erfolg oder Frust entscheidet die Einführung – und hier sprechen wir aus Projekterfahrung, nicht aus dem Datenblatt. Drei Punkte, an denen die Einführung von Passkeys im Unternehmen praktisch hängen bleibt:

Starte nie mit einem harten Passwort-Verbot. Der realistische Weg ist Koexistenz: Passkey als beworbene Standardoption, Passwort als Fallback, Recovery-Codes als Notanker. Erst wenn eine Nutzergruppe messbar überwiegend passwortlos kommt, ziehst du dort das Passwort zurück. Keycloak erlaubt genau diese schrittweise Gangart – pro Flow, pro Gruppe, ohne Alles-oder-nichts-Entscheidung.

Was passiert, wenn das Smartphone im Taxi liegen bleibt? Bei synchronisierten Passkeys ist die Antwort entspannt: Das neue Gerät bringt die Schlüssel über den Schlüsselbund mit. Kritisch wird es bei gerätegebundenen Keys und bei Nutzern ohne verwaltete Endgeräte – dort gehören Recovery-Codes verpflichtend zur Registrierung. Sonst tauschst du Passwort-Reset-Tickets nur gegen Passkey-Reset-Tickets.

Eine B2B-Eigenheit noch: Am Empfangstresen oder in der Werkstatt teilen sich zuweilen mehrere Personen ein Konto. Solche Sammel-Logins vertragen sich nicht mit Biometrie am persönlichen Gerät. Kläre vor dem Rollout, wo es sie gibt – und ob sie nicht ohnehin ein Fall für getrennte Konten sind.

Unsere Erfahrung: Zwang erzeugt Tickets, ein guter Moment erzeugt Adoption. Der beste Zeitpunkt für das Passkey-Angebot: direkt nach einem erfolgreichen Login, idealerweise nach einem Passwort-Reset – der Schmerz ist frisch, das Argument «nie wieder Passwort vergessen» wirkt.

Bei internen Nutzern geht es schneller: Dort setzt sich der Passkey nach unserer Einschätzung binnen weniger Wochen durch, sobald die ersten Kollegen den schnelleren Login vorführen. Bei Portalkunden plane in Monaten, nicht in Wochen, und miss den Fortschritt: Anteil passwortloser Logins, Reset-Tickets pro Monat, Registrierungsabbrüche. Die Merkregel: Passwortlos ist eine Migration, kein Schalter.

Läuft dein Portal bereits auf Keycloak, ist der Einstieg klein: Policy aktivieren, Pilotgruppe definieren, Registrierung bewerben – ein Vorhaben von Tagen, nicht Monaten. Steht das Portal noch aus, denk die Identitätsschicht von Beginn an mit: Wie wir Kundenportale mit Keycloak, SSO und ERP-Anbindung bauen, zeigt die Seite Kundenportal entwickeln lassen.

Du willst wissen, welches Stufenmodell zu deinen Nutzergruppen passt, oder ob dein bestehendes Setup passkey-bereit ist? Dann buch dir ein unverbindliches Beratungsgespräch: 30 Minuten, konkrete Einschätzung, kein Folien-Theater.