WebAuthn times out with PIN-configured CTAP 2.1 authenticator when user verification is discouraged

[all-solutions]

Steps to reproduce

1. Configure a FIDO2 PIN on a Swissbit iShield Key 2 Pro MIFARE.
2. Open the Web Vault and navigate to Settings > Security > Two-step login > Passkey.
3. Attempt to register the security key.
4. No PIN prompt appears and the WebAuthn operation eventually times out.
5. Resetting the FIDO2 applet and registering the key before configuring a PIN works, but this is not a complete workaround because authentication is also initiated with userVerification: discouraged.

The same Vaultwarden installation successfully registers YubiKeys that already have a FIDO2 PIN. A PIN prompt appears for those keys.

The iShield also registers and authenticates successfully on webauthn.io with its PIN configured.

Expected result

Vaultwarden should interoperate with the authenticator: either the non-UV operation should complete successfully, or user verification should be requested so the browser presents a PIN prompt.

Actual result

With a FIDO2 PIN configured, no PIN dialog appears and the operation times out. Registration works only while no PIN is configured.

Authenticator information

Product:              Swissbit iShield Key 2 Pro MIFARE
Device version:       1.1.0
FIDO version:         v1.4.0-0-gd69b47b
AAGUID:               7787a482-13e8-4784-8a06-c7ed49a7aaf4
Supported protocols:  U2F, CTAP 2.0, CTAP 2.1
clientPin:            yes
alwaysUv:             no
makeCredUvNotRqd:     yes

The authenticator advertises makeCredUvNotRqd: yes. Therefore, with Vaultwarden requesting userVerification: discouraged, Chrome does not present a PIN dialog. The resulting non-UV makeCredential operation does not complete.

Confirmed diagnostic workaround

I built Vaultwarden 1.36.0 with only the WebAuthn user-verification policy changed from discouraged to preferred for both registration and authentication:

• registration challenge: Discouraged_DO_NOT_USE > Preferred
• stored registration state: "discouraged" > "preferred"
• authentication challenge: Discouraged_DO_NOT_USE > Preferred
• stored authentication state: "discouraged" > "preferred"

With this test build:

1. Chrome presents the FIDO2 PIN dialog.
2. After entering the PIN and touching the key, registration completes.
3. The key appears in the WebAuthn security-key list.
4. Authentication in a new Incognito window also succeeds with PIN and touch.

No other source or configuration changes were made.

This indicates that Vaultwarden's explicit userVerification: discouraged policy triggers the incompatible path. The underlying issue may be in the authenticator firmware, Windows WebAuthn, or their interaction, but allowing preferred provides a working interoperability option.

Would the maintainers consider making the WebAuthn 2FA user-verification policy configurable, while keeping discouraged as the default for backward compatibility? I would be willing to prepare a PR once the preferred approach and configuration scope are agreed upon.

Environment

• Vaultwarden: 1.36.0
• Successful diagnostic build: 1.36.0-uv-preferred-test
• Web Vault: 2026.4.1
• Server: Debian 13, Linux x86_64
• Database: SQLite 3.51.3
• Deployment: built from source by the Proxmox VE Community Script
• Reverse proxy: none; Vaultwarden serves HTTPS directly
• Client: Web Vault
• Browser: Google Chrome 150.0.7871.124

Vaultwarden Support String

Your environment (Generated via diagnostics page)

• Vaultwarden version: v1.36.0-uv-preferred-test
• Web-vault version: v2026.4.1
• OS/Arch: linux/x86_64
• Running within a container: false (Base: Not applicable)
• Database type: SQLite
• Database version: 3.51.3
• Uses config.json: true
• Uses a reverse proxy: false
• Internet access: true
• Internet access via a proxy: false
• DNS Check: true
• Browser/Server Time Check: true
• Server/NTP Time Check: true
• Domain Configuration Check: false
• HTTPS Check: true
• Websocket Check: true
• HTTP Response Checks: true

