YubiKey management with x.ID: questions and answers.

PIV stands for Personal Identity Verification. On a compatible security key, the PIV application provides defined slots for private keys and X.509 certificates used for authentication, signatures or key management.

PIV attestation is cryptographic evidence that a supported private key was generated on the YubiKey rather than imported from outside.

x.ID can make attestation a required part of enrolment. The key is generated in the intended PIV slot, the available attestation chain is validated and policy decides whether the hardware evidence is sufficient before a certificate is issued.

Yes. x.ID controls FIDO2 device applications over USB and NFC. Its capabilities also include Entra FIDO2 pre-provisioning with personal PIN handover and central inventory of discoverable FIDO2 credentials on supported YubiKeys with firmware 5.8 or later. Each capability has its own release status.

Passkeys are origin-bound public-key credentials and are designed to resist phishing. Their real security still depends on the authenticator type, device protection, enrolment, recovery and the policy that governs their use.

Inventory discovers the estate and its state. Register places a PIV token under management and controls its Management Key. Assign links it to an accountable identity. Only Enroll generates the key, CSR and certificate and establishes the intended target state.

PIV-capable YubiKeys running firmware 5.3 or later are approved for the x.ID PIV lifecycle. This refers to the firmware version, not a model name. A FIDO-only security key without a PIV application is not included.

Thales SafeNet eToken Fusion, Nitrokey 3 and Swissbit tokens are integrated into x.ID lifecycle processes. Their current release status is shown below. Not all features are available on every token; supported functions depend on the specific model and firmware.

The PIV-capable YubiKeys described here provide 24 PIV certificate slots: four classic slots and twenty retired key-management slots. This does not automatically mean 24 identities: signing, encryption and archived decryption keys also occupy slots.

No. x.ID can also use retired key-management slots for active identities, with individual CA templates or certificate profiles. You can additionally specify how many slots remain reserved for old S/MIME decryption keys.

Yes. x.ID can install several certificates on one YubiKey that are issued from different connected CAs using their respective certificate templates or profiles.

Yes. A verified primary identity can remain accountable for separate secondary identities used for different roles, tiers, domains or applications on the same YubiKey.

The revocation action revokes affected certificates, publishes the CRL and cleans up AD/LDAP and Entra mappings. The user receives a new YubiKey with new keys—not a prepared clone. They use a previously approved fallback to perform their own enrollment.

No. There are four classic key roles: PIV authentication, digital signature, key management for encryption and card authentication. One suitable certificate may serve several applications; a key role and an application are not the same thing.

Previously encrypted email still needs its matching private decryption key. x.ID can reserve archive slots in the TemplateMapping for that purpose. Those slots are then unavailable for additional identities.

When a previously used YubiKey is first registered, it is fully reset and taken into management under the agreed integration procedure. Existing keys and certificates are deleted. Inventory alone is a read-only inventory operation without this reset.

No. Private PIV key material never leaves the YubiKey in any x.ID process. Hardware-internal backup/rollback for failed operations is not an exportable key backup. PFX import is not supported either.

Yes. The web-based CoreService can run in the cloud, on-premises or as part of a hybrid architecture. Outpost connectors link directories, CAs and separated environments where needed. Deployment follows your IT strategy rather than requiring a specific hosting location.

Yes. During predeployment, the service team can inventory PIV tokens such as YubiKeys and place them under management in advance. Enabling Auto-Inventory automates inventory collection; Auto-Register handles registration. This supports bulk preparation before devices are assigned to individual people and certificates are issued.

Before certificate issuance, x.ID checks identity, hardware and policy. Requested attributes in the Certificate Signing Request (CSR) are checked against the current authoritative identity source—through LDAP per forest or natively through Entra.

Yes. x.ID is designed for multi-forest, multi-domain and multi-CA environments while keeping their administrative and trust boundaries visible.

mTLS means that both connection endpoints authenticate with certificates. An Outpost makes an outbound connection to its configured upstream: directly to the central service or through another Outpost.

No. Outposts can form a star, a chain or a mixed topology. Defined connection paths can therefore reach networks with several layers of segmentation. Administrators can see which Outposts are connected.

The LDAP Connector and Azure Connector are separate paths to Active Directory and Microsoft Entra ID. They read identity context and maintain the respective certificate mappings.

