Herausforderungen und Lösungen bei der Einführung von Enterprise-Passkeys

1. Einleitung: Die operative Realität von Enterprise-Passkeys für Mitarbeiter#

Passkeys sind in der Arbeitswelt angekommen. Die Frage lautet nicht mehr: "Funktioniert die Technologie?". Die Frage ist nun: "Wie betreiben wir das in großem Maßstab?". Die Reibungspunkte haben sich auf die operative Ebene verlagert: das "Henne-Ei-Problem" der anfänglichen Registrierung (Bootstrapping), der Unterschied zwischen gerätegebundenen und synchronisierten Passkeys, die plattformübergreifende Interoperabilität und Wiederherstellungsmechanismen, die nicht auf die Unsicherheit eines Passworts zurückfallen.

Dieser Leitfaden befasst sich mit den realen Herausforderungen bei der Einführung von Passkeys in Microsoft Entra ID-Umgebungen und behandelt Konfigurationsfallen, operative Workflows und Wiederherstellungsstrategien. Konkret werden wir die folgenden Fragen beantworten:

1. Was ist der Unterschied zwischen gerätegebundenen und synchronisierten Passkeys in Entra ID?
2. Wie richte ich Passkeys für neue Mitarbeiter ohne Passwörter ein (Bootstrapping)?
3. Wie können Benutzer den Zugriff wiederherstellen, wenn sie ein neues Smartphone bekommen und den Zugang zu ihrem Authentikator verlieren?
4. Welche Konfigurationsfehler führen zu Fehlern bei der Passkey-Registrierung?
5. Wie gehe ich mit B2B-Gästen um, wenn ich phishing-resistente MFA verlange?
6. Sollte ich Hardware-Sicherheitsschlüssel (YubiKeys) oder mobile Passkeys verwenden?
7. Wie gehe ich mit macOS-Geräten neben Windows in einer Passkey-Einführung um?
8. Welche proaktiven Maßnahmen verhindern eine Überlastung des Helpdesks durch den Austausch von Smartphones?

2. Passkeys in Microsoft Entra verstehen#

In Entra bedeuten "Passkeys" = FIDO2/WebAuthn-Anmeldeinformationen. Anstelle eines Passworts weist der Benutzer den Besitz eines privaten Schlüssels nach, der in einem Authentikator gespeichert ist. Dies ist phishing-resistent, da WebAuthn die Anmeldeinformationen an den tatsächlichen Anmeldeursprung bindet (sodass eine Phishing-Seite, die dem Original ähnelt, sie nicht wiederholen kann). Siehe die Übersicht von Microsoft in der Dokumentation zu Passkey- (FIDO2) Konzepten.

Entra unterstützt effektiv zwei "Modi" von Passkeys, die sich unterschiedlich verhalten.

2.1 Gerätegebundene Passkeys in Entra#

Diese Passkeys sind an ein physisches Gerät gebunden (nicht synchronisierbar). Der private Schlüssel befindet sich auf einem spezifischen Hardware-Element (TPM auf einem Laptop, Secure Element auf einem YubiKey). Er ist nicht exportierbar.

In Entra übersetzt sich das Konzept der gerätegebundenen Passkeys üblicherweise in:

• Microsoft Authenticator-Passkeys
• Windows Hello oder Windows Hello for Business (WHfB) Passkeys (nicht synchronisiert ab Januar 2026)
• FIDO2-Sicherheitsschlüssel (Hardware-Schlüssel wie YubiKeys)
• Smartcards

Der Leitfaden von Microsoft für die Basiskonfiguration von gerätegebundenen Passkeys findet sich hier: https://learn.microsoft.com/en-us/entra/identity/authentication/how-to-enable-passkey-fido2

Anwendungsfälle: Hochprivilegierter Zugriff, "Break-Glass"-Konten, Umgebungen mit gemeinsam genutzten Arbeitsstationen. Nachteil: Hohe Reibung. Der Verlust des Geräts bedeutet den Verlust der Anmeldeinformationen. Hoher operativer Aufwand (z. B. Versand von YubiKeys).

2.2 Synchronisierte Passkeys in Entra#

Hierbei handelt es sich um Passkeys, die im Ökosystem eines Anbieters gespeichert und über die Geräte des Benutzers hinweg synchronisiert werden (z. B. iCloud-Schlüsselbund, Google Passwortmanager oder Drittanbieter). Der private Schlüssel wird verschlüsselt in der Sync-Struktur eines Cloud-Anbieters gespeichert.

Ab Januar 2026 werden synchronisierte Passkeys in Entra über das Vorschau-Feature gehandhabt: Synchronisierte Passkeys (Vorschau). Um synchronisierte Passkeys zu aktivieren und zu steuern, verwendet Entra Passkey-Profile (Vorschau).

Regulatorische Eignung: Kürzlich durch das NIST SP 800-63B Supplement 1 als die AAL2-Anforderungen erfüllend validiert. Dies ist ein massiver regulatorischer Erfolg, der bestätigt, dass synchronisierte Passkeys "phishing-resistent" genug für den allgemeinen Einsatz in der Belegschaft sind.

Anwendungsfälle: Wissensarbeiter, BYOD-Nutzer, Komfort für Führungskräfte. Nachteil: "Geringeres" Assurance-Level als Hardware. Abhängigkeit von der Sicherheit des Kontowiederherstellungs-Flows des Cloud-Anbieters.

Hier finden Sie eine Übersicht der von Entra unterstützten Anbieter von synchronisierten Passkeys:

Auf der Seite mit den Sicherheitsinformationen eines Benutzers werden synchronisierte und gerätegebundene Passkeys klar voneinander unterschieden. Unten sehen Sie, wie ein synchronisierter Passkey (von 1Password) und ein gerätegebundener Passkey (YubiKey 5C NFC) erscheinen:

2.3 Regulatorische Ausrichtung: NIST AAL-Stufen#

• AAL3 erforderte historisch gesehen hardwarebasierte, gerätegebundene Authentikatoren (wie YubiKeys oder Smartcards), die einen nicht exportierbaren privaten Schlüssel verwenden.
• AAL2 kann laut NIST-Richtlinien nun mit synchronisierten Passkeys erreicht werden.
• Nuance: Während synchronisierte Passkeys (wie die in iCloud) für Standardbenutzer hervorragend geeignet sind, erfüllen sie möglicherweise nicht strikt die AAL3-Anforderung an die "Nicht-Exportierbarkeit" für die höchsten Privilegienstufen. Daher ist eine segmentierte Strategie erforderlich: Hardware-Schlüssel für Admins (AAL3), synchronisierte Passkeys für die Belegschaft (AAL2).

2.4 Anforderungen an die Gerätebereitschaft#

Um sicherzustellen, dass die Geräte für eine phishing-resistente passwortlose Authentifizierung bereit sind, müssen sie über diese Mindestversionen verfügen:

Ältere Betriebssysteme erfordern möglicherweise externe Authentikatoren (FIDO2-Sicherheitsschlüssel), um die phishing-resistente passwortlose Authentifizierung zu unterstützen.

