Passkeys im Unternehmen: Entra ID, Vaultwarden und die Lücken dazwischen

/01Was ein Passkey ist und was nicht

Ein Passkey ist ein asymmetrisches Schlüsselpaar nach dem FIDO2-Standard. Der private Teil bleibt beim Nutzer, im Sicherheitschip des Telefons, im TPM des Notebooks oder auf einem Sicherheitsschlüssel. Der öffentliche Teil liegt beim Dienst. Bei der Anmeldung schickt der Dienst eine Zufallszahl, der Authenticator signiert sie nach Fingerabdruck, Gesicht oder PIN, der Dienst prüft die Signatur mit dem öffentlichen Schlüssel. Es wandert kein Geheimnis über die Leitung, das ein Angreifer abfangen und weiterverwenden könnte.

Die beiden Protokolle dahinter heißen WebAuthn und CTAP. WebAuthn ist die Schnittstelle zwischen Browser oder App und dem Dienst, CTAP die zwischen Gerät und externem Authenticator, also dem Sicherheitsschlüssel am USB-Port oder dem Telefon per Bluetooth. Zusammen heißt das FIDO2. Der Begriff „Passkey" ist jünger und bezeichnet dieselbe Technik, seit die Schlüssel auch zwischen Geräten synchronisiert werden können.

Was ein Passkey nicht ist: kein zweiter Faktor neben dem Passwort im klassischen Sinn. Er ersetzt das Passwort und den zweiten Faktor zugleich, weil Besitz des Geräts und Entsperrung durch Biometrie oder PIN zusammen bereits zwei Faktoren sind. Microsoft führt Passkeys deshalb in Entra ID als MFA-Methode und als passwortlose Methode gleichzeitig. Das Passwort soll am Ende weg, nicht ergänzt werden.

Die entscheidende Eigenschaft ist die Bindung an den Ursprung. Ein Passkey für login.microsoftonline.com antwortet nur auf eine Anfrage, die der Browser von genau dieser Domain erhält. Eine Seite unter login-microsoftonline.com-verify.example bekommt keine Signatur, selbst wenn sie das Original pixelgenau kopiert. Nicht der Nutzer entscheidet, ob die Seite echt aussieht; der Browser entscheidet anhand der Domain.

/02Warum TOTP und Push phishbar bleiben

Ein TOTP-Code aus der Authenticator-App ist sechs Ziffern, die dreißig Sekunden gelten. Das ist gegen gestohlene Passwörter wirksam, gegen Phishing in Echtzeit nicht. Der Angreifer setzt einen Reverse-Proxy zwischen Opfer und echten Dienst, reicht Nutzername, Passwort und Code sekundenschnell durch und übernimmt die Sitzung, die der echte Dienst daraufhin ausstellt. Der Code ist echt, und trotzdem hat der Angreifer das Sitzungscookie.

Push mit Nummernabgleich schließt die stumpfen Ermüdungsangriffe aus, bei denen der Nutzer irgendwann genervt auf „Genehmigen" tippt. Gegen den Proxy in der Mitte hilft er nicht: Die Zahl auf der gefälschten Seite stammt vom echten Dienst, der Nutzer tippt sie in seine App, die Sitzung gehört dem Angreifer.

Bei einem Passkey bricht diese Kette an der ersten Stelle. Der Browser des Opfers sieht die Proxy-Domain, nicht die echte, und der Authenticator findet dafür keinen passenden Schlüssel oder erzeugt eine Signatur, die der echte Dienst als fremd verwirft. In unserem Beitrag zur MFA-Einführung steht FIDO2 aus diesem Grund an der Spitze der Rangfolge; dieser Artikel erklärt, wie der Weg dorthin konkret aussieht.

/03Synchronisiert oder gerätegebunden

Microsoft unterscheidet in der Entra-Dokumentation zwei Arten. Beim gerätegebundenen Passkey wird der private Schlüssel auf einem Gerät erzeugt und verlässt es nie: Sicherheitsschlüssel nach FIDO2 und die Passkeys in Microsoft Authenticator gehören dazu. Beim synchronisierten Passkey wird der Schlüssel ebenfalls im Sicherheitschip erzeugt, dann aber verschlüsselt in die Schlüsselverwaltung des Plattformanbieters gelegt und auf alle Geräte desselben Kontos verteilt. Apple iCloud-Schlüsselbund und Google Password Manager sind die Beispiele, die Microsoft nennt; Passwortmanager von Drittanbietern arbeiten nach demselben Prinzip.

