Kann ein YubiKey auf einem Remote Mac verwendet werden? 2026 Anmeldelösung für digitale Nomaden

Der Browser auf dem Remote Mac fordert einen Sicherheitsschlüssel an, aber der YubiKey am iPad reagiert nicht.

Schnellste Lösung: Ein YubiKey kann Konten schützen, die auf einem Remote Mac genutzt werden. Er wird jedoch nicht automatisch aus der Remote-Sitzung erkannt. Die lokale Authentifizierung oder die Bestätigung über ein vertrauenswürdiges Gerät bleibt der Standard, bis die konkrete Weiterleitung vollständig geprüft wurde.

Dieser Leitfaden richtet sich an:

• Remote-Arbeiter, die einen YubiKey für Apple Account, Code-Repositories oder Kundenportale einsetzen.
• Digitale Nomaden, die nur ein iPad, Chromebook oder Windows-Notebook mitnehmen.
• Freie Entwickler, die starke Anmeldung, unbeaufsichtigten Zugriff und Kontowiederherstellung gleichzeitig planen müssen.

Letzte Aktualisierung: 06.09.2026. Die Aussagen wurden anhand der Apple-Supportdokumentation zu Sicherheitsschlüsseln, der WebAuthn-Spezifikation des W3C, der Yubico-Dokumentation zu CTAP sowie der offiziellen Hinweise zu Browsern und WebAuthn-Weiterleitung geprüft. Die konkrete Unterstützung bleibt client- und dienstabhängig.

[ SECTION_01 ] Der entscheidende Prüfpunkt liegt vor dem Remote Mac

Ein YubiKey ist kein allgemeiner Eingabestift, der durch jede Remote-Verbindung gereicht wird. Bei WebAuthn kommunizieren Browser, Client und Authenticator in einer bestimmten Kette. Der Browser, der die Anmeldung startet, entscheidet daher wesentlich darüber, wo die Sicherheitsabfrage erscheint.

Wird die Anmeldeseite im lokalen Browser des iPad geöffnet, spricht dieser Browser mit dem lokalen Authenticator. Wird die Seite dagegen im Browser des Remote Mac geöffnet, muss der Remote-Client die Authentifizierungsanfrage ausdrücklich an das lokale Gerät weiterreichen. Eine sichtbare Mausbewegung oder eine funktionierende Tastatur beweist diese Fähigkeit nicht.

Das WebAuthn Level 3 des W3C berücksichtigt Weiterleitungsfälle im Umfeld von Remote Desktop. Daraus folgt jedoch nicht, dass jeder VNC-Client, jede Webkonsole und jeder Browser diese Funktion umgesetzt hat. Die Yubico-Hinweise zur Browserunterstützung sind deshalb nur ein Teil der Prüfung. Der konkrete Remote-Client muss ebenfalls dokumentierte Unterstützung bieten.

Fehlerbild und Beobachtung trennen

Bei einer blockierten Anmeldung sollte die Prüfung nicht mit dem Austausch des YubiKeys beginnen. Zuerst wird festgehalten:

• Wo wurde die Login-Seite geöffnet?
• Welcher Browser erzeugte die Sicherheitsabfrage?
• Wo erschien die Touch- oder USB-Anforderung?
• Reagierte der lokale Schlüssel oder ein Schlüssel am Remote Mac?
• Was passierte nach einer erneuten Verbindung?

Ein erfolgreicher Login auf einer lokalen Webseite sagt nichts über den Browser im Remote Mac aus. Umgekehrt kann ein Remote-Dienst eine Weiterleitung unterstützen, während ein bestimmtes Code-Repository oder Kundenportal zusätzliche Richtlinien erzwingt.

[ SECTION_02 ] Erste Diagnose: WebAuthn findet an einem bestimmten Gerät statt

WebAuthn ist nicht gleichbedeutend mit „YubiKey am Reisegerät“. Der Authenticator kann lokal verbunden sein, über NFC angesprochen werden oder durch eine vom Client unterstützte Weiterleitung erreichbar sein. Die CTAP-Erklärung von Yubico beschreibt dabei die Protokollseite zwischen Client und Authenticator, nicht die automatische Kompatibilität jedes Remote-Produkts.

Für eine belastbare Diagnose werden dasselbe Konto und derselbe Dienst in zwei getrennten Durchläufen verwendet:

1. Die Anmeldeseite wird im lokalen Browser des iPad oder Notebooks geöffnet.
2. Danach wird dieselbe Seite im Browser des Remote Mac geöffnet.
3. Für jeden Durchlauf werden Browser, Gerät und Verbindungsmethode notiert.
4. Die Stelle der Touch-Bestätigung wird dokumentiert.
5. Nach einer Trennung der Sitzung wird die Anmeldung erneut ausgeführt.

Die Ergebnisse fallen typischerweise in drei Gruppen:

• Lokal erfolgreich, remote ohne Reaktion: Der Remote-Browser kann den lokalen Authenticator wahrscheinlich nicht erreichen.
• Remote mit ausdrücklicher Weiterleitung erfolgreich: Die Funktion kann verwendet werden, muss aber nach Neustart, Sitzungsabbruch und Clientwechsel erneut geprüft werden.
• Beide Wege scheitern: Der Dienst, das Konto, der Browser oder der Schlüssel benötigt eine getrennte Fehleranalyse.

Hinweis: Ein Remote Desktop überträgt nicht automatisch USB-, NFC- oder WebAuthn-Signale. Behandeln Sie Hardwareweiterleitung als eigene Funktion mit eigener Freigabe und eigenem Test.

[ SECTION_03 ] Apple Account, WebAuthn und SSH dürfen nicht vermischt werden

Die Bezeichnung „YubiKey-Anmeldung“ umfasst mehrere technisch unterschiedliche Arbeitsabläufe. Ein Erfolg bei einem Dienst ist deshalb kein Beweis für alle anderen Aufgaben.

Apple Account benötigt einen eigenen Wiederherstellungsplan

Apple beschreibt Sicherheitsschlüssel für den Apple Account als zusätzliche starke Anmeldekomponente. Bei einem neuen Gerät oder einer neuen Web-Anmeldung kann neben dem physischen Schlüssel auch ein bereits vertrauenswürdiges Apple-Gerät relevant sein. Die offizielle Apple-Anleitung zu Sicherheitsschlüsseln nennt außerdem Grenzen für Wiederherstellung und Ersatzschlüssel.

Vor einer Reise wird daher geprüft:

• Ist der Remote Mac bereits beim Apple Account angemeldet?
• Ist das mitgeführte iPhone oder iPad weiterhin als vertrauenswürdiges Gerät verfügbar?
• Befindet sich ein Ersatzschlüssel außerhalb derselben Tasche?
• Kann die Bestätigung lokal durchgeführt werden, falls der Remote-Browser blockiert?
• Wird eine Kontoeinstellung gerade in einer nicht verifizierten Sitzung geändert?

Wenn der Remote Mac bereits angemeldet ist und nur eine lokale Kontobestätigung fehlt, ist die lokale Bestätigung meist der kontrollierbare Weg. Wenn sowohl der Schlüssel als auch das vertrauenswürdige Gerät fehlen, sollte keine wichtige Kontosicherheitsänderung aus einer improvisierten Sitzung heraus gestartet werden.

WebAuthn muss pro Dienst geprüft werden

Code-Repository, E-Mail-Konto und Kundenportal können unterschiedliche Richtlinien verwenden. Einige erlauben mehrere Sicherheitsschlüssel, andere verlangen eine bestimmte Anmeldemethode oder unterbinden bestimmte Browserpfade.

Deshalb wird jeder wichtige Dienst separat geprüft:

• Browser und Version dokumentieren.
• Lokales Eingabegerät festhalten.
• Browser auf dem Remote Mac getrennt testen.
• Touch-Bestätigung und sichtbare Systemmeldung notieren.
• Verhalten nach Sitzungsabbruch testen.
• Einen genehmigten Ersatzweg dokumentieren.

Die Microsoft-Dokumentation zur WebAuthn-Weiterleitung in virtuellen Sitzungen zeigt, dass solche Funktionen ausdrücklich konfiguriert und unterstützt werden müssen. Dieser Hinweis darf nicht als Freigabe für einen beliebigen VNC- oder Webkonsolen-Zugang verstanden werden.

SSH und Git-Signaturen bilden eine andere Kette

Bei SSH kann der private Schlüssel auf dem lokalen Gerät, auf dem Remote Mac oder in einem zugelassenen Agent-Setup verwendet werden. Bei Git-Signaturen kommt zusätzlich die Signaturfunktion hinzu. Eine erfolgreiche WebAuthn-Anmeldung im Browser beweist daher nicht, dass ein SSH-Schlüssel verfügbar ist.

