Nitrokey 3A fails to work on GrapheneOS when using Google's FIDO library

This is a continuation of the discussion on the blog found here.

Authenticating via security key on Android is done on the browser, and all of my attempts to do so are failing. Firefox and Vanadium both support this functionality via Google’s FIDO library through Google Play Services, which appears to the the problem.

For example, upon authenticating to Bitwarden’s webvault using Vanadium web-browser I get:

NotAllowedError: The operation either timed out or was not allowed <...>

Google services also crashes:

However, something to note is that this is not an issue with the PIN (this happens even if one isn’t set up), and that all functions work as expected when using a third-party Webauthn implementation (For example the “FIDO2 / Webauthn test” app on Google play, which has no issues).

I was able to reproduce the exact same issue on another phone (LineageOS with Gapps). Hoping that someone could take a look at this.

Hey @SomeUser

what we’ve found so far:

  • it looks like PIN generally is not supported by Android’s native FIDO2 implementation
  • in contrast iOS seems to work
  • using a yubikey we see the same behavior on android
  • despite that also using a PIN does not work using the Nitrokey 3 connected via USB
  • using a 3rd party FIDO2 implementation most things look good

so under the line this is very much a Android limitation from what we know so far…

Hello and thanks for the reply, @daringer.

It’s good to hear that the issue is reproducible. I infer that the course of action is to try to report this to Google’s Play Services team directly. Can I be of some use in this case, like with a logcat report?

Generally, I would assume that this is no bug, but a feature. I don’t think they have accidentally left if out, this feels like a intentional limitation. But if you are willing, feel free to report it to the Google Play Services team, I am happily watching this thread and furthermore a confirmation from Google about this missing functionality would also be worth it. (As I haven’t found a reliable source for this information).

Additionally, we’ve been playing around with this topic and found out that is a reliable source to test this, using this website you can easily reproduce both (good & bad) cases:

  • go to and open the advanced options, both “Require User Verification” must be activated (default), then your use-case occurs and neither register nor authentication works
  • go to and open the advanced options, both “Require User Verification” must be DEactivated, then register & authentication work perfectly fine


I’ve looked into the possibility of reporting the issue to Google themselves, but I’m not sure how this can even be done. The closest feature to bug reports they have is their “support help community”, which is just practically randoms answering questions relating to basic issues. I doubt it’s possible to get any employees this way, so I’m not sure where I’d even begin with it.

Android support is quite important for a lot of users, since practically everyone needs to access something locked behind 2FA on their phones, so it’d be a huge bummer if the NK3 just didn’t work with it in the end.

Yeah, I also had the thought that “find-the-right-place-to-file-a-bug” would be the major challenge here, looks pretty much like a lost cause.

On Android support in general, as I mentioned previously the support for FIDO2 in general is working fine. So for instance, I can report that the NK3 works perfectly fine as a 2FA for Github, Gitlab, Google and various other logins where the NK3 is used as a 2FA.

Notably Microsoft does not even offer the option to log in via security key using an Android device. I would assume, this is done intentionally, as the NK3 is used for password-less logins at Microsoft, which implies saving and using a Resident Key. The latter can only be done using a PIN, which is not supported by Android’s Webauthn implementation. (This essentially is the case with activated “Require User Verification”)

Coming back to your initial point, I believe Bitwarden is doing exactly that, they require a Resident Key, which is essentially not supported via Android.

Overall there is very little we can do, Bitwarden could change their login to also support Android, or Android could support pin-based FIDO2/Webauthn operations - but Google has inherently not too much motivation to open doors for functionalities that might reduce the immediate dependency for a (Android) Smartphone, but that’s another story :slight_smile:


I tested out’s demo and yes, everything works perfectly fine without “require user verification”.

Bitwarden isn’t necessarily the only service that’s affected by this shortcoming on Google’s part, it’s just about every single service I’ve tested.

I wish there was a way to contact Google, but they seem to have built a very strong wall around themselves for protection against consumers seeking help. I’ll try checking out what Bitwarden can do about it.

I haven’t been able to receive much help or information around, however, to me it seems that the underlying issue is Google Play Services not supporting the CTAP2 protocol entirely. Discussions about it date back to 2020 as far as I can tell, and iOS has supported it for a while now.

Until Google does something about this, the only “mitigation” is for developers to use another Webauthn system.

People had the same problem with microG (FOSS play service reimplementation). The developer linked to an issue in the Chromium bug tracker that mentions it. Maybe that helps.

A PIN only makes sense when you want to go “passwordless” (so the FIDO-Hardware checks for something you know). Google has a different strategy there. From what I understand they push passkeys which would be FIDO platform authenticators instead of independent hardware.

oh and this also contains a trace to google: 997538 - chromium - An open-source project to help move the web forward. - Monorail

quoting from May 11, 2021:

Chromium is not Android, and I don’t speak authoritatively for Android, but if a timeline estimate is important to you then I don’t expect that a move into AOSP will happen in next couple of years. Not for any deep reason, just based on staffing.