Yes. Core, database, Microsoft AD CS and agent can share one protected Windows Server from 2019 onward. Microsoft SQL Server is supported across editions; PostgreSQL is also available. Neither an AD domain nor an HSM is mandatory.

No. userCertificate contains certificates published in Active Directory. altSecurityIdentities can hold the strong SKI mapping to an identity. The Windows certificate store is the local certificate collection for a user or computer.

In the recommended standard workflow, the OIDC-authenticated end user performs enrollment. SSO can use an existing Windows sign-in through WIA or an Entra sign-in. Administrative issuance is configurable, but keyONE explicitly advises against it.

The x.ID Agent runs on the client or on a jump host with supported smart card redirection. No local installation does not mean no agent. The YubiKey stays at the user’s computer; the agent communicates with the Core over mTLS.

Because the services enforcing identity and policy are highly privileged trust components. Their certificate, signing and protection keys should be hardware-protected wherever the risk model requires it.

Sensitive secrets such as Management Keys, PUKs and other credentials are encrypted in SQL Server or PostgreSQL. Each Management Key and PUK is individual, without cross-user derivation. Inventory, certificates and status are operational data readable by authorized functions.

x.ID immediately executes trust withdrawal in connected target systems: affected certificates are revoked through the CA Connector with a revocation reason, and the CRL is published. Affected certificate entries and SKI mappings are removed from AD/LDAP, the Windows certificate store and Microsoft Entra ID. This is more than an inventory status change.

x.ID retains the request and automatically resumes processing immediately when the target is reachable again. This also applies to revocation requests and directory cleanup. A temporary connection loss does not end the process.

For recognized YubiKey driver errors during Register or deregistration, x.ID can automatically reinitialize the device connection. This supports continuation of the intended process.

Every certificate renewal creates a new private key on the YubiKey. Changed device and application policies are applied during that renewal. x.ID executes administrative revocation independently of renewal.

The certificate template defines the overlap period; x.ID reads and follows these settings. During an allowed overlap, the old certificate is not revoked solely because of routine renewal. Administrative revocation and loss are separate processes.

Through a recovery path approved in advance by your organization. A secured jump host can allow password-based sign-in for this purpose, while normal operation retains its intended strong authentication methods. This workflow is agreed during project preparation.

After signing in through the approved fallback, users can set their PIV PIN again in self-service. Alternatively, authorized administrators can provide the individual PUK. x.ID changes that PUK again at the next enrollment.

x.ID logs all lifecycle actions. The current certificate and current attributes remain visible. Audit reports can be viewed and exported as CSV or Excel. Operational and reporting data can also be queried through the API with an authorized role.

Audit reports are not edited afterwards within the Core. Authorized users can view or download them; report generation runs under the Core’s gMSA service account.

x.ID imposes no fixed product-level retention limit. Available history depends on database capacity and operational planning. Your organization defines retention, archiving and deletion.

Installation, including HSM integration and certificate/key setup, is fully scripted and documented. This makes rebuilding the environment reproducible. The customer is responsible for database backups and the required server/HSM key backups.

keyONE recommends one Core with planned, tested rebuilding as the regular starting point. Special availability requirements are assessed within the project. Multi-Core operation is not a generally recommended standard setup.

The service team can pre-provision a YubiKey in Entra ID for the intended user, followed by personal PIN handover. During preparation the key is at the support computer; later it is at the user’s computer. Tenant registration and PIN handover remain distinct steps.

Yes—agentless* on the user’s computer in supported jump-host deployments. Employees and administrators use the web portal; a centrally deployed SYNRION component handles device communication. The YubiKey stays with the user.

SYNRION x.ID connects the company, users, identities and physical YubiKey with the recorded inventory. The shared view includes PIV certificates and discoverable FIDO2 credentials. Employees and authorized administrators receive their respective portal views.

Repeated FIDO2 inventory supports suitable YubiKeys with firmware 5.8 or later. Following authorization, collection can be repeated within the supported lifecycle workflow.

It connects device inventory and identity assignments with recorded lifecycle operations. This supports reviews against company policies and explains changes. Personal and company views follow the applicable permissions.

Yes. Employees and administrators can use the x.ID web portal in a browser on mobile devices with their respective permissions. No local SYNRION application is required for the portal interface.