Passkeys und Multi-Accounting: Isolierung der Schlüssel im Jahr 2026

Seit dem 1. September 2026 begann Microsoft, Passkeys als Standardanmeldemethode in Entra ID einzuführen, und ab dem 1. Februar 2027 werden die eigene SMS- und Sprachcode-Zustellung deaktiviert. Google hat Passkeys bereits im Oktober 2023 zur Hauptanmeldemethode für persönliche Konten gemacht. Für eine Person mit einem Konto ist das praktisch. Für diejenigen, die Dutzende von Konten im Antidetect führen, wird der Passkey leicht zu einem unsichtbaren Faden, der isolierte Profile miteinander verbindet. Im Folgenden erläutern wir, wie dies geschieht und wie man ein System aufbaut, in dem die Schlüssel nicht zwischen Konten „lecken“.

Warum die Frage gerade jetzt aufkam

Passkeys gibt es seit 2022, aber 2026 verwandelten sie sich von „kann aktiviert werden“ in „werden angefordert“. Drei konkrete Gründe:

Microsoft Entra ID. Ab September 2026 wird bei Benutzern, die sich per SMS oder Anruf anmelden, automatisch Passkeys aktiviert: Bei der nächsten MFA-Überprüfung wird die Möglichkeit angeboten, einen Schlüssel zu registrieren. Bis zum 31. Januar 2027 kann dies aufgeschoben werden, ab dem 1. Februar 2027 ist dies nicht mehr möglich. Microsoft führt als Begründung eine eigene Zahl an: Phishing-Kampagnen mit KI erhalten 54 % der Klicks im Vergleich zu 12 % bei normalen.
Google. Seit Oktober 2023 ist in persönlichen Konten standardmäßig die Option „Passworteingabe überspringen, wenn möglich“ aktiviert. Wenn ein Schlüssel erstellt wurde, bietet Google an, sich damit anzumelden.
Übertragung von Schlüsseln zwischen Managern. Die FIDO Alliance veröffentlichte den Standard Credential Exchange (Formate CXF und CXP). In iOS 26 und macOS 26 können Passkeys verschlüsselt zwischen Apple Passwords, 1Password, Bitwarden, Dashlane und anderen Anwendungen übertragen werden, ohne eine Datei zu exportieren. Der Schlüssel ist nicht mehr fest an einen Speicherort gebunden. Für Multi-Account-Management ist dies sowohl eine Möglichkeit als auch ein Risiko.

Wie Passkeys funktionieren und warum sie die Isolation von Profilen brechen

Ein Passkey ist ein Paar kryptografischer Schlüssel. Der öffentliche Schlüssel wird von der Website gespeichert, der private Schlüssel wird vom „Authenticator“ gespeichert. Der Schlüssel ist an die Domain gebunden (in der Spezifikation als rpId bezeichnet), daher kann eine Phishing-Website ihn nicht erhalten. Die Hauptfrage für Multi-Account-Management ist wo der private Schlüssel physisch gespeichert ist. Antidetect isoliert Cookies, localStorage, IndexedDB und Fingerabdrücke. Der Schlüssel-Speicher befindet sich oft außerhalb des Browserprofils:

Windows Hello speichert Schlüssel auf Kontoebene von Windows. Jeder Browser und jedes Profil unter diesem Konto greift auf denselben Speicher zu.
iCloud-Schlüsselbund auf macOS gehört zur Apple-ID. Chrome und Safari auf demselben Mac sehen denselben Satz von Schlüsseln.
Google Passwortmanager ist an das Google-Konto gebunden, in das der Browser oder das Telefon eingeloggt ist. Ein geschäftliches Google-Konto für zwanzig Profile ist ein gemeinsamer Tresor.
Manager-Erweiterungen (Bitwarden, 1Password und andere) speichern Schlüssel im Speicher ihres Kontos. Ein Speicher für alle Profile funktioniert wie ein einziger Punkt, über den alles sichtbar ist.

Hieraus ergibt sich ein typisches Problem. Sie klicken auf „Mit Passkey anmelden“ im Profil des Kontos Nr. 7, und das System zeigt die Schlüssel der Konten Nr. 3 und Nr. 12 auf derselben Website an. Die Website sieht diese Liste nicht: Sie erhält nur den ausgewählten Schlüssel. Aber ein falscher Klick — und Konto Nr. 3 wird aus dem Profil, der IP und dem Fingerabdruck des Kontos Nr. 7 angemeldet. Diese Verbindung kann nicht mehr rückgängig gemacht werden.

Was die Website bei der Anmeldung mit Passkey tatsächlich erfährt

