***GENERAL AVAILABILITY***

 

Overview

Beyond Identity integrates with Microsoft Windows to enable secure, password-less desktop logins using YubiKey 5 Series devices. By replacing traditional passwords with smart card–based credentials, this solution delivers strong, phishing-resistant authentication and significantly reduces the risk of credential theft.

For IT administrators, deploying Beyond Identity with Windows Desktop Login 2.0 strengthens organizational security, simplifies the login experience, and supports alignment with industry best practices for identity protection.

This article provides information to IT administrators with information on:

1. Current Limitations

A. Federated Domains and 3rd-Party IDPs
Windows Desktop Login 2.0 supports Microsoft Domain Joined, Hybrid Joined, and Entra joined devices generally, with an important caveat for domain federated to a 3rd-party IDP that is not Beyond Identity.

• Entra joined devices will not be able to log in using a YubiKey. YubiKeys can still be used for Web SSO, provided that Beyond Identity is delegated to by the 3rd-party IDP.

• Hybrid Joined devices will not obtain a Primary Refresh Token (PRT) during login. However, users can still sign in to the desktop and obtain a Kerberos ticket. YubiKeys can still be used for Web SSO, assuming Beyond Identity is delegated to by the 3rd-party IDP.

C. Windows PC/Server Clock Bug
A known issue affects Entra joined PCs when logging in to Windows. Most PCs are impacted.

• Workaround: Manually set the Windows PC clock back by one minute or more before NTP sync.

• Fix: A permanent resolution is scheduled for version 2.109.0.

D. Policy Targeting for YubiKey Authentication
Currently, authentication policy rules cannot target YubiKey-based logins directly.

• For example, administrators cannot create rules that isolate YubiKey usage from other features related to local user passkeys.

• This capability will be added in a future release. 
  However, this may not be an issue if your Authentication rule has no accompanying 'Verification' applied. Specifically, if your Authentication rule looks like the following, then this limitation is not of concern:

  

  The same rule, as seen in the policy editor:

  

  If you have a rule with verification applied, such as ANY FACTOR, ANY BIOMETRIC, or REGISTERED BIOMETRIC, as shown on the image below, then please use this workaround:

  • Create a new user group, such as YubiKey Testers, and create a new Authentication ALLOW rule with that user group.  

E. Overwritten YubiKey Credentials Not Automatically Deactivated
When a YubiKey is re-enrolled multiple times using the same test or user account, only the most recent credential remains valid. Older credentials associated with the same YubiKey should automatically be deactivated by the system, but this process does not occur yet.

• This limitation exists because a YubiKey can hold only one PIV credential at a time.

• The image below illustrates this issue: although several credentials are listed, only the top (most recent) one is valid.

• 

F. Revocation Delay
A revoked YubiKey may continue to function for up to 14 days before access to Windows login is fully disabled. Efforts are underway to shorten this interval.

• If you have physical access to the YubiKey being revoked, you can immediately disable it by resetting the PIV slot, rather than waiting for the revocation window to expire.  
  
  There is also a command you can run on all Domain Controllers if you absolutely must force the revocation to go faster:

certutil -setreg chain\ChainCacheResyncFiletime @now

G. Windows Desktop Login 1.0 Prevents YubiKey from Appearing at Login
An active Windows Desktop Login (WDL) 1.0 enrollment can prevent the smart card login option from appearing on the Windows login screen. This issue is expected to be resolved with a new release of the Windows Platform Authenticator, version 2.109.0.

Workaround
To restore visibility of the YubiKey smart card option:

1. Open regedit.exe.

2. Navigate to the following key:

   HKLM\Software\Policies\BeyondIdentity\Authenticator

3. Add a new DWORD value named SmartCardCPEnabled, and set its value to 1.

4. At the Windows login screen, the smart card tile corresponding to your YubiKey should now appear.

2. Prerequisites

• A Beyond Identity Secure Work tenant
• Microsoft requirements for smartcard logon apply to this solution. 
  • Windows PCs must be joined to an Active Directory or Entra domain.
  • Active Directory must have established PKI. 
    • Note: PKI can be either AD Certificate Services on a 3rd-party PKI service; Windows Desktop Login with YubiKey is not sensitive to either deployment approach.
