Passkeys 2026: Apple vs. Google vs. Microsoft im Vergleich

Fünf Milliarden Passkeys sind nach Angaben der FIDO Alliance inzwischen weltweit im Einsatz. Trotzdem stellt sich für IT-Verantwortliche in Deutschland, Österreich und der Schweiz noch immer dieselbe Frage: Welches der drei großen Ökosysteme, Apple, Google oder Microsoft, passt zur eigenen Infrastruktur? Die drei Plattformen setzen den FIDO2-Standard technisch ähnlich um, unterscheiden sich aber deutlich bei Synchronisierung, Verwaltung und Unternehmenssteuerung. Dieser Vergleich ordnet Spezifikationen, Preise, Benchmarks und Praxisfälle ein, Stand 14. Oktober 2026.

Der Druck zur Entscheidung wächst spürbar. Phishing bleibt laut gängigen Lageberichten einer der häufigsten Einstiegspunkte für Angriffe auf Unternehmensnetzwerke, und klassische Passwort-plus-SMS-Verfahren gelten als zunehmend unzureichend. Gleichzeitig zwingen neue EU-Regularien wie NIS2 mehr Unternehmen in DACH dazu, ihre Authentifizierungsverfahren zu dokumentieren und nachweisbar zu härten. Passkeys sind damit nicht mehr nur ein Komfort-Feature für Consumer-Apps, sondern ein Beschaffungsthema für IT-Leitungen, Security-Teams und Datenschutzbeauftragte zugleich. Wer jetzt entscheidet, legt die Authentifizierungsarchitektur für die nächsten Jahre fest, ein Wechsel des Ökosystems im laufenden Betrieb ist aufwendig und selten reibungslos.

Was sind Passkeys und warum verdrängen sie 2026 das Passwort?

Ein Passkey ist im Kern ein kryptografischer FIDO2-Schlüssel nach dem WebAuthn-Standard. Beim Anmelden erzeugt das Gerät ein Schlüsselpaar: Der private Schlüssel bleibt lokal oder in einem verschlüsselten Cloud-Tresor, der öffentliche Schlüssel liegt beim jeweiligen Dienst. Weil die Anmeldung kryptografisch an die echte Domain gebunden ist, funktionieren klassische Phishing-Seiten gegen Passkeys schlicht nicht, selbst ein perfekt kopiertes Login-Formular bekommt keine gültige Signatur zurück.

Apple, Google und Microsoft haben an der Entwicklung von WebAuthn und FIDO2 mitgearbeitet, bauen darauf aber unterschiedliche Produkte. Apple synchronisiert Passkeys Ende-zu-Ende-verschlüsselt über den iCloud-Schlüsselbund. Google nutzt den Password Manager, der eng mit Android und Chrome verzahnt ist. Microsoft trennt zwischen synchronisierten Passkeys über Authenticator und geräteweise gebundenen Optionen wie Windows Hello for Business oder separaten FIDO2-Sicherheitsschlüsseln. Für Unternehmen bedeutet das: Ein Passkey ist nicht gleich ein Passkey, die Synchronisierungsarchitektur bestimmt Wiederherstellung, Geräteverwaltung und letztlich auch das Risiko bei Kontoverlust.

Der heise-online-Hintergrundbericht zu Passkeys verweist auf genau dieses Spannungsfeld zwischen technischer Reife und praktischer Durchdringung: Der Standard ist seit Jahren stabil, die flächendeckende Nutzung hinkt der Verfügbarkeit jedoch hinterher.

Technisch läuft die Anmeldung über eine sogenannte WebAuthn-Ceremony ab: Der Dienst sendet eine Challenge, das Gerät signiert sie mit dem privaten Schlüssel und bestätigt zusätzlich per Biometrie oder Geräte-PIN, dass tatsächlich der berechtigte Nutzer anwesend ist. Dieses Verfahren ersetzt zwei getrennte Schritte, Passwort und zweiten Faktor, durch einen einzigen kryptografischen Vorgang. Für Entwickler bedeutet das weniger Code für Passwort-Resets und Rate-Limiting, für Nutzer einen spürbar kürzeren Anmeldevorgang. Der eigentliche Architekturstreit zwischen Apple, Google und Microsoft beginnt erst danach, nämlich bei der Frage, wo genau der private Schlüssel liegt und wer ihn im Verlustfall wiederherstellen darf.

Der Begriff Passkey selbst ist dabei jünger als die zugrunde liegende Technik. WebAuthn wurde bereits vor Jahren als W3C-Standard verabschiedet, blieb aber lange ein Nischenthema für Hardware-Sicherheitsschlüssel. Erst als Apple, Google und Microsoft gemeinsam begannen, synchronisierte, geräteübergreifende Passkeys direkt in ihre Betriebssysteme zu integrieren, wurde aus einem Nischenstandard eine massentaugliche Funktion. Diese Historie erklärt auch, warum die drei Ökosysteme technisch kompatibel, aber organisatorisch so unterschiedlich aufgebaut sind, jeder Anbieter hat die gemeinsame Basis in sein jeweils bestehendes Konto- und Gerätemodell eingebettet, statt ein neues, anbieterneutrales System zu schaffen.

Apple iCloud-Schlüsselbund: Passkeys für homogene Geräteflotten

Apples Ansatz ist am stärksten auf das eigene Ökosystem zugeschnitten. Passkeys sind fest in iOS, iPadOS, macOS, watchOS und visionOS integriert, sobald Anwendung und Betriebssystemversion WebAuthn unterstützen. Die Synchronisierung läuft über iCloud-Schlüsselbund, Ende-zu-Ende-verschlüsselt zwischen vertrauenswürdigen Apple-Geräten. Die Wiederherstellung hängt an der Account- und Gerätesicherheit des Apple-Kontos, es gibt keinen separaten Passkey-Export in ein Drittsystem.

