Passwordless Passkeys—Slow vs Fast Experience [11]

Insights for configuring MS admins, FIDO2 designers and curious Passkey adopters.

Users can be unpredictable, a lot of environmental factors can influence their decisions. Factors that one might not have predicted when one designed that authentication flow.

What might be counter-intuitive is that the MFA journey of least resistance for the user is not always the same path and not always what you expect it to be. Purchasing a FIDO2 Security Key is definitely not the default for users, which why (syncable) Passkeys were born, what this article will show however is that the relatively new default (device-bound) Passkey in Microsoft Authenticator App is not always better than the Security Key.

That being said, we must acknowledge different type of users. The majority of general users unfortunately takes less control regarding their authentication (method) and it is done to them, rather then they actively making decisions in a planning-ahead kind of fashion. This means that if the system asks them for MFA-factor A, even though factor B might be quicker, by default this user will not switch the other method. They will only switch if they fail to complete the first default method. — It can take time and effort to teach the user to “use the other door”, especially if their experiences differs per device and they need to remember different methods. (Ideally, the default is the best method; but even within a default, sometimes various paths exist.)

Picking low-effort MFA (by user)

The user that does plan ahead — let’s name them type 2 — will make choices based on the amount of effort it (will) costs. These users are also susceptible to environmental factors, but are more aware of the coming prompts and go looking for “the correct door”.

Type-2 users are able answer the question: “Is my MFA factor saved on the same device?”.¹

The goal is to gain insight in the journey regarding Passkeys from the user’s perspective and later the admin’s perspective. Some lessons can be a precursor.

[Flowchart] Picking low-effort MFA (by user) [Link]

The following factors influence where this user ends up:

1. Same device or different device authentication?
2. How often do I have to do this today?
3. What is the system currently asking for by default?
4. What is nearby me, my security key or my phone?

Let us zoom-in on the left section:

Different Device / Cross Device authentication

Regarding the frequency question: if part of your work is signing into various accounts (read tenants) frequently or your sign-in frequency is lower than a full work day, then not all methods are equal in comfort. One or more Security Keys connected to your computer (on your desk near your hands) might be the fastest way to authenticate.

Cross-device QR-Passkey flow seems slow:

Based on personal experience (so n=1), the Passkey in MS-Authenticator app is a great fallback for when my Security Key is not in arm’s reach, but is a slower authentication form:

I have to raise my device and scan a QR code and wait (one can see this as nitpicking, but there is more going here; if you have to do the QR-flow more than x times a day, it starts to feel annoying despite the technology being impressive) and do not underestimate the delay by the Bluetooth out-of-band transport setup.

The total time to task completion is higher because it takes more time than a connected Security Key’s flow. (Note that the actual Passkey exchange after your biometric is not the problem, but setting up that secure channel takes a few seconds.)

Here are the stages compared; the account is already chosen before:

Security Key flow:

1. Touch Yubikey
2. Enter Pin + Enter
3. Touch Yubikey

QR-flow:

1. Unlock Phone (quick)
2. Pick QR-button in Control Panel.
3. Raise, aim and scan QR-code
4. Wait for transport negotiation.
5. Pick Continue on phone.
6. Biometric.

So, in my mind: if the Security Key is not nearby: sure, do the QR-flow, but if the key is nearby, use that, it is faster.

Step QR-6 — representing the local authentication towards the phone —is faster than Security Key’s step 2, entering a PIN, but in order to facilitate step QR-6, step QR-2–4 take a lot of time.

If the Security Key is not nearby and the system already prompts for the 2-digits another choice happens:

I can choose to abort the push flow and start the Passkey-flow or I can just answer the push on my phone; it is a different operation but with the same device…

Reflection for Admin

I think this is an important realisation for an admin: your company’s exposure to non-phishing resistant MFA methods in this detail is determined by experienced comfort and speed. If an admin allows that two-digit PhoneSignIn as fall-back, do not underestimate how often it still will be used because in certain situations it might be quicker for the user which they might prefer and therefore never use phishing-resistant method(s).

(The only thing that might keep users from finding the “old method”, the two-digit PhoneSignIn, was explained in article[9] (deeplink): the path is several clicks away from the Passkey-flow.)

So if they keep finding & using the old method, it will leave the user more vulnerable to get phished. You would need Conditional Access policy per OS to nudge them away from that behaviour. However, do not apply a (broad) policy that forces the cross-device QR-Passkey-flow every few hours; it will not be a pleasant experience.

Not all FIDO2 authentication methods are equal in experience.

Let us zoom-in on the diagram’s right section:

Same Device Authentication

Passkey auth on-device with biometric is fast

