---
url: 'https://www.corbado.com/de/blog/enterprise-passkey-einfuehrung-herausforderungen'
title: 'Herausforderungen und Lösungen bei der Einführung von Enterprise-Passkeys'
description: 'Passkeys in Microsoft Entra ID skalierbar einführen. Behandelt Registrierungsherausforderungen, gerätegebundene vs. synchronisierte Passkeys, Wiederherstellung und Fehlerbehebung.'
lang: 'de'
author: 'Vincent Delitz'
date: '2026-05-22T13:43:38.767Z'
lastModified: '2026-10-03T06:01:39.086Z'
keywords: 'Entra synchronisierte Passkeys, FIDO2, Temporary Access Pass, Passkey Einführung, Microsoft Entra ID'
category: 'Passkeys Strategy'
---

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

## Key Facts

- Das **NIST SP 800-63B Supplement 1** bestätigt, dass synchronisierte Passkeys die
  AAL2-Anforderungen erfüllen. Damit sind sie ausreichend phishing-resistent für den
  allgemeinen Einsatz in der Belegschaft, ohne dass Hardware-Schlüssel benötigt werden.
- Der **Temporary Access Pass (TAP)** löst das Bootstrapping-Paradoxon: Ein zeitlich
  begrenzter Passcode ermöglicht es neuen Mitarbeitern, einen Passkey zu registrieren,
  ohne jemals ein Passwort festzulegen.
- Die Durchsetzung der **Attestation** (Bescheinigung) in Microsoft Entra ID blockiert
  alle synchronisierten Passkeys. Verwenden Sie Passkey-Profile, um sie selektiv
  anzuwenden: erforderlich für Admins, deaktiviert für allgemeine Mitarbeiter.
- Ein **segmentiertes Assurance-Modell** ist unerlässlich: Hardware-Schlüssel erfüllen
  AAL3 für Admins und privilegierte Rollen, während synchronisierte Passkeys AAL2 für die
  breitere Belegschaft bieten.

