Complex technology. Clear 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 brings FIDO2 security keys and passkey processes into the controlled device and identity lifecycle alongside PIV certificates.

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.

YubiKey 4 and 5 provide 24 certificate-bearing PIV slots: four standard slots and twenty retired key-management slots. In the x.ID identity model, this can support one primary and up to 23 secondary identities where the selected design permits it.

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 lost device and its credentials enter a controlled loss process: assignments are removed, certificates are revoked, directory and FIDO2 states are reconciled, and replacement hardware receives new keys and credentials.

Policy enforcement means that x.ID evaluates defined requirements before trust is granted or changed. Identity, device evidence, role, intended use and approvals can all become mandatory inputs.

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

Mutual TLS, or mTLS, means that both sides of an Outpost connection authenticate with certificates. The central service verifies the Outpost, and the Outpost verifies the central service.

The LDAP Connector works with on-premises Active Directory; the Azure Connector addresses Microsoft Entra ID natively. They are separate target paths rather than two names for the same synchronization mechanism.

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.

x.ID does not treat all data identically. Inventory, assignment and status information must remain usable by authorized application functions, while security-critical application data and stored credentials are protected with integrated application data protection.