Über die Mindestversionsanforderungen hinaus variiert auch die Unterstützung browserseitiger Funktionen je nach Plattform. Gemäß der Corbado Passkey Benchmark 2026 WebAuthn-Client-Funktionsanalyse liegt die Browserunterstützung im ersten Quartal 2026 bei 97–100 % für Conditional Get und Hybrid Transport, aber nur bei 83–92 % für Conditional Create in einem typischen Consumer-Browser-Mix – eine Einschränkung, die sich am stärksten auf Windows auswirkt, da Windows Hello kein Conditional Create-Pfad ist und Edge in demselben Datensatz eine besonders geringe Conditional Create-Unterstützung meldet. Die Benchmark-Studie deckt B2C-Implementierungen für Endverbraucher ab, nicht jedoch Unternehmensumgebungen. Die gleichen Einschränkungen hinsichtlich der zugrunde liegenden Browser-/OS-Funktionen gelten jedoch auch für Entra ID-Rollouts; stark von Unternehmen genutzte Edge-Populationen können deutlich unter dem gemischten Conditional Create-Bereich von 83–92 % liegen.

2.5 Empfehlungen für Anmeldeinformationen nach Benutzer-Persona#

Microsoft empfiehlt einen Ansatz, der auf Benutzer-Personas basiert, wenn es um die Bereitstellung von Anmeldeinformationen geht. Unterschiedliche Rollen haben unterschiedliche Sicherheitsanforderungen und akzeptable Reibungsniveaus:

Portable Anmeldeinformationen (geräteübergreifend nutzbar):

Lokale Anmeldeinformationen (gerätespezifisch):

Das Endziel: Die meisten Benutzer sollten mindestens eine portable Anmeldeinformation sowie lokale Anmeldeinformationen auf jedem Rechengerät haben.

3. Erfahrungen aus Live-Passkey-Einführungen#

In Gesprächen mit Unternehmen, die Passkeys eingeführt haben, lassen sich einige reale Reibungspunkte und Muster erkennen.

3.1 Operative Verlagerung#

"Die Herausforderungen liegen nicht im Technologie-Stack, sondern auf der operativen Ebene." Dies bestätigt, dass technische Hürden wie "Passkey nicht registriert"-Fehler oder die Unsichtbarkeit von Windows Hello-Optionen auf persönlichen Geräten keine einzigartigen Anomalien sind, sondern systemische Reibungspunkte, die mit der aktuellen Reife des Ökosystems einhergehen. Für den Unternehmensbetrieb ist es entscheidend, erwartete und unerwartete Fehler bei der Überwachung zu trennen. Gruppieren Sie WebAuthn-Fehler explizit und verfolgen Sie NotAllowedError, AbortError und Passkey-Fehler des Credential Managers als getrennte Signale. Unser Playbook für Authentifizierungsanalysen bietet einen Rahmen zur Klassifizierung dieser Signale, und Passkey-Analysen decken passkeyspezifische KPIs wie Aktivierungs- und Anmelderaten ab.

3.2 Registrierung: Der "Alles-oder-Nichts"-Moment#

Die Registrierung (Enrollment) ist die bei weitem schwierigste Phase der Einführung und erfordert ein erhebliches Change-Management.

• Komplexität vor der Registrierung: Das Onboarding neuer Mitarbeiter, die keine vorherigen Anmeldeinformationen haben, ist der primäre Flaschenhals. Die Abhängigkeit von einer durch Admins vermittelten Registrierung führt zu einer unzusammenhängenden Benutzererfahrung.
• Plattform-Fragmentierung: "Frustration der Benutzer mit den Schritten" aufgrund unabhängiger Iterationen von Browsern, Betriebssystemen und Passwortmanagern. Dies führt zu temporären Inkonsistenzen, bei denen ein Flow unter Chrome/Windows funktioniert, unter Safari/macOS jedoch fehlschlägt, oder auf nicht verwalteten persönlichen Geräten fehlschlägt, während er auf Unternehmensgeräten erfolgreich ist.

3.3 Die mentale Modell-Lücke#

"Benutzer brauchen keine Kryptographie, sie brauchen ein mentales Modell." Die terminologische Verwirrung erzeugt kognitive Belastung:

• Passkey
• Security Key (Sicherheitsschlüssel)
• Hardware Key (Hardware-Schlüssel)
• YubiKey
• passwortlos
• Windows Security (Windows-Sicherheit)
• Windows Hello
• Windows Hello for Business (WHfB)
• Microsoft Authenticator
• Telefon-Anmeldung

Für technisch nicht versierte oder sogar technisch versierte Benutzer sind die Unterschiede zwischen diesen Begriffen oft nicht offensichtlich.

Wir empfehlen, Fachjargon wie "phishing-resistent" oder "Schlüsselpaar" in der Kommunikation mit den Endbenutzern zu vermeiden. Konzentrieren Sie sich stattdessen auf das Konzept des "Entsperrens": "Nutzen Sie Ihr Gesicht, um die Systeme des Unternehmens zu entsperren", analog zum Entsperren ihres Smartphones.

3.4 Einschränkungen in der Kommunikation#

Eine starke Akzeptanz zu Beginn ist entscheidend für den Erfolg, aber Kommunikation allein reicht nicht aus. Sie können nicht regelmäßig E-Mails versenden, in denen Sie die Benutzer auffordern, ihre Authentifizierungsmethoden zu überprüfen. Generell kann man das Benutzerverhalten nicht gut planen. Diese Realität erzwingt die Notwendigkeit proaktiver technischer Maßnahmen, anstatt sich ausschließlich auf die Schulung der Benutzer zu verlassen.

4. Microsoft Entra ID Konfigurations-Deep-Dive#

Die Implementierung von Passkeys in einer Unternehmensumgebung erfordert das Verständnis und die Einrichtung voneinander abhängiger Richtlinien. Passkeys sind nicht einfach ein Feature, das man einfach einschalten kann, da sie massive Auswirkungen auf jeden Mitarbeiter in seiner täglichen Arbeit haben.

4.1 Richtlinie für Authentifizierungsmethoden#

Die alten MFA- und SSPR-Portale sind veraltet. Die gesamte FIDO2-Konfiguration muss in dem zentralen Blade für Richtlinien für Authentifizierungsmethoden erfolgen.

• FIDO2-Sicherheitsschlüssel-Methode: Diese muss aktiviert und zugewiesen werden. Wir empfehlen, die Aktivierung auf "Alle Benutzer" (All Users) anzuwenden, aber die Durchsetzung über Conditional Access (Bedingter Zugriff) zu steuern.
• Schlüsseleinschränkungen (AAGUIDs): Jedes FIDO2-Gerät (z. B. YubiKey 5 NFC, Microsoft Authenticator auf iOS, Google Passwortmanager) verfügt über eine eindeutige Authenticator Attestation GUID (AAGUID). Als Best Practice für Hochsicherheitsumgebungen sollten Sie die Einstellung "Schlüsseleinschränkungen erzwingen" nutzen, um nur spezifische, genehmigte AAGUIDs zuzulassen. Dadurch wird verhindert, dass Benutzer billige, ungeprüfte "Graumarkt"-Sicherheitsschlüssel registrieren.

4.2 Attestation: Der kritische Entscheidungspunkt#

Eine der wichtigsten Konfigurationsentscheidungen ist "Attestation erzwingen" (Enforce Attestation).

