One accountable person
The primary identity remains the clear owner of every additional role and certificate.
MULTI-IDENTITY YUBIKEY MANAGEMENT
One YubiKey. Multiple identities. Clear accountability.
User, administrator and further role identities can share one YubiKey. SYNRION x.ID maps each identity to its certificates, issuers, PIV slots and rules. The approved slot profile determines what fits on the shared hardware.
VALUE IN 30 SECONDS
Fewer physical keys without mixing responsibilities.
Separated use cases
Certificates, domains and roles retain their logical assignments. Shared hardware explicitly does not provide physical separation between administrative tiers.
Independent lifecycles
A secondary identity can be issued, renewed or removed without turning the whole device into an unmanaged exception.
ONE CARRIER · CONTROLLED IDENTITIES
How do identities remain distinguishable on shared hardware?
The answer is not to treat the YubiKey as one global identity. x.ID models the person, each secondary identity, its certificate and its permitted use as separate but connected objects.
-
01
Anchor the primary identity
Begin with the verified person who is accountable for the hardware and every secondary identity assigned to it.
-
02
Define roles and trust boundaries
Create secondary identities for distinct administration tiers, domains, forests, applications or operational duties.
-
03
Assign suitable PIV slots
Place each supported certificate identity in a controlled slot and keep the mapping visible to administrators and auditors.
-
04
Enforce issuance policy
Check hardware evidence, identity, role and required approvals before each secondary identity becomes active.
-
05
Maintain every assignment in the target directory
Set the certificate and strong mapping for each identity in its intended AD or Entra context instead of documenting only the token slot.
-
06
Operate each identity deliberately
Renew, suspend or remove the affected identity while preserving the remaining approved roles on the same key.
THE ARCHITECTURE AT A GLANCE
Plan active identities and S/MIME archive capacity deliberately—including retired slots.
TECHNICAL DEPTH
Capacity is a design decision, not a blanket promise.
The physical device can consolidate credentials, but the usable arrangement must be planned against hardware, cryptography, applications and organizational separation rules.
- 24 certificate slots are not 24 complete identity profiles
- The PIV-capable YubiKeys described here provide four classic and twenty retired key-management slots. x.ID requires firmware 5.3 or later; individual features may require newer firmware. Identity capacity depends on certificates per identity, applications, S/MIME reservations and the approved slot profile—not slot count alone.
- Retired slots for active identities and S/MIME archives
- In the PIV model, the twenty retired key-management slots 82–95 are intended for previous decryption keys. x.ID can also assign supported slots to active identities with individual CA profiles. Reserved S/MIME archive slots remain available for their intended purpose. Firmware, cryptography, target applications and policy must permit the chosen layout.
- Role separation
- Separate certificates and policies distinguish logical identities, not the physical device. The PIV application uses a shared PIN; loss of the device affects every identity it carries. Where tier or role policy requires separate hardware, separate keys remain necessary.
- Rollback without private-key export
- x.ID can use hardware-internal backup/rollback options for a failed operation. Private PIV key material never leaves the YubiKey. This does not create a PFX file or a cloned key for a replacement device. S/MIME archiving remains a separate slot-planning task.
- Assignments in AD and Entra
- Multiple identities require more than separate slots: every target assignment must remain correct. x.ID combines the LDAP path for userCertificate and X509:<SKI> with the native Azure Connector path for Microsoft Entra ID.
EVIDENCE & BOUNDARIES
What remains controllable when identities are consolidated.
The important result is not the maximum slot count. It is the ability to reduce hardware while keeping every identity understandable and changeable.
Identity-to-slot assignment
Administrators can see which secondary identity, certificate and use case belong together.
Policy per identity
Approval and lifecycle rules can differ by role, tier, domain or application context.
Controlled removal
A role can be removed without automatically discarding all remaining identities on the hardware.
Target systems remain consistent
Removed or renewed identities are deliberately reconciled in their AD and Entra assignments as well.
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
Map your roles before buying one key per identity.
We will examine your tiers, domains, applications and separation rules and show which identities can share hardware without losing control.