Config & Details (Generated via diagnostics page)

Show Config & Details

Environment settings which are overridden: ADMIN_TOKEN

Config:

{
  "_duo_akey": "***",
  "_enable_duo": false,
  "_enable_email_2fa": true,
  "_enable_smtp": true,
  "_enable_yubico": true,
  "_icon_service_csp": "",
  "_icon_service_url": "",
  "_ip_header_enabled": true,
  "_max_note_size": 10000,
  "_smtp_img_src": "***:",
  "admin_ratelimit_max_burst": 3,
  "admin_ratelimit_seconds": 300,
  "admin_session_lifetime": 20,
  "admin_token": "***",
  "allowed_connect_src": "",
  "allowed_iframe_ancestors": "",
  "attachments_folder": "/opt/vaultwarden/data/attachments",
  "auth_request_purge_schedule": "30 * * * * *",
  "authenticator_disable_time_drift": false,
  "data_folder": "/opt/vaultwarden/data",
  "database_conn_init": "",
  "database_idle_timeout": 600,
  "database_max_conns": 10,
  "database_min_conns": 2,
  "database_timeout": 30,
  "database_url": "********************************",
  "db_connection_retries": 15,
  "disable_2fa_remember": false,
  "disable_admin_token": false,
  "disable_icon_download": false,
  "dns_prefer_ipv6": false,
  "domain": "*****://*******************",
  "domain_origin": "*****://*******************",
  "domain_path": "",
  "domain_set": true,
  "duo_context_purge_schedule": "30 * * * * *",
  "duo_host": null,
  "duo_ikey": null,
  "duo_skey": null,
  "duo_use_iframe": false,
  "email_2fa_auto_fallback": false,
  "email_2fa_enforce_on_verified_invite": false,
  "email_attempts_limit": 3,
  "email_change_allowed": true,
  "email_expiration_time": 600,
  "email_token_size": 6,
  "emergency_access_allowed": true,
  "emergency_notification_reminder_schedule": "0 3 * * * *",
  "emergency_request_timeout_schedule": "0 7 * * * *",
  "enable_db_wal": true,
  "enable_websocket": true,
  "enforce_single_org_with_reset_pw_policy": false,
  "event_cleanup_schedule": "0 10 0 * * *",
  "events_days_retain": null,
  "experimental_client_feature_flags": "",
  "extended_logging": true,
  "helo_name": null,
  "hibp_api_key": null,
  "http_request_block_non_global_ips": true,
  "http_request_block_regex": null,
  "icon_blacklist_non_global_ips": true,
  "icon_blacklist_regex": null,
  "icon_cache_folder": "/opt/vaultwarden/data/icon_cache",
  "icon_cache_negttl": 259200,
  "icon_cache_ttl": 2592000,
  "icon_download_timeout": 10,
  "icon_redirect_code": 302,
  "icon_service": "internal",
  "incomplete_2fa_schedule": "30 * * * * *",
  "incomplete_2fa_time_limit": 3,
  "increase_note_size_limit": false,
  "invitation_expiration_hours": 120,
  "invitation_org_name": "Vaultwarden",
  "invitations_allowed": true,
  "ip_header": "X-Forwarded-For",
  "job_poll_interval_ms": 30000,
  "log_file": null,
  "log_level": "info",
  "log_timestamp_format": "%Y-%m-%d %H:%M:%S.%3f",
  "login_ratelimit_max_burst": 10,
  "login_ratelimit_seconds": 60,
  "org_attachment_limit": null,
  "org_creation_users": "",
  "org_events_enabled": false,
  "org_groups_enabled": false,
  "password_hints_allowed": true,
  "password_iterations": 100000,
  "purge_incomplete_sso_auth": "0 20 0 * * *",
  "push_enabled": false,
  "push_identity_uri": "https://identity.bitwarden.com",
  "push_installation_id": "***",
  "push_installation_key": "***",
  "push_relay_uri": "https://push.bitwarden.com",
  "reload_templates": false,
  "require_device_email": false,
  "rsa_key_filename": "/opt/vaultwarden/data/rsa_key",
  "send_purge_schedule": "0 5 * * * *",
  "sendmail_command": null,
  "sends_allowed": false,
  "sends_folder": "/opt/vaultwarden/data/sends",
  "show_password_hint": true,
  "signups_allowed": false,
  "signups_domains_whitelist": "",
  "signups_verify": true,
  "signups_verify_resend_limit": 6,
  "signups_verify_resend_time": 3600,
  "smtp_accept_invalid_certs": false,
  "smtp_accept_invalid_hostnames": false,
  "smtp_auth_mechanism": "\"Login\"",
  "smtp_debug": false,
  "smtp_embed_images": true,
  "smtp_explicit_tls": null,
  "smtp_from": "***********************",
  "smtp_from_name": "*********",
  "smtp_host": "********************",
  "smtp_password": "***",
  "smtp_port": 587,
  "smtp_security": "starttls",
  "smtp_ssl": null,
  "smtp_timeout": 15,
  "smtp_username": "***********************",
  "sso_allow_unknown_email_verification": false,
  "sso_audience_trusted": null,
  "sso_auth_only_not_session": false,
  "sso_authority": "",
  "sso_authorize_extra_params": "",
  "sso_callback_path": "*****://************************************************",
  "sso_client_cache_expiration": 0,
  "sso_client_id": "",
  "sso_client_secret": "***",
  "sso_debug_tokens": false,
  "sso_enabled": false,
  "sso_master_password_policy": null,
  "sso_only": false,
  "sso_pkce": true,
  "sso_scopes": "email profile",
  "sso_signups_match_email": true,
  "templates_folder": "/opt/vaultwarden/data/templates",
  "tmp_folder": "/opt/vaultwarden/data/tmp",
  "trash_auto_delete_days": null,
  "trash_purge_schedule": "0 5 0 * * *",
  "use_sendmail": false,
  "use_syslog": false,
  "user_attachment_limit": null,
  "user_send_limit": null,
  "web_vault_enabled": true,
  "web_vault_folder": "/opt/vaultwarden/web-vault",
  "yubico_client_id": "51567",
  "yubico_secret_key": "***",
  "yubico_server": null
}