• Was sie tut: Zwingt den Authentikator, bei der Registrierung in Entra ID kryptographisch nachzuweisen, von welchem Hersteller und Modell er ist.
• Konflikt: Synchronisierte Passkeys (die in Software-Anbietern wie iCloud-Schlüsselbund, Bitwarden oder Google Passwortmanager gespeichert sind) unterstützen generell keine Attestation, da sie softwarebasiert und plattformunabhängig sind. Sie können keine Challenge (Herausforderung) mit einem Hardware-Batch-Zertifikat signieren.
• Kompromiss:
  • Auf JA gesetzt: Erforderlich für hohe Sicherheit (AAL3). Stellt sicher, dass der Schlüssel hardwaregebunden ist. Blockiert softwarebasierte Passkey-Anbieter.
  • Auf NEIN gesetzt: Erlaubt synchronisierte Passkeys. Senkt das Assurance-Level leicht (AAL2). Aktiviert softwarebasierte Passkey-Anbieter.

Sie können keine globale "Keine Attestation"-Richtlinie anwenden, wenn Sie hochprivilegierte Administratoren haben, die Hardware-Schlüssel benötigen. Sie müssen Passkey-Profile (Vorschau) verwenden:

• Profil A (Admins): Attestation erzwingen = Ja
• Profil B (Allgemeine Belegschaft): Attestation erzwingen = Nein

4.3 Passkey-Profile erklärt#

Stellen Sie sich Passkey-Profile als den Mechanismus vor, um Folgendes zu definieren:

• "Diese Benutzer dürfen synchronisierte Passkeys verwenden"
• "Diese Benutzer müssen nur gerätegebundene verwenden"
• "Attestation erforderlich vs. nicht erforderlich" (und somit: synchronisierte Passkeys erlaubt vs. ausgeschlossen)
• "Auf bestimmte Authentikatortypen beschränken (AAGUID-Einschränkungen)"

Unten sehen Sie die Einstellungsseite für Passkeys (FIDO2) im Microsoft Entra Admin Center, wo Sie Passkey-Profile konfigurieren:

Beim Bearbeiten eines Passkey-Profils können Sie die Durchsetzung der Attestation, Zieltypen (gerätegebunden, synchronisiert oder beides) sowie spezifische AAGUID-Beschränkungen konfigurieren:

4.4 Conditional Access & Authentifizierungsstärken#

Die Durchsetzung kann über Conditional Access (CA)-Richtlinien (Bedingter Zugriff) gesteuert werden, die Authentifizierungsstärken (Authentication Strengths) nutzen.

• Phishing-resistente MFA-Stärke: Diese integrierte Stärke erfordert FIDO2, Windows Hello for Business (WHfB) oder zertifikatsbasierte Authentifizierung (CBA).
• Aussperrungs-Falle (Lockout Trap): Wenn Sie eine CA-Richtlinie erstellen, die "Phishing-resistente MFA" für "Alle Cloud-Apps" vorschreibt und diese auf "Alle Benutzer" anwenden, sperren Sie sofort alle Benutzer aus, die noch keinen Passkey registriert haben. Sie können sich nicht einmal anmelden, um einen zu registrieren.
• "Register Security Info"-Paradoxon: Dies ist eine spezifische Benutzeraktion (User Action) in CA. Wenn Sie phishing-resistente MFA verlangen, um die Aktion Sicherheitsinformationen registrieren (Register Security Information) durchzuführen, schaffen Sie eine zirkuläre Abhängigkeit (Henne-Ei-Problem). Ein Benutzer kann seinen ersten Passkey nicht registrieren, weil er einen Passkey benötigt, um auf die Registrierungsseite zuzugreifen.

Hier ist eine Übersicht darüber, welche Authentifizierungsmethoden welche Stärkeanforderungen erfüllen:

4.5 Systembevorzugte Authentifizierung#

Die Funktion "Vom System bevorzugte Multifaktor-Authentifizierung" in Entra ID zwingt die Anmelde-Engine, den Benutzer nach der sichersten registrierten Methode zu fragen.

Wenn ein Benutzer sowohl SMS als auch einen Passkey registriert hat, wählt das System standardmäßig den Passkey. Dies treibt die Passkey-Einführung organisch voran, ohne harte Durchsetzung. Es führt praktisch automatisch ein "Upgrade" des Sicherheitsstatus des Benutzers durch, sobald dieser die Anmeldeinformation registriert.

Unten sehen Sie die Passkey-Anmeldeerfahrung. Der Benutzer wird aufgefordert, "Gesicht, Fingerabdruck, PIN oder Sicherheitsschlüssel" zu verwenden und kann seinen Passkey aus einer Browser-Erweiterung oder dem System-Passwortmanager auswählen:

4.6 Besonderheiten bei macOS: Platform SSO#

Für Organisationen mit gemischten Windows-/macOS-Umgebungen bietet macOS Platform SSO das Apple-Äquivalent zu Windows Hello for Business. In Kombination mit MDM-Lösungen können Sie Folgendes erreichen:

• Gerätegebundene Anmeldeinformationen, die an die Secure Enclave des Macs gebunden sind
• SSO-Erfahrung über native Apps und Web-Apps hinweg
• Phishing-resistente Authentifizierung, die AAL2/AAL3-Anforderungen erfüllt

Hinweis: macOS Platform SSO erfordert macOS 13+ und eine korrekte MDM-Konfiguration. Die Einrichtung unterscheidet sich erheblich von Windows WHfB, planen Sie also separate Einführungs-Tracks ein.

5. Häufige Fehlkonfigurationen: Warum "es nur mit Microsoft Authenticator funktioniert"#

Wenn Ihr Ziel synchronisierte Passkeys auf nicht verwalteten Geräten ist, sind dies die häufigsten Blocker:

5.1 Synchronisierte Passkeys nicht aktiviert/zugewiesen#

Es reicht nicht aus, "FIDO2" in Entra nur generell zu aktivieren. Für synchronisierte Passkeys benötigen Sie in der Regel:

• Den Vorschau-Feature-Pfad, wie in Synchronisierte Passkeys (Vorschau) beschrieben
• Eine Profilkonfiguration unter Verwendung von Passkey-Profilen

Wenn eine Gruppe nicht durch ein Profil adressiert wird, das synchronisierte Passkeys erlaubt, werden Sie zurück in die Welt der "nur gerätegebundenen" Passkeys gezogen.

5.2 Attestation erzwungen (blockiert synchronisierte Passkeys)#

Dies verursacht in sicherheitsbewussten Organisationen die meisten Fragen:

• Entra kann für bestimmte Passkey-Szenarien Attestation vorschreiben (hilft bei der Validierung des Authentikatortyps/-ursprungs)
• Synchronisierte Passkeys unterstützen in Entra keine Attestation, wenn Attestation also erzwungen wird, schlägt die Registrierung synchronisierter Passkeys fehl und Sie haben am Ende nur gerätegebundene Optionen

5.3 AAGUID-Allow-Listing blockiert Anbieter#