Passkeys heben das Risiko-Scoring nicht auf, sie ersetzen einfach das Passwort. Bei der Anmeldung sieht die Plattform weiterhin die IP, den Fingerabdruck des Browsers und die Sitzungshistorie. Außerdem erhält sie einige eigene WebAuthn-Signale:

Schlüssel-ID (credential ID). Sie ist einzigartig für das Paar „Konto — Authenticator“.
AAGUID — Identifikator des Authenticator-Modells. Anhand dieses Identifikators signieren Websites wie Google den Schlüssel in den Kontoeinstellungen: „erstellt im iCloud-Schlüsselbund“, „im Google Passwortmanager“ usw. Dies ist keine eindeutige Nummer Ihres Geräts, sondern ein weiteres Merkmal, das mit der Legende des Profils übereinstimmen sollte.
Flags BE und BS (Backup-Berechtigung und Backup-Zustand) zeigen an, ob dieser Schlüssel synchronisiert oder an das Gerät gebunden ist.

Fazit: Ein „mobiles“ Profil, das sich mit einem Schlüssel aus Windows Hello anmeldet, sieht genauso unlogisch aus wie ein iPhone mit der Zeitzone von Brasilien und einer IP aus Deutschland. Der Schlüssel muss mit derselben Legende übereinstimmen wie der Proxy und der Fingerabdruck.

Schritt-für-Schritt-Schema: ein Konto — ein Profil — ein Speicher — eine IP

Führen Sie eine Bestandsaufnahme durch. Notieren Sie die Plattformen, auf denen Ihre Konten bereits Passkeys haben oder die Möglichkeit zur Erstellung angeboten wurde: Google, Microsoft, große Marktplätze und soziale Netzwerke. In den Sicherheitseinstellungen jedes Kontos ist sichtbar, wie viele Schlüssel registriert sind und wo sie erstellt wurden. Alle unerwarteten Einträge „Windows Hello“ und „iCloud-Schlüsselbund“ sind Kandidaten für die Löschung.
Deaktivieren Sie die systemweite Speicherung von Schlüsseln für Arbeitsprofile. Deaktivieren Sie im Browser, in dem die Profile arbeiten, das Speichern von Passwörtern und Passkeys im integrierten Manager. Erstellen Sie auf dem Arbeitsgerät keine Schlüssel in Windows Hello oder im iCloud-Schlüsselbund. Wenn das Fenster zur Erstellung eines Schlüssels „dieser Computer“ anbietet, wählen Sie eine andere Methode.
Wählen Sie einen Speicher für jedes Konto. Die Regel ist einfach: Der Speicher sollte genauso getrennt sein wie die Profile. Optionen:
- ein separater Speicher des Passwortmanagers für jedes Konto oder für eine Gruppe von Konten eines Kunden;
- ein Hardware-Schlüssel (FIDO2) für die wertvollsten Konten;
- für die Automatisierung — ein Software-Authenticator, dazu mehr in Schritt 6.
Ein gemeinsamer Speicher für alle ist die häufigste Methode, um Konten miteinander zu verbinden.
Registrieren Sie den Schlüssel nur aus dem „einheimischen“ Profil. Dasselbe Profil, derselbe Fingerabdruck, derselbe Proxy mit fester Sitzung, dasselbe Geo, wie bei der normalen Arbeit des Kontos. Die Registrierung eines Schlüssels ist eine sensible Aktion, und die Plattformen beobachten sie genau. Ein IP-Wechsel während des Verfahrens führt häufig zu einer zusätzlichen Überprüfung. Wie man eine Adresse für ein Profil hält, haben wir ausführlich im Artikel Sticky-Sitzung oder Rotation für das Antidetect-Profil behandelt.
Hinterlassen Sie einen Backup-Zugang. Ein verlorener Speicher bedeutet ein verlorenes Konto. Für jedes Konto ist eine zweite Anmeldemethode erforderlich: ein zweiter Passkey in einem anderen Speicher, ein Passwort mit TOTP oder Wiederherstellungscodes, die getrennt vom Schlüssel aufbewahrt werden. Microsoft verlangt in Entra ausdrücklich, dass Benutzer bis Februar 2027 auf phishing-resistente Methoden umgestellt werden. Warten Sie nicht, bis das Registrierungsfenster nicht mehr geschlossen werden kann.
Verwenden Sie in der Automatisierung einen virtuellen Authenticator. Im Chrome DevTools-Protokoll gibt es die Domain WebAuthn. Die Methode addVirtualAuthenticator erstellt einen Software-Authenticator mit dem Protokoll ctap2 und dem Transport internal (plattformbasiert) oder usb/hybrid. Die Parameter hasResidentKey und hasUserVerification aktivieren die Speicherung des Schlüssels im Authenticator und die Benutzerüberprüfung. getCredentials gibt nach der Registrierung den Schlüssel vollständig zurück: credentialId, rpId, userHandle, signCount und den privaten Schlüssel im PKCS#8-Format. addCredential legt ihn beim nächsten Start wieder zurück. So entsteht ein Schlüssel, der nur in Ihrem geheimen Speicher lebt und mit der Sitzung eines bestimmten Kontos verbunden ist. Zwei Vorbehalte: Die Domain ist als experimentell gekennzeichnet und wurde zum Testen von WebAuthn erstellt, und der exportierte private Schlüssel ist ein Passwortniveau-Geheimnis, das entsprechend aufbewahrt werden muss.
Übertragen Sie Schlüssel über Credential Exchange, nicht manuell. Wenn Sie den Manager wechseln oder Konten auf verschiedene Speicher verteilen, verwenden Sie den integrierten Export nach dem FIDO-Standard: Er wird in Apple Passwords, 1Password, Bitwarden, Dashlane, DuckDuckGo, Devolutions unterstützt. Beachten Sie, dass einige Anwendungen diesen Mechanismus auf macOS noch nicht implementiert haben.