Für die Remote-Entwicklung werden diese Zustände getrennt kontrolliert:

• Der SSH-Aufruf funktioniert bei bestehender Sitzung.
• Der Schlüssel bleibt nach einer erneuten Anmeldung erreichbar.
• Ein Neustart verändert die Zugriffskette nicht unbemerkt.
• Eine Agent-Weiterleitung ist organisatorisch erlaubt.
• Die Git-Signatur verwendet tatsächlich den vorgesehenen Schlüssel.
• Kunden- und Unternehmensregeln werden eingehalten.

Die GitHub-Anleitung zu geschützten Konten und SSH sowie die Dokumentation zur SSH-Schlüsselerzeugung behandeln diese Wege getrennt. Für ein Kundenprojekt sollte nur die von der Organisation genehmigte Architektur eingesetzt werden.

[ SECTION_04 ] Zweite Diagnose: Das Gerät unterwegs ändert die Vertrauenskette

Ein iPad, ein Windows-Notebook und ein geliehenes Gerät sind nicht austauschbar. USB-Anschluss, NFC-Unterstützung, Browserrechte, lokale Richtlinien und die Fähigkeit zur WebAuthn-Weiterleitung können sich unterscheiden.

Ein realistischer Reisetest umfasst daher mehrere Situationen:

1. Anmeldung mit dem Hauptgerät und lokalem Browser.
2. Anmeldung mit dem iPad und der vorgesehenen Remote-App.
3. Wechsel auf ein leichtes Notebook in einem fremden Netzwerk.
4. Erneute Verbindung nach einem Sitzungsabbruch.
5. Zugriff mit nur einem Telefon und einem Ersatzschlüssel.
6. Neustart des Remote Mac und erneute Anmeldung.

Die Frage lautet nicht nur „funktioniert der YubiKey?“. Entscheidend ist: Welcher Teil der Arbeitsumgebung bleibt zugänglich, wenn genau dieses Gerät oder dieser Anmeldeweg ausfällt?

Ein temporäres Gerät ohne bestätigte starke Authentifizierung sollte als ungeeignet oder höchstens als lesender Notzugang markiert werden. Ein lokaler Login, der den Schlüssel zuverlässig erkennt, kann dagegen der bevorzugte Einstieg sein. Danach wird die Arbeitssitzung auf dem Remote Mac fortgesetzt.

[ SECTION_05 ] Entscheidungslogik für die Wahl des Anmeldewegs

Die folgende Bedingungsliste dient als operative Entscheidungshilfe:

• Wenn der lokale Browser den YubiKey erkennt, der Dienst die lokale Anmeldung erlaubt und der Remote Mac anschließend erreichbar ist, dann wählen Sie lokale Authentifizierung als Standard.
• Wenn der Browser auf dem Remote Mac die Anfrage erzeugt, der Client die WebAuthn-Weiterleitung offiziell unterstützt und die Prüfung nach Trennung und Neustart wiederholbar erfolgreich ist, dann kann die Weiterleitung als Hauptweg eingesetzt werden.
• Wenn der lokale Login funktioniert, die Weiterleitung aber keine Reaktion zeigt, dann authentifizieren Sie lokal und verwenden den Remote Mac erst danach.
• Wenn Apple Account eine Bestätigung verlangt, aber weder der Schlüssel noch ein vertrauenswürdiges Gerät verfügbar ist, dann pausieren Sie Kontosicherheitsänderungen und nutzen den dokumentierten Wiederherstellungsweg.
• Wenn SSH oder Git-Signaturen nur über eine nicht genehmigte Agent-Weiterleitung funktionieren, dann fällt dieser Weg für Kunden- und Unternehmensarbeit aus.
• Wenn ein Schlüssel verloren wurde, dann verwenden Sie Ersatzschlüssel und vertrauenswürdige Geräte gemäß dem jeweiligen Dienst, statt Sicherheitskontrollen zu umgehen.

[ SECTION_06 ] FAQ: Die häufigsten Fälle unterwegs

Erkennt ein Remote Desktop einen lokal eingesteckten YubiKey?