• A physical YubiKey 5 series manufactured by Yubico such as:
  • YubiKey 5C NFC (USB-C)
  • YubiKey 5C NFC (USB-A)
  • YubiKey 5C Nano (USB-C)
  • YubiKey 5C Nano (USB-A)
  • YubiKey 5C
  • YubiKey 5Ci
  • YubiKey 5C NFC FIPS  (USB-C)
  • YubiKey 5C NFC FIPS (USB-A)
  • YubiKey 5C Nano FIPS (USB-C)
  • YubiKey 5C Nano FIPS (USB-A)
  • YubiKey 5C FIPS
  • YubiKey 5Ci FIPS
     
• A Windows PC with a Windows System Beyond Identity platform Authenticator installed.

3. Configure Active Directory and Entra ID to use WDL 2.0

Before you begin, ensure that your Secure Work tenant is fully set up and configured.

For sections 3a, 3b, and 3c, you will not necessarily need to perform all 3.   Whether you do or not depends on how your Windows PCs are joined (domain-only, hybrid, or Entra-only).  These three sections will clearly indicate if you need to perform then at the top of each section.

3a. Configuring Active Directory for Windows Desktop Login

This section only must be implemented if you intend to support logging in to Windows PCs that are either domain-joined or hybrid-joined.

First, you must configure Active Directory to trust the Beyond Identity Certificate Authority in order to use smart card logon certificates issued by Beyond Identity for domain login. Follow the steps below to complete the configuration.

1. Download the .zip file containing the five Beyond Identity certificates from the link below, and save it to a convenient location on your Active Directory server. You will need to replace TENANT_NAME with the tenant name of your Secure Work tenant.
   
   https://api-us.beyondidentity.com/v1/tenants/TENANT_NAME/realms/V0/issuers:chain 
   
   Note: If you see an error like the one below, you will need to enroll one YubiKey to proceed.

   {
   "code":"404 Not Found",
   "message":"The requested object wasn't found: 'The issuer with subject alternative name 'tid:TENANT_NAME,rid:V0' was not found'"
   }

   
    

2. Next, unzip the file. This guide assumes you extract the contents to the following path: 
   C:\tmp\bi_ca (see the image below). 
   
   
   
   The certificates listed are the root certificate and four intermediate issuers, comprising the current Beyond Identity CA.   These must be trusted on your Active Directory installation, which the next section will describe how to do.

   000_certificate.cer  Purpose: Issues the smartcard logon certificates. Subject: BYID Realm <TENANT_NAME> v0 YYYYMMDD

   001_certificate.cer  Purpose: Issues your Realm CA Subject: BYID Tenant <TENANT_NAME> YYYYMMDD

   002_certificate.cer  Purpose: Issues your Tenant CA. Subject: CN=Beyond Identity Intermediate CA 1.2.3, O=Beyond Identity, Inc., C=US

   003_certificate.cer  Purpose: Issues the the Level 2 intermediate CA (002_certificate.cer)  Subject: CN=Beyond Identity Intermediate CA 1.1.2, O=Beyond Identity, Inc., C=US

   004_certificate.cer  Purpose: This is the Beyond Identity Root CA. Issues the Level 1 Intermediate CA (003_certificate.cer) Subject: CN=Beyond Identity Root CA 1, O=Beyond Identity, Inc., C=US

To establish trust for the Beyond Identity CA in your Active Directory environment, follow these steps from an administrative Command Prompt or PowerShell session:

Note: The certutil commands below are a standard and officially supported way of adding 3rd-party CA certificates.  Official Microsoft documentation here: https://learn.microsoft.com/en-us/troubleshoot/windows-server/certificates-and-public-key-infrastructure-pki/import-third-party-ca-to-enterprise-ntauth-store.  

Note: gpupdate /force is used to push these trusted certs to all domain controllers immediately.  This allows someone to validate the changes took effect by logging in to Windows with a Yubikey on a domain-joined or hybrid-joined PC as soon as these commands are done.  

Official Microsoft documentation here: https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/gpupdate

1. Navigate to the directory containing the extracted certificates:

cd C:\tmp\bi_ca

2. Add the certificates to the appropriate certificate stores:

certutil -addstore -f Root 004_certificate.cer
certutil -addstore -f CA 003_certificate.cer
certutil -addstore -f CA 002_certificate.cer
certutil -addstore -f CA 001_certificate.cer
certutil -addstore -f CA 000_certificate.cer

3. Publish the certificates to Active Directory:

certutil -dspublish -f 004_certificate.cer RootCA
certutil -dspublish -f 003_certificate.cer SubCA
certutil -dspublish -f 002_certificate.cer SubCA
certutil -dspublish -f 001_certificate.cer SubCA
certutil -dspublish -f 000_certificate.cer SubCA

4. Publish the certificates to the NTAuth store (required for smart card logon):

certutil -dspublish -f 000_certificate.cer NTAuthCA
certutil -dspublish -f 001_certificate.cer NTAuthCA
certutil -dspublish -f 003_certificate.cer NTAuthCA
certutil -dspublish -f 004_certificate.cer NTAuthCA
certutil -dspublish -f 005_certificate.cer NTAuthCA

5. Optional: Force a Group Policy update to apply changes immediately. Otherwise you will need to wait for up to an hour.

gpupdate /force

CRL Access Requirements

To ensure proper certificate validation, all Domain Controllers must have internet access to the following base URLs:

• http://crl.rootca.beyondidentity.com/
• http://crl.ca3.beyondidentity.com/
• http://crl-us.beyondidentity.com
   

Note: Lack of access to these CRL domains may prevent proper certificate validation and result in authentication failures.

3b. Configuring Entra ID for Windows Desktop Login - Managed Domain

This section is only relevant if you need to support Hybrid or Entra-only joined Windows PC on a managed domain.   

• For Entra-only joined PCs, you will not be able to log in to Windows without the below steps.
• For hybrid-joined PCs, you will be able to log in to Windows assuming you completed section 3a, but you will not be able to obtain a PRT without the below steps.

3c. Enabling Certificate-Based Authentication

For any Entra-only joined PC, no matter if federated or managed, you will need to enable certificate-based authentication as an authentication method.

This is done by navigating to Authentication methods > Certificate-based authentication settings > Enable and Target > Enable = ON, as shown below. You will then need to decide which  users or a group(s) of users can log in to Windows with a YubiKey. 

End-User Usage Note

When Certificate-Based Authentication (CBA) is enabled, users will see a new option: “Use a certificate or smart card” on any Entra-hosted login screen.

• This is the option end users should select when signing in to their applications with a YubiKey..

Trusting the Beyond Identity Certificate Authority in Entra

You must ensure that Entra trusts the Beyond Identity Certificate Authority (CA) before enabling certificate-based authentication.
 

Follow the steps below to establish this trust relationship.

1. Download the Beyond Identity Certificate Authority chain.
Click the link below to download a .zip file containing the five CA certificates, then save the file to a convenient location on your PC.

https://api-us.beyondidentity.com/v1/tenants/%3CTENANT_NAME%3E/realms/V0/issuers:chain 

2. Next, un-zip the file.

3. Upload the certificates to Entra. 

• Browse to https://entra.microsoft.com/ and login.
• Select Certificate Authorities from the left navigation bar.

4. Click Upload and upload each certificate one by one.

Make sure to mark 004_certificate.cer as Root CA when uploading!

3c. Configuring Entra ID for Windows Desktop Login - Federated Domain

This section applies only if you need to support Hybrid or Entra only joined Windows PCs on a domain federated with Beyond Identity.

If your domain is already federated with Beyond Identity, no further action is required.
Otherwise, follow the steps below to federate your domain with Beyond Identity.

# You will need to update these 4 variables before running this script

# Domain that needs to be federated. Update with customer domain name.
$domain = "contoso.com"
# Your Beyond Identity tenant name
$tenant_name = "my-tenant-name"
# Get this value from https://admin.byndid.com/integrations/wsfed,
# and copy the IdP ID (as shown in the above screenshot)
$tenant_id = "XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXX"
# Get this value from https://admin.byndid.com/integrations/wsfed,
# and click the Download Certificate icon as shown in the screenshot above, and remove all spaces to create a single string.  It usually starts with MII and ends with ="
[String] $SigningCert = "MII...="

