Want to use your NFC passkey token with your laptop but don’t have an NFC reader, or just don’t want to lug one around with you when you have a perfectly good (Android) phone with NFC in it? You need VivoKey NFC Passkey Bridge!
Purchased. Thank you.
Unfortunately I saw this about an hour too late this morning. I have been using the authenticator app all morning booking flights and accommodation and stuff and swearing about not being able to use my Apex on the desktop! Lol
Purchased.
Samsung Phones:
- the app’s “Credential Provider Settings” button takes you to the wrong spot to enable it as a service. Instead:
- Settings → Security and Privacy → More Security Settings → Passwords, passkeys, and autofill
- When enrolling a new passkey, the phone’s Samsung Passkey storage is selected by default. Changing it to the NFC Bridge won’t get remembered for the next enrollment
- When authenticating using an already stored passkey, Samsung does seem to remember the last used credential store (NFC Bridge)
- the process of display QR code, scan QR code, wait for connection, select NFC Bridge as the credential store, scan the FIDO2 device, enter PIN, hit OK, scan the FIDO2 device has to be done very quickly or the desktop will timeout, invalidating the auth request. I’m not sure if the timeout is settable by the website/service, the browser, the OS, or something else. So far I’ve only tried passkeys.io.
Observation 1:
Windows 10 + Firefox + passkeys.io: Firefox does not prompt to use another device. It defers the request to Windows Security, which only has a prompt for using the key directly on the desktop.
Windows 10 + Chrome + passkeys.io does provide the cell/QR code option, but….
Observation #2: Initial attempt to enroll a passkey onto open-source FIDO2 applet on a P71 test card does not work unless a pin has already been set (via desktop + USB NFC reader).
Windows 10 + Chrome + passkeys.io + Samsung S24 + Android 15
Initial Conditions:
- P71 test card with the FIDO2 applet installed
- No credential for passkeys.io stored
- No PIN set for the applet
Details:
- passkeys.io → create account → enter email → Create a passkey
- Chrome prompts with “Choose where to save your passkey”, select “Use Phone” → QR Code
- Scan QR Code with phone → Bluetooth connection established –> Passkey provider selection
- Change provider to the NFC Bridge
- Prompted to tap the NFC passkey → hold P71 to phone
- Prompted “Enter PIN”
- input new pin → ok
- Prompted to tap the NFC passkey → hold P71 to phone
- Error: CTAP error: PIN_NOT_SET
Desktop:
If I repeat the same process, but select to use “Windows Hello or external security key”, click through the consent screens, I’m prompted to scan my NFC card and create a PIN. Scanning via an ACR USB reader works, the PIN gets set, and the passkey.io credential is created and stored.
NFC Bridge #2:
After I have a PIN created, I can now use the mobile/QR/NFC Bridge option to successfully:
- authenticate to passkeys.io via passwordless login using a PIN
- enroll a new credential (different email with passkeys.io) using the same PIN
So it is only the setting of the initial PIN that doesn’t seem to work via the NFC Bridge app.
Purchased.
I am encountering the same CTAP error: PIN NOT SET error, but I don’t have a Windows machine to set it. Is there any other way to initially set the pin or should I just wait for an app update?
Great observations and perfect level of detail reporting issues.
This is extremely difficult to handle properly across all the different types of Android builds. Samsung is especially prone to making significant changes to the UX across the board.
I think I should probably just remove that button completely since there is likely a >50% chance it won’t open to the correct place.
Yes.. this process is rather irritating and longwinded for passkey registration. Luckily authentication takes less time and after your first QR interaction with a device, that part of the process should no longer be necessary (if you checked the “remember” box).
Yes this issue has more to do with Windows 10 than anything. Updated FIDO2 CTAP2.x support was not well established in the OS so browsers are sometimes required to do some of the heavy lifting.. and well, Firefox just isn’t on Win 10.
An oversight. Update in the works.
It doesn’t look like you can use a hardware device as a credential store directly on Android without the bridge (e.g. visiting passkeys.io from your phone).
Linux is probably a no-go, given that it itself requires a bridge to communicate with hardware tokens over NFC.
I don’t have a Mac desktop or laptop to test with, but it should be possible. This tool looks promising, as it says it can set FIDO2 pins and has at least some NFC support (you would need a reader).
Yes – I really really wish they would just abandon making any kind of software all together.
It looks like you were using Firefox in your video, so I’m guessing there are no issues with it on Windows 11? I’ve been putting off upgrading my main desktop, but I guess its time (and I just enabled 1 year of extended support, lol).
It’s my understanding that on Win 11 pretty much all browsers hand FIDO over to the Windows OS completely, and Win 11 has more robust FIDO CTAP handling, and follows the CTAP2.2 which is where the caBLE protocol that handles “the qr code stuff” for passkeys is defined. Since Win 10 doesn’t get updates anymore and does not support CTAP2.2, I think Chrome realizes this limitation and takes matters into it’s own hands.. while Firefox does not do this and just hands everything over to Win 10, which is why this feature seems lacking when using Firefox on Win 10.
App update to handle this should be available later tonight. Not sure how quickly Google will approve but it’s an incremental update.
Sweet! Is there any way to skip the pin all together? It’s kind of a pain to type a pin while holding the phone to my implant. If not, It would be a little better if the numeric keypad came up on the pin entry screen instead of the full keyboard.
That looks like it would work! Thanks!
Re: Firefox - since this is a proprietary Google implementation (the caBLE QR connection establishment) it needs Google Chrome on the desktop side, and Google Play Services on the phone side. Firefox does not implement this Google server protocol. Neither does microG.
However it does work on Linux with Google Chrome.
There is not.. this is a requirement for resident keys (aka discoverable credentials aka passkeys) on the authenticator (Apex FIDO applet), and most relying parties (websites) also require it.
You don’t have to! Sorry the video made it seem you had to, but you can totally tap, get prompted for a pin, remove the phone, enter pin code and hit submit, then Bridge will prompt you to re-scan. I will make a note on the info page. Eventually I may re-shoot a new video that shows this is possible.
I read the first sentence of this thread and I literally spelled out loud: “oh, yes, I wanted to do this for years but was too lazy to start coding jt” ![]()
New version (1.0.5) submitted to Google for review that supports PIN SET. Also updated some small UI elements to improve process transparency.
Outstanding work is always guys. This flow seems like it will work great with Windows. My work laptop is Linux though. Does anyone know if there’s any tools on Linux that would allow for this type of functionality?
My work laptop is Linux though
However it does work on Linux with Google Chrome.
Try it with Chrome. The only thing that is needed on the desktop side is bluetooth and a browser that supports the phone/tablet flow.
Awesome!!! Thank you!!
This was on my list of things to figure out, now I don’t have to!!
Heading over to purchase.
As for Linux, I’m not sure how they are talking to it but I imagine it is some form of SPP/RFCOMM. Writing something in Linux to connect to it should be trivial. Even vibe codable. You would need a pam module that could interface with the Bluetooth profile they use.
Vivokey could even do this over USB UART.
I’m not sure how they are talking to it
Essentially, Bluetooth Low Energy is used as an out-of-band key exchange and proof of physical proximity, and then a encrpted websocket tunnel is established via a Google proxy server to exchange FIDO commands and responses.
See also:
- CTAP 2.2 Hybrid Transports at Client to Authenticator Protocol (CTAP)
- FOSS reverse engineered implementation at webauthn_authenticator_rs::cable - Rust
Google proxy server
Apparently Apple operates its own proxy as well.. cable.ua5v.com is Google’s and cable.auth.com is Apple’s. Key 2 in the QR code data tells you how many well known tunnel servers it’s aware of, not which to use. Generally speaking it’s value is 2.. which means sometimes you connect to Google’s only to get a 404 for the request ID, so you have to move on to Apple’s.


