Passkey-Einführung in Unternehmen: Nuancen, Fallstricke, Herausforderungen

Wenn Unternehmen auf Passkeys umsteigen, entscheiden sie sich für ein kostengünstiges und robustes System zur Mitarbeiterauthentifizierung, das obendrein verspricht, die Produktivität zu steigern und Compliance-Vorschriften zu erfüllen. Sämtliche Vor- und Nachteile beim Einsatz von Passkeys im Unternehmensumfeld haben wir in diesem Artikel bereits umfänglich betrachtet. Die Durchführbarkeit (und damit letztlich auch der Erfolg) einer solchen Umstellung hängt jedoch stark von den technischen Nuancen und den unterschiedlichen Passkey-Integrationen innerhalb der zahlreichen Unternehmenssysteme ab.

Unterstützung von Passkeys in Systemen zur Identitätsverwaltung

Bevor man mit dem Planen und dem Entwerfen von Richtlinien beginnen kann, muss zunächst festgestellt werden, ob die IT-Kern-Systeme überhaupt auf den Einsatz von Passkeys vorbereitet sind.

Von Microsoft Entra ID (Azure AD) werden Passkeys beispielsweise vollständig unterstützt, sodass Administratoren diese als primäre Anmeldemethode festlegen können. Für hybride Bereitstellungen mit lokalen Ressourcen kann Entra ID auch Kerberos-Tickets (TGTs) generieren, die anschließend vom Active Directory-Domänencontroller verarbeitet werden.

In anderen Systemen des Microsoft-Ökosystems, etwa in den Bereichen RDP, VDI oder bei lokalen Active Directory-Anmeldungen, fehlt der Passkey-Support hingegen noch. Mit ein wenig Extra-Aufwand kann ein Unternehmen aber Passkeys auf Hardware-Tokens wie YubiKey speichern. Diese Art von Token unterstützt gleichzeitig sowohl die traditionelle PIV-Technologie (Smart Cards) als auch den FIDO2-Ansatz (Passkeys). Es existieren zwar auch Lösungen von Drittanbietern für diese Szenarios, es muss allerdings bewertet werden, inwieweit deren Verwendung das allgemeine Sicherheits-Stack beeinflusst und ob Auswirkung auf Compliance-Richtlinien bestehen.

Gute Nachrichten gibt es für Nutzer von Google Workspace und Google Cloud: von beiden Diensten werden Passkeys vollständig unterstützt.

Populäre Systeme zur Identitätsverwaltung wie Okta, Ping, Cisco Duo und RSA IDplus unterstützen ebenfalls FIDO2 und alle relevanten Arten von Passkeys.

Unterstützung von Passkeys auf Client-Geräten

Auch zu diesem Thema haben wir bereits einen ausführlichen Beitrag verfasst. Alle von Google, Apple und Microsoft entwickelten modernen Betriebssystemen unterstützen die Verwendung von Passkeys. Linux hingegen hinkt diesen hinterher: Hier werden Unternehmen am ehesten auf zusätzliche Tools setzen, da die native Unterstützung unter Linux im Allgemeinen eher begrenzt ist.

Und auch wenn es auf den ersten Blick so scheint, als böten alle großen Betriebssysteme (mit Ausnahme von Linux) umfassenden Support, liegen die Nuancen aber in den Details: Denn die jeweils unterschiedlichen Ansätze zum Speichern der Passkeys können später zu Schwierigkeiten bei der Kompatibilität führen. Am problematischsten wird es bei Kombinationen aus mehreren unterschiedlichen Systemen wie Windows-PCs und Android-Smartphones. Es kann vorkommen, dass ein auf einem Gerät erstellter Passkey auf einem anderen nicht verfügbar ist. Unternehmen mit streng reglementiertem Geräte-Management können solche Fallstricke auf verschiedene Arten versuchen zu umschiffen. So kann etwa vorgegeben werden, dass Mitarbeiter für jedes von ihnen genutzte Gerät einen separaten Passkey generieren müssen. Das bedeutet zwar etwas mehr Aufwand bei der Ersteinrichtung, da Mitarbeiter den Vorgang für all ihre Geräte wiederholen müssen. Einmal eingerichtet, wird man dafür anschließend mit schnellen und unkomplizierten Anmeldevorgängen belohnt. Weiterer Pluspunkt: Geht ein Gerät verloren, hat dessen Besitzer über ein anderes Gerät nach wie vor Zugriff auf seine Arbeitsdaten.

Eine andere Möglichkeit bestünde darin, einen unternehmensweit zugelassenen Passwort-Manager einzusetzen, der Passkeys speichert und zwischen den Geräten synchronisiert. Diese Variante wäre auch für Unternehmen mit Linux-Computern interessant, da deren Betriebssysteme Passkeys, wie oben bereits erwähnt, nicht nativ speichern können. Allerdings sollte man beachten, dass dieser Ansatz etwas mehr Kopfzerbrechen bereiten kann, wenn es zu Audits auf Compliance-Richtlinien kommt.

Wer nach einer Lösung sucht, bei der die plattformübergreifende Synchronisation möglichst reibungslos vonstattengeht, wird bei YubiKeys wahrscheinlich am ehesten fündig. Allerdings sind diese auch erheblich kostspieliger in der Bereitstellung und Verwaltung.