Entra ermöglicht es Ihnen einzuschränken, welche Authentikatoren zulässig sind (oft über AAGUID-Allow/Block-Listen). Wenn Sie nur den Microsoft Authenticator (oder eine enge Auswahl an Authentikatoren) zulassen (Allow-List), können synchronisierte Anbieter von Drittanbietern implizit blockiert werden. Das Verwirrende daran ist, dass die lokale Authentifizierung (z. B. Touch ID, Face ID, Windows-Biometrie-Scan) funktioniert, die Entra-Anmeldeseite dann aber einen Fehler anzeigt.

5.4 Conditional Access erzwingt bestimmte Passkey-Typen#

Auch wenn Passkeys aktiviert sind, kann Conditional Access Benutzer effektiv zu einer Teilmenge von Methoden zwingen (z. B. "nur Authenticator" oder eine Stärkenkonfiguration, die das beabsichtigte Passkey-Profil nicht zulässt). In der Praxis führt dies zur "Authenticator-Abhängigkeit", selbst wenn synchronisierte Passkeys geplant sind.

5.5 B2B-Gäste vs. Mitgliederkonten#

Wenn externe Partner B2B-Gastbenutzer in einem Ressourcen-Tenant sind, gibt es bekannte Einschränkungen bezüglich des Ortes/der Art und Weise, wie sie Authentifizierungsmethoden registrieren können. Dies ist häufig das versteckte "Warum funktioniert es nicht", wenn die Absicht lautet: "Partner verwenden Passkeys in unserem Tenant".

6. Operative Herausforderungen & Lösungen#

6.1 Bootstrapping-Paradoxon#

Das am weitesten verbreitete Problem ("Die Registrierung ist der schwierigste Teil") ist das Bootstrapping-Problem: Wie geben Sie sicher hochgradige Anmeldeinformationen an einen Benutzer aus, der derzeit keine Anmeldeinformationen (oder nur solche mit geringer Sicherheit) hat?

6.1.1 Temporary Access Pass (TAP)#

Der Temporary Access Pass (TAP) ist ein architektonischer Ansatz für passwortloses Onboarding.

• Was es ist: Ein zeitlich begrenzter (z. B. 1 Stunde), hoch-entropischer Passcode, den Entra ID als Methode der "starken Authentifizierung" (Strong Authentication) behandelt. Er umgeht die Notwendigkeit eines Passworts oder einer bestehenden MFA.
• Workflow:
  1. Identitätsprüfung: Die Identität des neuen Mitarbeiters wird verifiziert (z. B. über den HR-Prozess oder eine Bestätigung des Managers).
  2. Ausstellung: Ein Admin (oder eine automatisierte Logic App) generiert einen TAP für den Benutzer.
  3. "Magischer" Login: Der Benutzer navigiert zu aka.ms/mysecurityinfo. Er gibt seinen Benutzernamen und den TAP ein.
  4. Registrierung: Da der TAP die Anforderung "Starke Auth" erfüllt, darf der Benutzer auf das Blade für Sicherheitsinformationen zugreifen. Er klickt auf "Methode hinzufügen" (Add Method) und registriert seinen Passkey.
  5. Endzustand: Der TAP läuft ab. Der Benutzer verfügt nun über eine phishing-resistente Anmeldeinformation. Er hat nie ein Passwort eingegeben.

6.1.2 Automatisierung via Graph API#

Für große Organisationen ist die manuelle TAP-Ausstellung nicht skalierbar. Die Best Practice besteht darin, dies über die Microsoft Graph API zu automatisieren.

• Szenario: Ein neuer Mitarbeiter wird im HR-System (Workday/SuccessFactors) verarbeitet.
• Auslöser: Das Bereitstellungsereignis löst eine Azure Logic App aus.
• Aktion: Die Logic App ruft den Graph API POST /users/{id}/authentication/temporaryAccessPassMethods auf.
• Zustellung: Der TAP wird dem einstellenden Manager oder an die persönliche E-Mail des Benutzers (verschlüsselt) für den Zugriff am ersten Arbeitstag sicher zugestellt.

6.1.3 Microsoft Entra Verified ID für hochsicheres Onboarding#

Für Remote-Onboarding oder Szenarien, die eine hohe Identitätssicherheit (Identity Assurance) erfordern, bietet Microsofts Entra Verified ID mit Face Check einen primär passwortlosen Registrierungspfad:

1. Identitätsprüfung (Identity Proofing): Neuer Benutzer verifiziert seine Identität über einen IDV-Partner (Scan eines staatlichen Ausweises).
2. Biometrischer Abgleich: Face Check vergleicht ein Live-Selfie mithilfe von Azure AI Vision mit dem Foto im Ausweisdokument. Es wird nur ein Übereinstimmungs-Konfidenz-Wert (Confidence Score) geteilt (keine rohen biometrischen Daten).
3. Verified Credential ausgestellt: Der Benutzer erhält einen Verified ID-Nachweis.
4. TAP-Ausstellung: Nach erfolgreicher Verifizierung stellt das System einen Temporary Access Pass aus.
5. Passkey-Bootstrap: Der Benutzer registriert seinen ersten Passkey mithilfe des TAP.

Der Face Check-Flow führt Benutzer durch drei Schritte: Verify (Anmeldeinformationen teilen), Confirm (Gesichtsscan durchführen) und Review (Übereinstimmungsergebnis anzeigen):

Dieser Flow ermöglicht wirklich passwortlose Konten ab dem ersten Tag. Es wird niemals ein Passwort erstellt.

6.2 Das Smartphone-Austausch-Problem (die versteckte Skalierungsherausforderung)#

Dies ist häufig die größte Quelle für Helpdesk-Anrufe bei Passkey-Implementierungen. Organisationen mit großen BYOD-Populationen (z. B. mehr als 10.000 Geräte) können allein aufgrund von Benutzern, die neue Smartphones erhalten und den Prozess zur Neuregistrierung von Authentifizierungsmethoden nicht kennen, eine große Anzahl von Supportanrufen verzeichnen.

Wenn Sie Passkeys ins Spiel bringen, wird dies noch kritischer, da:

• Benutzer Apps (wie Outlook) auf ihrem neuen Smartphone installieren
• Diese Apps zur Authentifizierung auffordern
• Die MFA-Aufforderung auf dem alten Smartphone erscheint (das sie vielleicht schon in Zahlung gegeben oder gelöscht haben)
• Der Benutzer ausgesperrt ist und den Helpdesk anruft

6.2.1 Szenario-Matrix für den Smartphone-Austausch#

Das Ziel ist es, so viele Fälle wie möglich in die ersten beiden Zeilen zu verlagern, um die Inanspruchnahme des Helpdesks zu minimieren.

6.2.2 Intune-Registrierungs-Trick#

Ein cleverer Einblick: Die Anforderung eines Passkeys für die Intune-Registrierung zwingt die Benutzer, die Einrichtung des Microsoft Authenticators auf ihrem neuen Smartphone sofort abzuschließen – bevor sie auf Unternehmens-Apps zugreifen können.

• Heute: Die Intune-Registrierung erfordert einen MFA-Step-up. Das heißt, wenn Sie sich auf einem neuen Smartphone anmelden wollen, installieren Sie Outlook dort. Die MFA-Aufforderung geht jedoch an das alte Smartphone.
• Mit Passkey-Anforderung: Benutzer müssen zuerst Microsoft Authenticator-Passkeys auf dem neuen Smartphone einrichten, um die Registrierung abzuschließen. Dies geschieht zeitnah (am Tag des Smartphone-Wechsels) und nicht erst Monate später, wenn das alte Smartphone weg ist.

