I am currently waiting for my Jolla phone 2026, and I was wondering what the passkey support is like on the Jolla phone. Could I register the phone itself as a passkey device or can I use the passkey inside my bitwarden using app support to authenticate me in a browser on sailfish OS? Would love to know it from somebody already in the possession of the Jolla phone.
nobody knows???
I would like to know if it is possible, or coming in the feature.
So I’m not sure, as I don’t use passkeys myself, but I have never seen a passkey prompt even for websites where I did set one up at some point. I do use a browser inside AAS, I don’t know if the native browser does anything with passkeys.
It’s not possible. AAS is using Android 13, passkeys are from 14. Native SFOS also has no concept of webauthn/passkeys, not to mention no support for this in that abandoned keepass client.
SFOS version 5.2 has android level 15 
2 Likes
With YubiKey Nano 5C I ran into 5.2.0.16: scdaemon --server Segmentation fault (core dumped) - normal?
I have a passkey configured in my bitwarden, so should a browser app be able to read this?
Then apparently they disabled passkeys via some config. I went to those Android settings and it’s not there (compared with LineageOS where the entry is there and I can point to KeepassDX as passkey provider).
There is no normal passkey support 
I use passkeys to log into a few services and the browser does not support it. Will either straight fail or will spin and time out.
(Using Sailwarden as an fyi)
So I have to copy the url, send it to my iPhone, passkey auth there and the continue on on the phone (for things I self host or tailscale)
Thats a big turnoff, for a secure OS i would have though passkeys are supported since this enhances security overall
2 Likes
Passkeys in a password vault shared between devices isn’t really any more secure than just storing passwords in that same vault afaik. All you’re “proving” in both cases is that you have access to the vault. They’re supposed to identify one single device, sharing them defeats a big part of the purpose.
2 Likes
More probably they haven’t enabled those if it is a new thing. And I’m not even fully sure how those can work in virtual container, which doesn’t know at which device you are using it?
not always, since i have 2 factor on my password vault ass well. Plus it has no password the account, so brute forcing a password will not work. Passwords in general are bad nowadays
1 Like
>Passkeys in a password vault shared between devices isn’t really any more secure than just storing passwords in that same vault afaik. All you’re “proving” in both cases is that you have access to the vault. They’re supposed to identify one single device, sharing them defeats a big part of the purpose.
Passkeys are not solving the “my password will leak problem”. Passkeys are ensuring my credentials are strong, I don’t re-use them and I’m not able to put them on a malicious website that would pass them along to an original domain.
On top of that, since websites know passkeys are non-reusable, strong and not coming from a man in the middle, they tend to be less annoying while logging in (e.g. less MFA).
2 Likes
Sure, but all of that is also true if you correctly use a password vault. Generate strong passwords. Don’t re-use passwords (sure hope that’s the reason you’re using a password vault at all, otherwise what’s the point). And no password manager will offer to fill a password on a non-matching domain, unless you set it up to do so.
Also, a passkey is still a single factor. You should still use multiple factors (which are stored separately from where the passkey is stored).
This is not my point. My point is that passkeys enforce all of that so website owners can use lax rules when someone logs in with a passkey, instead of normal password.
A quick check with chatgpt why passkeys are beter in terms of security, and why i love them:
Why passkeys are safer
| Password | Passkey | |
|---|---|---|
| Phishing resistant |  |
 |
| Can be guessed |  Yes |
No |
| Can be reused | Often |
No |
| Stored on server | Usually a password hash | No private key |
| Credential stolen in a database breach | Potentially exploitable |
Generally useless |
| MFA-like protection | Not inherently |
Often combined with device unlock |
| Easy to use |  |
 |
The big difference is cryptography.
With a passkey, your device creates a key pair:
-
Private key → stays on your device/password manager -
Public key → stored by the website -
The website never receives your secret/private key.
When you log in, your device proves that it possesses the private key. Your fingerprint, Face ID, PIN, etc. can be used to authorize that operation.
The biggest win: phishing
Suppose you receive:
“Your Microsoft account has been locked. Click here to log in.”
With a password, you might enter your password into a convincing fake site.
With a passkey, the credential is bound to the legitimate website’s origin. A fake microsoft-login.example site can’t simply ask your passkey to authenticate as Microsoft.
That’s one of the biggest security advantages.
What if someone steals your phone?
This is where passkeys are particularly interesting.
If your passkey is protected by your device’s PIN/biometrics, simply stealing the physical device generally isn’t enough to use it. And depending on where you store your passkeys, they may be synchronized to your other devices.
For example, if you’re using a password manager that supports passkeys, you could have the same passkey available on your phone and computer.
But passkeys aren’t magic
There are still things to consider:
-
Account recovery can become the weak point.
-
Losing access to all devices/password-manager accounts can be problematic.
-
A compromised device can potentially be used to authenticate while you’re logged in/unlocked.
-
Some websites still have weaker fallback methods such as SMS or email recovery.
So I’d rank authentication roughly like this:
Password alone
Password + authenticator app
Password + hardware security key
Passkey 
Passkey + strong account recovery/security controls 
For everyday accounts, passkeys are one of the best authentication methods currently available.
3 Likes
Heya @RandyMartin 
Appreciate the write up but don’t get baited to respond to comments like that or this thread will become like the “I hate Auto Complete, therefore I don’t want anyone on Sailfish to have it either” thread.
+1 for passkeys
Let’s wait for the devs to give feedback
3 Likes
Please, no full AI spam I can counter that with only AI conclusion:
AI stuff starts:
Bottom Line
A strong password + vault is often more secure in practice because:
-
It’s portable, auditable, and recoverable.
-
It works everywhere, including legacy systems.
-
It allows defense in depth (e.g., hardware tokens + offline backups).
Passkeys are the future and excel at phishing resistance, but they’re not a silver bullet—especially if you lose your device or need offline access. **A well-configured vault with strong passwords and 2FA is currently the most robust option for most users.
AI stuff ends**…
Again, someone who know, how can passkeys even work on android side, when android is running in emulator, not on actual device?
Again, someone who know, how can passkeys even work on android side, when android is running in emulator, not on actual device?
Android has an API for passkeys (and other credentials). AAS would have to include a stub that bridges this to the native SfOS keychain, when it supports passkeys anyway.
1 Like