Für den Nutzer ist der synchronisierte Passkey bequemer: neues iPhone, Anmeldung bei Apple, alle Passkeys sind da. Microsoft gibt für synchronisierte Passkeys aus dem Verbraucherbereich an, dass 99 Prozent der Nutzer die Registrierung abschließen und die Anmeldung 3 statt 69 Sekunden dauert. Das sind Herstellerzahlen aus Microsoft-Konten, nicht aus Unternehmen; wir nennen sie, weil sie die Richtung zeigen, nicht als Messwert für Ihre Umgebung.

Der Preis der Bequemlichkeit heißt Attestation. Bei der Registrierung kann ein gerätegebundener Authenticator kryptografisch nachweisen, welches Modell er ist, über eine 128-Bit-Kennung namens AAGUID und den Metadatendienst der FIDO Alliance. Entra ID kann dann festlegen, dass nur bestimmte Modelle zugelassen sind. Synchronisierte Passkeys liefern diesen Nachweis nicht. Microsoft schreibt dazu wörtlich, man solle sie als phishing-resistent behandeln, aber mit derselben Sicherheitslage wie andere nicht attestierte Authenticatoren. Übersetzt: Sie wissen, dass die Anmeldung von einem Passkey kam, aber nicht, ob der Schlüssel in einem Sicherheitschip liegt oder in einer Browsererweiterung.

Unsere Einordnung: Für die Belegschaft sind synchronisierte Passkeys ein großer Schritt nach vorn. Für alle mit Zugriff auf Sicherung, Firewall oder Zahlungsverkehr gilt: gerätegebunden, Attestation erzwungen, zwei Exemplare.

/04Passkeys in Entra ID einrichten

Entra ID nimmt Passkeys in allen Editionen an, auch in der kostenlosen. Microsoft schreibt ausdrücklich, dass keine zusätzlichen Lizenzen nötig sind. Die Steuerung sitzt in der Authentifizierungsmethodenrichtlinie unter Entra ID › Security › Authentication methods › Policies › Passkey (FIDO2). Neu seit 2026 sind Passkey-Profile: Statt einer Einstellung für den ganzen Mandanten legen Sie je Gruppe fest, welche Passkey-Typen erlaubt sind, ob Attestation Pflicht ist und welche AAGUIDs zugelassen oder gesperrt werden. Wer Profile aktiviert, kann das nicht mehr rückgängig machen; die bisherigen globalen Einstellungen wandern in ein Standardprofil. Bis zu drei Profile einschließlich des Standardprofils sind derzeit möglich, die Richtlinie darf 20 KB nicht überschreiten.

Ein Aufbau, der sich für einen Betrieb mit getrennten Admin-Konten bewährt:

Drei Details aus der Dokumentation, die im Betrieb Ärger sparen. Erstens prüft Entra ID die Attestation nur bei der Registrierung; wer heute ohne Attestation registriert und morgen die Pflicht einschaltet, sperrt niemanden aus, hat aber Altbestand ohne Herkunftsnachweis. Zweitens wirken Schlüsselbeschränkungen bei Registrierung und Anmeldung; wer eine AAGUID aus der Allow-Liste entfernt, sperrt sofort alle Nutzer aus, die genau diesen Schlüssel tragen. Drittens muss der Nutzer in den fünf Minuten vor der Registrierung eine MFA abgeschlossen haben. Wer noch gar keinen zweiten Faktor hat, braucht den Temporary Access Pass aus Abschnitt 08.

Für Passkeys in Microsoft Authenticator gilt eine Versionsuntergrenze, wenn ein Profil beide Typen erlaubt: iOS 6.8.37 oder Android 6.2507.4749. Ältere Apps registrieren dann nicht. Gastkonten können keine Passkeys registrieren, und eine Änderung des UPN macht vorhandene Passkeys unbrauchbar: löschen, neu registrieren.

/05Conditional Access: phishing-resistente MFA erzwingen

Passkeys zu erlauben heißt nicht, sie zu verlangen. Solange das Passwort mit TOTP daneben weiter funktioniert, greift der Angreifer den schwächeren Weg an. Die Erzwingung läuft in Entra ID über Conditional Access und den Grant-Control Require authentication strength. Microsoft liefert drei eingebaute Stärken: MFA, passwortlose MFA und phishing-resistente MFA. Die dritte lässt genau drei Kombinationen zu: FIDO2-Sicherheitsschlüssel, Windows Hello for Business beziehungsweise Plattformanmeldedaten, und zertifikatbasierte Authentifizierung mit mehreren Faktoren. Passkeys in Authenticator und synchronisierte Passkeys zählen technisch als FIDO2 und sind darin enthalten; die klassische Telefonanmeldung per Authenticator-Push ist es nicht.