Dies löst die Wiederherstellung nicht, aber es verschiebt den Zeitplan. Die Benutzer registrieren ihr neues Gerät, solange sie noch Zugriff auf das alte haben.

6.3 Hardware-Sicherheitsschlüssel bringen Logistikprobleme mit sich#

Hardware-Schlüssel (YubiKeys etc.) werden manchmal als die universelle Lösung positioniert. In der Theorie sind sie das, in der Praxis zeigen sich jedoch mehr Herausforderungen:

• Logistischer Albtraum: Organisationen, die zuvor physische Token (wie RSA SecurID) eingesetzt haben, verbrachten oft Jahre damit, diese zu eliminieren. Der Austausch eines physischen Token-Programms durch ein anderes ist wenig reizvoll.
• Direktversand (Drop-Shipping): Yubico kann Schlüssel direkt an Benutzer versenden und sie benötigen nicht alle paar Jahre einen Batteriewechsel (im Gegensatz zu SecurID). Aber wenn jemand seinen Schlüssel vergisst, kann er sich nicht anmelden (bei gemeinsam genutzten Desktops).
• Belastung der lokalen IT: Lokale Vorgesetzte sollten nicht zum De-facto-IT-Support für vergessene Schlüssel werden.
• Kosten: Hardware-Schlüssel erhöhen die Kosten pro Benutzer, was mit der Mitarbeiterzahl skaliert.

Wann Hardware-Schlüssel sinnvoll sind:

• Tier 0 Admins: Domänen-Admins, "Break-Glass"-Konten
• Gemeinsam genutzte Arbeitsstationen (Shared Workstations): Kiosk-Umgebungen, Werkhallen, Tablets im Außendienst
• Externe Dienstleister ohne BYOD: Externe Nutzer, die keine persönlichen Geräte verwenden werden

6.4 Herausforderungen bei nicht verwalteten Geräten#

Viele Benutzer beschweren sich, dass sie auf einem persönlichen Gerät keine Optionen zur Passkey-Nutzung sehen können. Dies ist ein klassischer Reibungspunkt bei "nicht verwalteten Geräten" (Unmanaged Devices).

6.4.1 Analyse des Fehlers "Passkey nicht registriert"#

Benutzer können möglicherweise keine Passkeys auf einem persönlichen Gerät hinzufügen, während es auf einem Unternehmensgerät funktioniert. Dies liegt wahrscheinlich an der Interaktion von Intune-Compliance-Richtlinien mit dem Registrierungs-Flow.

• Mechanismus: Windows Hello for Business (WHfB) ist eine Plattform-Anmeldeinformation. Sie ist an das TPM des jeweiligen Geräts gebunden (gerätegebundener Passkey).
• Einschränkung: Um WHfB zu registrieren, muss das Gerät in der Regel in den Tenant eingebunden sein (Entra Joined oder Hybrid Joined). Auf ein persönliches Gerät, das nur "registriert" ist (Workplace Joined), können über Intune Richtlinieneinschränkungen angewendet werden, die die Bereitstellung von WHfB-Containern blockieren, wenn das Gerät nicht vollständig verwaltet oder compliant ist. Siehe Anforderungen an die Anmeldung mit FIDO2-Sicherheitsschlüsseln.
• "Passkey"-Option: Auf einem persönlichen Gerät sollte der Benutzer versuchen, einen FIDO2-Sicherheitsschlüssel (Roaming) oder einen geräteübergreifenden Passkey (auf seinem Smartphone) zu registrieren, nicht Windows Hello for Business (es sei denn, BYOD-Registrierung wird vollständig unterstützt).
• Sichtbarkeitsproblem in Entra ID: Wenn "Windows Hello" nicht als Option angezeigt wird, hat das Gerät die vorausgesetzte MDM-Registrierung nicht abgeschlossen.

6.4.2 Fehler bei der geräteübergreifenden Authentifizierung (CDA)#

Auf nicht verwalteten Geräten versuchen Benutzer oft den Cross-Device Authentication (CDA) Flow (Scannen eines QR-Codes auf dem PC mit ihrem Smartphone).

• Bluetooth-Abhängigkeit: CDA erfordert, dass Bluetooth sowohl auf dem PC als auch auf dem Smartphone aktiviert ist. Sie müssen sich nicht koppeln, müssen aber einen Bluetooth Low Energy (BLE)-Handshake durchführen, um die Nähe zu beweisen. Details finden Sie unter gerätegebundene Passkeys im Microsoft Authenticator.
• Unternehmensrichtlinie als Blocker: Wenn Bluetooth auf Firmenlaptops über BIOS oder GPO aus "Sicherheitsgründen" deaktiviert ist, haben Sie bereits den primären Mechanismus für Roaming-Passkeys zerstört.
• Websocket-Blockierung: Der CDA-Flow nutzt eine Websocket-Verbindung zu cable.ua5v.com oder cable.auth.com. Aggressive Unternehmensfirewalls oder Zscaler-Konfigurationen blockieren diese Domains häufig, wodurch der QR-Code-Scan hängen bleibt oder stillschweigend fehlschlägt. Siehe die Dokumentation zu Microsoft Authenticator Passkeys.

6.5 B2B und externe Identitäten#

Ein weiterer Schmerzpunkt für Unternehmen ist der Umgang mit externen Beratern (B2B-Gäste).

• Problem: Ein Berater versucht, auf eine SharePoint-Seite zuzugreifen. Der Tenant erzwingt eine Conditional Access-Richtlinie, die "Phishing-resistente MFA" erfordert.
• Fehler: Der Berater versucht, einen FIDO2-Schlüssel im Ressourcen-Tenant zu registrieren. Dies schlägt fehl. Entra ID unterstützt nicht, dass Gastbenutzer FIDO2-Schlüssel im Ressourcen-Tenant registrieren.
• Lösung: Mandantenübergreifende Zugriffseinstellungen (Cross-Tenant Access Settings)
  • Logik: Anstatt den Gast zu zwingen, eine Anmeldeinformation in Ihrem Tenant zu registrieren, sollten Sie der Anmeldeinformation vertrauen, die er in seinem Tenant verwendet.
  • Konfiguration: Gehen Sie zu Externe Identitäten > Mandantenübergreifende Zugriffseinstellungen (External Identities > Cross-tenant access settings). Wählen Sie die Partnerorganisation aus. Aktivieren Sie unter Inbound Trust das Kontrollkästchen "Trust multifactor authentication from Microsoft Entra tenants" (Multifaktor-Authentifizierung aus Microsoft Entra-Tenants vertrauen).
  • Ergebnis: Wenn sich der Berater mit einem YubiKey in seinem Heimat-Tenant anmeldet, erhält Ihr Tenant einen Anspruch (Claim), der besagt "MFA Satisfied + Phishing Resistant". Der Zugriff wird gewährt, ohne dass der Benutzer etwas registrieren muss. Dies lagert das Lifecycle-Management der Anmeldeinformationen an den Partner aus, was Ihre Haftung und die Belastung des Helpdesks reduziert.