Für Unternehmen mit Apple-only-Flotten ist das ein Vorteil: Apple Business Manager und Managed Apple Accounts bieten eine straffe Geräteverwaltung, die sich gut mit MDM-Profilen kombinieren lässt. Die zentrale Steuerung einzelner Passkeys bleibt dabei aber stärker an das jeweilige Gerät und den Dienstanbieter gebunden als bei Microsofts Entra-Richtlinien, es fehlt ein mit Conditional Access vergleichbares, plattformweites Regelwerk. Wer dagegen bereits auf Windows-Clients oder Android-Flotten setzt, muss für Apple-Passkeys zusätzliche Cross-Device-Schritte einplanen, typischerweise per QR-Code und Bluetooth-Nähe zum iPhone.

Interessant für DACH-Admins: Apple-Passkeys lassen sich auch für Microsoft- oder Drittanbieter-Konten nutzen, sofern der Browser den iCloud-Schlüsselbund als Passkey-Provider anbietet. Damit entsteht in gemischten Umgebungen eine praktikable, aber nicht immer intuitive Brücke zwischen den Ökosystemen.

Für kleinere Teams, etwa Agenturen oder Kanzleien mit zehn bis fünfzig Beschäftigten, liegt der eigentliche Charme von Apples Lösung im fehlenden Verwaltungsaufwand. Es gibt kein separates Admin-Portal für Passkeys, keine zusätzliche Lizenzbuchung und keine Schulung für ein neues Sicherheitsprodukt. Die Kehrseite zeigt sich erst bei Wachstum: Sobald ein Unternehmen über einhundert Mitarbeitende hinauswächst oder gesetzliche Nachweispflichten entstehen, fehlt die feingranulare Steuerung, die größere Organisationen typischerweise benötigen, etwa um Passkeys nur für bestimmte Anwendungen verpflichtend zu machen.

Google Password Manager: Die Android- und Chrome-Schiene

Google Password Manager ist die naheliegende Wahl für Unternehmen mit Android-Geräten, Chromebooks oder Chrome als Standardbrowser. Passkeys synchronisieren über das Google-Konto zwischen unterstützten Android-Geräten und Chrome-Installationen, auf Android existiert zusätzlich eine lokale, geräteisolierte Schlüsseloption für besonders sensible Anwendungsfälle.

Chrome läuft plattformübergreifend auf Windows, macOS, Linux, Android und iOS, wodurch Google-Passkeys faktisch auch außerhalb reiner Android-Umgebungen nutzbar sind. Die konkrete Synchronisierungslogik und Provider-Unterstützung unterscheidet sich dabei je nach Plattform und Richtliniensatz. Für Google-Workspace-Administratoren stehen Authentifizierungsrichtlinien, 2-Step Verification, Sicherheitsschlüssel-Durchsetzung und Passkey-Verwaltung im Admin-Konsolenkontext zur Verfügung, ergänzt durch Android Enterprise und Chrome Enterprise für Geräte- und Browserkontrolle.

Praktisch heißt das: Google deckt die größte Plattformvielfalt am Client ab, ohne dabei eine so granulare Conditional-Access-Logik wie Microsoft zu bieten. Für mittelständische Unternehmen mit gemischten Browser- und Gerätelandschaften, aber ohne komplexe Identitäts-Governance-Anforderungen, ist das meist ausreichend.

Ein praktischer Vorteil für DACH-Betriebe mit vielen Außendienstmitarbeitenden: Weil Chrome auf nahezu jedem Gerät läuft, lässt sich ein Passkey-Rollout über Google Password Manager oft ohne zusätzliche Hardware realisieren, selbst wenn die Belegschaft eine Mischung aus privaten und dienstlichen Geräten nutzt. Das senkt die Einstiegshürde gegenüber reinen MDM-Lösungen, bringt aber auch weniger Kontrolle darüber, auf welchem Gerät ein Schlüssel am Ende tatsächlich gespeichert ist, ein Punkt, den Datenschutzbeauftragte bei der Dokumentation der Zugriffskette berücksichtigen sollten.

Microsoft Entra ID und Authenticator: Die Enterprise-Schiene

Microsoft verfolgt den unternehmenslastigsten Ansatz der drei Anbieter. Entra ID unterscheidet explizit zwischen synchronisierten Passkeys über Microsoft Authenticator und geräteweise gebundenen FIDO2-Sicherheitsschlüsseln oder Windows Hello for Business. Administratoren legen über Authentication Strengths fest, welche Methoden für welche Benutzergruppen, Anwendungen oder Risikostufen zulässig sind, kombiniert mit Conditional Access und Risiko-Richtlinien.

Microsoft Authenticator läuft auf iOS und Android, Windows Hello for Business bleibt der zentrale, gerätegebundene Pfad unter Windows. Entra-Passkeys lassen sich zusätzlich von Android- und iOS-Geräten über unterstützte Authenticator- oder FIDO2-Flows nutzen. Alex Simons, Corporate Vice President für Identity Program Management bei Microsoft, beschreibt das Nutzererlebnis so: “The employee taps a fingerprint or glances at their camera, on any device, and they’re in.” Die Aussage stammt aus einem Microsoft-Entra-Blogbeitrag zu Passkeys im Unternehmenskontext.

Simons macht in demselben Beitrag auch deutlich, dass Synchronisierung allein nicht das Ziel ist: “The passkey syncs across devices via iCloud Keychain, Google Password Manager, Microsoft Password Manager or other platform credential managers, so it works wherever they work.” Das ist zugleich eine Warnung an Admins, Passkeys nicht isoliert, sondern als Teil eines größeren Identitätsmodells mit klaren Fallback- und Recovery-Regeln zu betrachten, gerade weil schwache Fallbacks wie SMS oder wiederherstellbare Passwörter den Gesamtschutz wieder aufweichen können.

Technische Spezifikationen im direkten Vergleich

Die folgende Tabelle fasst die wichtigsten technischen Unterschiede zwischen den drei Passkey-Ökosystemen zusammen, Stand Oktober 2026.

