Altes Vertrauen zuerst entziehen
Die Sperraktion führt Widerruf, CRL-Veröffentlichung und Bereinigung der betroffenen Verzeichniszuordnungen aus – ohne Zugriff auf den verlorenen YubiKey.
PIV ATTESTATION & SELF-SERVICE
YubiKey auf Reisen verloren. Der kontrollierte Identitäts-Lifecycle läuft weiter.
Zuerst entzieht x.ID dem verlorenen YubiKey das Vertrauen: Zertifikate widerrufen, CRL veröffentlichen, AD/LDAP und Entra bereinigen. Anschließend nimmt der Benutzer über den genehmigten Recovery-Weg einen neuen YubiKey auf – mit neuen hardwaregebundenen Schlüsseln und sicherer Anmeldung.
NUTZEN IN 30 SEKUNDEN
Altes Vertrauen entziehen. Sicher wieder arbeiten.
Ersatzhardware nachweisen
PIV Attestation und Policy prüfen, ob der neue Schlüssel die geforderten Hardwarenachweise liefert.
Identität neu binden
Neue Credentials werden für die verifizierte Person und den Anwendungskontext ausgestellt, nicht blind vom verlorenen Gerät kopiert.
RECOVERY OHNE UNKONTROLLIERTE AUSNAHME
Wie bleibt Self-Service sicher, wenn Ersatz schnell verfügbar sein muss?
Der Recovery-Weg wird im Vorprojekt mit Ihrem Change- und Freigabeprozess festgelegt. x.ID kann abgestimmte Schritte automatisieren; ein verlorener YubiKey ist kein Anlass für einen ungeprüften Zugang.
-
01
Verlust melden und altes Vertrauen entziehen
Benutzer oder Service Desk starten den vereinbarten Verlustprozess. x.ID widerruft die Zertifikate über den CA Connector mit Sperrgrund und CRL-Veröffentlichung. LDAP- und Azure-Connectoren bereinigen die betroffenen Zertifikate und Zuordnungen.
-
02
Ersatz und genehmigten Rückfallzugang vorbereiten
Der Benutzer erhält einen neuen, freigegebenen YubiKey. Falls die normale Anmeldung den verlorenen Schlüssel verlangt, ermöglicht ein vorbereiteter, abgesicherter Jump Host den vereinbarten passwortbasierten Rückfallzugang.
-
03
Register und Assign getrennt abschließen
Ersatzhardware nach dem Integrationsverfahren unter Verwaltung nehmen und der geprüften Person zuordnen. Die Erstregistrierung setzt vorhandene Schlüssel und Zertifikate zurück; sie übernimmt keine alten Credentials.
-
04
PIV Attestation prüfen
Im autorisierten Enrollment entsteht der neue private Schlüssel auf dem Token. Die PIV Attestation prüft seine Hardwareherkunft, bevor das zugehörige CA-Zertifikat ausgestellt wird.
-
05
Zertifikat ausstellen und zuordnen
CSR, aktuelle Identitätsattribute und Policy prüfen, die zuständige CA einbeziehen und das Zertifikat im vorgesehenen PIV-Slot installieren. Anschließend folgen Veröffentlichung und separate SKI-Zuordnung.
-
06
Neuen Zugang prüfen und Ausnahme beenden
Anmeldung und Zielzuordnungen prüfen, den vereinbarten normalen Anmeldezustand wiederherstellen und den Vorgang dokumentieren. Die Ersatzhardware trägt neue Schlüssel, keinen Klon des verlorenen Geräts.
DIE ARCHITEKTUR AUF EINEN BLICK
Verlust melden, Vertrauen entziehen, Rückfallzugang nutzen und neue PIV-Schlüssel ausgeben.
TECHNISCHE TIEFE
Was Attestation nachweist – und was nicht.
Attestation stärkt die Aussage über die Hardware. Die vollständige Trust-Entscheidung benötigt weiterhin Identität, Berechtigung, Policy und Lifecycle-Kontext.
- Hardwaregestützte Schlüsselerzeugung
- PIV Attestation kann signiert nachweisen, dass ein unterstütztes Schlüsselpaar im Security Key erzeugt wurde. Das unterscheidet sich vom Import eines extern erzeugten privaten Schlüssels.
- Identitätsprüfung
- Attestation identifiziert nicht die Person am Schlüssel. Primäridentität und Freigabeprozess bleiben getrennte Pflichtsignale.
- Kontrollierter Self-Service
- Der Benutzer kann erlaubte Schritte über ein Portal initiieren und abschließen. Die Policy bestimmt jedoch Gerät, Nachweise, Freigebende und Ziel-Credentials.
- Neuausgabe statt Schlüsselkopie
- Ein nicht exportierbarer privater Schlüssel wird nicht vom verlorenen Gerät verschoben. Neues Schlüsselmaterial und neue Credentials werden ausgegeben, während altes Vertrauen entzogen und die Beziehung nachvollziehbar bleibt.
- PIV-PIN vergessen oder gesperrt
- Über den genehmigten Rückfallzugang kann der Benutzer seine PIV-PIN im Self-Service neu setzen. Alternativ kann eine berechtigte Administration die individuelle PUK herausgeben. Beim nächsten Enrollment wird diese PUK wieder geändert. Das ist kein FIDO2-PUK-Verfahren.
NACHWEIS & GRENZEN
Das Recovery-Ergebnis bleibt auditierbar.
Ein erfolgreicher Ersatz bedeutet mehr als „der Benutzer kann sich wieder anmelden“. Er muss zeigen, warum der neue Schlüssel akzeptiert wurde und was mit dem alten geschehen ist.
Alte und neue Hardware bleiben getrennt
Verlustnachweis, entzogenes Vertrauen, Ersatzschlüssel und neue Credentials verschmelzen nicht zu einer Gerätehistorie.
Policy bleibt durchsetzbar
Geräteklasse, Attestation, Identität und optionale unabhängige Freigabe werden vor erfolgreicher Aufnahme geprüft.
Notfallwege bleiben kontrolliert
Für Reise oder betriebliche Dringlichkeit lässt sich ein schnellerer Ablauf definieren, ohne die geforderten Trust-Nachweise zu umgehen.
AD und Entra werden nachgeführt
CA-Sperrung, entfernte AD-/Entra-Zuordnungen und Neuausgabe bleiben als separate Aktionen nachvollziehbar. Protokolldaten sind exportierbar.
PASSENDES PRODUKT
SYNRION x.ID
YubiKeys, Identitäten, PIV-Zertifikate und FIDO2 zentral im Browser verwalten. SYNRION x.ID verbindet native Entra-Anbindung mit Cloud-, On-Premises- oder Hybridbetrieb über Outpost-Connectoren. Das Portal ist auch mobil bedienbar; Freigabestatus und Voraussetzungen stehen in der Funktionsübersicht.
NÄCHSTER KONTROLLIERTER SCHRITT
Testen Sie das Verlustszenario, bevor es zum Notfall wird.
Wir gehen Sperrung, Attestation, Identitätsfreigabe und Credential-Neuausgabe mit den Kontrollen Ihres Unternehmens durch.