# if you don't have Connect-MgGraph, run:
# Install-Module Microsoft.Graph -Scope AllUsers
Connect-MgGraph -Scopes "Domain.ReadWrite.All", "Directory.AccessAsUser.All"
#+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
#https://auth-us.beyondidentity.run/v1/tenants/wdl-demo/realms/v0/applications/bb38f02a-e8e1-4a3b-8ee5-041220586902/wstrust/mex

$idp = "auth.byndid.com"
$auth_endpoint = "auth-us.beyondidentity.com"
$idphost = "https://" + $idp
$auth_endpoint_host = "https://" + $auth_endpoint
$LogOnUrl =  $idphost + "/wsfed/v1/" + $tenant_id + "/sso"
$mex = $auth_endpoint_host + "/v1/tenants/" + $tenant_name + "/realms/v0/applications/" + $tenant_id + "/wstrust/mex"
#$issueruri = "https://" + $idp + "/federation/ws-trust/" + $tenant_id
$issueruri = "https://" + $idp + "/wsfed/v1/" + $tenant_id
$LogOffUrl = "https://portal.azure.com/"
$Protocol = "wsFed"

# Convert domain to Managed Authentication briefly
Update-MgDomain -DomainId $domain -AuthenticationType "Managed"

# Configure WS-Federation
$params = @{
  DisplayName           = $domain
  IssuerUri            = $issueruri
  PassiveSignInUri        = $LogOnUrl
  SigningCertificate       = $SigningCert
  SignOutUri           = $LogOffUrl
  PreferredAuthenticationProtocol = $Protocol
  FederatedIdpMfaBehavior     = "acceptIfMfaDoneByFederatedIdp"
}
# Conditionally add MetadataExchangeUri if a valid value is provided
if ($mex -ne "") {
  $params.MetadataExchangeUri = $mex
}
New-MgDomainFederationConfiguration -DomainId $domain -BodyParameter $params
# Check Federation Settings
Get-MgDomainFederationConfiguration -DomainId $domain | Format-List *

3d. Preparing the Beyond Identity Directory and SCIM

To enable large-scale enrollment, you will either already have — or will eventually want to configure — SCIM provisioning from your central identity store (typically Entra ID) to Beyond Identity.

Within the Beyond Identity directory, there are three user account fields that are critical for proper YubiKey functionality:

The Username and On-Premises SID must be correctly set before YubiKey enrollment, as these values are written directly to the YubiKey during the enrollment process.

The External ID (Immutable ID), however, is read dynamically from the Beyond Identity directory at authentication time.

• Therefore, it does not need to be set during enrollment but must be correct when authenticating to an app using Web SSO.

Below is an example of a Beyond Identity user record with all three fields populated correctly — as required for domain or hybrid-joined PCs logging in to federated domains via WS-Fed.

And below are those same three values as they appear in Entra ID for the corresponding user account. This view helps confirm that the Beyond Identity directory attributes are properly aligned with their Entra counterparts.

If this comparison looks correct, you should be able to enroll and authenticate a YubiKey successfully using this account.

In general, you’ll want to use SCIM provisioning to ensure that all user attributes in the Beyond Identity directory are accurate across your organization. It’s common to have SCIM set up between Entra ID and Beyond Identity for broader deployment purposes beyond Windows Desktop Login with YubiKey, so you may already have an integration in place.

For detailed guidance, see Step 5: Set up Beyond Identity User Console in Microsoft Entra ID .  

Note:
If you already have SCIM configured before deploying Windows Desktop Login with YubiKey, you likely already have Username and External ID mapped correctly to User Principal Name (UPN) and Immutable ID.

However, you may still need to configure a mapping for the On-Premises Security Identifier (Active Directory User SID).

In that case, simply update your SCIM mappings for that field — as described in: SCIM Setup: Optional - Enabling Windows Desktop Login with Beyond Identity

3e. Configuring a Windows PC for Yubikey Usage

To enroll users for Windows Desktop Login 2.0 using YubiKeys, follow the steps below.

Steps

1. Download the YubiKey Smart Card Minidriver for Windows. Be sure to select the version that matches your Windows system specifications: Windows Minidriver downloads

Note: We recommend using the MSI installer rather than the CAB option when configuring an individual machine for testing.  
 

2. Next, begin the Minidriver installation process.

3. Ensure the Beyond Identity Windows System Platform Authenticator is installed. 
Click the link to download the latest Authenticator: https://app.byndid.com/downloads 