Nicht automatisch. Eine Remote-Sitzung kann Maus- und Tastatureingaben übertragen, ohne USB-, NFC- oder WebAuthn-Signale weiterzugeben. Der lokale Browser und der Browser auf dem Remote Mac werden deshalb getrennt getestet. Erst eine dokumentierte, wiederholbare Weiterleitung nach Sitzungsabbruch und Neustart rechtfertigt die Einstufung als regulärer Anmeldeweg.

Wie verwendet ein iPad einen YubiKey mit einem Remote Mac?

Zunächst wird die Anmeldung im lokalen iPad-Browser geprüft. Erscheint die Anmeldeseite im Remote-Browser, muss der konkrete Client WebAuthn-Weiterleitung unterstützen. USB und NFC werden nicht als gleichwertig angenommen. Entscheidend sind die sichtbare Touch-Anforderung, der Ort der Bestätigung und das Ergebnis nach einer erneuten Verbindung.

Was tun, wenn der Apple Account den Sicherheitsschlüssel nicht findet?

Der Status des Remote Mac, das vertrauenswürdige iPhone oder iPad und der Ersatzschlüssel werden zuerst geprüft. Ist eine lokale Bestätigung möglich, sollte sie dort erfolgen. Wenn kein vertrauenswürdiges Gerät und kein gültiger Schlüssel verfügbar sind, werden Kontoeinstellungen nicht aus einer blockierten Remote-Sitzung heraus verändert. Stattdessen wird die offizielle Wiederherstellung verwendet.

Wie wird ein YubiKey bei SSH für Remote-Entwicklung eingesetzt?

SSH wird getrennt von WebAuthn geprüft. Der private Schlüssel kann lokal, auf dem Remote Mac oder über eine freigegebene Agent-Struktur liegen. Nach Verbindungstrennung, Neustart und erneuter Anmeldung muss derselbe Zugriff weiterhin funktionieren. Bei Kundenprojekten entscheidet die Sicherheitsrichtlinie des Auftraggebers, nicht die technische Bequemlichkeit.

Wie lässt sich ein verlorener YubiKey auf Reisen auffangen?

Vor der Abreise werden Ersatzschlüssel, vertrauenswürdige Geräte und Wiederherstellungscodes nach den Regeln des jeweiligen Dienstes geprüft. Ein Schlüssel sollte nicht die einzige Zugangsmöglichkeit sein. Nach Verlust wird der betroffene Schlüssel ersetzt oder entfernt. Ein geliehenes Gerät ohne geprüfte starke Anmeldung wird nicht als vollwertiger Ersatz behandelt.

[ SECTION_07 ] Drei Vergleichstabellen für die Reiseplanung

Authentifizierungsaufgabe	Wo die Anmeldung typischerweise entsteht	Was der YubiKey-Test zeigen muss	Bevorzugter Rückfall
WebAuthn im lokalen Browser	iPad oder leichtes Notebook	Lokale Touch-Bestätigung und erfolgreicher Login	Zweites vertrauenswürdiges Gerät
WebAuthn im Remote-Browser	Remote Mac	Dokumentierte Weiterleitung und wiederholbare Bestätigung	Lokale Anmeldung vor dem Remote-Zugriff
Apple Account	Remote Mac, lokale Apple-Seite oder neues Gerät	Status des vertrauenswürdigen Geräts und Schlüsselanforderung	Lokales iPhone oder iPad
SSH	Lokales Gerät oder Remote Mac	Tatsächliche Position des privaten Schlüssels	Genehmigter lokaler Schlüsselweg
Git-Signatur	Entwicklungsumgebung auf dem Remote Mac	Signatur mit dem vorgesehenen Schlüssel	Freigegebener alternativer Signaturpfad

Eingangssituation	Erwartbare Stärke der Prüfung	Einstufung für produktive Arbeit
iPad mit lokalem Browser und erkanntem Schlüssel	Hohe Nachvollziehbarkeit, weil der Authenticator lokal angesprochen wird	Geeignet, sofern der Dienst diesen Browser unterstützt
Windows-Notebook mit lokalem Browser	Abhängig von Anschluss, Treiber, Browser und Dienst	Nach erfolgreichem Diensttest geeignet
Remote-Browser ohne bestätigte Weiterleitung	Hardwarepfad bleibt unklar	Nicht als Hauptweg einsetzen
Geliehenes Notebook ohne eigenen Schlüssel	Wiederherstellung und Kontoschutz sind unsicher	Nur für unkritische oder lesende Aufgaben
Nur Telefon und Ersatzschlüssel	Kann für Bestätigung genügen, ersetzt aber nicht jeden Arbeitsclient	Als Notfallpfad prüfen

Bedingung	Entscheidung	Nächste Handlung
Lokale Anmeldung erfolgreich, Remote-Anmeldung nicht reproduzierbar	Lokale Authentifizierung wählen	Danach Remote Mac öffnen
Weiterleitung offiziell unterstützt und nach Neustart erfolgreich	Remote-Weiterleitung möglich	Ersatzweg trotzdem dokumentiert lassen
Apple Account verlangt Bestätigung, vertrauenswürdiges Gerät verfügbar	Lokal bestätigen	Kontoänderung erst danach fortsetzen
SSH funktioniert nur mit ungeprüfter Agent-Weiterleitung	Nicht für geschützte Arbeit verwenden	Genehmigte Architektur einrichten
Hauptschlüssel verloren, Ersatzweg geprüft	Wiederherstellung starten	Betroffenen Schlüssel nach Dienstregeln ersetzen
Kein Schlüssel und kein vertrauenswürdiges Gerät verfügbar	Zugriff als gefährdet behandeln	Offizielle Kontowiederherstellung nutzen

Diese Bewertungen sind keine Herstellerzertifizierung. Sie helfen nur dabei, eine konkrete Zugangskette sichtbar zu machen. Die Prüfung muss mit dem tatsächlich verwendeten Browser, Remote-Client und Dienst erfolgen.

[ SECTION_08 ] Sechs Schritte für eine belastbare Abnahme

Schritt eins: Konten nach Risiko sortieren

Beginnen Sie mit dem Apple Account, dem wichtigsten Code-Repository und dem kritischsten Kundenportal. Ein einzelner Demo-Dienst reicht nicht aus. Für jedes Konto werden primärer Login, Ersatzweg und zuständige Sicherheitsrichtlinie festgehalten.

Schritt zwei: Den Authentifizierungsort markieren

Notieren Sie, ob die Seite im lokalen Browser oder im Browser des Remote Mac geöffnet wird. Diese Unterscheidung gehört in die Dokumentation, bevor der YubiKey eingesteckt wird.

Schritt drei: Die lokale Kette prüfen

Testen Sie den Schlüssel lokal. Dabei werden Browser, Anschluss oder NFC, Touch-Bestätigung und Login-Ergebnis notiert. Falls der Dienst bereits lokal scheitert, ist die Remote-Verbindung nicht die erste Fehlerquelle.

Schritt vier: Den Remote-Weg separat prüfen

Öffnen Sie denselben Dienst im Remote-Browser. Achten Sie darauf, ob überhaupt eine Hardwareanforderung erscheint. Keine Reaktion bedeutet nicht automatisch einen defekten Schlüssel. Häufig fehlt lediglich die Weiterleitung zwischen Browser und lokalem Authenticator.

Schritt fünf: Neustart und Sitzungsabbruch simulieren

Trennen Sie die Remote-Sitzung kontrolliert und melden Sie sich erneut an. Danach wird der Remote Mac neu gestartet, sofern der Arbeitsablauf dies erlaubt. Für SSH und Git wird zusätzlich geprüft, ob Schlüssel und Signatur nach der erneuten Anmeldung wieder verfügbar sind.

Schritt sechs: Wiederherstellung praktisch ausführen

Nutzen Sie den Ersatzschlüssel oder das vertrauenswürdige Gerät in einer kontrollierten Prüfung. Dokumentieren Sie die benötigten Bedingungen, nicht eine pauschale Wiederherstellungsdauer. Anschließend wird entschieden, ob ein Reisegerät produktiv, nur lesend oder gar nicht verwendet werden darf.

[ SECTION_09 ] Wann ein gemieteter Remote Mac die bessere Arbeitsbasis ist

Ein selbst verwalteter Mac kann langfristig sinnvoll sein, wenn eine feste Person dauerhaft darauf arbeitet, physischer Zugriff möglich ist und Ersatzgerät sowie Wiederherstellung bereits organisiert sind. Für digitale Nomaden entstehen jedoch oft drei konkrete Nachteile: Der eigene Mac muss transportiert werden, ein Verlust unterbricht den lokalen Arbeitsweg, und ein unbeaufsichtigter Host benötigt zusätzlich getestete Wiederherstellungs- und Zugangswege.

Eine Remote-Umgebung von NOVAKVM kann hier als zeitlich begrenzte Prüfstrecke dienen. Die Entscheidung sollte nicht mit dem Einrichten von Kundendaten beginnen. Zuerst werden Apple Account, WebAuthn, SSH, Neustart und Ersatzweg mit einem unkritischen Projekt geprüft. Informationen zu einem Remote Mac für flexible Arbeitsumgebungen können anschließend mit der vorhandenen Eigenlösung verglichen werden. Wer einen festen Standort und eine eigene Hardwarebasis bevorzugt, kann dagegen die Optionen für einen Mac mini mit langfristiger Nutzung prüfen.

Für einen kurzfristigen Aufenthalt, einen Gerätewechsel oder eine Reise ohne eigenes MacBook ist die sinnvollere Reihenfolge klar: Zugangskette testen, Wiederherstellung durchführen, erst danach Kundenprojekte übernehmen. So bleibt der YubiKey ein kontrollierter Sicherheitsfaktor und wird nicht zum einzigen Punkt, an dem die gesamte Arbeitsumgebung hängt.

Häufige Fragen

Erkennt ein Remote Desktop einen YubiKey, der am lokalen Gerät steckt?

Nicht automatisch. Eine Remote-Sitzung überträgt Maus- und Tastatureingaben, aber damit ist keine Weiterleitung des Hardware-Authenticators bewiesen. Prüfen Sie, ob der lokale Browser oder der Browser auf dem Remote Mac die WebAuthn-Anfrage erzeugt. Nur wenn der verwendete Client die betreffende Weiterleitung offiziell unterstützt und der Test erfolgreich ist, darf dieser Weg als regulärer Anmeldepfad gelten.

Wie lässt sich ein iPad mit einem Remote Mac und einem YubiKey sinnvoll verbinden?

Führen Sie die Anmeldung zunächst im lokalen Browser des iPad durch, wenn der Dienst dies unterstützt. Öffnet sich die Anmeldeseite dagegen im Browser des Remote Mac, muss der Remote-Client den Authenticator ausdrücklich weiterreichen. Testen Sie USB, NFC, die Position der Touch-Bestätigung und eine erneute Verbindung getrennt. Ohne reproduzierbares Ergebnis bleibt die lokale Anmeldung der sichere Standard.

Was hilft, wenn der Apple Account auf dem Remote Mac den Sicherheitsschlüssel nicht findet?

Kontrollieren Sie zuerst, ob der Remote Mac bereits als vertrauenswürdiges Gerät angemeldet ist und ob ein iPhone oder iPad für die Bestätigung verfügbar bleibt. Halten Sie den Ersatzschlüssel bereit. Ändern Sie die Sicherheitskonfiguration nicht aus einer blockierten Sitzung heraus. Wenn die lokale Bestätigung funktioniert, erledigen Sie sie dort und kehren erst danach zum Remote Mac zurück.

Wie funktioniert ein YubiKey für SSH bei der Remote-Entwicklung?

SSH, Git-Signaturen und WebAuthn verwenden nicht automatisch dieselbe Authentifizierungskette. Prüfen Sie, ob der private Schlüssel am lokalen Gerät, auf dem Remote Mac oder über eine genehmigte Agent-Weiterleitung verwendet wird. Testen Sie außerdem Trennung, Neustart und erneute Anmeldung. Für Kunden- oder Unternehmenssysteme gilt ausschließlich die freigegebene Architektur; eine Umgehung von Richtlinien ist keine Wiederherstellungslösung.

Wie bleibt der Zugang erhalten, wenn der YubiKey auf einer Reise verloren geht?

Verlassen Sie sich nicht auf einen einzelnen Schlüssel. Vor der Reise müssen ein Ersatzschlüssel, ein noch vertrauenswürdiges Gerät und ein dokumentierter Wiederherstellungsweg geprüft werden. Markieren Sie temporäre Geräte ohne starke Authentifizierung als ungeeignet oder nur lesend. Nach einem Verlust sperren oder ersetzen Sie den betroffenen Schlüssel gemäß den Regeln des jeweiligen Dienstes und ändern nicht unkontrolliert mehrere Sicherheitsfaktoren gleichzeitig.