Kriterium	Apple (iCloud-Schlüsselbund)	Google (Password Manager)	Microsoft (Entra ID / Authenticator)
Synchronisierung	Ende-zu-Ende verschlüsselt über iCloud	Über Google-Konto, Android + Chrome	Über Authenticator, getrennt von Device-Bound-Optionen
Native Plattformen	iOS, iPadOS, macOS, watchOS, visionOS	Android, Chrome (plattformübergreifend)	Windows (Hello for Business), iOS/Android via Authenticator
Cross-Device-Login	QR-Code + Bluetooth zum iPhone	QR-Code, browser-/kontoabhängig	FIDO2-Sicherheitsschlüssel, Authenticator-Flow
Geräteweise gebundene Option	Nein, nur Synchronisierung	Ja, lokale Option auf Android	Ja, Windows Hello for Business, FIDO2-Keys
Enterprise-Verwaltung	Apple Business Manager, Managed Apple Accounts, MDM	Google Workspace Admin-Konsole, Android/Chrome Enterprise	Entra ID Conditional Access, Authentication Strengths
Granulare Zugriffsrichtlinien	Eingeschränkt, gerätebasiert	Mittel, über Workspace-Richtlinien	Umfangreich, Conditional Access + Risiko-Policies
FIDO2/WebAuthn-Basis	Ja	Ja	Ja
Browser-Interoperabilität	Als Provider in Drittbrowsern nutzbar	Chrome auf allen gängigen Desktop-/Mobil-OS	Authenticator-App auf iOS/Android, Edge nativ
Phishing-Resistenz	Hoch, domaingebunden	Hoch, domaingebunden	Hoch, abhängig von zugelassenen Fallbacks
Recovery-Mechanismus	An Apple-ID-Sicherheit gebunden	An Google-Konto-Sicherheit gebunden	Richtliniengesteuert, admin-konfigurierbar
Typisches Einsatzfeld	Homogene Apple-Flotten	Android-/Chrome-lastige Organisationen	Heterogene Enterprise-Umgebungen, Zero Trust

Auffällig ist, dass alle drei Anbieter FIDO2/WebAuthn als gemeinsame technische Basis nutzen. Der Unterschied liegt fast ausschließlich in der Verwaltungsebene: Microsoft bietet die differenzierteste Richtliniensteuerung, Apple die engste Geräteintegration, Google die breiteste Browser-Reichweite.

Wer sich allein an dieser Tabelle orientiert, sollte einen Punkt nicht übersehen: Die Spezifikation beschreibt das jeweilige Maximum, nicht zwangsläufig die Konfiguration, mit der ein Unternehmen tatsächlich startet. Viele Organisationen aktivieren anfangs nur einen Bruchteil der verfügbaren Richtlinienoptionen, etwa weil die Umstellung schrittweise erfolgt oder weil Fachabteilungen zunächst nur Pilotgruppen zulassen. Die reale Sicherheitswirkung hängt deshalb weniger vom theoretischen Funktionsumfang ab als davon, wie konsequent ein Unternehmen die verfügbaren Werkzeuge tatsächlich nutzt.

Preise und Lizenzmodelle: Was kostet der Umstieg?

Passkeys selbst sind bei allen drei Anbietern eine kostenlose Betriebssystem- beziehungsweise Kontofunktion. Die eigentlichen Kosten entstehen auf der Verwaltungsebene, also bei MDM-Lizenzen, Workspace-Tarifen oder Identitäts-Add-ons.

Preise für die jeweilige Verwaltungsebene (Richtwerte Oktober 2026)

Anbieter	Passkey-Funktion	Verwaltungslayer	Preis
Apple	Kostenlos (iCloud-Schlüsselbund)	Apple Business Manager / MDM	Keine gesonderte Passkey-Gebühr, MDM-Kosten variieren je nach Anbieter
Google	Kostenlos (Password Manager)	Google Workspace Admin-Konsole	In Workspace-Tarifen enthalten, kein separates Passkey-Add-on ausgewiesen
Microsoft	Kostenlos (Authenticator)	Entra ID P1	7 US-Dollar pro Nutzer/Monat (jährliche Zahlung), auch in Microsoft 365 E3 / Business Premium enthalten
Microsoft	Kostenlos (Authenticator)	Entra ID P2	10 US-Dollar pro Nutzer/Monat (jährliche Zahlung), auch in Microsoft 365 E5 enthalten

Die offizielle Entra-Preisliste von Microsoft ist damit die einzige der drei Plattformen mit einer klar bezifferten, direkt dem Identitätsmanagement zugeordneten Lizenzstufe. Google weist für Workspace aktuell keinen separaten Passkey-Posten aus, hier zählt der ohnehin gebuchte Tarif. Für Apple fällt in reinen Consumer-Szenarien gar keine zusätzliche Lizenzgebühr an, Unternehmen zahlen lediglich für das MDM ihrer Wahl, nicht für die Passkey-Funktion selbst. Wer Entra ID P2 bereits für Conditional Access oder Identity Protection gebucht hat, bekommt die granulare Passkey-Steuerung quasi kostenneutral dazu, das verschiebt die Kalkulation zugunsten von Microsoft in stark regulierten Branchen.

Belastbare, plattformspezifische Nutzerzahlen für iCloud-Schlüsselbund, Google Password Manager und Entra-Passkeys sind öffentlich kaum getrennt ausgewiesen. Mehrere unabhängige Berichte liefern aber konkrete Ökosystem-weite Kennzahlen.

Quelle	Kennzahl	Wert
FIDO Alliance, State of Passkeys 2026	Weltweit aktive Passkeys	Mehr als 5 Milliarden
FIDO Alliance, State of Passkeys 2026	Login-Erfolgsrate mit Passkey	93 Prozent
FIDO Alliance, State of Passkeys 2026	Reduktion loginbezogener Helpdesk-Vorfälle	81 Prozent
FIDO Alliance, State of Passkeys 2026	Unternehmen mit Passkeys im Einsatz, Pilot oder Rollout (1.400 Befragte, 10 Länder)	68 Prozent
Enterprise-Studie, 500 IT-/Security-Entscheider (USA, Kanada, UK, Frankreich, Deutschland)	Auf dem Adoptionspfad	93 Prozent
Dieselbe Enterprise-Studie	Bereits vollständig skaliert ausgerollt	Nur 13 Prozent
Dashlane, Oktober 2026	Nutzer mit mindestens einem gespeicherten Passkey	57 Prozent (Vorjahr: 40 Prozent)
Dashlane, Oktober 2026	Passkey-Authentifizierungen pro Monat	Rund 2,5 Millionen, fast doppelt so viele wie im Vorjahr
Infosecurity Magazine	Trend bei Passkey-Authentifizierungen	Verdoppelung, Adoption bleibt dennoch langsam