On-device, so on-phone for example, if Outlook needs to be signed in: using a Passkey is actually faster than the two-digit PhoneSignIn method because biometric is faster than entering two digits and on-device there is no need for QR-code scanning and negotiations over Bluetooth.

It is so fast that when inquiring users about their latest log-in interaction, they could not remember how they accomplished it, but the logs did. The two-digit dance (and needing to hide the prompt because the number was behind it) they could articulate that after being confronted with it for months, but authentication with Passkey had less friction, so no memory was saved. Perhaps its because it is new and they have not been exposed that long. Cautiously I would guess they could not remember because there is less friction, but more data is required.

If Windows Hello PIN is allowed, it is fairly straight forward on a Windows device; it is the OS’s default. Windows Hello Fingerprint will be faster than Windows Hello PIN depending on the quality of the scanner and the length of the PIN; I have witnessed users struggle with both.

(Same-device evaluation was not evaluated for MacOS; expecting the Touch ID and fallback device password being part of that flow.)

Reflection for Admins

It also means that for authenticating on Windows, unless actions are taken, the Windows Hello device PIN will be the secret-unlock that unlocks the Passkey by Windows Hello to sign in the resource (or via SSO). Though this local authentication by PIN can be accelerated by a Fingerprint-reader or Face Recognition. The Windows Hello PIN is a sharable secret that could be typed in by other users, observed by others or cameras, written down and it can be used remotely when connecting via third-party remote desktop software². Additionally, users could be tricked in typing it in elsewhere accidentally.

Windows Hello is coloured orange because the PIN is a fallback that is not phishing-resistant itself and is effectively not Passwordless. It could leak. Though this argument could also be made with a Yubikey; that PIN is on-top-of a possession-based factor and cannot be used remotely because it requires a touch.

Perhaps Windows Computers needs a proximity button locally to strengthen the Windows Hello PIN. A button that cannot be emulated remotely.

However, the PIN is still not bound to the main user and still sharable, leakable, observable. — Ideally, Windows Hello needs a redesign where there the fallback could be the Security Key and the biometrics are the regular path and there is no PIN. A fingerprint button (like Touch ID) can be both a proximity button and identifying component.

Creative Setup
If Passkeys could be protected by Windows Hello Fingerprint and NOT allow the PIN fallback, this system would be stronger; however, at the moment, Windows Hello itself is not designed for the end-user not to know their Windows Hello PIN.

• Though admins can set long PINs (>25, [a-Z;0–9]) for users’ accounts (and save them in admin password managers only) and
• Then prevent changing WinHelloPIN via GPO, forcing users to only login Windows with Security Key or fingerprint or face.

It is a work-around method that works; but you still have to train the users not to interact with any PIN prompts and only the Security Key PIN prompts which can be confusing for them.

A silver lining is that for remote support of a computer, those saved Windows Hello PINs can come in handy for the helpdesk admin to unlock Windows or perform MFA actions inside the user account without the need of having to register a separate MFA factor. (Some helpdesk work might still need to be done inside the user account by mouse and keyboard (remotely) and not by script or intune.)

Knowing all this, how should admin configure the Authentication Methods and Conditional Access and Authentication Strength in your MS365 tenant?

Configuring 365-MFA by an Admin

The Always Incomplete Gigantic MFA Admin Diagram finding the balance between security and user experience.

Usually admins do not have a background in User Experience, but nevertheless they will be confronted with the experiences of their users including the user’s perspective. If you have affinity with security and usability, you might find diagram below a useful tool in deciding in how to configure MFA for your users.

Hopefully your organisation is aspiring to operate Passwordless, (timestamped [2025–05–10 | May 10th]). Generally one might hope that most resources are behind SSO, a Password manager for non-SSO resources and depending on your company’s adoption rate, you either have adopted Security Keys for at least the admins or you have never had one in your hand 😅. Extremes still exist today.

Luckily for anyone, you do have an extra type because device-bound Passkeys in Microsoft Authenticator are now an option; however, since company data may also be on one’s phone; a Security Key (Passkey) is still superior to the aforementioned Passkey in MS-App. The diagram will tell you why.

Let us take a look in what you can balance for different type of users:

[Flowchart] Configuring MFA by admin [HQ: svg, png]

This diagram tries to get everybody on Passwordless, Phishing-resistant methods. As you can see that is not always possible at the moment [timestamped 2025–05–11 | May 11th].

Get Joeri — Juramento’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

Topics that are not discussed in the diagram but assumed:

• Bitlocker + Startup PIN. (MacOs FileVault + password)
• The first mile issue; the setup of the Passkey or Security Key still requires a Temporary Access Password or a Duo Mobile Push (onboarding journey).
• If a flow path ends in ‘Allow Passkey in MS-Authenticator’, that does not mean that one should not allow the better ‘Passkey in Security Key’ for that user (group); you should allow it, but based on your choices you must at least provide the ‘lower’ option.
• Quality of MFA: Dark green < light green < orange < yellow.

Topics beyond scope that might be worth keeping an eye on:

• For MacOS silicon-based, one could unlock FileVault and login with a Yubikey’s PIV applet, smart-card feature on Security Key. However this is a different applet than the FIDO2 Passkey being used on Windows and the mac-password might still be needed in certain situations (terminal). Footnote:³
• Webauthn redirection, so local Passkey authentication passing from client to remote computer (RDP).

Key & Nuance takeaways:

1. Going Passwordless is not easy: Windows Hello PIN and FileVault Password remain not easy to prevent. Device PINs are usually fallback to biometrics.
2. Understand the difference in (phishing-)risk during an authentication towards a local device and that device’s authentication on your behalf towards an online resource.
   However; acknowledge that in User Experience, remembering a password or a (alpha)numeric PIN still net-results into needing to remember and type in a secret.
3. Regular Yubikeys have a default PIN length of 4 digits. Yubikey (5.7) FIPS have a default PIN of 8 (link⁴). Yubikey FIPS (FIDO2) PIN complexity does not prevent using dates YYYYMMDD or variations as PIN. If your users are trained and they will never configure their birthday or any date as PIN; great. If they could, you should configure the Yubikey minimum PIN length to 9 digits. (Perhaps you could settle for 7 digits as YYMMDDX is still one digit off from a shortened date; decide based on risk.)
   Setting min. length forces you to hand over the Yubikey face-to-face as you should not re-package the Yubikey and teach your employees to accept opened packages of Security devices by mail. (How could they know the difference?)
4. The relatively new Microsoft’s device-bound Passkeys are fast on same-device authentications (phone-for-itself), but potentially experienced slow on phone-for-other (QR-flow) authentications due the delay in setting up a secure connection over Bluetooth.
5. Existing authentications journeys like Password-managers interactions with Password + OTP can be experienced faster that cross-device QR-Passkey-flow.
6. Cross-OS authentication can be tricky and with many variations of Windows computers (AzVD, Win365, MSDevBox, WinPC, VM) force us to evaluate per type if Passkey authentication works to get into the VM from MacOS and if we are ably to authenticate inside the remote browser.
7. Security Key connected to computer when working, can save time when authenticating several times during the day. (Even outperforming new QR-flow.)

Designing improvements

The Windows Hello Proximity button.

Just like Fritzbox routers which require you pressing a button on the device to do protected tasks. However, for our Windows iteration, this is what I would propose:

1. It should have a LED that is usually off.
2. When authentication is required, the led will blink, before able to enter a Windows Hello PIN.
3. The user presses the proximity button and the special UI field to enter the PIN will become visible.
4. The user enters the PIN en hits enter.
5. Optionally another tap of the proximity button. (Unsure if we need this.)

The benefit of doing the first tap is that if limits possibilities of user accidentally entering their PIN in fields where it should not go or remote emulation. The OS can even interrupt the user and state: “You pressed the Windows Hello {Login | Unlock} button, but no legitimate service is requesting you to login.”

Though this design does not mitigate all risks, it mitigates some.

The Next Iteration of Windows Hello (PIN)

Imagined: Do not use a PIN as the anchor, use a (device-bound) Passkey on a phone or a Security Key as the anchor. Don’t force the usage of a Windows Hello PIN, allow the usage of Windows Hello Fingerprint and Face too without a PIN.

Regarding Bitlocker a user is allowed to add different protectors. Though the startup-pin or startup-keyfile works in conjunction with the TPM (both required). The Recovery Password or Recovery Key(file) or normal Password protector are all additional OR-access-keys. One or the other. I would suggest the Windows Hello system moves to such a design. The PIN was made too important making it inflexible.

One can use Passkey extension PRF to facilitate symmetric cryptography instead of Passkeys’ default asymmetric kind if ever needed for key-wrapping.

If needed, you can enforce setting up a “frozen” Passkey (article[9], deeplink) to the user’s MSA account or company’s AAD/EntraID or if no better fallback is available, force saving an imagined ‘Windows Account Recovery Number’.

Minimize length of QR-flow

So the QR-flow leans on something called CTAP2 over BLE Secure Channel Establishment.

So the new goal is that is must be quicker, at least for subsequent authentications that workday.

Now every QR-flow recreates a secure channel.