## 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](https://www.corbado.com/de/blog/passkey-erstellung-optimieren)?
5. Wie gehe ich mit B2B-Gästen um, wenn ich [phishing](https://www.corbado.com/glossary/phishing)-resistente
   [MFA](https://www.corbado.com/de/blog/medibank-datenleck) verlange?
6. Sollte ich
   [Hardware-Sicherheitsschlüssel](https://www.corbado.com/de/blog/die-besten-fido2-hardware-sicherheitsschluessel-2025)
   (YubiKeys) oder mobile Passkeys verwenden?
7. Wie gehe ich mit [macOS](https://www.corbado.com/de/blog/parallels-passkeys-cda)-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](https://www.corbado.com/glossary/phishing)-Seite, die dem Original ähnelt, sie nicht wiederholen
kann). Siehe die Übersicht von Microsoft in der
[Dokumentation zu Passkey- (FIDO2) Konzepten](https://learn.microsoft.com/en-us/entra/identity/authentication/concept-authentication-passkeys-fido2).

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](https://www.corbado.com/glossary/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](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](https://www.corbado.com/de/faq/login-zweites-geraet-geraetegebundener-passkey) oder
Drittanbieter). Der private Schlüssel wird verschlüsselt in der Sync-Struktur eines
Cloud-Anbieters gespeichert.

Ab Januar 2026 werden [synchronisierte Passkeys](https://www.corbado.com/de/blog/device-bound-synced-passkeys) in
Entra über das **Vorschau-Feature** gehandhabt:
[Synchronisierte Passkeys (Vorschau)](https://learn.microsoft.com/en-us/entra/identity/authentication/how-to-authentication-synced-passkeys).
Um [synchronisierte Passkeys](https://www.corbado.com/de/blog/device-bound-synced-passkeys) zu aktivieren und zu
steuern, verwendet Entra
[Passkey-Profile (Vorschau)](https://learn.microsoft.com/en-us/entra/identity/authentication/how-to-authentication-passkey-profiles).

**Regulatorische Eignung:** Kürzlich durch das
[NIST SP 800-63B](https://www.corbado.com/faq/nist-sp-800-63b-supplement-passkey-adoption) Supplement 1 als die
**AAL2**-Anforderungen erfüllend validiert. Dies ist ein massiver regulatorischer Erfolg,
der bestätigt, dass [synchronisierte Passkeys](https://www.corbado.com/de/blog/device-bound-synced-passkeys)
"[phishing-resistent](https://www.corbado.com/de/blog/vollstaendig-passwortlos-werden)" 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](https://www.corbado.com/de/blog/vollstaendig-passwortlos-werden) des Kontowiederherstellungs-Flows
des Cloud-Anbieters.

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

| Passkey-Anbieter                                     | Windows                        | macOS                          | iOS                           | Android                                                   |
| ---------------------------------------------------- | ------------------------------ | ------------------------------ | ----------------------------- | --------------------------------------------------------- |
| Apple Passwords (iCloud-Schlüsselbund)               | N/A                            | Nativ integriert. macOS 13+    | Nativ integriert. iOS 16+     | N/A                                                       |
| Google Passwortmanager                               | Integriert in Chrome           | Integriert in Chrome           | Integriert in Chrome. iOS 17+ | Nativ integriert (ausgenommen Samsung-Geräte). Android 9+ |
| Andere Passkey-Anbieter (z. B. 1Password, Bitwarden) | Auf Browser-Erweiterung prüfen | Auf Browser-Erweiterung prüfen | Auf App prüfen. iOS 17+       | Auf App prüfen. Android 14+                               |

Auf der Seite mit den Sicherheitsinformationen eines Benutzers werden synchronisierte und
[gerätegebundene Passkeys](https://www.corbado.com/de/blog/device-bound-synced-passkeys) klar voneinander
unterschieden. Unten sehen Sie, wie ein synchronisierter Passkey (von
[1Password](https://www.corbado.com/blog/1password-passkeys-best-practices-analysis)) und ein gerätegebundener
Passkey (YubiKey 5C NFC) erscheinen:

![Passkey-Kontoeinstellungen](https://s3.eu-central-1.amazonaws.com/corbado-cloud-staging-website-assets/passkey_account_settings_946c956180.png)

### 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](https://www.corbado.com/blog/nist-passkeys)-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](https://www.corbado.com/blog/nist-passkeys)-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](https://www.corbado.com/glossary/phishing)-resistente
[passwortlose Authentifizierung](https://www.corbado.com/de/glossary/ctap) bereit sind, müssen sie über diese
Mindestversionen verfügen:

| Plattform | Mindestversion                                     | Hinweise                                                                                   |
| --------- | -------------------------------------------------- | ------------------------------------------------------------------------------------------ |
| Windows   | 10 22H2 (für WHfB), 11 22H2 (für beste Passkey-UX) | Ältere Versionen erfordern möglicherweise FIDO2-Sicherheitsschlüssel                       |
| macOS     | 13 Ventura                                         | Erforderlich für Platform SSO Secure Enclave Key                                           |
| iOS       | 17                                                 | Erforderlich für Passkey-Sync und geräteübergreifende Flows                                |
| Android   | 14                                                 | Erforderlich für synchronisierte Passkeys; ältere Versionen benötigen Sicherheitsschlüssel |

Ältere Betriebssysteme erfordern möglicherweise externe Authentikatoren
(FIDO2-Sicherheitsschlüssel), um die phishing-resistente
[passwortlose Authentifizierung](https://www.corbado.com/de/glossary/ctap) 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](https://www.corbado.com/passkey-benchmark-2026/webauthn-client-capabilities)
liegt die Browserunterstützung im ersten Quartal 2026 bei 97–100 % für Conditional Get und
[Hybrid Transport](https://www.corbado.com/de/blog/webauthn-transports-intern-hybrid), aber nur bei 83–92 % für
[Conditional Create](https://www.corbado.com/blog/conditional-create-passkeys) in einem typischen
Consumer-Browser-Mix – eine Einschränkung, die sich am stärksten auf Windows auswirkt, da
[Windows Hello](https://www.corbado.com/glossary/windows-hello) kein
[Conditional Create](https://www.corbado.com/blog/conditional-create-passkeys)-Pfad ist und Edge in demselben
Datensatz eine besonders geringe
[Conditional Create](https://www.corbado.com/blog/conditional-create-passkeys)-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):

| Benutzer-Persona                     | Empfohlen                  | Alternativen                                                   |
| ------------------------------------ | -------------------------- | -------------------------------------------------------------- |
| Admins und stark regulierte Benutzer | FIDO2-Sicherheitsschlüssel | Passkey im Microsoft Authenticator, Smartcard                  |
| Nicht-Admin-Belegschaft              | Synchronisierter Passkey   | FIDO2-Sicherheitsschlüssel, Passkey im Microsoft Authenticator |

**Lokale Anmeldeinformationen** (gerätespezifisch):

| Benutzer-Persona | Windows       | macOS                                    | iOS                               | Android                           |
| ---------------- | ------------- | ---------------------------------------- | --------------------------------- | --------------------------------- |
| Admins           | WHfB oder CBA | Platform SSO Secure Enclave Key oder CBA | Passkey im Authenticator oder CBA | Passkey im Authenticator oder CBA |
| Nicht-Admins     | WHfB          | Platform SSO Secure Enclave Key          | Synchronisierter Passkey          | Synchronisierter Passkey          |

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](https://www.corbado.com/glossary/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](https://www.corbado.com/de/blog/authentifizierungs-observability) 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](https://www.corbado.com/de/blog/digital-credentials-api)/Windows funktioniert, unter
  [Safari](https://www.corbado.com/de/blog/digital-credentials-api)/[macOS](https://www.corbado.com/de/blog/parallels-passkeys-cda)
  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](https://www.corbado.com/glossary/security-key) (Sicherheitsschlüssel)
- Hardware Key (Hardware-Schlüssel)
- [YubiKey](https://www.corbado.com/glossary/yubikey)
- [passwortlos](https://www.corbado.com/de/blog/warum-passkey-implementierungen-scheitern)
- Windows Security (Windows-[Sicherheit](https://www.corbado.com/de/blog/vollstaendig-passwortlos-werden))
- [Windows Hello](https://www.corbado.com/glossary/windows-hello)
- Windows Hello for Business (WHfB)
- Microsoft [Authenticator](https://www.corbado.com/glossary/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](https://www.corbado.com/de/blog/vollstaendig-passwortlos-werden)" 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](https://www.corbado.com/de/blog/passkeys-cheat-sheet) 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](https://www.corbado.com/de/blog/medibank-datenleck)- und SSPR-Portale sind veraltet. Die gesamte
[FIDO2](https://www.corbado.com/glossary/fido2)-Konfiguration muss in dem zentralen Blade für
[Richtlinien für Authentifizierungsmethoden](https://www.threatscape.com/cyber-security-blog/common-entra-id-mfa-mistakes-you-might-be-making/)
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](https://www.corbado.com/glossary/fido2)-Gerät (z. B.
  [YubiKey](https://www.corbado.com/glossary/yubikey) 5 NFC, Microsoft [Authenticator](https://www.corbado.com/glossary/authenticator)
  auf [iOS](https://www.corbado.com/blog/how-to-enable-passkeys-ios), Google
  [Passwortmanager](https://www.corbado.com/de/faq/login-zweites-geraet-geraetegebundener-passkey)) 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](https://www.corbado.com/blog/passkey-analysis-bitwarden-developer-survey-2024) oder Google
  [Passwortmanager](https://www.corbado.com/de/faq/login-zweites-geraet-geraetegebundener-passkey) gespeichert
  sind) unterstützen generell **keine** [Attestation](https://www.corbado.com/glossary/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](https://www.corbado.com/de/blog/vollstaendig-passwortlos-werden) (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](https://www.corbado.com/glossary/attestation)"-Richtlinie anwenden,
wenn Sie hochprivilegierte Administratoren haben, die Hardware-Schlüssel benötigen. Sie
müssen
[Passkey-Profile (Vorschau)](https://learn.microsoft.com/en-us/entra/identity/authentication/how-to-authentication-synced-passkeys)
verwenden:

- _Profil A (Admins):_ [Attestation](https://www.corbado.com/glossary/attestation) erzwingen = **Ja**
- _Profil B (Allgemeine Belegschaft):_ Attestation erzwingen = **Nein**

### 4.3 Passkey-Profile erklärt

Stellen Sie sich
[Passkey-Profile](https://learn.microsoft.com/en-us/entra/identity/authentication/how-to-authentication-passkey-profiles)
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:

![Passkey FIDO2 Einstellungen ausgewählte Profile](https://s3.eu-central-1.amazonaws.com/corbado-cloud-staging-website-assets/passkey_fido2_settings_selected_profiles_8fad7bfc7a.png)

Beim Bearbeiten eines Passkey-Profils können Sie die Durchsetzung der Attestation,
Zieltypen (gerätegebunden, synchronisiert oder beides) sowie spezifische
[AAGUID](https://www.corbado.com/glossary/aaguid)-Beschränkungen konfigurieren:

![Passkey FIDO2 Einstellungen](https://s3.eu-central-1.amazonaws.com/corbado-cloud-staging-website-assets/passkey_fido2_settings_800cee0438.png)

### 4.4 Conditional Access & Authentifizierungsstärken

Die Durchsetzung kann über Conditional Access (CA)-Richtlinien (Bedingter Zugriff)
gesteuert werden, die
[Authentifizierungsstärken (Authentication Strengths)](https://learn.microsoft.com/en-us/entra/identity/authentication/concept-authentication-strengths)
nutzen.

- **Phishing-resistente MFA-Stärke:** Diese integrierte Stärke erfordert
  [FIDO2](https://www.corbado.com/glossary/fido2), Windows Hello for Business (WHfB) oder zertifikatsbasierte
  [Authentifizierung](https://www.corbado.com/de/blog/passkey-fallback-recovery) (CBA).
- **Aussperrungs-Falle (Lockout Trap):** Wenn Sie eine CA-Richtlinie erstellen, die
  "Phishing-resistente [MFA](https://www.corbado.com/de/blog/medibank-datenleck)" 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)](https://learn.microsoft.com/en-us/entra/identity/conditional-access/policy-all-users-security-info-registration)
  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:

| Kombination der Authentifizierungsmethode                     | MFA-Stärke | Passwortlose MFA-Stärke | Phishing-resistente MFA-Stärke |
| ------------------------------------------------------------- | :--------: | :---------------------: | :----------------------------: |
| FIDO2-Sicherheitsschlüssel                                    |     ✅     |           ✅            |               ✅               |
| Windows Hello for Business oder Plattform-Anmeldeinformation  |     ✅     |           ✅            |               ✅               |
| Zertifikatsbasierte Authentifizierung (Multifaktor)           |     ✅     |           ✅            |               ✅               |
| Microsoft Authenticator (Telefon-Anmeldung)                   |     ✅     |           ✅            |                                |
| Temporary Access Pass (Einmal- und Mehrfachnutzung)           |     ✅     |                         |                                |
| Passwort plus etwas, das der Benutzer besitzt                 |     ✅     |                         |                                |
| Föderierter Einzelfaktor plus etwas, das der Benutzer besitzt |     ✅     |                         |                                |
| Föderierter Multifaktor                                       |     ✅     |                         |                                |
| Zertifikatsbasierte Authentifizierung (Einzelfaktor)          |            |                         |                                |
| SMS-Anmeldung                                                 |            |                         |                                |
| Passwort                                                      |            |                         |                                |
| Föderierter Einzelfaktor                                      |            |                         |                                |

### 4.5 Systembevorzugte Authentifizierung

Die Funktion "Vom System bevorzugte
Multifaktor-[Authentifizierung](https://www.corbado.com/de/blog/passkey-fallback-recovery)" in Entra ID zwingt
die Anmelde-Engine,
[den Benutzer nach der sichersten registrierten Methode zu fragen](https://www.token2.com/site/page/default-mfa-method-for-microsoft-entra-id-users).

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:

![1password passkey entra](https://s3.eu-central-1.amazonaws.com/corbado-cloud-staging-website-assets/1password_passkey_entra_e261b05849.png)

### 4.6 Besonderheiten bei macOS: Platform SSO

Für Organisationen mit gemischten
Windows-/[macOS](https://www.corbado.com/de/blog/parallels-passkeys-cda)-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](https://www.corbado.com/glossary/secure-enclave) des Macs gebunden sind
- [SSO](https://www.corbado.com/blog/passkeys-single-sign-on-sso)-Erfahrung über
  [native Apps](https://www.corbado.com/de/blog/webauthn-relying-party-id-rpid-passkeys) und Web-Apps hinweg
- Phishing-resistente [Authentifizierung](https://www.corbado.com/de/blog/passkey-fallback-recovery), die
  [AAL2](https://www.corbado.com/blog/nist-passkeys)/[AAL3](https://www.corbado.com/blog/nist-passkeys)-Anforderungen erfüllt

**Hinweis:** macOS Platform [SSO](https://www.corbado.com/blog/passkeys-single-sign-on-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)](https://learn.microsoft.com/en-us/entra/identity/authentication/how-to-authentication-synced-passkeys)
  beschrieben
- Eine Profilkonfiguration unter Verwendung von
  [Passkey-Profilen](https://learn.microsoft.com/en-us/entra/identity/authentication/how-to-authentication-passkey-profiles)

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](https://www.corbado.com/glossary/aaguid)-Allow/Block-Listen). Wenn Sie nur den Microsoft
[Authenticator](https://www.corbado.com/glossary/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](https://www.corbado.com/faq/is-face-id-passkey),
Windows-[Biometrie](https://www.corbado.com/de/blog/biometrie-payer-awareness)-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)](https://learn.microsoft.com/en-us/entra/identity/authentication/howto-authentication-temporary-access-pass)
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](https://www.corbado.com/de/blog/digital-credentials-api) 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](https://janbakker.tech/how-to-create-a-temporary-access-pass-using-logic-apps/).

- **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](https://learn.microsoft.com/en-us/entra/identity/authentication/how-to-deploy-phishing-resistant-passwordless-authentication)
mit **Face Check** einen primär passwortlosen Registrierungspfad:

1. **Identitätsprüfung (Identity Proofing):** Neuer Benutzer verifiziert seine
   [Identität](https://www.corbado.com/de/blog/digital-credentials-api) über einen IDV-Partner (Scan eines
   staatlichen Ausweises).
2. **Biometrischer Abgleich:**
   [Face Check](https://learn.microsoft.com/en-us/entra/verified-id/using-facecheck)
   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](https://www.corbado.com/blog/enterprise-passkey-deployment-challenges) 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):

![Microsoft Entra Verified ID Face Check Flow mit den Schritten Verifizieren, Bestätigen und Überprüfen](https://s3.eu-central-1.amazonaws.com/corbado-cloud-staging-website-assets/face_check_b5a23174b0.png)

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

| Szenario               | Benutzer hat altes Smartphone | Benutzer hat vertrauenswürdigen Laptop | Lösung                                                                                                                                                     |
| ---------------------- | ----------------------------- | -------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Bester Fall**        | Ja                            | Ja                                     | Führen Sie den Benutzer an, den neuen Passkey hinzuzufügen, während das alte Smartphone noch funktioniert. Wechseln Sie zum "Happy Path".                  |
| **Häufiger Fall**      | Nein                          | Ja                                     | **Laptop als Bootstrap:** Nutzen Sie eine per WHfB authentifizierte Sitzung, um den Passkey auf dem neuen Smartphone zu registrieren (Self-Service Kiosk). |
| **Schlechtester Fall** | Nein                          | Nein                                   | Intervention des Helpdesks oder SSAR mit Identitätsprüfung unvermeidlich.                                                                                  |

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](https://learn.microsoft.com/en-us/entra/identity/authentication/howto-authentication-passwordless-security-key-windows).
- **"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](https://www.corbado.com/de/glossary/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](https://www.corbado.com/de/blog/parallels-passkeys-cda) Low
  [Energy](https://www.corbado.com/passkeys-for-energy) (BLE)-Handshake durchführen, um die Nähe zu beweisen.
  Details finden Sie unter
  [gerätegebundene Passkeys im Microsoft Authenticator](https://janbakker.tech/things-you-should-know-before-rolling-out-device-bound-passkeys-in-microsoft-authenticator-app/).
- **Unternehmensrichtlinie als Blocker:** Wenn
  [Bluetooth](https://www.corbado.com/de/blog/parallels-passkeys-cda) 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](https://www.corbado.com/de/glossary/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](https://learn.microsoft.com/en-us/entra/identity/authentication/how-to-enable-authenticator-passkey).

### 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](https://www.corbado.com/de/blog/die-besten-fido2-hardware-sicherheitsschluessel-2025) im
  Ressourcen-Tenant zu registrieren. **Dies schlägt fehl.** Entra ID
  [unterstützt nicht, dass Gastbenutzer FIDO2-Schlüssel im Ressourcen-Tenant registrieren](https://learn.microsoft.com/en-us/answers/questions/1192906/cannot-register-fido2-key-for-guest-users-on-resou).
- **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 &gt; 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)](https://learn.microsoft.com/en-us/entra/identity/authentication/concept-account-recovery-overview)
Flow (in der Vorschau) ermöglicht eine hochsichere Wiederherstellung ohne Eingriff des
Helpdesks.

![Kontowiederherstellungs-Flow mit Microsoft Entra Verified ID, der den 4-stufigen Prozess zeigt](https://s3.eu-central-1.amazonaws.com/corbado-cloud-staging-website-assets/account_recovery_microsoft_entry_recovery_8c9f369047.png)

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](https://learn.microsoft.com/en-us/entra/verified-id/using-facecheck)
   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](https://www.corbado.com/de/blog/vollstaendig-passwortlos-werden) 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](https://www.corbado.com/blog/enterprise-passkey-deployment-challenges)
  (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](https://www.corbado.com/de/blog/parallels-passkeys-cda) zulassen (für Näherungsprüfungen), und
   setzen Sie die
   [FIDO](https://www.corbado.com/de/blog/emv-3ds-acs-passkeys-fido-und-spc)/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](https://www.corbado.com/blog/enterprise-passkey-deployment-challenges) 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](https://www.corbado.com/blog/passkeys-single-sign-on-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](https://www.corbado.com/de/blog/mfa-pflicht) 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)

| **Fehlermeldung / Symptom**                        | **Grundursache (Root Cause)**                                                                                                                               | **Strategie zur Behebung**                                                                                                                  |
| -------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------- |
| **"Passkey nicht registriert"** (Windows Desktop)  | Richtlinie erzwingt "Attestation", aber Benutzer verwendet eine nicht bescheinigte Methode (z. B. Google Passwortmanager, iCloud-Schlüsselbund, 1Password). | Verwenden Sie **Passkey-Profile**, um "Attestation erzwingen" für Standardbenutzer zu deaktivieren.                                         |
| **"Passkey nicht registriert"** (Mobile App)       | Spezifische AAGUID für Microsoft Authenticator (Android/iOS) fehlt auf der Whitelist für "Schlüsseleinschränkungen".                                        | AAGUIDs hinzufügen: Android: `de1e552d-db1d-4423-a619-566b625cdc84` iOS: `90a3ccdf-635c-4729-a248-9b709135078f`.                            |
| **Registrierungs-Schleife / Ausgegraute Optionen** | Benutzer hat keine bestehende MFA und CA erfordert phishing-resistente MFA, um auf "Sicherheitsinformationen registrieren" zuzugreifen.                     | **Bootstrapping-Fehler.** Stellen Sie einen **Temporary Access Pass (TAP)** aus, um die MFA-Prüfung für die anfängliche Sitzung zu umgehen. |
| **QR Code Scan schlägt fehl / dreht sich endlos**  | Bluetooth auf einem Gerät deaktiviert, oder Firewall blockiert `cable.auth.com` WebSocket.                                                                  | Bluetooth aktivieren (Näherungsprüfung). FIDO-Relay-Domains auf Whitelist setzen.                                                           |
| **Gastbenutzer-Registrierung schlägt fehl**        | Entra ID blockiert Gast-FIDO2-Registrierung in Ressourcen-Tenants.                                                                                          | **Nicht beheben.** Aktivieren Sie **Cross-Tenant Access Trust**, um stattdessen den MFA-Anspruch des Heimat-Tenants zu akzeptieren.         |

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

Microsoft hat ein
[Phishing-Resistant Passwordless Workbook](https://learn.microsoft.com/en-us/entra/identity/authentication/how-to-deploy-phishing-resistant-passwordless-authentication)
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:

![Microsoft Entra Workbooks mit der Option Phishing-Resistant Passwordless Deployment](https://s3.eu-central-1.amazonaws.com/corbado-cloud-staging-website-assets/phishing_resistant_passwordless_workbook_6b06c63518.png)

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](https://www.corbado.com/blog/how-to-enable-passkeys-ios), [Android](https://www.corbado.com/blog/how-to-enable-passkeys-android))
und Anmeldeinformationstyp (Authenticator App Passkey, FIDO2-Sicherheitsschlüssel,
zertifikatsbasierte Authentifizierung) filtern:

![Phase der Registrierungsbereitschaft, die eine Aufschlüsselung der Gerätebereitschaft mit den Paaren Benutzer/Gerät Bereit vs. Nicht Bereit zeigt](https://s3.eu-central-1.amazonaws.com/corbado-cloud-staging-website-assets/enrollment_phase_165ed80a39.png)

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.

![Phase der Durchsetzungsbereitschaft, die eine Aufschlüsselung der Richtlinienerfüllung mit weiterer Datenanalyse zeigt](https://s3.eu-central-1.amazonaws.com/corbado-cloud-staging-website-assets/detail_analysis_workbook_1c0931ee47.png)

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)](https://learn.microsoft.com/en-us/entra/identity/authentication/how-to-authentication-synced-passkeys).

2. **Passkey-Profile (Vorschau) verwenden und der Pilotgruppe zuweisen** Erstellen/weisen
   Sie ein Profil zu, das synchronisierte Passkeys erlaubt, wie in
   [Passkey-Profile](https://learn.microsoft.com/en-us/entra/identity/authentication/how-to-authentication-passkey-profiles)
   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](https://learn.microsoft.com/en-us/entra/identity/authentication/concept-authentication-passkeys-fido2)
   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](https://learn.microsoft.com/en-us/entra/identity/authentication/how-to-enable-passkey-fido2).

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](https://www.corbado.com/blog/nist-passkeys). Synchronisierte
   Passkeys (z. B. iCloud-Schlüsselbund, Google Passwortmanager) funktionieren
   geräteübergreifend und erfüllen [AAL2](https://www.corbado.com/blog/nist-passkeys). 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](https://www.corbado.com/de/blog/mfa-pflicht)) 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](https://www.corbado.com/glossary/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](https://www.corbado.com/de/blog/die-besten-fido2-hardware-sicherheitsschluessel-2025)
   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](https://www.corbado.com/de/blog/passkey-erstellung-optimieren) 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.

## 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](https://www.corbado.com/de/blog/die-besten-fido2-hardware-sicherheitsschluessel-2025) in einem
Ressourcen-Tenant registrieren, sodass der Versuch, die
[Passkey-Registrierung](https://www.corbado.com/de/blog/passkey-erstellung-optimieren) 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](https://www.corbado.com/de/glossary/cda) 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 &gt; 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](https://www.corbado.com/de/blog/mfa-pflicht) mit der
biometrischen Face Check-Funktion von Entra Verified ID bewältigt Randfälle, die eine
vollständige Überprüfung der [Identität](https://www.corbado.com/de/blog/digital-credentials-api) erfordern.

## Weiterführende Literatur

Für Deep-Dives in unternehmensweite FIDO2-/Passkey-Implementierungen folgen Sie Experten
wie **[Merill Fernando](https://au.linkedin.com/in/merill)** und
**[Jan Bakker](https://www.linkedin.com/in/jan-bakker/)**, die regelmäßig praktische
Leitfäden zur Microsoft Entra-Authentifizierung veröffentlichen.