Conditional Access setzt Entra ID P1 voraus. Wer nur Business Basic oder Standard hat, kann Passkeys registrieren und nutzen, aber nicht erzwingen. Ohne Erzwingung bleibt der Passkey ein Angebot, das die Nutzer annehmen können, und der Angreifer nimmt das Passwort.

Eine Eigenheit, die Microsoft selbst als Einschränkung führt: Die Stärke wird erst nach der Erstanmeldung ausgewertet. Ein Nutzer kann also weiter sein Passwort eintippen und wird dann aufgefordert, mit dem Passkey nachzulegen. Das Passwort verschwindet damit nicht aus dem Angriffsbild, es verliert nur seinen Wert. Wer es wirklich loswerden will, geht den zweiten Schritt und schaltet die Passwortanmeldung je Nutzer ab; das ist ein eigenes Projekt und setzt voraus, dass Abschnitt 07 abgearbeitet ist.

Wir beginnen mit einer Richtlinie für die Admin-Rollen und die Verwaltungsportale im Modus „nur Bericht", danach folgen Finanzanwendungen, Fernzugänge und zuletzt die Breite. Im Berichtsmodus sehen Sie vorher, wen die Regel aussperren würde; ohne ihn erfahren Sie es am Montag um acht.

/06Passkeys im Passwortmanager: Bitwarden-Clients gegen Vaultwarden

Entra ID deckt Microsoft 365, Azure und alles ab, was per SSO über OpenID Connect oder SAML angebunden ist. Der Rest, vom Paketdienst-Portal bis zur Herstellerkonsole, hat eigene Konten und landet im Passwortmanager. Dort sind zwei Dinge auseinanderzuhalten, die im Alltag ständig verwechselt werden.

Passkeys speichern: geht

Die Bitwarden-Clients können Passkeys für fremde Websites erzeugen und ablegen. Der Passkey liegt als Teil eines Login-Eintrags im Tresor, Ende-zu-Ende verschlüsselt, und ist auf allen Geräten verfügbar, auf denen der Tresor synchronisiert ist. Unterstützt sind laut Bitwarden die Browsererweiterung sowie iOS ab 17.0 und Android ab 14.0. Weil die Verschlüsselung im Client passiert, ist dem Server egal, was in dem Eintrag steht: Vaultwarden speichert den verschlüsselten Blob wie jeden anderen. Ein Betrieb mit Vaultwarden 1.37.2, dem Stand vom 22. August 2026, kann Passkeys für Dritte also heute nutzen. Voraussetzung ist ein aktueller Server: Die Version ist laut Release-Hinweis Pflicht für Clients ab 2026.8.0, ältere Server bringen mit neuen Apps Fehler. Eine Einschränkung nennt Bitwarden für Android: Dort dürfen Drittanbieter Passkeys nur als Primäranmeldung bedienen, nicht als zweiten Faktor.

Mit Passkey in den Tresor: geht bei Vaultwarden noch nicht

Der zweite Fall ist die Anmeldung am Passwortmanager selbst. Bitwarden bietet in seiner Cloud „Log in with passkeys" an: Der Passkey ersetzt das Master-Passwort, und wenn Browser und Authenticator die WebAuthn-Erweiterung PRF unterstützen, leitet der Client daraus auch den Schlüssel ab, der den Tresor entschlüsselt. Bis zu fünf Passkeys je Konto sind möglich, die Unterstützung liegt derzeit bei Chromium-basierten Browsern und der Web-App. Vaultwarden hat diese Funktion nicht. Das Wiki führt „Login with Passkeys" unter den fehlenden Funktionen und verweist auf den Pull Request #5929, der am 8. September 2026 offen und nicht zusammengeführt ist.

Was Vaultwarden für die eigene Anmeldung kann: WebAuthn als zweiten Faktor neben dem Master-Passwort, mit Sicherheitsschlüssel oder Plattform-Authenticator. Dafür muss der Server unter HTTPS mit gültigem Zertifikat laufen und die Variable DOMAIN auf genau diese Adresse zeigen, sonst bricht die Registrierung ab. Das Master-Passwort bleibt damit das eine Passwort, das jeder Nutzer noch kennt, und es sollte lang sein; unser Beitrag zum Passwort-Management beschreibt die Richtlinie dazu.

Für Skripte gibt es die Bitwarden-CLI, die auch gegen Vaultwarden arbeitet; die Anmeldung läuft dort über eine Umgebungsvariable:

# Eigene Instanz statt bitwarden.com hinterlegen
bw config server https://vault.example.de