[RaphaelRoumezin]

I'm not really sure why this is the policy, other than to match the Bitwarden's own webauthn policy.
A hard failure on the website discouraging user verification seems like a strict policy configured on your specific authenticator key, considering this problem doesn't occur on other authenticators, such as the Yubikey. I believe the userVerification field is merely a suggestion towards the authenticator when set to preferred or discouraged.
Having it set to preferred would certainly be a more hardened configuration, especially considering the frontend supports it.

[all-solutions]

I'd be happy to create a PR and test it beforehand—including with YubiKeys—if that's OK with everyone.

[RaphaelRoumezin]

It's hard to think there is a good solution here. I understand Bitwarden's choice of discouraged as wanting the process to be more user-friendly, because in the end it's not really necessary to have user verification (PIN) for a 2FA.
You could perhaps make a PR that have this be a server configuration option.

[all-solutions]

While testing the proposed configurable user-verification policy, I discovered an important additional condition for reproducing the original timeout.

I created a clean Vaultwarden test instance from the current main branch and added a server configuration option that allows switching the WebAuthn 2FA user-verification policy between discouraged and preferred.

Initially, the original problem did not occur on the clean instance:

1. The iShield had an existing FIDO2 PIN.
2. No other WebAuthn credentials were registered in the test account.
3. The policy was set to discouraged.
4. The iShield registered successfully without requesting its PIN.
5. Authentication with the newly registered iShield also succeeded without a PIN, requiring only touch/user presence.

This is the expected behavior for the iShield capabilities:

clientPin: yes
alwaysUv: no
makeCredUvNotRqd: yes