4. Check that users logged in to Windows have a passkey registered to the Windows Platform Authenticator. The Username field (see the image below) will be used as the UserPrincipleName (UPN) when the smartcard logon certificate is created.  This must match a UPN in Active Directory (Entra ID).

Enabling User Enrollment

5. To allow users to enroll a YubiKey directly from the Windows Platform Authenticator, you must enable the self-enrollment feature using the BIConfigure.exe tool from an administrative command prompt:

"c:\Program Files\BeyondIdentity\Tools\BIConfigure" --set-wdl-type modern

3f. Configuring Policy

You can define the conditions under which users are permitted to enroll YubiKeys—either for themselves or for other users.

By default, the platform denies all YubiKey enrollments, so you must configure at least one ALLOW rule in order to enable this feature.

In the Policy Editor, a new transaction type is available: Security Key Enrollment.
This transaction type introduces a unique attribute:

“This user is enrolling [for themselves] / [for someone else]”

With this attribute, administrators can create policies that distinguish between self-enrollment (typically for end users) and delegated enrollment (typically for administrators).

For example, you can allow end-user groups to enroll their own YubiKeys, while restricting enrollment on behalf of others to specific administrative groups.

3g. Viewing Event Logs

1. To view event logs of user activity, log in to your tenant at, https://admin.byndid.com/
2. Then, click Events from the left-hand navigation panel.
    
   
    
3. To view event log details, click the event's Date & time. 
   

3h. Remediating a Blocked YubiKey

If a user enters an incorrect PIN too many times in succession, the YubiKey becomes locked. There are three ways to resolve this issue, depending on available permissions and access.

Option 1: Self-Service Remediation

Users can unlock and restore their YubiKey credentials on their own if all the following conditions are met:

• They have access to a machine with the Windows Authenticator installed.

• Their local passkey is already present on that machine.

• Policy allows the user to enroll a YubiKey for themselves.

Steps

1. In the Windows Authenticator, select your local passkey.

2. Choose Manage Security Keys.

3. Re-enroll the YubiKey.

This process will overwrite the locked YubiKey with a new, valid credential.

Option 2: Remote Admin Assistance (Unblock at Windows Login Screen)

If self-service is not possible, an administrator with Beyond Identity admin access can assist remotely by providing the user’s Personal Unblocking Key (PUK).

Process

1. The administrator retrieves the PUK code from the user’s profile in the Admin Console:

• Navigate to the user’s page.

• Open the Roaming Passkeys tab.

• Locate the active YubiKey passkey.

• Select View Personal Unblocking Key (PUK) to display the code.

2. The administrator securely shares the PUK with the user (via phone, voice, or secure message).

3. The user enters the PUK on the Windows login screen to reset their PIN and unlock the YubiKey.

Once the PIN is reset, the YubiKey becomes usable again for authentication.

The user, now equipped with the PUK, should attempt to log in using the smart card option at the Windows login screen. This action triggers the built-in Windows PIN Recovery feature.

4. After entering the incorrect PIN, the Windows login screen will display the following prompt:

5. By selecting OK, the user will be presented with a special-purpose PIN reset screen, allowing them to unlock and set a new PIN for their YubiKey.

6. The user simply enters their PUK and chooses a new PIN. After completing the reset, they can log in to Windows again and resume using Web SSO with their YubiKey.

 

Option 3: Enabling the Built-In Windows PIN Reset Feature at the Login Screen

By default, the Windows PIN Reset feature is disabled. To enable it, configure the setting through Group Policy Objects (GPO):

1. Press Windows + R, type gpedit.msc, and press Enter to open the Local Group Policy Editor.

2. Navigate to Computer Configuration > Administrative Templates > Windows Components > Smart Card.

3. In the right pane, locate and double-click Allow Integrated Unblock screen to be displayed at the time of logon.

4. Select the Enabled option.

5. Click Apply, then OK to save your changes.

6. Once enabled, users will be able to access the integrated unblock (PIN reset) screen directly from the Windows login screen when unlocking a blocked YubiKey.

   
    

Option 4: Unblock Using the Yubico Authenticator Application (with Remote Admin Assistance)