7. Wiederherstellungsstrategien#

Oft hinken Wiederherstellungsentscheidungen dem eigentlichen Rollout noch hinterher. Es gibt mehrere Wiederherstellungsoptionen, abhängig von den Anforderungen Ihrer Organisation.

7.1 Self-Service Account Recovery (SSAR) mit Verified ID#

Microsoft Entra IDs neuer Self-Service Account Recovery (SSAR) Flow (in der Vorschau) ermöglicht eine hochsichere Wiederherstellung ohne Eingriff des Helpdesks.

1. Auslöser: Benutzer kann sich nicht anmelden. Wählt "Mein Konto wiederherstellen" (Recover my account).
2. Identitätsprüfung: Der Benutzer wird zu einem Drittanbieter für Identitätsverifizierung (IDV) weitergeleitet (z. B. Onfido, IDemia).
3. Dokumentenprüfung: Der Benutzer scannt seinen physischen Führerschein, Personalausweis oder Reisepass mit der Kamera seines Mobiltelefons.
4. Lebendigkeitsprüfung (Liveness Check): Der Benutzer führt ein Selfie per Face Check durch. Dies wird mit dem Ausweisdokument (und potenziell mit dem in Entra ID gespeicherten Foto) abgeglichen. Der Abgleich verwendet Azure AI Vision Face APIs und es wird nur ein Konfidenz-Wert geteilt. Es gelangen keine rohen biometrischen Daten an die Anwendung.
5. Wiederherstellung: Bei Erfolg stellt das System dem Benutzer automatisch einen Temporary Access Pass (TAP) aus.
6. Neuregistrierung: Der Benutzer verwendet den TAP, um sofort einen neuen Passkey zu registrieren.

Empfehlung: Dieser automatisierte, biometrisch gestützte Wiederherstellungspfad ist besser als "Rufen Sie den Helpdesk an", was anfällig für Social Engineering (Deepfake-Sprachangriffe) ist.

7.2 Manager-unterstützte Wiederherstellung mit My Staff#

Wenn Sie die Auslastung des Service Desks reduzieren möchten, aber keinen vollständigen Self-Service aktivieren können, enthält Microsoft Entra ein natives Feature für delegierte Administration namens My Staff.

• Wie es funktioniert: Delegieren Sie eingeschränkte Berechtigungen an "Team Manager" (über Verwaltungseinheiten in Entra).
• Flow: Wenn ein Benutzer den Zugriff verliert, kann er einen delegierten lokalen Admin kontaktieren, der das My Staff-Portal für unterstützte Wiederherstellungsaufgaben nutzen kann, wie z. B. das Zurücksetzen eines Passworts oder die Aktualisierung einer Telefonnummer.
• Warum es hilft: Es verlagert häufige Arbeiten zur Kontowiederherstellung vom zentralen Helpdesk weg und beschleunigt den Support.

7.3 Self-Service Recovery Kiosk (Intranet)#

Da Benutzer häufig noch über einen vertrauenswürdigen, per WHfB gesicherten Laptop verfügen, können Sie eine einfache "Break-Glass"-Intranetseite aufbauen.

• Aufbau: Eine einfache interne Web-App, die eine WHfB-Anmeldung (starke Authentifizierung) erfordert.
• Aktion: Nach der Authentifizierung klickt der Benutzer auf "Ich habe ein neues Smartphone". Die App nutzt die Microsoft Graph API (Hintergrunddienst), um einen kurzlebigen Temporary Access Pass (TAP) zu generieren, und zeigt ihn auf dem Bildschirm an.
• Ergebnis: Der Benutzer tippt diesen TAP in sein neues Smartphone ein, um die Microsoft Authenticator-App via Bootstrap einzurichten. Null Helpdesk-Beteiligung.

Dies ist der wichtigste Hebel, um Resets der "Clear Authentication Methods" zu reduzieren, ohne die Richtlinie zu schwächen. Wenn Sie über einen starken Laptop-als-Bootstrap-Mechanismus verfügen, sinkt Ihr Kommunikationsaufwand erheblich, da sich die Benutzer erholen können, ohne die perfekte Sequenz zu kennen.

8. Empfehlungen für Passkey-Einführungen im Unternehmen#

Strukturieren Sie Ihren Rollout anhand von Reifegradstufen. Erkennen Sie die Reibung an ("Die Technologie ist bereit, der Betrieb ist schwierig") und wenden Sie diese Abhilfemaßnahmen an.

8.1 Sofortmaßnahmen ("Fix-It"-Phase)#

1. Bluetooth & Firewalls prüfen (Audit): Stellen Sie sicher, dass Firmenlaptops Bluetooth zulassen (für Näherungsprüfungen), und setzen Sie die FIDO/WebAuthn-Relay-Domains (\*.cable.auth.com) auf die Whitelist, um geräteübergreifende Fehler zu beheben.
2. Mandantenübergreifendes Vertrauen (Cross-Tenant Trust) aktivieren: Hören Sie auf, Gast-Passkeys registrieren zu wollen. Konfigurieren Sie Inbound Trust für MFA für wichtige Partner, um B2B-Zugriffsprobleme sofort zu lösen.
3. TAP für das Onboarding implementieren: Schreiben Sie die Verwendung des Temporary Access Pass für das Onboarding aller neuen Benutzer vor, um den "Henne-Ei"-Registrierungsblocker zu lösen.

8.2 Strategische Entscheidungen ("Architektur"-Phase)#

1. Ein "Hybrid Assurance"-Modell annehmen:
   • Tier 0 (Admins): Attestation und Schlüsseleinschränkungen (Key Restrictions) erzwingen. Nur YubiKeys/Hardware erlaubt (AAL3).
   • Tier 1 (Belegschaft): Attestationsdurchsetzung über Passkey-Profile deaktivieren. Synchronisierte Passkeys zulassen, um Reibung und Kosten zu reduzieren (AAL2).
2. Für macOS planen: Implementieren Sie Platform SSO mit Ihrem MDM als parallelen Track zu Windows WHfB.

8.3 Zukunftssicherheit ("Optimierungs"-Phase)#

1. SSAR planen: Beginnen Sie ein Pilotprojekt für Self-Service Account Recovery mit Verified ID, um den Helpdesk als Vektor für Social Engineering zu eliminieren.
2. Systembevorzugte Authentifizierung: Aktivieren Sie diese Richtlinie, um automatisch ein "Upgrade" der Benutzer auf Passkeys durchzuführen, sobald diese einen registrieren, und treiben Sie die Akzeptanz ohne harten Zwang voran.
3. Wiederherstellungsoptionen bereitstellen: Implementieren Sie den Manager-unterstützten TAP über My Staff und/oder einen Self-Service Recovery Kiosk.
4. Intune Passkey-Anforderung: Erwägen Sie, einen Passkey für die Intune-Registrierung vorschreiben zu lassen, um eine frühzeitige Registrierung auf neuen Geräten zu erzwingen.

8.4 Fehlersuch-Matrix (Troubleshooting)#

9. Überwachung der Implementierung mit dem Phishing-Resistant Passwordless Workbook#