Der State of Passkeys 2026 Report der FIDO Alliance liefert damit die belastbarste Ökosystem-Kennzahl des Jahres: über fünf Milliarden aktive Passkeys weltweit. Entscheidend für Unternehmen ist aber die zweite Zahl aus der separaten Enterprise-Befragung: 93 Prozent der Organisationen befinden sich zwar auf dem Adoptionspfad, aber nur 13 Prozent haben die Umstellung tatsächlich skaliert abgeschlossen. Pilotprojekt und flächendeckende Durchsetzung sind also zwei verschiedene Dinge, ein Umstand, der bei keiner der drei Plattformen automatisch gelöst wird.

Der Dashlane-Bericht liefert zusätzlich dienstspezifische Zahlen: Bei Google lag der Passkey-Anteil an beobachteten Logins bei 28 Prozent, bei PayPal 18 Prozent, bei Amazon 17 Prozent und bei eBay 8 Prozent. Das sind Nutzungswerte einzelner Dienste und kein Marktanteil von Apple, Google oder Microsoft als Plattform, sie zeigen aber, wie unterschiedlich schnell Passkeys je nach Dienst tatsächlich ankommen. Der von Infosecurity Magazine beschriebene Trend bestätigt dieses Bild: Authentifizierungen verdoppeln sich, die Adoption in der Breite bleibt trotzdem langsamer als die reine Verfügbarkeit vermuten lässt.

Für IT-Entscheider in DACH lässt sich aus den drei Quellen eine klare Priorität ableiten: Die technische Verfügbarkeit von Passkeys ist 2026 kein Thema mehr, alle drei Ökosysteme liefern ausgereifte Implementierungen. Der limitierende Faktor ist die organisatorische Umsetzung, gemessen an der Lücke zwischen den 68 Prozent mit laufendem Projekt und den nur 13 Prozent mit abgeschlossener Skalierung. Wer die Lücke schließen will, sollte weniger Zeit in die Anbieterwahl stecken und mehr in Change-Management, klare Fristen und ein Enddatum für parallele Legacy-Methoden.

Phishing-Resistenz: Wo die drei Ökosysteme wirklich sicherer sind

Apples Ricky Mondello, Entwickler und WWDC-Referent, bringt den Sicherheitsvorteil auf den Punkt: “They are much more secure because they’re guaranteed to be strong and unique for each app or website and are extremely resistant to phishing attacks.” Die Aussage stammt aus der WWDC-Session zum Deployment von Passkeys im Unternehmen und gilt technisch für alle FIDO2-konformen Implementierungen, nicht nur für Apple.

Mondello beschreibt im selben Vortrag auch das Synchronisierungsmodell: “And when you use the built-in password manager in iOS, iPadOS, and macOS to store your passkeys, passkeys are securely synced across Apple devices using iCloud Keychain, so they are instantly available across your devices.” Genau diese Bequemlichkeit ist zugleich der wunde Punkt in der Sicherheitsdiskussion: Wer das Apple-Konto selbst kompromittiert, bekommt im schlimmsten Fall Zugriff auf alle synchronisierten Schlüssel. Dasselbe Grundrisiko gilt strukturell für Google Password Manager und für synchronisierte Microsoft-Authenticator-Passkeys.

Wichtig für die Einordnung in einem deutschen Fachartikel: FIDO-Zertifizierung ist keine pauschale Eigenschaft von “Apple”, “Google” oder “Microsoft” als Marke. Zertifiziert werden konkrete Authenticator-, Client- und Server-Implementierungen. Ein Unternehmen, das Beschaffungsanforderungen mit FIDO-Zertifikaten belegen muss, sollte deshalb die jeweilige Komponente einzeln prüfen, etwa den konkreten Entra-Dienst, die Authenticator-App-Version oder den eingesetzten Hardware-Sicherheitsschlüssel, statt sich auf eine allgemeine Markenaussage zu verlassen.

Eine deutsche Forschungsarbeit vom August 2026 untersuchte 103 Webseiten mit Passkey-Login und fand laut Berichterstattung keine einzige Seite, die sämtliche geprüften Sicherheitsanforderungen vollständig erfüllte. Das relativiert den reinen Marketing-Begriff “phishing-resistent”: Die Kryptografie ist solide, die konkrete Implementierung beim jeweiligen Dienst entscheidet aber trotzdem über die reale Schutzwirkung.

Für Sicherheitsverantwortliche folgt daraus eine klare Konsequenz: Ein Penetrationstest oder eine Konfigurationsprüfung sollte nicht nur den Login-Vorgang selbst abdecken, sondern auch Session-Management, Token-Lebensdauer und die Übergänge zwischen Passkey- und Fallback-Anmeldung. Gerade dieser Übergangsbereich, etwa wenn ein Nutzer vom Passkey auf eine temporäre Passwort-Zurücksetzung ausweicht, ist in der Praxis häufiger die Schwachstelle als die eigentliche FIDO2-Signatur.

Enterprise- und MDM-Unterstützung im Detail

Für IT-Abteilungen ist die Verwaltungsebene oft wichtiger als die reine Kryptografie. Apple bietet mit Apple Business Manager und Managed Apple Accounts eine ausgereifte Geräteverwaltung, die Passkey-Steuerung bleibt dabei aber stärker an die Apple-Plattform selbst gebunden als an ein zentrales Identitätsmodell. Google Workspace erlaubt Administratoren, Authentifizierungsmethoden, 2-Step Verification und Passkey-Durchsetzung zentral zu konfigurieren, ergänzt durch Android Enterprise und Chrome Enterprise für die Geräteseite.