An administrator with Beyond Identity admin access must first retrieve the Personal Unblocking Key (PUK), as described in the previous section.

The user, with their YubiKey in hand, must then be physically present at a machine that has the Yubico Authenticator application installed. The app can be downloaded from the Yubico website.

Steps

a. In the Yubico Authenticator application, select:
Certificates → 9a Authentication → Change PIN.

b. Enter the PUK provided by the administrator when prompted.

c. Set a new PIN for the YubiKey.

d. After this process, the YubiKey will be unblocked and ready for use again.
 

Option 5: Unblock or Re-Enroll When the Administrator Has the YubiKey Physically in Hand

If the administrator has physical possession of the user’s YubiKey, they can remediate the issue directly.

a. Log in to a machine with the Windows Authenticator installed and ensure the administrator’s local passkey is present.

b. Launch the Beyond Identity Admin Console at:
https://admin.byndid.com/

c. Locate the user who owns the blocked YubiKey.

d. Choose one of the following actions:

• Re-enroll the YubiKey for the user. This will overwrite the existing credential with a new, valid one.

• Or, reveal the PUK and reset the PIN instead of overwriting the credential, using the Yubico Authenticator application as described above.

Either approach restores the YubiKey to a working state, enabling the user to authenticate normally again.

3i. Error Messages

The following screens may display when encountering errors, along with their likely reasons.

	The Active Directory server does not trust the Beyond Identity CA Certificates.
	The Beyond Identity Certificate Authority certificates are not stored in NTAuthCA.
	The PIN entered by the user does not match the PIN used at enrollment.
	The user entered the wrong PIN multiple times.
	If you are using a new smartcard on a PC that isn't connected to its domain controller, you will see this message.
	If you log in with a smartcard containing a domain suffix unknown to AD, you will get the error: “Your credentials could not be verified.” Also, on the PC you attempted to log in, you’ll see System Log Event ID 11, with the description: “The Distinguished Name in the subject field of your smart card logon certificate does not contain enough information to identify the appropriate domain on a non-domain joined computer.”  Reason: If the Object User SID does not match to a user, this can occur.  The Log you'll get is in System Log Event ID 4, with the General tab indicating: Log Name:       System Source:         Microsoft-Windows-Kerberos-Key-Distribution-Center Event ID:       41 Level:          Error Description: The Key Distribution Center (KDC) encountered a user certificate that was valid but contained a different SID than the user to which it mapped. As a result, the request involving the certificate failed. See https://go.microsoft.com/fwlink/?linkid=2189925 to learn more. User: john.doe

Error: “Your credentials could not be verified.”

This error occurs when you attempt to log in with a smart card whose domain suffix is not recognized by Active Directory (AD).

On the affected PC, you may also see the following System Log entry:

Event ID 11
Source: System
Description:
The Distinguished Name in the subject field of your smart card logon certificate does not contain enough information to identify the appropriate domain on a non-domain-joined computer.

Additionally, you may encounter another instance of “credentials could not be verified” accompanied by a Kerberos Key Distribution Center (KDC) warning:

Event Log Warning: Microsoft-Windows-Kerberos-Key-Distribution-Center
Event ID: 39

Example:
The Key Distribution Center (KDC) encountered a user certificate that was valid but could not be mapped to a user in a secure way (such as via explicit mapping, key trust mapping, or a SID). Such certificates should either be replaced or mapped directly to the user via explicit mapping. See https://go.microsoft.com/fwlink/?linkid=2189925 to learn more.

User: john.doe
Certificate Subject: O=some-tenant, CN=Seth Call
Certificate Issuer: Staging Beyond Identity Intermediate CA 1.2.2
Certificate Serial Number: 515AB74D9A59BC635869D7618B58BF39BF7AF93C
Certificate Thumbprint: 6FF07463F7850C0DD44BAC24F449FD1F834C6578

Resolution
Verify that the smart card certificate subject and domain suffix align with the expected Active Directory domain configuration. If necessary, reissue the certificate or explicitly map it to the correct user account following the guidance in the Microsoft documentation linked above.

4. Enable Enrollment on Individual Computers for Initial Testing

The goal of this section is to provide administrators with the steps to try out enrolling and authenticating a YubiKey without impacting other users.

The steps below let you test YubiKey functionality in complete isolation, limited to your own PC or test machine.

1. Install a preview build of the Beyond Identity Windows Platform Authenticator (v2.107.9 or later).
   Click the link below to download the Authenticator:
   https://app.byndid.com/downloads
2. Configure the Platform Authenticator for WDL Modern Mode.
   This mode ensures that the Manage Security Key link appears on the user’s passkey entry.

3. Enable Self-Enrollment.
   To allow users to enroll a YubiKey from the Windows Platform Authenticator, use the BIConfigure.exe tool from an administrative prompt to enable the self-enrollment feature.

   # System Installer Path
   "C:\Program Files\BeyondIdentity\Tools\BIConfigure" --set-wdl-type modern
   
   # User Installer Path
   "%localappdata%\Programs\BeyondIdentity\Tools\BIConfigure.exe" --set-wdl-type modern
   

After running the command, either select File > Refresh Passkeys or restart the Windows Platform Authenticator. You should now see the Manage Security Keys link appear when you select a user passkey.

Select the Manage Security Keys link to begin the YubiKey enrollment process, just as an end user would when enrolling their own device.

As an administrator, however, you can also enroll a YubiKey on behalf of any user in the directory. Follow the steps in the next section, Enroll Users, which is the recommended next step for enrolling your first YubiKey.

5. Enroll Users

5a. Enrolling a User's YubiKey (On-Behalf-Of Enrollment)

To enroll a user's YubiKey to your tenant, follow these steps:

1. Log in to your tenant at https://admin.byndid.com/
2. Then, from the left-hand navigation panel, click Users. 
   
   
3. Select a user from the list by clicking their name. 

4. Next, click Enroll a Passkey, and select the Roaming Passkey option from the drop-down.

   Note: if you do not have the Roaming Passkey option, ask your Beyond Identity customer support contact to turn on the Windows Desktop Login YubiKey feature set. 
   
   
    

5. Plug in the YubiKey for the user and follow the rest of the prompts.
   
   

5b. The End User Self-Enrollment Process

To learn about the self-enrollment process for users, click here. 
 

6. Manage Users

6a. Listing Windows Login Passkeys for a Given User

1. To view users enrolled with YubiKeys, log in to your tenant at, https://admin.byndid.com/

2. Then, from the left-hand navigation panel, click Users. 

   
    

3. Click the Roaming passkeys tab to view the list of users able to enroll with a YubiKey.
   
   
     

6b. Revoking a User's YubiKey Credential

1. To revoke a user's YubiKey credential, log in to your tenant at, https://admin.byndid.com/
2. Click Users from the left-hand navigation, then select the Roaming passkeys tab. 
   
   
    

3. Under the Actions column, click the three vertical dots to revoke the user's credential, and select the Revoke Credential option from the dropdown.

   
    

4. Read the message, then click Revoke certificate (Note: This action cannot be undone). 

   

7. Troubleshooting

7a. Difficulty Enrolling a YubiKey

If a YubiKey fails to enroll successfully, the issue typically falls into one of a few common causes. The error message displayed during enrollment should provide helpful context, but it can also be useful to review the authenticator log file while troubleshooting.

%APPDATA%\BeyondIdentity\logs\authenticator\authenticator-DD-MM-YYY.log

An even more convenient approach is to use PowerShell to tail (follow) the log file in real time while attempting YubiKey enrollments. This allows you to see log events as they occur directly in the PowerShell window:

Get-Content -Wait $env:APPDATA\BeyondIdentity\logs\authenticator\authenticator-DD-MM-YYY.log 

Usually, it’s worth trying the following steps first:

1. Reset the YubiKey using the YubiKey Authenticator application.

• Download the YubiKey Authenticator from the Yubico website

• Open the application, connect your YubiKey, then select Factory Reset from the top-right corner.

• Choose PIV to perform the reset.

1. Restart the Windows Authenticator and attempt the YubiKey enrollment again.

2. Close conflicting applications.
   Other applications may temporarily lock the YubiKey, preventing the Beyond Identity Windows Authenticator from writing to it.

3. Exit all open applications, especially any that use Remote Desktop Protocol (RDP), and try again.

4. Verify your policy configuration.
   Ensure at least one ALLOW rule for YubiKey enrollment exists in your Policy settings.

5. See the Configuring Policy