# Anmeldung ohne Passwortabfrage: Master-Passwort aus BW_PASSWORD lesen
export BW_PASSWORD='…'
bw login benutzer@example.de --passwordenv BW_PASSWORD

# Sitzung entsperren und Schlüssel für Folgebefehle setzen
export BW_SESSION="$(bw unlock --passwordenv BW_PASSWORD --raw)"

# Stand prüfen: serverUrl, Status, letzte Synchronisation
bw status
bw sync

Der Weg über die Umgebungsvariable ist für Wartungsskripte gedacht, mit eigenem Dienstkonto und minimaler Sammlung, nicht für Menschen.

/07Wo Passkeys 2026 nicht greifen

Ehrlich: Der Passkey löst das Anmeldeproblem im Browser und in modernen Apps. Ein Mittelstandsbetrieb hat aber Anmeldungen, die weder das eine noch das andere sind. Fünf Stellen, an denen Projekte hängen bleiben.

• Legacy-Anwendungen mit eigener Anmeldemaske. Die Warenwirtschaft von 2014 fragt Nutzername und Passwort in einem Windows-Dialog ab und kennt weder WebAuthn noch SSO. Der Passkey hilft hier nur indirekt: Das Passwort im Vaultwarden ablegen, lang und einmalig, und die Anwendung mittelfristig hinter einen Identity Provider bringen, etwa über Keycloak oder Entra-App-Proxy.
• RDP und VPN-Clients. Die Anmeldung am Terminalserver oder am VPN-Client läuft über Windows-Anmeldedaten oder RADIUS. FIDO2 am Windows-Anmeldebildschirm funktioniert gegen Active Directory über Entra ID nur mit Kerberos- Vertrauensstellung und passender Domänencontroller-Ausstattung, und die Weitergabe des Passkeys durch eine RDP-Sitzung ist ein eigenes Kapitel. Die Microsoft-Dokumentation nennt zudem, dass ein Temporary Access Pass mit der NPS-Erweiterung und dem AD-FS-Adapter nicht funktioniert; RADIUS-basierte Zugänge bleiben also bei TOTP oder Push. Wer Fernzugang ohne Passwort will, kommt um ZTNA statt klassischem VPN kaum herum.
• Gemeinsam genutzte Konten. Das Empfangs-Postfach, das Social-Media-Konto, die Herstellerkonsole mit einem Login für drei Techniker. Ein Passkey gehört zu einem Menschen und einem Gerät; ein Sammelkonto passt nicht in dieses Modell. Der Weg ist entweder Einzelkonten mit Delegation oder das geteilte Passwort samt TOTP-Seed im Vaultwarden, bis der Dienst Einzelkonten erlaubt.
• Geräteverlust und Wiederherstellung. Beim synchronisierten Passkey ist das Apple- oder Google-Konto der neue Angriffspunkt, und dessen Wiederherstellung hat Ihr Betrieb nicht in der Hand. Beim gerätegebundenen Passkey ist der Schlüssel weg, wenn das Gerät weg ist. Ohne zweiten registrierten Passkey landet der Nutzer beim Helpdesk, und der Helpdesk braucht ein Verfahren, um die Person zu identifizieren, das selbst nicht phishbar ist. Rückruf auf die hinterlegte Nummer, Vorgesetzter bestätigt, dann Temporary Access Pass mit kurzer Laufzeit.
• Dienst- und Automationskonten. Ein Skript kann keinen Fingerabdruck geben. Dienstkonten bleiben bei Zertifikaten, verwalteten Identitäten oder Geheimnissen mit kurzer Laufzeit.

Keine dieser Lücken spricht gegen den Rollout. Sie verlangen vorher eine Liste, welche Anmeldung wohin führt, mit einer Entscheidung je Zeile: Passkey, SSO davor, Passwortmanager oder bewusst offen mit Datum.

/08Rollout-Reihenfolge: Admins, Notfallkonten, Temporary Access Pass

Die Reihenfolge ist keine Formsache: Wer die Admins zum Schluss macht, hat monatelang die wertvollsten Konten am schwächsten geschützt.

