Remove old trust first
The revocation action executes certificate revocation, CRL publication and cleanup of affected directory mappings—without access to the lost YubiKey.
PIV ATTESTATION & SELF-SERVICE
A YubiKey is lost while travelling. The controlled identity lifecycle continues.
First, x.ID withdraws trust from the lost YubiKey: revoke certificates, publish the CRL and clean up AD/LDAP and Entra. The user then enrols a new YubiKey through the approved recovery path—with new hardware-bound keys and secure sign-in.
VALUE IN 30 SECONDS
Withdraw old trust. Return to work securely.
Verify replacement hardware
PIV attestation and policy check whether the new key provides the required hardware evidence.
Rebind the identity
New credentials are issued to the verified person and application context, not copied blindly from the lost device.
RECOVERY WITHOUT AN UNCONTROLLED EXCEPTION
How can self-service remain secure when replacement must be fast?
The recovery path is agreed during project preparation as part of your change and approval process. x.ID can automate agreed steps; losing a YubiKey does not justify unverified access.
-
01
Report loss and withdraw old trust
The user or service desk starts the agreed loss process. x.ID revokes certificates through the CA Connector with a revocation reason and CRL publication. LDAP and Azure Connectors clean up the affected certificates and mappings.
-
02
Prepare a replacement and approved fallback access
The user receives a new, approved YubiKey. If normal sign-in requires the lost key, a prepared, secured jump host provides the agreed password-based fallback access.
-
03
Complete Register and Assign separately
Bring the replacement under management using the integration procedure and assign it to the verified person. First registration resets existing keys and certificates; it does not preserve old credentials.
-
04
Verify PIV attestation
During authorized enrollment, the new private key is generated on the token. PIV Attestation verifies its hardware origin before the corresponding CA certificate is issued.
-
05
Issue and map the certificate
Check the CSR, current identity attributes and policy, involve the responsible CA and install the certificate in its assigned PIV slot. Publication and separate SKI mapping follow.
-
06
Test the new access and close the exception
Check sign-in and target mappings, restore the agreed normal sign-in state and document the operation. The replacement carries new keys, not a clone of the lost device.
THE ARCHITECTURE AT A GLANCE
Report loss, withdraw trust, use approved fallback access and issue new PIV keys.
TECHNICAL DEPTH
What attestation proves—and what it does not.
Attestation strengthens the hardware statement. The complete trust decision still needs identity, authorization, policy and lifecycle context.
- Hardware-backed key generation
- PIV attestation can provide signed evidence that a supported key pair was generated in the security key. This is different from importing an externally generated private key.
- Identity proofing
- Attestation does not identify the person holding the key. The primary identity and approval process remain separate mandatory signals.
- Controlled self-service
- The user can initiate and complete permitted steps through a portal, but policy determines the allowed device, required evidence, approvers and target credentials.
- Reissue instead of key copying
- A non-exportable private key is not moved from the lost device. New key material and credentials are issued, while old trust is removed and the relationship remains traceable.
- Forgotten or blocked PIV PIN
- Through the approved fallback, users can set their PIV PIN again in self-service. Alternatively, authorized administrators can release the individual PUK. That PUK is changed at the next enrollment. This is not a FIDO2 PUK procedure.
EVIDENCE & BOUNDARIES
The recovery result remains auditable.
A successful replacement is more than “the user can log in again”. It must show why the new key was accepted and what happened to the old one.
Old and new hardware remain distinct
The loss record, removed trust, replacement key and new credentials do not collapse into one device history.
Policy remains enforceable
Device class, attestation, identity and optional independent approval are evaluated before enrolment succeeds.
Emergency paths remain controlled
A faster process can be defined for travel or operational urgency without bypassing the required trust evidence.
AD and Entra are reconciled
CA revocation, removed AD/Entra mappings and fresh issuance remain traceable as separate actions. Log data can be exported.
RELATED PRODUCT
SYNRION x.ID
Manage YubiKeys, identities, PIV certificates and FIDO2 centrally in a browser. SYNRION x.ID combines native Entra integration with cloud, on-premises or hybrid deployment through Outpost connectors. The portal also supports mobile access; the feature overview states release status and requirements.
THE NEXT CONTROLLED STEP
Test the loss scenario before it becomes an emergency.
We will walk through blocking, attestation, identity approval and credential reissue with the controls your organization requires.