Microsoft hat ein Phishing-Resistant Passwordless Workbook veröffentlicht, das Organisationen mit Protokollen in Azure Monitor verwenden können, um den Rollout-Fortschritt zu verfolgen. Rufen Sie es über das Entra Admin Center unter Monitoring > Workbooks auf:

Das Arbeitsbuch hat zwei primäre Abschnitte:

9.1 Phase der Registrierungsbereitschaft (Enrollment Readiness)#

Verwenden Sie diesen Tab, um Anmeldeprotokolle zu analysieren und festzustellen, welche Benutzer bereit für die Registrierung sind und welche Benutzer möglicherweise blockiert sind. Sie können nach Betriebssystemplattform (Windows, macOS, iOS, Android) und Anmeldeinformationstyp (Authenticator App Passkey, FIDO2-Sicherheitsschlüssel, zertifikatsbasierte Authentifizierung) filtern:

Das Arbeitsbuch zeigt:

• Benutzer/Geräte-Paare, die für die Registrierung bereit sind: Benutzer, die den ausgewählten Typ der Anmeldeinformation registrieren können
• Benutzer/Geräte-Paare nicht bereit: Benutzer, bei denen Registrierungsprobleme auftreten könnten (z. B. veraltete OS-Versionen)

Sie können Listen von Benutzern exportieren, bei denen Abhilfemaßnahmen erforderlich sind (z. B. OS-Upgrades, Geräteaustausch oder alternative Optionen für Anmeldeinformationen).

9.2 Phase der Durchsetzungsbereitschaft (Enforcement Readiness)#

Sobald die Benutzer für eine ausschließlich phishing-resistente Authentifizierung bereit sind, verwenden Sie den Tab "Enforcement Readiness". Erstellen Sie zunächst eine Nur Bericht (Report-Only) Conditional Access-Richtlinie, die phishing-resistente MFA erfordert. Dies füllt die Anmeldeprotokolle mit Daten darüber, ob der Zugriff blockiert worden wäre, wenn die Durchsetzung aktiv gewesen wäre.

Das Dashboard zeigt:

• Gesamte Benutzer im Geltungsbereich
• Nur Bericht Erfolg (Report Only Success) - Benutzer, die die Durchsetzung bestehen würden
• Richtlinie nicht erfüllt (Policy Not Satisfied) - Benutzer, die blockiert würden (untersuchen Sie diese!)
• Aufschlüsselungen nach Gerätestatus (Device State), Geräteplattform (Device Platform) und Client-App (Client App)

Verwenden Sie den Tab Weitere Datenanalyse (Further Data Analysis), um zu untersuchen, warum bestimmte Benutzer blockiert würden. Diese Daten helfen Ihnen, Benutzer für eine Remediation (Abhilfe) anzusprechen, bevor Sie die Durchsetzung aktivieren.

9.3 Rollout in Wellen mit Helpdesk-Überwachung#

Microsoft empfiehlt, Einführungen in Wellen mit flexiblen Zeiträumen durchzuführen. Überwachen Sie das Ticketvolumen des Helpdesks als Signal:

• Ticketvolumen steigt: Verlangsamen Sie die Einführungen, Kommunikation und Durchsetzungsaktionen
• Ticketvolumen sinkt: Fahren Sie die Aktivitäten wieder hoch

Erstellen Sie Microsoft Entra ID-Sicherheitsgruppen für jede Welle und fügen Sie den Richtlinien inkrementell Gruppen hinzu. Dies verhindert eine Überlastung der Support-Teams.

10. Checkliste für das Synchronisierte-Passkey-Pilotprojekt#

Wenn das Ziel synchronisierte Passkeys ohne Abhängigkeit vom Microsoft Authenticator lautet, befolgen Sie dieses Vorgehen für den Piloten:

1. Synchronisierte Passkeys aktivieren (Vorschau) Befolgen Sie Synchronisierte Passkeys (Vorschau).

2. Passkey-Profile (Vorschau) verwenden und der Pilotgruppe zuweisen Erstellen/weisen Sie ein Profil zu, das synchronisierte Passkeys erlaubt, wie in Passkey-Profile beschrieben.

3. Keine Attestation erzwingen (zumindest für die Pilotgruppe) Das Erzwingen der Attestation schließt synchronisierte Passkeys gemäß der Dokumentation zu Passkey- (FIDO2) Konzepten aus.

4. Strenge AAGUID-Allow-Listen anfangs vermeiden Beginnen Sie permissiv, um den Flow zu bestätigen, und verschärfen Sie dann die Einschränkungen, sobald Sie wissen, welche Anbieter Sie zulassen möchten. Siehe Passkeys (FIDO2) aktivieren.

5. Bestätigen, dass Conditional Access den Microsoft Authenticator nicht erzwingt Stellen Sie sicher, dass CA/Authentifizierungsstärken das von Ihnen beabsichtigte Passkey-Profil weiterhin zulassen (sonst sieht es wie eine Microsoft Authenticator-Abhängigkeit aus).

6. Das Identitätsmodell validieren (Mitglied vs. Gast) Wenn Benutzer Gäste sind, bestätigen Sie die erwartete Unterstützbarkeit in Ihrem Tenant-Modell, bevor Sie Zeit in die Feinabstimmung von Profilen investieren.

11. Fazit#

Die Einführung von Enterprise-Passkeys ist operativ komplex, aber der Weg in die Zukunft ist klar definiert. Hier sind die wichtigsten Antworten, abgestimmt auf die oben angesprochenen wesentlichen operativen Fragen:

1. Gerätegebundene vs. synchronisierte Passkeys: Gerätegebundene Anmeldeinformationen (z. B. Microsoft Authenticator, Windows Hello, YubiKeys, Smartcards) sind strikt an ein einziges Gerät gebunden und erfüllen AAL3. Synchronisierte Passkeys (z. B. iCloud-Schlüsselbund, Google Passwortmanager) funktionieren geräteübergreifend und erfüllen AAL2. Die meisten Unternehmen benötigen beides: Hardware-Authentikatoren für Admins (AAL3) und synchronisierte Passkeys für die breitere Belegschaft (AAL2).

2. Bootstrapping für neue Mitarbeiter: Verwenden Sie den Temporary Access Pass (TAP), um das Henne-Ei-Problem beim Onboarding zu lösen. Bei groß angelegten Implementierungen automatisieren Sie dies über die Graph API. Für Anwendungsfälle mit hoher Sicherheit ergänzen Sie das Onboarding um Entra Verified ID und Face Check.

3. Wiederherstellung bei Smartphone-Austausch: Bieten Sie mehrere Wiederherstellungsmethoden an: Self-Service Recovery Kiosk (verwenden Sie einen Laptop als Bootstrap-Gerät), Manager-unterstützten TAP via My Staff und SSAR (Self-Service Account Recovery) mit Verified ID für Randfälle.

4. Konfigurationsfehler: Zu den häufigsten Fehltritten gehören die globale Durchsetzung der Attestation, das Nicht-Aktivieren von Vorschau-Features für synchronisierte Passkeys, zu strenge AAGUID-Allow-Listen und Conditional Access (CA)-Richtlinien, die zirkuläre Abhängigkeiten schaffen.