1. Notfallkonten zuerst absichern, nicht umstellen. Zwei Break-Glass-Konten mit Globaladministrator-Rolle, ohne Bindung an eine Person, je mit einem eigenen FIDO2-Sicherheitsschlüssel im Tresor an zwei Standorten, von allen Conditional-Access-Regeln ausgenommen und mit Alarm bei jeder Anmeldung. Diese Konten sind der Weg zurück, wenn eine Regel danebengeht. Bei uns liegen die Schlüssel in Lichtenfels und im Rechenzentrum Coburg, getrennt und protokolliert.
2. Administratoren mit gerätegebundenen Passkeys. Jeder Admin bekommt zwei Sicherheitsschlüssel oder einen Schlüssel plus Authenticator-Passkey, registriert beide, das Profil „Privilegiert" mit Attestation greift. Danach die Conditional-Access-Regel für die Verwaltungsportale.
3. Pilotgruppe aus der Belegschaft. Zehn bis zwanzig Personen aus verschiedenen Abteilungen, synchronisierte Passkeys erlaubt. Hier zeigt sich, welche Anwendungen aus Abschnitt 07 wirklich im Weg stehen.
4. Onboarding über den Temporary Access Pass. Der TAP ist ein zeitlich begrenzter Einmalcode, mit dem ein Nutzer ohne Passwort seine erste Methode registriert. Standardlaufzeit ist eine Stunde, das voreingestellte Maximum acht Stunden; die Richtlinie erlaubt Werte zwischen 10 Minuten und 43.200 Minuten, also 30 Tagen, und eine Länge von 8 bis 48 Zeichen. Bei einem Einmal-TAP muss die Registrierung binnen zehn Minuten nach der Anmeldung abgeschlossen sein. Je Nutzer existiert nur ein TAP; ein neuer überschreibt den alten. Der TAP ersetzt damit das Startpasswort auf dem Zettel.
5. Breite, dann Abbau. Nach der Belegschaft die schwächeren Methoden aus der Richtlinie nehmen: erst SMS, dann TOTP für alle, die einen Passkey registriert haben. Was übrig bleibt, steht auf der Liste aus Abschnitt 07 mit Datum.

Ein Hinweis zum TAP: Sitzungen aus einer TAP-Anmeldung laufen nicht automatisch mit dem TAP ab; Microsoft verweist dafür auf die Anmeldehäufigkeit in Conditional Access. Für den Fall „Gerät verloren" setzen Sie beides kurz.

/09Vier Verfahren im Vergleich

Kosten geben wir als Richtung an; Sicherheitsschlüssel haben je nach Modell und Menge sehr unterschiedliche Preise, und wir haben die Preisseiten für diesen Artikel nicht geprüft.

Auffällig ist die Spalte Geräteverlust. Der beste Passkey nützt nichts, wenn der Wiederherstellungsweg ein Anruf beim Helpdesk mit Geburtsdatum ist; er gehört in dieselbe Sicherheitsklasse wie die Anmeldung, die er ersetzt.

/10Wann Passkeys noch die falsche Wahl sind

Wenn mehr als die Hälfte der Anmeldungen über RDP, VPN oder Legacy-Masken läuft. Dann schützt der Passkey den kleineren Teil, und die Belegschaft lernt zwei Verfahren nebeneinander. Erst SSO und Zero-Trust-Zugang vor die Altanwendungen, dann Passkeys. Andersherum bleibt es Stückwerk.

Wenn keine Lizenz für Conditional Access da ist und auch nicht kommen soll. Ohne Erzwingung bleiben Passwort und TOTP als Weg für den Angreifer offen. Dann lieber TOTP mit Nummernabgleich sauber für alle und Sicherheitsschlüssel nur für die Admin-Konten, was auch ohne P1 geht, weil die Methode selbst keine Lizenz braucht.

Wenn der Betrieb keine Zweitgeräte finanzieren will. Ein gerätegebundener Passkey ohne Zweitexemplar ist ein Helpdesk-Ticket mit Ansage. Ohne zweite Registrierung gibt es TAPs im Wochenrhythmus, und ein TAP-Prozess unter Zeitdruck ist der Ort, an dem Social Engineering wieder funktioniert.

Wenn die Vaultwarden-Anmeldung das Ziel ist. Wer Passkeys einführen will, damit die Mitarbeiter ihren Passwortmanager ohne Master-Passwort öffnen, wartet auf den Pull Request #5929 oder nimmt den Bitwarden-Cloud-Dienst mit den Folgen für Datenhaltung und Preis. Für den Tresor selbst bleibt bei Vaultwarden 2026 das lange Master-Passwort plus WebAuthn als zweiter Faktor der Stand der Technik.

In allen anderen Fällen ist die Empfehlung eindeutig: Admin-Konten diesen Monat auf gerätegebundene Passkeys mit Attestation, Belegschaft in den nächsten zwei Quartalen auf synchronisierte Passkeys, TOTP als Übergang für die Liste aus Abschnitt 07. Die Ausnahmen zu kennen ist der Unterschied zwischen einem Rollout und einem Rückbau.

/11Häufige Fragen