Fallstricke

Standardmäßige Synchronisierung. Ein Schlüssel, der „auf diesem Gerät“ erstellt wurde, kann sofort in die iCloud oder Google-Cloud hochgeladen werden und auf allen Geräten dieses Kontos erscheinen, einschließlich Ihres persönlichen Telefons.
Cross-Device-Anmeldung über QR. Das Szenario „Scannen Sie den QR-Code mit dem Telefon“ (Transport hybrid) verbindet ein echtes Telefon mit seinen Schlüsseln mit der Sitzung des Profils. Für Arbeitsprofile ist dies eine zusätzliche Verbindung.
Der gleiche AAGUID für die gesamte Farm ist normal. Millionen von Menschen verwenden denselben Manager. Gefährlich ist nicht der gleiche Anbieter, sondern der gemeinsame Schlüssel oder der gemeinsame Speicher.
Passkey heilt nicht den „schmutzigen“ Zugang. Wenn ein Konto sich mit einer IP anmeldet, die bereits bei benachbarten Konten sichtbar war, oder von einem Rechenzentrum, das die Plattform nicht mag, hilft starke Kryptografie nicht. Das Risiko wird anhand einer Kombination von Signalen bewertet.
Der zweite Faktor muss ebenfalls isoliert werden. Wenn der Backup-Zugang TOTP ist, werden die Geheimnisse ebenfalls auf die Konten verteilt und nicht in einer einzigen Anwendung auf dem persönlichen Telefon aufbewahrt. Wie man 2FA und Proxy verbindet, haben wir im Artikel zur Zwei-Faktor-Authentifizierung bei der Arbeit über Proxy behandelt.

Welcher Proxy benötigt wird und warum

Für den Zugang über den Schlüssel ist Beständigkeit am wichtigsten: Das Konto muss den Schlüssel registrieren und sich dann aus demselben Netzwerk, im selben Geo anmelden. Daher:

Web-Profile im Antidetect — residente Proxys mit fester Sitzung im Land des Kontos. Dies sind Adressen von lokalen Anbietern, und sie stimmen mit der Legende „normaler Benutzer zu Hause“ überein.
Mobile Plattformen und Konten mit mobiler Legende — mobile Proxys. Ein mobiles Profil, das einen Schlüssel aus einem Heimnetzwerk an einem anderen Ende des Landes registriert, weicht von seiner Geschichte ab.
Rotation bei jeder Anfrage ist geeignet für das Parsen, aber nicht für den Zugang zu Konten. Stellen Sie einen Pufferzeitraum für die gesamte Arbeitssitzung ein.

Fazit

Passkeys machen den Zugang phishing-resistent, verschieben jedoch den Verbindungspunkt zwischen Konten von Cookies und Passwörtern in den Schlüssel-Speicher. Dieser Punkt befindet sich oft außerhalb des Antidetect-Profils: in Windows Hello, iCloud, Google-Konto oder gemeinsamem Speicher des Managers. Das Arbeitschema sieht so aus: Jedes Konto hat sein eigenes Profil, seinen eigenen Schlüssel-Speicher, seine eigene feste IP und eine Backup-Anmeldemethode. Für die Automatisierung gibt es einen virtuellen Authenticator im CDP. Kümmern Sie sich darum, bevor Microsoft im Februar 2027 die Registrierung nicht mehr aufschiebt. Danach müssen Sie sich in Eile und direkt an aktiven Konten damit befassen.