Microsoft Entra ID bietet nach Einschätzung der verfügbaren Herstellerdokumentation die umfangreichste native Steuerung: Authentication Strengths legen fest, welche Methoden für welchen Kontext zulässig sind, Conditional Access verknüpft das mit Standort, Gerätezustand und Risikobewertung, Windows Hello for Business deckt die native Windows-Schiene ab. Für Unternehmen mit eigener Compliance-Abteilung oder regulatorischen Nachweispflichten, etwa im Finanzsektor oder in kritischer Infrastruktur, ist das in der Praxis oft der entscheidende Faktor.

Ein Praxisaspekt wird in Vergleichen häufig unterschätzt: die Reihenfolge der Einführung. Unternehmen, die zuerst die Richtlinienebene bei Microsoft Entra ID aufsetzen und erst danach Endgeräte migrieren, berichten in der Praxis von weniger Reibungsverlusten als Organisationen, die Geräte zuerst umstellen und die Governance nachträglich ergänzen. Bei Apple und Google ist dieser Unterschied kleiner, weil beide Systeme weniger auf eine zentrale Vorab-Richtliniendefinition angewiesen sind, dafür aber auch weniger Stellschrauben bieten, falls nachträglich doch feinere Kontrolle benötigt wird.

Ein Beispiel für eine typische Entra-Richtliniendefinition, wie sie in einem Conditional-Access-Rollout für Passkeys verwendet wird:

{
  "displayName": "Passkey-Pflicht fuer Finanzanwendungen",
  "conditions": {
    "applications": { "includeApplications": ["ERP-App-ID"] },
    "users": { "includeGroups": ["Finance-Team"] }
  },
  "grantControls": {
    "authenticationStrength": "Phishing-resistant MFA",
    "operator": "OR"
  }
}

Solche granularen Regeln lassen sich bei Apple und Google in dieser Tiefe aktuell nicht abbilden, beide Anbieter setzen stärker auf Standardverhalten pro Konto oder Gerätegruppe statt auf anwendungsspezifische Richtlinienlogik.

Regulatorischer Druck in der DACH-Region: Warum jetzt entscheiden?

Für deutsche, österreichische und Schweizer Unternehmen ist die Wahl des Passkey-Ökosystems längst keine reine IT-Entscheidung mehr. Die europäische NIS2-Richtlinie verpflichtet einen deutlich größeren Kreis an Unternehmen als bisher, Zugriffskontrollen und Authentifizierungsverfahren nachvollziehbar zu dokumentieren und regelmäßig zu überprüfen. Wer im Rahmen einer Prüfung nachweisen muss, welche Authentifizierungsmethode für welche Nutzergruppe gilt, profitiert von einem System mit klaren, exportierbaren Richtlinien, genau der Stärke, die Microsoft Entra ID gegenüber Apple und Google ausspielt.

Auch die Sorgfaltspflichten aus der DSGVO spielen eine Rolle: Passkeys verarbeiten biometrische Merkmale lokal auf dem Gerät, nicht auf Servern der Anbieter, was datenschutzrechtlich in der Regel unproblematischer ist als zentrale biometrische Datenbanken. Entscheidend ist aber, wie transparent ein Unternehmen gegenüber Beschäftigten und Kunden dokumentiert, wo und wie lange Schlüssel synchronisiert werden. Für Behörden und Betreiber kritischer Infrastruktur, die ohnehin an BSI-Vorgaben gebunden sind, ist die Kombination aus zertifizierten FIDO2-Hardwareschlüsseln und einer zentralen Richtlinienverwaltung meist die konservativere und leichter prüfbare Wahl, selbst wenn die reine Synchronisierungslösung bei Apple oder Google technisch gleichwertig sicher wäre.

Die bereits erwähnte deutsche Forschungsarbeit zu 103 Passkey-Webseiten ist in diesem Zusammenhang eine Warnung an alle drei Ökosysteme gleichermaßen: Eine korrekt implementierte FIDO2-Anmeldung allein genügt nicht, wenn Recovery-Flows, Fallback-Methoden oder Session-Handling beim jeweiligen Dienst Lücken aufweisen. Wer in DACH regulatorisch sauber aufgestellt sein will, sollte Passkeys deshalb nie isoliert bewerten, sondern immer im Zusammenspiel mit Account-Recovery, Protokollierung und Audit-Fähigkeit des gesamten Identitätssystems.

In Österreich und der Schweiz gelten zwar andere Aufsichtsbehörden und teils abweichende Meldepflichten als in Deutschland, der grundsätzliche Trend ist aber identisch: Mehr Branchen fallen unter verschärfte Cybersicherheitsvorgaben, und Authentifizierung gehört regelmäßig zu den zuerst geprüften Kontrollen. Unternehmen mit Standorten in mehreren DACH-Ländern tun deshalb gut daran, eine einheitliche Passkey-Strategie zu verfolgen, statt pro Standort unterschiedliche Ökosysteme ohne zentrale Abstimmung einzuführen.

Praxisbeispiele: Fünf reale Einsatzszenarien für Passkeys

Statt hypothetischer Szenarien lohnt der Blick auf bereits dokumentierte Einsatzdaten:

Google als Dienst: Laut Dashlane-Bericht liegt der Passkey-Anteil an den Logins bei Google selbst bei 28 Prozent, dem höchsten Wert unter den untersuchten Großdiensten.
PayPal: 18 Prozent der beobachteten Logins laufen bereits über Passkey statt Passwort, ein Hinweis darauf, dass Finanzdienstleister die Umstellung trotz Haftungsfragen aktiv vorantreiben.
Amazon: Mit 17 Prozent Passkey-Anteil zeigt sich, dass auch Handelsplattformen mit sehr hohem Login-Volumen den Umstieg technisch bewältigen.
eBay: Der niedrigere Wert von 8 Prozent verdeutlicht, dass die Umstellungsgeschwindigkeit stark vom jeweiligen Nutzerstamm und UX-Design abhängt.
Internationale Enterprise-Stichprobe: Die von der FIDO Alliance zitierte Befragung von 1.400 Entscheidern in zehn Ländern, Deutschland eingeschlossen, zeigt 68 Prozent mit aktivem Passkey-Projekt, aber eben nur 13 Prozent mit abgeschlossenem Rollout in der separaten 500-Personen-Studie.