I then continued testing compatibility with YubiKeys. After registering a YubiKey in the same Vaultwarden test account, the original iShield timeout became reproducible:

1. Register a YubiKey as a WebAuthn 2FA credential.
2. Physically disconnect the YubiKey from the computer.
3. Keep userVerification set to discouraged.
4. Attempt to register the PIN-configured iShield.
5. No PIN prompt appears.
6. Touching the iShield does not complete the ceremony.
7. The registration eventually times out.

The YubiKey was physically disconnected throughout the failing iShield attempt, so this is not caused by both authenticators competing for USB or WebAuthn access.

I then removed only the YubiKey registration from the Vaultwarden account, without changing the iShield, browser, PIN, server, or policy. Immediately afterward, the iShield registered successfully again with userVerification: discouraged.

I repeated the test with the YubiKey credential present but changed the new server option to preferred. In that configuration:

1. The browser requested the iShield PIN.
2. The PIN was accepted.
3. After touching the iShield, registration completed successfully.
4. Authentication with the iShield also succeeded and requested the PIN as expected.

The resulting test matrix is:

Existing WebAuthn credentials	User verification	iShield registration
None	discouraged	Succeeds without PIN
YubiKey registered	discouraged	Times out
YubiKey registered	preferred	Succeeds with PIN
YubiKey registration removed again	discouraged	Succeeds without PIN

This explains why the problem occurred on my production account but was initially absent on a clean test instance.

Vaultwarden passes the credential IDs of already registered WebAuthn keys in excludeCredentials when starting a new registration. Therefore, the relevant failing combination appears to be:

• FIDO2 PIN configured on the iShield
• iShield advertises makeCredUvNotRqd: yes
• userVerification is discouraged
• excludeCredentials is non-empty and contains a credential belonging to another authenticator

The iShield appears able to perform PIN-less credential creation when excludeCredentials is empty, but the same operation does not complete when Vaultwarden supplies an existing YubiKey credential in the exclusion list.

Changing the Vaultwarden policy to preferred consistently avoids this path and succeeds after PIN verification. The proposed server configuration option is therefore still a confirmed workaround, while preserving discouraged as the backward-compatible default.

I'm still working on the final implementation and completing compatibility tests with both iShield and YubiKey authenticators before submitting a pull request.

[kuchida1981]

Adding a data point from an independent case, in case it's useful for the discouraged vs preferred discussion (also raised in #7500 and my own Discussion #7556).

Authenticator: Google Titan Security Key
Symptom: Registers as WebAuthn 2FA without issue, but every subsequent login attempt hangs at "insert & touch your security key" and eventually times out with NotAllowedError. The same physical key works fine on other relying parties (Google, webauthn.io).

Unlike the iShield case above, this reproduces with a single, freshly-registered credential — no other WebAuthn credentials in the account, so excludeCredentials isn't a factor here. That suggests the discouraged UV policy causing trouble isn't limited to the multi-credential/excludeCredentials scenario described above; it can also affect first-time registration on its own with certain authenticators.

I compared the DB records for the same physical key registered two different ways:

	Registered via Chrome (discouraged, no PIN prompt)	Registered via Firefox (still prompted for PIN despite discouraged)
user_verified	false	true
counter after logins	0 (login never completes)	increments normally
credential ID length	160 bytes	288 bytes

So the credential this key produces when UV is actually performed at registration time is structurally different (and apparently the only one this key can later assert successfully against). Re-registering via Firefox — which performs UV regardless of the discouraged hint — fixed login for me without any server change.

Re: the compatibility concern raised on #7500 — since this is the 2FA ceremony (not passwordless/passkey login), the requested UV level is only relevant to the browser/authenticator negotiation; I wouldn't expect it to affect how official Bitwarden clients process the 2FA response either way, but I don't have visibility into anything beyond the public client/server source, so happy to be corrected if there's a reason it matters there.

