Passkeys für Firmenwebsites: Wann sich passwortloser Login für KMU lohnt
Beitrag teilen

Ein Kundenportal, ein Mitgliederbereich oder ein internes Dashboard soll den Alltag vereinfachen. Trotzdem beginnt der Zugang oft mit dem mühsamsten Teil: Passwort suchen, Code abwarten, Eingabe wiederholen. Passkeys ersetzen dieses Muster durch eine Anmeldung, die an die echte Website und an ein freigegebenes Gerät gebunden ist. Nutzerinnen und Nutzer bestätigen den Zugang mit der Gerätesperre, also etwa per PIN, Fingerabdruck oder Gesichtserkennung. Das kann sicherer und zugleich bequemer sein als ein Passwort.
Für österreichische KMU ist die entscheidende Frage aber nicht, ob Passkeys modern klingen. Wichtig ist, ob sie ein konkretes Problem lösen. Eine reine Informationswebsite ohne Benutzerkonten braucht keinen Passkey. Bei Kundenportalen, Händlerzugängen, Mitarbeitenden-Dashboards oder wiederkehrenden Buchungsprozessen kann sich eine Einführung dagegen lohnen. Dieser Leitfaden zeigt, wie Betriebe Nutzen, Aufwand, Datenschutz, Wiederherstellung und schrittweise Einführung realistisch bewerten.
Was ein Passkey technisch bedeutet
Passkeys beruhen auf dem offenen WebAuthn-Standard. Bei der Einrichtung erzeugt das Gerät ein kryptografisches Schlüsselpaar. Der öffentliche Schlüssel wird beim Online-Dienst gespeichert. Der private Schlüssel bleibt im Gerät oder in einem dafür vorgesehenen, geschützten Passkey-Anbieter. Beim Login sendet der Server eine einmalige Aufgabe, die das Gerät mit dem privaten Schlüssel signiert. Der Server prüft die Antwort mit dem öffentlichen Schlüssel.
Das unterscheidet sich grundlegend vom Passwort. Ein Passwort ist ein gemeinsames Geheimnis: Die Nutzerin kennt es, und der Dienst muss einen daraus abgeleiteten Prüfwert verwalten. Wird ein Passwort auf einer täuschend echten Seite eingegeben, kann es abgegriffen werden. Ein Passkey ist dagegen an die Identität der Website gebunden. Browser und Betriebssystem prüfen den Ursprung. Der Schlüssel für das echte Kundenportal lässt sich deshalb nicht einfach auf einer fremden Phishing-Seite verwenden.
Die lokale Freigabe per Fingerabdruck oder Gesichtserkennung bedeutet nicht automatisch, dass biometrische Daten an das KMU übertragen werden. Die Website erhält die kryptografische Bestätigung, nicht das Fingerabdruckbild. Je nach Gerät kann auch eine PIN oder eine andere Gerätesperre verwendet werden. Diese Trennung sollte der Betrieb verständlich erklären, weil viele Menschen „Anmeldung mit Fingerabdruck“ sonst mit der Speicherung biometrischer Daten durch den Website-Betreiber verwechseln.
Wann Passkeys für Firmenwebsites sinnvoll sind
Passkeys schaffen dort den größten Nutzen, wo Menschen regelmäßig auf geschützte Funktionen zugreifen. Typische Einsatzfelder sind:
- Kundenportale mit Rechnungen, Auftragsstatus, Dokumenten oder Servicefällen,
- B2B-Bereiche für Händler, Lieferanten oder Partnerunternehmen,
- Mitarbeitenden-Zugänge zu Dienstplänen, internen Formularen oder Administrationsoberflächen,
- Mitgliederbereiche von Verbänden, Studios oder Bildungseinrichtungen,
- Webshops mit häufig wiederkehrenden Kundinnen und Kunden,
- Portale mit sensiblen Änderungen, etwa neue Bankverbindungen, Kontaktpersonen oder Zugriffsrechte.
Eine einfache Kontaktseite, ein Blog oder eine digitale Visitenkarte gewinnt durch Passkeys nichts, solange es keinen Login gibt. Auch ein Portal mit sehr wenigen, technisch betreuten Konten kann vorerst mit einem guten Passwortmanager und phishing-resistenter Mehrfaktor-Authentifizierung auskommen. Die Technik sollte dem Risiko und der tatsächlichen Nutzung folgen, nicht umgekehrt.
Vier Fragen für die erste Entscheidung
- Wie oft melden sich Menschen an? Je häufiger der Login, desto stärker wirkt sich weniger Reibung aus.
- Was wäre bei einer Kontoübernahme betroffen? Dokumente, personenbezogene Daten, Bestellungen und Verwaltungsrechte erhöhen das Schutzbedürfnis.
- Wie viele Supportfälle entstehen durch Passwörter? Zurücksetzungen, gesperrte Konten und nicht ankommende Einmalcodes sind messbare Kosten.
- Beherrscht die eingesetzte Plattform Passkeys sauber? Ein etablierter Identitätsdienst oder eine bewährte Bibliothek ist meist sinnvoller als eine Eigenentwicklung.
Ein KMU sollte daraus eine kurze Ausgangsbasis bilden: Loginanzahl pro Monat, Passwort-Resets, Abbrüche, Supportzeit und bekannte Sicherheitsvorfälle. Ohne Ausgangswert lässt sich später kaum beurteilen, ob die Umstellung tatsächlich geholfen hat.
Welche Vorteile im Betrieb realistisch sind
Weniger Angriffsfläche durch Phishing und wiederverwendete Passwörter
Passkeys sind auf eine konkrete Website beziehungsweise deren zulässige Domain gebunden. Das reduziert das Risiko, dass Zugangsdaten auf einer gefälschten Anmeldeseite landen. Gleichzeitig gibt es kein Passwort, das dieselbe Person bei mehreren Diensten wiederverwenden könnte. Auch sogenannte Credential-Stuffing-Angriffe, bei denen geleakte Kombinationen automatisiert ausprobiert werden, verlieren für reine Passkey-Konten ihren Ansatzpunkt.
Das macht das Gesamtsystem nicht unangreifbar. Eine unsichere Wiederherstellung, gestohlene Sitzungen, fehlerhafte Berechtigungen oder Schadsoftware bleiben relevante Risiken. Passkeys lösen den Authentifizierungsteil, nicht jede Sicherheitsaufgabe einer Webanwendung. Der bestehende Leitfaden zur Website-Sicherheit für KMU hilft, den größeren organisatorischen Rahmen zu betrachten.
Ein kürzerer Login ohne SMS-Code
Wer einen Passkey eingerichtet hat, wählt das Konto aus und bestätigt mit der bekannten Gerätesperre. Das kann weniger Schritte benötigen als Passwort plus Einmalcode. Besonders auf Mobilgeräten und bei häufigen Anmeldungen ist das relevant. FIDO nennt unter anderem höhere Erfolgsraten beim Login, weniger Passwort-Resets und geringere Kosten für SMS als mögliche betriebliche Vorteile. Solche Angaben sind keine Garantie für jeden Shop oder jedes Portal; sie zeigen, welche Kennzahlen ein Pilot beobachten sollte.
Weniger wertvolle Geheimnisse auf dem Server
Der Online-Dienst speichert für die Passkey-Prüfung einen öffentlichen Schlüssel. Der private Schlüssel, der die Anmeldung ermöglicht, wird nicht beim Website-Betreiber abgelegt. Ein Datenabfluss aus der Anwendung enthält damit nicht denselben direkt wiederverwendbaren Login-Faktor wie eine ungeschützte Passwortsammlung. Unabhängig davon müssen öffentliche Schlüssel, Kontozuordnungen, Sitzungen und Wiederherstellungsdaten weiterhin korrekt geschützt werden.
Wo die Einführung scheitern kann
Die größte Schwachstelle eines Passkey-Projekts ist häufig nicht die Kryptografie, sondern der Randprozess. Was passiert nach einem verlorenen Handy? Wie meldet sich eine Mitarbeiterin am Ersatzgerät an? Wer darf einen neuen Passkey hinzufügen? Wie wird ein Zugang entfernt, wenn eine externe Person das Unternehmen verlässt?
Ein bloßer „Passwort vergessen“-Link, der jeden Schutz per E-Mail zurücksetzt, kann den Sicherheitsgewinn verkleinern. Umgekehrt darf der Wiederherstellungsprozess Menschen nicht dauerhaft aussperren. Je nach Risiko kommen ein geprüfter E-Mail-Zugang, Wiederherstellungscodes, ein zweites registriertes Gerät, ein Hardware-Sicherheitsschlüssel oder eine kontrollierte manuelle Identitätsprüfung infrage. Bei administrativen Konten sollte der Betrieb strengere Verfahren wählen als bei einem einfachen Merklisten-Konto.
Auch gemeinsam genutzte Arbeitsplätze brauchen Aufmerksamkeit. Ein Passkey auf dem persönlichen Smartphone ist etwas anderes als ein gemeinsamer Rechner in Werkstatt, Rezeption oder Lager. Dort sollten persönliche Konten, klare Abmeldung, geeignete Geräteverwaltung und gegebenenfalls hardwaregebundene Schlüssel vorgesehen werden. Geteilte Sammelkonten machen Verantwortlichkeiten unklar und erschweren das Entfernen einzelner Berechtigungen.
Passkeys schrittweise statt mit Zwang einführen
Phase 1: Einsatzbereich und Verantwortlichkeit klären
Der Betrieb legt zuerst fest, welche Konten in den Pilot kommen. Ein guter Startpunkt sind interne Administratorinnen und Administratoren oder eine kleine Gruppe häufiger Portalnutzer. Gleichzeitig werden Verantwortliche für Technik, Support, Datenschutz und Freigaben benannt. Bei einem extern betreuten Portal gehört auch der Dienstleister an den Tisch.
Vor der Umsetzung sind Domain und Systemarchitektur zu prüfen. WebAuthn arbeitet mit einer sogenannten Relying Party ID, die in der Regel an die Domain gebunden ist. Ein späterer Wechsel von Portal-Domain, Mandantenstruktur oder Identitätsanbieter kann deshalb Auswirkungen haben. Diese Architekturfrage sollte dokumentiert werden, bevor viele Zugangsdaten angelegt sind.
Phase 2: Passkey als zusätzliche Option anbieten
Für die meisten KMU ist ein freiwilliger Einstieg sinnvoller als die sofortige Abschaffung aller Passwörter. Bestehende Nutzerinnen und Nutzer melden sich wie gewohnt an und können danach in den Sicherheitseinstellungen einen Passkey erstellen. Der Zeitpunkt nach einem erfolgreichen Login oder einer erneuten Bestätigung ist günstig, weil die Identität bereits geprüft wurde.
Die Oberfläche braucht klare deutsche Texte: „Passkey erstellen“, „Mit Passkey anmelden“ und „Passkey löschen“ sind verständlicher als technische Begriffe wie FIDO-Credential. Vor dem Betriebssystem-Dialog sollte kurz stehen, dass die Anmeldung über die Gerätesperre erfolgt und biometrische Merkmale nicht an die Website übertragen werden. Nach Abbruch oder Erfolg muss ein eindeutiger Status erscheinen.
Phase 3: Verwaltung und Wiederherstellung testen
Nutzerinnen und Nutzer sollten mehrere Passkeys hinzufügen können, etwa für Notebook und Smartphone. Die Verwaltung zeigt Erstellungsdatum, letzte Verwendung und eine verständliche Bezeichnung. Ein einzelner Passkey muss widerrufbar sein, ohne das ganze Konto zu löschen. Support-Mitarbeitende brauchen einen dokumentierten Ablauf, dürfen aber nie private Schlüssel sehen oder Passkeys im Namen einer Person erzeugen.
Der Testplan umfasst mindestens: neues Konto, bestehendes Konto, Anmeldung auf demselben Gerät, Anmeldung mit einem zweiten Gerät, abgebrochener Dialog, verlorenes Gerät, gelöschter Passkey, gesperrtes Konto, Rollenwechsel und Austritt einer Mitarbeiterin. Zusätzlich sind aktuelle Versionen der tatsächlich genutzten Browser und Betriebssysteme zu testen. Ein erfolgreicher Technik-Demo-Login allein reicht nicht.
Phase 4: Kennzahlen prüfen und Schutz erhöhen
Nach dem Pilot vergleicht der Betrieb Login-Erfolgsrate, Dauer, Supportkontakte, Wiederherstellungen und Sicherheitsereignisse mit der Ausgangsbasis. Erst wenn Nutzung und Recovery funktionieren, kann Passkey für risikoreiche Rollen verpflichtend werden. Alte Login-Verfahren sollten nicht unbemerkt als dauerhaftes schwaches Hintertürchen bestehen bleiben. Ihre Nutzung, Absicherung und spätere Abschaltung gehören in den Migrationsplan.
Datenschutz und Kommunikation in Österreich
Passkeys ändern die Datenverarbeitung rund um Konten, Geräteinformationen, Anmeldeereignisse und Wiederherstellung. Welche Angaben konkret verarbeitet werden, hängt von Plattform, Identitätsdienst und Konfiguration ab. Deshalb sollten österreichische Unternehmen ihr Verzeichnis der Verarbeitungstätigkeiten, Datenschutzhinweise, Auftragsverarbeiter und Löschfristen prüfen. Dieser Beitrag ist keine individuelle Rechtsberatung; bei sensiblen Anwendungen oder umfangreicher Identitätsprüfung ist fachliche Prüfung sinnvoll.
Wichtig ist eine sachliche Erklärung. Der Betrieb sollte weder „hundertprozentige Sicherheit“ versprechen noch behaupten, Passkeys benötigten immer Biometrie. Eine gute Kurzinfo beantwortet vier Fragen:
- Was ist ein Passkey und wofür wird er verwendet?
- Welche Geräte- oder Kontosperre bestätigt den Login?
- Welche Daten erhält der Website-Betreiber und welche bleiben lokal?
- Was ist bei Gerätewechsel oder Zugriffsverlust zu tun?
Auch Barrierefreiheit gehört zur Einführung. Nutzerinnen und Nutzer brauchen ausreichend Zeit, verständliche Fehlermeldungen und alternative lokale Verifikationsmöglichkeiten wie eine PIN, wenn Biometrie nicht möglich oder nicht gewünscht ist. Der W3C-Entwurf zu WebAuthn Level 3 verweist ausdrücklich auf mehrere Verifikationsmethoden und ausreichende Zeit für den Anmeldevorgang.
Build oder Buy: Was KMU beauftragen sollten
Eine vollständige WebAuthn-Implementierung enthält serverseitige Challenges, Prüfung von Ursprung und Relying Party ID, Signaturvalidierung, Zähler- und Statuslogik, Kontozuordnung, Passkey-Verwaltung sowie sichere Wiederherstellung. Das ist kein geeigneter Bereich für improvisierten Anwendungscode. Selbst Google empfiehlt, serverseitig eine bewährte Bibliothek einzusetzen, statt den Ablauf von Grund auf selbst zu bauen.
Bei einem bestehenden Shop-, Portal- oder Identity-System sollte der erste Schritt eine Funktionsprüfung beim Anbieter sein. Die Leistungsbeschreibung an Agentur oder Softwarehaus sollte nicht nur „Passkey-Login“ nennen, sondern folgende Ergebnisse verlangen:
- unterstützte Browser, Geräte und Passkey-Anbieter,
- Registrierung, Login, Verwaltung und Widerruf,
- Recovery-Konzept mit abgestuften Risiken,
- Protokollierung sicherheitsrelevanter Änderungen,
- Rollen- und Berechtigungsprüfung nach erfolgreichem Login,
- barrierefreie deutsche Oberfläche und Supporttexte,
- Pilot, messbare Abnahmekriterien und Rückfallplan.
Ein guter Anbieter erklärt außerdem, ob synchronisierte oder gerätegebundene Passkeys zum Einsatz kommen, wie Administrationskonten behandelt werden und welche Abhängigkeit vom Identitätsdienst entsteht. Für besonders schützenswerte Rollen können andere Anforderungen gelten als für normale Kundenzugänge.
Praxis-Checkliste vor dem Start
- Die Website hat tatsächlich einen wiederkehrend genutzten Login.
- Schutzbedarf und betroffene Rollen sind dokumentiert.
- Passwort-Resets, Abbrüche und Supportaufwand wurden als Ausgangswert erfasst.
- Domain, Relying Party ID und zukünftige Systemarchitektur sind geklärt.
- Eine bewährte Plattform oder WebAuthn-Bibliothek ist ausgewählt.
- Nutzer können mehrere Passkeys erkennen, hinzufügen und einzeln löschen.
- Geräteverlust, Recovery, Rollenwechsel und Austritt sind getestet.
- Alternative Verifikation und barrierefreie Fehlermeldungen sind vorhanden.
- Datenschutzhinweise, Dienstleister und Löschfristen wurden geprüft.
- Der Pilot hat klare Kennzahlen und einen Rückfallplan.
Fazit: Erst den Zugang verstehen, dann das Passwort ersetzen
Passkeys können Firmenwebsites mit Kundenkonto spürbar verbessern: weniger phishing-anfällige Zugangsdaten, weniger Eingabeschritte und weniger Passwort-Support. Der Nutzen entsteht aber nur, wenn Registrierung, Gerätewechsel, Berechtigungen und Wiederherstellung als zusammenhängender Prozess geplant werden.
Österreichische KMU sollten deshalb mit einer kleinen, messbaren Gruppe starten. Prüfen Sie zuerst, welche Portale wirklich genutzt werden, wo Passwortprobleme auftreten und welche Konten besonders schützenswert sind. Danach kann eine Agentur oder der Plattformanbieter einen freiwilligen Passkey-Pilot umsetzen. Wer Recovery und Support genauso gründlich testet wie den Login, schafft einen Zugang, der im Alltag einfacher ist, ohne Sicherheit nur zu versprechen.
Quellen und weiterführende Informationen
- W3C: Web Authentication Level 3, Candidate Recommendation 2026
- W3C: Web Authentication Level 3 – technische Spezifikation
- FIDO Alliance: Passkeys und Nutzen für Organisationen
- FIDO Alliance: State of Passkeys 2026
- Google for Developers: Passkey-Nutzerpfade und UX
- Bundeskriminalamt Österreich: Accountsicherheit und Passkeys