application broken since January 2026 Patch Tuesday

[Nono-m0le]

Tested on:
25h2 Build 26200.7623 & 24H2 26100.7462

The application doesn't choose automatically the security key.

[Aldaviva]

Thanks for reporting this. I will probably have time to look at this next week.

---

Workaround

Run manually

1. Start AuthenticatorChooser elevated (as an administrator) using right click › Run as administrator, from an elevated terminal, or after enabling Properties › Compatibility › Run this program as an administrator.

Autorun at startup

1. Create a new task in Task Scheduler that runs AuthenticatorChooser with highest privileges at user log on.
2. Delete the old AuthenticatorChooser value from the HKCU\Software\Microsoft\Windows\CurrentVersion\Run registry key.

[Aldaviva]

Cause

This seems to be caused by an undocumented security change by Microsoft to the Windows program CredentialUIBroker.exe that displays Windows Security FIDO dialogs.

• Previously, the CredentialUIBroker.exe program ran with Medium integrity level (S-1-16-8192), and AuthenticatorChooser could access its UI because it also ran with medium integrity by default (when you double-click it, or Explorer starts it on logon from the Startup folder, etc.).
  
• Now, CredentialUIBroker.exe runs with UIAccess integrity level (S-1-16-8202), which is stricter than medium. This means that any program like AuthenticatorChooser with lower integrity can't access its UI.

   d | 2026-01-18 23:51:48.536 | WindowsSecurityKeyChooser | Window is not a passkey choice prompt because it does not have a ScrollViewer child
  

  

Solution ideas

1. Run AuthenticatorChooser elevated (as an administrator), which gives it High integrity (S-1-16-12288).
   • To autostart an elevated process on logon, you need to switch from the Startup folder or Run registry keys to a Scheduled Task which runs at user logon with "Run with highest privileges" enabled.
   • I believe it is possible to automate the creation of this scheduled task, for example to reimplement --autostart-on-logon, but even that automated step would need to be run as administrator, and I am not positive that it would be a good idea to attempt to migrate users automatically.
   • I tested this by right-clicking AuthenticatorChooser and running it as an administrator.
   • This is the approach used by AltSnap, PowerToys, DisplayCAL, EVGA Precision, and a ton of other programs that need to start elevated on logon.
2. Compile AuthenticatorChooser with UI Access, which gives it UI Access integrity (S-1-16-8202).
   • Requires uiAccess=true in the application manifest file.
   • Requires Authenticode signature, which is fairly expensive over time. The best price I have found is $92.40/year USD when prepaid for 10 years, which is a large upfront cost.
   • May require the program to be installed inside Program Files, not some other top-level folder.
   • I have not yet tested this with a self-signed code signing certificate, so I'm not sure this would work. I'm just guessing based off of some Visual Basic weirdos in an OLE DnD forum post from 9 years ago.
3. Mess with CredentialUIBroker.exe's integrity level, which sounds brittle, not secure, and overall a fool's errand.

[AFulgens]

$1k for 10 years to fix a UX debacle of MS in an OSS project? That's an absolute no-go from my point of view, especially if it additionally needs installing into Program Files.

For me as an end-user it seems so that solution 1 is the pragmatic way to go. Unfortunate (many of us in enterprise environments will have to jump hurdles to start a "low-impact" OSS software as local admin), but it's what it is.

[Aldaviva]

To clarify, you can choose to pay for only 1 year at a time instead of 10 years prepaid, but unfortunately the price per year is twice as high if you do so, leading to a higher total cost. But yes, code signing pricing in general is very frustrating, and I wish I could sign my programs as cheaply as enabling TLS on an HTTPS server. And to think that we almost got free signing with Sigstore/Fulcio…

I will try to automate creating an elevated scheduled task. The open questions are more around how to nicely and intuitively keep users from getting stuck if they don't update the startup entry, or if the old startup entry is not removed and it tries to launch twice and gets stuck in the non-elevated process.

[Aldaviva]

First attempt at creating a Highest Privileges scheduled task for the current user with --autostart-on-logon committed to the elevated branch for now.

[DennisGaida]

I'm on Windows 11 25H2 (26200.7628) and even starting AuthenticationChooser.exe via an elevated shell or right mouse button > Start as Administrator doesn't help it to find any FIDO popup. The log is rather silent, when started with -l:

 i | 2026-01-25 12:13:10.934 | Startup                    | AuthenticatorChooser 0.4.0 starting
 i | 2026-01-25 12:13:11.124 | Startup                    | Operating system is Microsoft Windows 11 Pro 25H2 10.0.26200.7628 AMD64
 i | 2026-01-25 12:13:11.191 | Startup                    | Locales are de-DE, en-US
 i | 2026-01-25 12:13:11.247 | Startup                    | Waiting for Windows Security FIDO dialog boxes to open

Unfortunately same log result, when starting via Task Scheduler > Run with highest privileges. The dialog box itself is a bit of a weird mix between German & English, but I don't know whether this is the problem: