Komplexe Technik. Klare Antworten.

PIV steht für Personal Identity Verification. Auf einem kompatiblen Security Key stellt die PIV-Anwendung definierte Slots für private Schlüssel und X.509-Zertifikate zur Authentifizierung, Signatur oder Schlüsselverwaltung bereit.

PIV Attestation ist ein kryptografischer Nachweis, dass ein unterstützter privater Schlüssel auf dem YubiKey erzeugt und nicht von außen importiert wurde.

x.ID kann Attestation zu einer verpflichtenden Bedingung des Enrollments machen. Der Schlüssel wird im vorgesehenen PIV-Slot erzeugt, die verfügbare Attestation Chain geprüft und die Policy entscheidet vor der Zertifikatsausgabe, ob der Hardwarenachweis ausreicht.

Ja. x.ID bindet FIDO2-Sicherheitsschlüssel und Passkey-Prozesse neben PIV-Zertifikaten in den kontrollierten Geräte- und Identitäts-Lifecycle ein.

Passkeys sind an den jeweiligen Dienst gebundene Public-Key-Credentials und auf Phishing-Resistenz ausgelegt. Ihre tatsächliche Sicherheit hängt trotzdem von Authenticator, Geräteschutz, Registrierung, Recovery und der durchgesetzten Policy ab.

YubiKey 4 und 5 stellen 24 zertifikatstragende PIV-Slots bereit: vier Standard-Slots und zwanzig Retired-Key-Management-Slots. Im x.ID-Identitätsmodell kann dies eine Primäridentität und bis zu 23 Sekundäridentitäten ermöglichen, wenn das gewählte Design es zulässt.

Ja. x.ID kann mehrere Zertifikate auf einem YubiKey installieren, die anhand der jeweiligen Zertifikatvorlagen oder Certificate Profiles unterschiedlicher angebundener CAs ausgestellt wurden.

Ja. Eine verifizierte Primäridentität kann für getrennte Sekundäridentitäten verantwortlich bleiben, die auf demselben YubiKey für verschiedene Rollen, Tiers, Domains oder Anwendungen verwendet werden.

Der verlorene Token und seine Credentials durchlaufen einen kontrollierten Verlustprozess: Zuordnungen werden aufgehoben, Zertifikate gesperrt, Verzeichnis- und FIDO2-Zustände bereinigt und Ersatzhardware erhält neue Schlüssel und Credentials.

Policy Enforcement bedeutet, dass x.ID festgelegte Anforderungen prüft, bevor Vertrauen erteilt oder verändert wird. Identität, Gerätenachweis, Rolle, Verwendungszweck und Freigaben können verpflichtende Eingangssignale sein.

Ja. x.ID ist für Multi-Forest-, Multi-Domain- und Multi-CA-Umgebungen ausgelegt und hält deren Verwaltungs- und Trust-Grenzen weiterhin sichtbar.

Mutual TLS oder mTLS bedeutet, dass sich beide Seiten einer Outpost-Verbindung mit Zertifikaten authentifizieren. Der zentrale Dienst prüft den Outpost – und der Outpost den zentralen Dienst.

Der LDAP Connector arbeitet mit lokalem Active Directory; der Azure Connector adressiert Microsoft Entra ID nativ. Es sind getrennte Zielpfade und nicht zwei Bezeichnungen für denselben Synchronisationsmechanismus.

Weil die Dienste, die Identität und Policy durchsetzen, besonders privilegierte Trust-Komponenten sind. Ihre Zertifikats-, Signatur- und Schutzschlüssel sollten hardwaregeschützt werden, wo das Risikomodell dies verlangt.

x.ID behandelt nicht alle Daten gleich. Inventar-, Zuordnungs- und Statusinformationen müssen für berechtigte Anwendungsfunktionen nutzbar bleiben; sicherheitskritische Anwendungsdaten und abgelegte Credentials werden durch integrierte App Data Protection geschützt.