WebAuthn MakeCredential Deadlock: RP requests UV=discouraged on a FIDO2 key with a PIN set (Error 0x4DE / CTAP 0x31)

Question

event logs.txt

I was trying to generate a security key for my Swissbit iSHield Key 2 Pro on Protons websites. It did not work.

There is a logic flaw and subsequent UI deadlock in the Windows 11 WebAuthN API when registering a FIDO2 security key (e.g., Swissbit iShield Key 2 Pro).

The issue occurs when a Relying Party (like Proton) requests the creation of a non-discoverable credential (requireResidentKey: false) and explicitly discourages user verification (userVerification: discouraged), but the user inserts a FIDO2.1 key that already has a PIN configured (clientPin: true).

Windows attempts to verify User Presence by sending a dummy/empty PIN request to the key. The key correctly rejects the empty PIN parameter with CTAP2_ERR_PIN_INVALID (0x31). The WebAuthN API translates this to Error: 0x4DE (ERROR_CONTINUE), expecting the Windows Security UI to prompt the user for a PIN. However, because the RP requested UV: discouraged, the UI suppresses the PIN prompt.

As a result, the background service deadlocks waiting for a PIN that the UI will never ask for. The process hangs indefinitely with no error message presented to the user.

Steps to Reproduce

Take a FIDO2/FIDO2.1 Security Key (e.g., Swissbit iShield Key 2 Pro) and configure a PIN on it using Windows Settings.

Open a browser (Edge, Brave, Chrome) and navigate to a Relying Party that registers server-side credentials without UV (e.g., Proton.me security settings).

Initiate the registration of a new security key.

Note the WebAuthN payload includes requireResidentKey: false and userVerification: discouraged.

The key flashes to request User Presence. Touch the key.

Result: The browser and Windows Security prompt hang indefinitely. Nothing happens.

Expected Behavior

Windows WebAuthN should properly handle the touch assertion for UV: discouraged without sending an invalid PIN token, OR if the authenticator state requires a PIN transaction to proceed, the UI should override the RP's discouraged preference and display the Windows Security PIN prompt to prevent a deadlock.

Diagnostic Data & Event Log Evidence

Captured from Microsoft-Windows-WebAuthN/Operational:

1. RP Request Details (Event 2100):

codeText

RequireResidentKey: 

2. Key Capabilities (Event 2225):

codeText

Response: 

3. The trigger - Key rejects the dummy PIN Auth (Event 2225):

codeText

Request Command: 0x90 Response Command: 0x90
Response: 0x31 (CTAP2_ERR_PIN_INVALID)

4. The Deadlock - API translates to 0x4DE but UI never prompts (Events 2103 / 1008 / 2212):

codeText

Ctap MakeCredential completed.
TransactionId: {08404f70-

codeText

State: 

Answer 1

event logs.txt

The AI responded, but it got it wrong.

The bug is that the Windows WebAuthn background service does not know how to handle this scenario gracefully, resulting in an infinite deadlock/hang, rather than a successful touch registration or a graceful failure.

Specifically:

1. The RP correctly requests userVerification: discouraged.
2. The FIDO2.1 key already has a PIN set (clientPin: true).
3. Windows correctly suppresses the UI prompt, but the underlying API sends a CTAP2 request with an empty pinAuth parameter to check for User Presence.
4. The authenticator rejects the empty PIN parameter with CTAP2_ERR_PIN_INVALID (0x31).
5. The Windows API translates this to Error: 0x4DE (ERROR_CONTINUE) internally, but because the UI is suppressed, the background service loops/hangs indefinitely waiting for a PIN that the UI will never ask for.