5. B2B-Gäste: Vermeiden Sie es, Passkeys direkt für B2B-Gäste in Ihrem Tenant zu registrieren. Aktivieren Sie stattdessen Cross-Tenant Access Trust, um die Anmeldeinformationen aus dem Heimat-Tenant des Gastes zu validieren.

6. Hardware-Schlüssel vs. mobile Passkeys: Hardware-Sicherheitsschlüssel sind für bestimmte Hochsicherheitsrollen (Admins, gemeinsam genutzte Arbeitsstationen) erforderlich, stellen jedoch in der Breite logistische Hürden dar. Mobile Passkeys sind für die Belegschaft im Allgemeinen praktischer.

7. macOS neben Windows: Verwenden Sie Platform SSO mit JAMF/MDM, um die Passkey-Unterstützung auf macOS parallel zu Windows-Implementierungen zu aktivieren. Planen Sie plattformspezifische Workflows ein.

8. Proaktive Maßnahmen: Verwenden Sie Intune, um inaktive Geräte zu identifizieren, und fordern Sie Benutzer zur Remediation auf, bevor eine Aussperrung auftritt. Erwägen Sie, die Passkey-Registrierung zur Voraussetzung für die Intune-Registrierung zu machen, um eine frühzeitige Akzeptanz zu fördern. Bauen Sie einen Self-Service-Wiederherstellungs-Workflow auf, der Laptops als Bootstrap-Geräte nutzt.

Die Technologie ist bereit. Die größte Herausforderung ist die operative Ausführung. Die Wiederherstellungsplanung muss vom ersten Tag an integriert sein und darf kein nachträglicher Gedanke sein. Sobald die Infrastruktur solide ist, konzentrieren Sie sich auf die Optimierung der Passkey-Anmeldeakzeptanz, um sicherzustellen, dass Passkeys zur primären Authentifizierungsmethode in Ihrer gesamten Belegschaft werden.

Über Corbado

Corbado ist die Passkey Intelligence Platform für CIAM-Teams, die Consumer-Authentifizierung im großen Maßstab betreiben. Wir zeigen Ihnen, was IDP-Logs und generische Analytics-Tools nicht sehen können: welche Geräte, OS-Versionen, Browser und Credential-Manager Passkeys unterstützen, warum Enrollments nicht zu Logins werden, wo der WebAuthn-Flow scheitert und wann ein OS- oder Browser-Update den Login still und leise unterbricht – und das alles, ohne Okta, Auth0, Ping, Cognito oder Ihren In-House-IDP zu ersetzen. Zwei Produkte: Corbado Observe ergänzt Observability für Passkeys und jede andere Login-Methode. Corbado Connect bringt Managed Passkeys mit integrierter Analytics (neben Ihrem IDP). VicRoads betreibt Passkeys für über 5 Mio. Nutzer mit Corbado (+80 % Passkey-Aktivierung). Mit einem Passkey-Experten sprechen →

Häufig gestellte Fragen (FAQ)#

Warum sperrt die Aktivierung von phishing-resistenter MFA in Conditional Access alle meine Benutzer aus?#

Das Erstellen einer Conditional Access-Richtlinie, die phishing-resistente MFA für alle Cloud-Apps erfordert, blockiert sofort jeden Benutzer, der noch keinen Passkey registriert hat, einschließlich des Zugriffs auf die Seite zur Registrierung von Sicherheitsinformationen selbst. Diese zirkuläre Abhängigkeit, das 'Register Security Info'-Paradoxon genannt, bedeutet, dass Sie betroffenen Benutzern vor der Durchsetzung einen Temporary Access Pass ausstellen müssen, damit sie die Ersteregistrierung abschließen können.

Wie gehe ich mit B2B-Gastbenutzern um, wenn mein Tenant phishing-resistente MFA erfordert?#

Entra ID unterstützt nicht, dass Gastbenutzer FIDO2-Schlüssel in einem Ressourcen-Tenant registrieren, sodass der Versuch, die Passkey-Registrierung für Gäste zu erzwingen, fehlschlägt. Die korrekte Lösung besteht darin, mandantenübergreifende Zugriffseinstellungen (Cross-Tenant Access Settings) unter Externe Identitäten so zu konfigurieren, dass MFA-Ansprüchen aus dem Heimat-Tenant des Gastes vertraut wird. Das bedeutet, dass ein YubiKey, der in der eigenen Organisation verwendet wird, Ihre Anforderung an phishing-resistente MFA erfüllt, ohne dass eine Registrierung in Ihrem Tenant erforderlich ist.

Was führt dazu, dass die geräteübergreifende QR-Code-Authentifizierung bei der Anmeldung mit einem Passkey stillschweigend fehlschlägt?#

Die geräteübergreifende Authentifizierung erfordert, dass Bluetooth sowohl auf dem PC als auch auf dem Smartphone aktiviert ist, um einen BLE-Näherungs-Handshake durchzuführen. Jede Unternehmensrichtlinie, die Bluetooth deaktiviert, bricht den Flow daher vollständig ab. Der Flow nutzt auch eine WebSocket-Verbindung zu cable.auth.com, die von Firewalls oder Zscaler-Konfigurationen häufig blockiert wird, was dazu führt, dass der QR-Code-Scan ohne klare Fehlermeldung hängen bleibt oder fehlschlägt.

Wie überwache ich, welche Mitarbeiter für die Durchsetzung der phishing-resistenten MFA bereit sind, bevor ich sie einschalte?#

Das Microsoft Phishing-Resistant Passwordless Workbook, das im Entra Admin Center unter Monitoring > Workbooks zugänglich ist, bietet eine Ansicht zur Registrierungsbereitschaft (Enrollment Readiness), die zeigt, welche Benutzer-/Gerätepaare sich nach Plattform und Anmeldeinformationstyp registrieren können. Für die Durchsetzungsbereitschaft erstellen Sie eine 'Nur Bericht'-Richtlinie (Report-Only) für Conditional Access, die phishing-resistente MFA erfordert, sodass Anmeldeprotokolle zeigen, welche Benutzer blockiert würden, bevor Sie die Live-Durchsetzung aktivieren.

Was ist die beste Wiederherstellungsstrategie für Mitarbeiter, die ein neues Smartphone erhalten und den Zugriff auf ihren Passkey verlieren?#

Der empfohlene Ansatz ist mehrstufig: Ein Self-Service Recovery Kiosk, der einen per WHfB gesicherten Laptop nutzt, generiert über die Graph API einen Temporary Access Pass und deckt die meisten Fälle ohne Helpdesk-Eingriff ab. Für Benutzer ohne Laptop delegiert der Manager-unterstützte TAP über das My Staff-Portal die Wiederherstellung an direkte Vorgesetzte, und die Self-Service Account Recovery mit der biometrischen Face Check-Funktion von Entra Verified ID bewältigt Randfälle, die eine vollständige Überprüfung der Identität erfordern.

Weiterführende Literatur#

Für Deep-Dives in unternehmensweite FIDO2-/Passkey-Implementierungen folgen Sie Experten wie Merill Fernando und Jan Bakker, die regelmäßig praktische Leitfäden zur Microsoft Entra-Authentifizierung veröffentlichen.