Gemeinsam ist allen fünf Beispielen: Keiner der Dienste hat vollständig auf Passwörter verzichtet. Passkeys laufen parallel zu bestehenden Methoden, bis Nutzerverhalten und Supportprozesse den vollständigen Umstieg erlauben. Das deckt sich mit dem Befund aus dem techshotsapp.com-Bericht, dass technische Verfügbarkeit allein noch keine Nutzerumstellung erzwingt.

Bemerkenswert ist zudem die Spannweite zwischen 28 Prozent bei Google und 8 Prozent bei eBay. Beide Dienste haben Passkeys technisch vollständig implementiert, trotzdem unterscheidet sich die tatsächliche Nutzung um den Faktor drei. Der wahrscheinlichste Grund liegt im Standard-Verhalten beim Login-Formular: Dienste, die Passkey als voreingestellte erste Option anzeigen statt als versteckte Alternative, erzielen laut den vorliegenden Daten spürbar höhere Nutzungsraten. Für Unternehmen, die eigene Kundenportale betreiben, ist das ein direkt umsetzbarer Hebel, unabhängig davon, für welches der drei Ökosysteme sich die Entwicklung letztlich entscheidet.

Die internationale Enterprise-Stichprobe mit 1.400 Entscheidern verdient dabei eine genauere Einordnung: Sie deckt Unternehmen mit mindestens 500 Beschäftigten in zehn Ländern ab, Deutschland eingeschlossen, liefert aber keinen separat ausgewiesenen deutschen Teilwert. Für die Berichterstattung in diesem Artikel bedeutet das, dass sich belastbare Aussagen nur auf internationaler Ebene treffen lassen, ein rein deutscher Adoptionswert mit Anbieteraufschlüsselung lag zum Redaktionsschluss nicht vor. Wer genauere Zahlen für den eigenen Markt benötigt, sollte sich direkt an die FIDO Alliance oder an nationale Branchenverbände wie den TeleTrusT Bundesverband IT-Sicherheit wenden.

Migrationsleitfaden: In acht Schritten zu Passkeys

Der Wechsel von Passwort und SMS-Code auf Passkeys lässt sich unabhängig vom gewählten Ökosystem in acht Schritten strukturieren. Die Reihenfolge ist bewusst so gewählt, dass technische und organisatorische Schritte sich abwechseln, denn reine Technik-Rollouts ohne begleitende Kommunikation sind laut den oben zitierten Adoptionsstudien der häufigste Grund, warum Projekte in der Pilotphase steckenbleiben.

Bestandsaufnahme: Welche Anwendungen, IdPs und Gerätetypen sind im Einsatz, welche davon unterstützen WebAuthn bereits?
Ökosystem-Entscheidung: Apple für homogene Geräteflotten, Google für Android-/Chrome-Schwerpunkte, Microsoft Entra ID für heterogene Enterprise-Umgebungen mit Conditional-Access-Bedarf.
Pilotgruppe festlegen: Eine technikaffine Abteilung zuerst, um Supportaufwand und Akzeptanz realistisch einzuschätzen.
Fallback-Strategie definieren: Welche Methode greift, wenn ein Gerät verloren geht, und wie streng werden schwächere Fallbacks wie SMS eingeschränkt?
Richtlinien konfigurieren: Bei Microsoft über Authentication Strengths und Conditional Access, bei Google über die Workspace Admin-Konsole, bei Apple über MDM-Profile.
Nutzerkommunikation: Klare Anleitung zur Ersteinrichtung, idealerweise mit Live-Demo statt reiner E-Mail-Anweisung.
Helpdesk vorbereiten: Laut FIDO Alliance sinken loginbezogene Helpdesk-Vorfälle um 81 Prozent, dieser Effekt tritt aber erst nach stabiler Einführung ein, nicht in der Pilotphase.
Legacy-Methoden stufenweise abschalten: Passwort und SMS-Fallback erst deaktivieren, wenn die skalierte Rollout-Phase erreicht ist, laut Enterprise-Studie aktuell nur bei 13 Prozent der Organisationen der Fall.

Der letzte Schritt ist in der Praxis der heikelste: Solange Passwort und SMS parallel aktiv bleiben, bleibt auch das alte Angriffsrisiko bestehen. Der eigentliche Sicherheitsgewinn entsteht erst, wenn Fallbacks konsequent eingeschränkt werden, nicht schon durch die bloße Verfügbarkeit von Passkeys.

Häufige Fehler bei der Passkey-Einführung

Viele Rollouts scheitern nicht an der Kryptografie, sondern an organisatorischen Details. Ein verbreiteter Fehler ist, Passkeys parallel zu allen bisherigen Methoden anzubieten, ohne jemals ein Enddatum für Passwort oder SMS-Code festzulegen. Ohne diesen Druck bleibt die Nutzung dauerhaft bei den von der FIDO Alliance beobachteten niedrigen Werten jenseits der Pilotphase, wie die 13-Prozent-Zahl aus der zitierten Enterprise-Studie zeigt.

Ein zweiter häufiger Fehler betrifft die Recovery-Planung: Unternehmen richten Passkeys ein, vergessen aber, klare Prozesse für verlorene oder gestohlene Geräte zu definieren. Landet die Wiederherstellung am Ende doch wieder bei einem Helpdesk-Mitarbeiter, der per Telefon Identitäten mündlich prüft, geht ein Großteil des Phishing-Schutzes verloren, den Passkeys eigentlich bieten sollen. Drittens unterschätzen viele IT-Teams den Schulungsaufwand: Nutzer, die zum ersten Mal einen Passkey einrichten, verwechseln häufig Geräte-PIN, biometrische Freigabe und Cloud-Konto, was in der Einführungsphase zu einem kurzfristigen Anstieg von Support-Tickets führt, bevor die von der FIDO Alliance gemessene Entlastung von 81 Prozent überhaupt greifen kann.