In design-speech: The system must never be the delaying factor in this interaction, unless it is to inform the user about system activity or status within the realm of the user’s expectations.

I expect it must take less than a second; 1000 ms. (Reference NN/g.)

My proposal would be to consider allowing a phone and computer pair to remain familiar with each other. Whatever can be done to minimize time of QR-scanning and setting up the secure channel.

The connection does not have to be active all the time, but it should be able to get in this new state, so that subsequent authentications do not take that much time and the experience should be equal to the Yubikey experience.

The challenge is that if there is no QR scanning anymore:
Q: How are we sure you are logging in the correct session?
Answer: Because you have a pre-established connection to this trusted device.
Q: What if you have more than one trusted devices linked, how would the user know they are authenticating to their trusted device in front of them and not (for example) behind them?
Answer: The user could be tricked here, but that would require an attacker having (remote) access to a trusted device already. — Thinking along though: Perhaps the trusted connection expires after a few hours and/or only one device is allowed to be the trusted device.
Q: What if the user’s machine was switched with another after setting up the trusted connection?
A: Ouch — Wait, the QR-scanning is not ideal, but the delay comes from the Bluetooth phase after the scan, so one could keep the QR-scanning, but then accelerate through the trusted connection.

The Fallback of Biometrics

Currently: Bring Your Own Device (Phone) + Fallback biometric + default iPhone PIN = employee’s family and friends might have access to company resources.

Historically, friends and family do not have access to work-password that is in the user’s memory. Now we we effectively replaced that secret in a nice Secure Enclave wrapper on the phone which is accessible by a PIN or biometric. But this means suddenly this device’s PIN is the new weak link.

A PIN a user might have shared with family and friends. It can be observed when entering.

I opt for the ability to not have the PIN be a fallback of biometrics for the Microsoft device-bound passkey. If the biometric is not working, another form must be used. If you add a fingerprint, I would like an out-of-band approval or warm-up period. I have seen certain apps ask for their own PIN or password again if you add a fingerprint so I expect there is something here.

Alternatively, a separate PIN must be settable for device-bound Microsoft Passkeys. This PIN does not need to be shared with family & friends.

This would require FIDO2 alliance collaboration because the resource needs to be able to say “this passkey must be protected by biometric only and PIN2”. Subsequently iOS would have to be able to mange two device passcodes and the user needs to learn that they should only share PIN1 with there family if needed and never PIN2. There is no enforcement they will do so however.

Recap alternative biometric fallbacks:

• Imagined frozen Passkeys on other device.
• Imagined PIN2
• Proposed having Touch ID and Face ID on 1 phone as redundancy.
• Imagined Anchor key card. (Credit card sized Passkey holder via NFC.)

Future

All this FIDO2 tech results in a session cookie that is being send back and forth between your computer and your resource endpoint, maintaining your identity. This session cookie can be vulnerable. If hijacked one could impersonate you. Next topic to prevent that: Device Bound Session Credential.

Thank you for reading.

Kind Regards,

Joeri•Juramento

References:

NN/g; Nielsen, Jacob. https://www.nngroup.com/articles/response-times-3-important-limits/

Microsoft. https://learn.microsoft.com/en-us/previous-versions/remote-desktop-client/compare-remote-desktop-clients?pivots=remote-pc#other-redirection

Footnotes

1: “Is my MFA factor saved on the same device?” → This should become a question that any user should be able to deal with: “With which key will I unlock what (digital) door?”, just like in the physical world.

2: Third-party remote desktop software cannot directly use the Windows Hello PIN to login the system, it is a local-authentication mechanism towards the laptop. A FIDO2 Security Key enforces a user-presence check — typically a touch on the key itself — before it will use its private credential. Because that tap must occur on the physical device, there is no way for an attacker to submit the security-key PIN or trigger the signature from remotely-controlled software alone. By contrast, a Windows Hello PIN is just a local unlock code: once you’ve established a session (even via RDP or remote-control software), an attacker can type that PIN into the Windows logon UI, and the TPM will release the user’s key.

3: It might not experience as a true reliable replacement like a Security‑Key is on Windows. There are more caveats for you to discover at Yubico — .‘Requiring your YubiKey smart card’ at https://support.yubico.com/hc/en-us/articles/19506639966236-YubiKey-for-macOS-login-Advanced-topics#h_01JNPKZ6N1JVHXYKH0YYZ3QSWQ

4: Table, row ‘Default minimum PIN length’: https://docs.yubico.com/hardware/yubikey/yk-tech-manual/5.7-firmware-specifics.html#ctap-2-1

Other Passwordless articles:

https://medium.com/@joeri.juramento/list/passwordfree-passkeys-beyond-43b32ef37164