Given there are now at least two different authenticators (iShield, Titan) from two different users hitting variants of this under discouraged, it seems like a real interoperability gap rather than a one-off. Would be glad to test a preferred build against my setup if that's useful.

For what it's worth, I'd also tried a fix on my own fork before finding #7500, and initially just hardcoded Preferred for both registration and login rather than making it configurable. Having now seen the concern raised about diverging from Bitwarden's own default behavior, I think #7500's opt-in approach (default stays discouraged, existing installs unaffected) is the more sensible way to land this than what I did — it addresses the interoperability gap without changing anyone's behavior who doesn't ask for it.

[swissbit-csteuer]

This seems to be a bug in the Windows WebAuthn implementation (Windows Hello).

In our testing, this happened under the same conditions already reported here:

1. The device supports credential creation without user verification (makeCredUvNotRqd=true),
2. another WebAuthn credential for the same RP is already registered,
3. and userVerification is set to discouraged

Windows Hello then sends an authenticatorMakeCredential request where pinUvAuthParam is present but empty (zero length):

CTAP2 request: authenticatorMakeCredential
    Map: (7 entries)
        clientDataHash: h'51b9a2cfd47e6c488963ab71380e4f06b1951fcdac43962b'... (32 bytes)
        rp: Map (2 entries)
            id: "vault.local"
            name: "https://vault.local"
        user: Map (3 entries)
            id: h'b583ee25c1d246d898c93391483d5612'
            name: "user@test.test"
            displayName: "Test"
        pubKeyCredParams: Array (2 items)
            [0]: Map (2 entries)
                alg: -7 (ES256)
                type: "public-key"
            [1]: Map (2 entries)
                alg: -257 (RS256)
                type: "public-key"
        excludeList: Array (1 items)
            [0]: Map (2 entries)
                id: h'69b52e63ddd730371e994ba896b800bd273e52b55063ac0d'... (70 bytes)
                type: "public-key"
        pinUvAuthParam: h''
        pinUvAuthProtocol: 2

Because pinUvAuthParam is present but zero-length, the authenticator enters the backwards-compatibility path defined in CTAP 2.1 §6.1.2 Step 1. It requests user presence (the iShield Key starts blinking), and after the touch returns CTAP2_ERR_PIN_INVALID when a PIN is configured. A CTAP 2.1 authenticator that supports clientPin or pinUvAuthToken is required to behave this way when it receives such a request.

Another iShield Key user has already reported that problem to Microsoft and the same Windows behavior has also been reported in the FIDO Dev group.

We will also report this to Microsoft, but an RP-side workaround may still be useful in the meantime.

In the FIDO Metadata Service there are currently 106 authenticator entries with makeCredUvNotRqd=true, including some YubiKey models.

On the RP side, using userVerification: preferred when creating the credential instead of discouraged avoids this Windows path for affected authenticators. It may be possible to keep userVerification: discouraged for authentication, but we have not tested that combination yet. Making the policy configurable, as suggested in the issue, seems like a good workaround until Windows fixes the underlying behavior.

[BlackDex]

@swissbit-csteuer, thanks for your test!
I have tested this on Linux (Arch) using the iShield Key 2 with Chrome, Chromium, Edge, FireFox, nothing seems to trigger this bug.
If this is linked to Microsoft in general, that could be why I'm not able to trigger this.

On the Windows system i have access to, i can not install Chrome or Chromium, but i do have Microsoft Edge, but there it seems to work just fine using this key.

Ill do some more testing with having this set to preferred and see if it causes any weird issues on the devices i have access too, but if not, i think we could as well just change the default. It is also discouraged to use discouraged, so why not, as at least all the Bitwarden clients do not seem to be causing issues where.

[swissbit-csteuer]

@BlackDex You are very welcome. If we can help you with testing, just let me know and I will see what I can do.

On Windows, it should not matter which browser you use, as WebAuthn requests go through the Windows WebAuthn API / Windows Hello. An application that wants to talk directly to a FIDO authenticator via CTAPHID instead requires administrator privileges.