Viertens wird die Browser- und App-Kompatibilität oft zu spät geprüft. Nicht jede interne Anwendung, insbesondere ältere On-Premises-Systeme, unterstützt WebAuthn nativ. Ein Rollout ohne vorherige Bestandsaufnahme, wie in Schritt eins des Migrationsleitfadens beschrieben, führt regelmäßig dazu, dass einzelne Kernsysteme am Ende doch wieder auf Passwörter angewiesen bleiben und die angestrebte vollständige Umstellung nie erreicht wird.

Ein fünfter, seltener diskutierter Fehler betrifft die Kommunikation zwischen Fachabteilung und IT-Sicherheit. Wenn die Entscheidung für ein Ökosystem allein in der IT-Abteilung fällt, ohne Rücksprache mit Datenschutz, Compliance oder Betriebsrat, tauchen Einwände häufig erst kurz vor dem geplanten Rollout auf und verzögern das Projekt um Wochen oder Monate. Ein kurzer, früh angesetzter Abstimmungstermin mit allen betroffenen Stellen kostet wenig Zeit, verhindert aber genau diese Art von Verzögerung, die in der Praxis deutlich teurer ist als die eigentliche technische Umsetzung.

Vor- und Nachteile im Überblick

Die folgende Gegenüberstellung fasst die zentralen Argumente aus den vorherigen Abschnitten zusammen, getrennt nach Anbieter, damit Entscheider die Kernpunkte ohne erneutes Lesen der Spezifikationstabelle abgleichen können.

Apple iCloud-Schlüsselbund

Vorteil: Enge Integration in Apple-Geräteflotten, starke Ende-zu-Ende-Verschlüsselung
Vorteil: Keine zusätzliche Lizenzgebühr für die Passkey-Funktion selbst
Nachteil: Granulare Conditional-Access-Logik fehlt gegenüber Entra ID
Nachteil: Cross-Device-Login außerhalb des Apple-Ökosystems erfordert zusätzliche Schritte

Google Password Manager

Vorteil: Breiteste Browser-/Plattformabdeckung durch Chrome
Vorteil: Einfache Verwaltung über Google Workspace ohne separate Zusatzkosten
Nachteil: Weniger differenzierte Enterprise-Richtlinien als Microsoft
Nachteil: Keine gesonderte, öffentlich belegte Deutschlandzahl zur Adoption verfügbar

Microsoft Entra ID / Authenticator

Vorteil: Umfangreichste native Richtliniensteuerung mit Conditional Access
Vorteil: Klar bezifferte Lizenzstufen (P1: 7 US-Dollar, P2: 10 US-Dollar pro Nutzer/Monat)
Nachteil: Zusätzliche Lizenzkosten für P1/P2, sofern nicht bereits in M365 E3/E5 enthalten
Nachteil: Komplexere Einrichtung durch Trennung von synchronisierten und gerätegebundenen Methoden

Für wen eignet sich welches Ökosystem? Sechs Empfehlungen

Die technischen Spezifikationen und Preise aus den vorherigen Abschnitten lassen sich zu sechs konkreten Einsatzempfehlungen verdichten. Sie ersetzen keine individuelle Risikoanalyse, geben aber eine belastbare erste Richtung vor, abgestimmt auf Unternehmensgröße, Gerätelandschaft und regulatorischen Kontext.

Kreativagenturen und Schulen mit reiner Apple-Flotte: iCloud-Schlüsselbund plus Apple Business Manager, geringster Verwaltungsaufwand.
Mittelständler mit Android- und Chrome-Schwerpunkt: Google Workspace plus Password Manager, kein separates Passkey-Budget nötig.
Konzerne mit Zero-Trust-Anspruch: Microsoft Entra ID P2, wegen Conditional Access und Authentication Strengths die differenzierteste Steuerung.
Hybride BYOD-Umgebungen: Plattformübergreifende FIDO2-Hardwareschlüssel als gemeinsamer Nenner, unabhängig vom primären Ökosystem.
E-Commerce mit hohem Login-Volumen: Orientierung am Dashlane-Befund zu Google, PayPal und Amazon, Passkey als bevorzugte, aber nicht einzige Option anbieten.
Regulierte Branchen mit BSI-Bezug: Kombination aus Entra-Richtlinien und zertifizierten FIDO2-Hardware-Keys statt reiner Cloud-Synchronisierung, um Nachweispflichten sauber zu erfüllen.

Diese Einteilung ist bewusst grob gehalten, in der Praxis setzen viele Unternehmen zwei Ökosysteme parallel ein, etwa Entra ID für die zentrale Richtliniensteuerung bei gleichzeitiger Nutzung von Apple-Geräten im Außendienst. Entscheidend ist weniger die Reinheit der Lösung als die Frage, ob am Ende jede Nutzergruppe eine klare, dokumentierte Fallback-Regel hat, statt stillschweigend auf das alte Passwort zurückzufallen.

Das Urteil: Welches Passkey-Ökosystem gewinnt 2026?

Eine pauschale Empfehlung für “den besten” Anbieter greift hier zu kurz, weil die Ausgangslage pro Unternehmen zu unterschiedlich ist. Für Apple-only-Umgebungen bleibt der iCloud-Schlüsselbund die reibungsloseste Lösung, ohne nennenswerte Zusatzkosten. Google Password Manager gewinnt überall dort, wo Android- und Chrome-Flotten dominieren und keine tiefe Identitäts-Governance gefordert ist. Microsoft Entra ID liegt bei der reinen Richtlinientiefe vorn, bezahlt das aber mit klar bezifferten 7 beziehungsweise 10 US-Dollar pro Nutzer und Monat für P1 und P2.

Die wichtigste Zahl für die Entscheidung ist aber keine Produktmetrik, sondern die 13-Prozent-Marke aus der zitierten Enterprise-Studie: Nur eine Minderheit der Unternehmen hat die Passkey-Einführung bislang tatsächlich skaliert, unabhängig vom gewählten Anbieter. Wer 2026 noch in der Pilotphase steckt, befindet sich damit in guter Gesellschaft, sollte den Rollout aber nicht beliebig verzögern. Die FIDO-Alliance-Zahl von 81 Prozent weniger loginbezogenen Helpdesk-Tickets zeigt, dass sich der Umstieg finanziell rechnet, sobald die skalierte Phase tatsächlich erreicht ist. Die Wahl zwischen Apple, Google und Microsoft ist am Ende weniger eine Sicherheitsfrage als eine Frage der bestehenden Geräte- und Identitätsinfrastruktur.