Unterstützung von Passkeys in Unternehmensanwendungen

Das ideale Szenario zum Einführen von Passkeys in Unternehmensanwendungen stellen Single Sign-On-Anmeldungen (SSO) an allen intern genutzten Anwendungen dar. Auf diese Weise ist es ausreichend, die Unterstützung der Passkeys in der vom Unternehmen eingesetzten SSO-Lösung zu konfigurieren. Wenn allerdings nicht alle kritischen Business-Anwendungen SSO unterstützen oder der SSO-Support nicht Teil des Lizenzvertrags ist (was leider durchaus vorkommt), muss für jede dieser Anwendung die Passkey-Nutzung separat konfiguriert werden. Da Hardware-Token gewöhnlich zwischen 25 und 100 Passkeys speichern können, besteht der größte Anteil an den zusätzlichen Kosten in diesem Fall eher aus der Token-Verwaltung.

Zu den häufig genutzte Business-Anwendungen mit vollständiger Passkey-Unterstützung zählen unter anderem Adobe Creative Cloud, AWS, GitHub, Google Workspace, HubSpot, Office 365, Salesforce und Zoho. Auch einige Systeme von SAP bieten Support für Passkeys.

Sensibilisierung der Mitarbeiter

Ganz unabhängig vom Szenario bedeutet die Einführung von Passkeys auch, dass das Team aus Mitarbeitern abgeholt werden muss. Die Nutzung neuer Verfahren und Anmeldemasken sollte keine Fragen aufkommen lassen. Letztendlich müssen alle Mitarbeiter sicher genug im Umgang mit Passkeys sein, um sich mit jedem ihrer Geräte anmelden zu können. Dies sind die Kerninhalte, die den Mitarbeitern vermittelt werden sollten:

• Warum Passkeys besser als Passwörter sind (gesteigerte Sicherheit, beschleunigte Anmeldung und wegfallende Rotation)
• Wie Passkeys mit Biometriedaten umgehen (biometrische Daten verlassen das Gerät nicht und werden vom Arbeitgeber weder gespeichert noch verarbeitet)
• Wie man seinen ersten Passkey erhält (z. B. verfügt Microsoft über eine TAP-Funktion [Temporary Access Path] und IAP-Systeme von Drittanbietern versenden häufig Onboarding-Links – Achtung: hier auf gute Dokumentation achten)
• Was zu tun ist, wenn das Gerät einen Passkey nicht erkennt
• Was zu tun ist, wenn ein Gerät verloren geht (mit anderem Gerät mit eigenem Passkey oder mit [im versiegelten Umschlag übergebenen] Notfall-OTP anmelden)
• Wie man sich mit anderen Geräten an Business-Anwendungen anmeldet (wenn es die Unternehmensrichtlinie erlaubt)
• Wie typische/bekannte Phishing-Versuche in Bezug auf Passkeys aussehen

Passkeys sind kein Allheilmittel

Eine Umstellung auf Passkeys bedeutet nicht, dass das IT-Sec-Team die Gefahren durch kompromittierte Anmeldedaten einfach von seiner Risiko-Liste streichen kann. Angreifern wird zwar das Handwerk erschwert, aber sie können weiterhin:

• Zielsysteme angreifen, die nicht auf Passkeys umgestellt wurden
• Systeme angreifen, die Fallback-Methoden wie Passwörter oder OTPs bereitstellen
• Authentifikator-Token von Geräten entwenden, die mit Infostealern infiziert wurden
• Spezielle Verfahren entwickeln, um den Passkey-Schutz zu umgehen

Es ist zwar unmöglich, einen Passkey an sich mittels Phishing zu stehlen, aber Angreifer könnten stattdessen eine gefälschte Web-Infrastruktur aufsetzen und das Opfer dazu bringen, sich anzumelden und eine schädliche Session in der Business-Anwendung zu validieren.

Ein solcher AiTM-Angriff wurde neulich in den USA dokumentiert. In diesem Fall wurde das Opfer zunächst auf die gefälschte Anmeldeseite einer Business-Anwendung gelockt. Dort fischten die Angreifer anschließend Nutzername und Password ab und versuchten durch das Einscannen eines QR-Codes auch an die Sitzungsbestätigung zu kommen. In diesem Vorfall wurden die Sicherheitsrichtlinien korrekt konfiguriert, sodass das Einscannen des QR-Codes nicht zur erfolgreichen Authentifizierung führte. Wenn in diesem Fall die Passkey-Konfiguration die physische Nähe zwischen dem Gerät, dass den Angriff ausführt und dem Gerät, auf dem der Schlüssel gespeichert ist, nicht abgeprüft hätte, wäre der Angriff wohl gelungen.

Die Umstellung auf Passkeys erfordert daher eine detaillierte Richtlinienkonfiguration. Das gilt sowohl für Richtlinien zur Authentifizierung (herkömmliche Passwörter deaktivieren und physische Token unbekannter Anbieter verbieten) als auch für Richtlinien zur Überwachung (Protokollieren von Passkey-Registrierungen und geräteübergreifenden Szenarien an verdächtigen Standorten).