One YubiKey. Multiple identities. Managed in your browser.

Keep the accountable person as the starting point for every further identity and authorization decision.

Assign additional identities and roles without losing the connection to the primary identity.

Enforce approval conditions technically instead of relying on the target system or a single signal.

Apply separation of duties and required independent verification as part of the trust decision.

x.ID can also use retired key-management slots for active identities with their own CA profiles. S/MIME archive slots can be reserved. Certificate requirements, hardware and policy determine the layout; shared hardware and PIV PIN do not replace physical tier separation.

Include hardware authenticity and the origin of the bound key as trust signals.

Enable allowed YubiKey applications separately for USB and NFC, and define configuration protection and reset settings. PIV PIN/PUK and FIDO2 remain separate; changes apply at the next certificate renewal.

PIV lifecycle, device settings and policy controls support implementation of your BSI-oriented requirements. Assessment of actual compliance remains with the organization; no certification is claimed.

Run the web-based CoreService in the cloud or in your own data center. Outpost connectors provide targeted access to the required directories, CAs and separated networks. Deployment follows the customer’s strategy, including mixed environments. The portal is accessible through a browser; local device operations use the supported access path.

Connect certificate-based Windows authentication with verified identity, hardware and policy assignment.

Support certificate-based authentication for Linux use cases with the same trust decision.

Use the x.ID portal in a browser on desktop, tablet or smartphone. *Supported jump-host deployments require no SYNRION agent installation on the user’s computer. A central component handles device access through approved smartcard redirection; the YubiKey stays with the user. Local agent deployment is also supported. Portal access and specific device operations have their own technical requirements.

Relate identities and policies across separated tiers and multiple directory structures.

Connect multiple certification authorities to one identity and approval model.

The Azure Connector integrates Microsoft Entra ID directly through Microsoft Graph. Entra CBA and certificateUserIds are part of the available certificate lifecycle. Local AD uses LDAP; AD synchronization does not replace native Entra integration.

Certificate publication and SKI mapping are maintained at issuance and cleaned up at withdrawal: AD userCertificate, X509: in altSecurityIdentities, the Windows certificate store and certificateUserIds for Entra CBA.

Windows Outposts can run under specifically authorized gMSA service accounts. mTLS authenticates the connection; an HSM can protect the service certificate’s private key. This is separate from gMSA password management.

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.

Integrate operational and reporting data into your own processes through the API. Queries require the appropriate authorized role.

A revocation action executes certificate revocation, including its reason and CRL publication. x.ID removes affected certificates and mappings from connected AD/LDAP directories, the Windows certificate store and Microsoft Entra ID.

Withdraw old trust, use approved recovery access and enrol a new YubiKey through self-service. After OIDC sign-in, the user receives new hardware-bound keys and certificates; x.ID maintains directory mappings and the process record.

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.

Secrets are encrypted in SQL Server or PostgreSQL. The authorized Core can use a protection key in an HSM, or the Windows certificate store without an HSM. Database access alone does not decrypt secrets.

View audit reports or export them as CSV and Excel; query operational data through role-authorized APIs. Compliance reporting and CBOM-capable data belong to the shared SYNRION base module. Prepared PCI DSS-, DORA- and BSI-oriented reports support assessments, not automatic compliance.

If a CA or target system is temporarily unreachable, x.ID retains the request and automatically resumes processing as soon as connectivity returns. This includes revocation and cleanup.

Installation, including HSM integration and certificate/key setup, is scripted and documented. The customer backs up the database and required server/HSM keys. Rebuilding the installation does not replace those backups.