Für die DACH-Region kommt ein zusätzlicher Faktor hinzu: Wer ohnehin unter NIS2 oder vergleichbare Nachweispflichten fällt, sollte die Entscheidung nicht allein nach Lizenzkosten treffen. Die 7 beziehungsweise 10 US-Dollar pro Nutzer und Monat für Entra ID P1/P2 wirken im Vergleich zu kostenlosen Apple- oder Google-Lösungen zunächst teurer, amortisieren sich aber oft schon dadurch, dass Audits und Nachweisführung deutlich weniger manuellen Aufwand erfordern. Wer dagegen überwiegend Consumer-nahe oder kleine Teams betreut, fährt mit der kostenfreien Variante von Apple oder Google in aller Regel günstiger und ausreichend sicher.

Unabhängig von der Anbieterwahl bleibt ein Punkt konstant: Passkeys sind kein einmaliges Projekt, sondern eine laufende Betriebsaufgabe. Neue Mitarbeitende brauchen eine Ersteinrichtung, ausscheidende Mitarbeitende eine saubere Deaktivierung, und neue Anwendungen müssen in die bestehende Richtlinienlandschaft eingepasst werden. Unternehmen, die das von Anfang an als festen Bestandteil des Identitäts-Lifecycles einplanen statt als einmaliges IT-Projekt, vermeiden die meisten der oben beschriebenen typischen Fehler von vornherein.

Häufig gestellte Fragen zu Passkeys bei Apple, Google und Microsoft

Sind Passkeys bei Apple, Google und Microsoft gleich sicher?

Alle drei Anbieter bauen auf demselben FIDO2/WebAuthn-Standard auf und sind damit grundsätzlich phishing-resistent. Unterschiede entstehen nicht bei der Kryptografie selbst, sondern bei Synchronisierung, Recovery und zugelassenen Fallback-Methoden.

Kann ich einen Apple-Passkey auch für ein Microsoft-Konto nutzen?

Ja, sofern der verwendete Browser den iCloud-Schlüsselbund als Passkey-Provider zulässt. Die praktische Nutzerführung ist in solchen Mischszenarien aber weniger intuitiv als innerhalb eines einzelnen Ökosystems.

Was kostet die Einführung von Passkeys im Unternehmen?

Die Passkey-Funktion selbst ist bei Apple, Google und Microsoft kostenlos. Kosten entstehen auf der Verwaltungsebene, etwa für Microsoft Entra ID P1 (7 US-Dollar pro Nutzer/Monat) oder P2 (10 US-Dollar pro Nutzer/Monat), sofern diese nicht bereits in einem bestehenden Microsoft-365-Tarif enthalten sind.

Wie viele Unternehmen setzen 2026 bereits Passkeys ein?

Laut FIDO Alliance befinden sich 68 Prozent der befragten Organisationen im Einsatz, Pilot oder Rollout. Eine separate Studie mit 500 IT- und Security-Entscheidern fand jedoch nur bei 13 Prozent eine bereits vollständig skalierte Einführung.

Ersetzen Passkeys das Passwort vollständig?

In der Praxis noch nicht. Selbst bei Diensten mit hohem Passkey-Anteil wie Google (28 Prozent) oder PayPal (18 Prozent) laufen Passwort und Passkey laut Dashlane-Bericht weiterhin parallel.

Welches Ökosystem eignet sich für stark regulierte Branchen in Deutschland?

Microsoft Entra ID bietet mit Conditional Access und Authentication Strengths die differenzierteste Richtlinienlogik, was Nachweispflichten gegenüber Aufsichtsbehörden erleichtert. Eine Kombination mit zertifizierten FIDO2-Hardwareschlüsseln ist hier oft sinnvoller als reine Cloud-Synchronisierung.

Was passiert, wenn ich mein Smartphone mit Passkeys verliere?

Bei Apple und Google hängt die Wiederherstellung an der jeweiligen Konto- und Gerätesicherheit, also iCloud- beziehungsweise Google-Konto-Absicherung. Bei Microsoft Entra ID legen Administratoren die Recovery-Richtlinie selbst fest, was mehr Kontrolle, aber auch mehr Konfigurationsaufwand bedeutet.

Sind alle Passkey-Implementierungen offiziell FIDO-zertifiziert?

Nicht automatisch. FIDO-Zertifizierung bezieht sich auf konkrete Authenticator-, Client- oder Server-Komponenten, nicht pauschal auf eine Marke. Unternehmen mit Nachweispflichten sollten die jeweilige Komponente einzeln prüfen.

Lohnt sich der Umstieg auf Passkeys schon 2026 oder sollte man warten?

Die Daten sprechen für einen zeitnahen Start statt für Abwarten. Fünf Milliarden aktive Passkeys und eine Verdopplung der Authentifizierungen laut Infosecurity Magazine zeigen, dass der Standard etabliert ist. Da aber nur 13 Prozent der Unternehmen die Einführung bereits skaliert haben, bleibt ausreichend Zeit für eine sorgfältige Pilotphase, ein vollständiges Zuwarten verschiebt den mit 81 Prozent bezifferten Helpdesk-Entlastungseffekt jedoch nur unnötig weiter nach hinten.

Kann ich Apple, Google und Microsoft gleichzeitig im selben Unternehmen einsetzen?

Ja, und in gemischten Geräteflotten ist das sogar der Normalfall. Entscheidend ist eine zentrale Richtlinie, meist über Microsoft Entra ID, die festlegt, welche Passkey-Quelle für welche Anwendung akzeptiert wird. Ohne diese zentrale Steuerung entstehen leicht uneinheitliche Fallback-Regeln, die das eigentliche Sicherheitsniveau wieder senken.