I use Bitwarden to store my passkeys. Syncs to all my devices and just works. I have very few issues with it. Also for the truly paranoid, you can run the open-source back end on your own server if you want.
Every vendor I see offering a solution has no documented export option at all. Yes, you can use the legacy method to login, but an authentication stream that is not used regularly is one that will break, or will ask for a factor that I no longer have access to (I wouldn't know this because I only use passkeys.)
I also expect that there will be sites that only accept passkeys eventually, even if the spec says you shoudln't.
But in general it's a bad idea to have the passkeys just sitting around in text files so the current managers are largely designed around preventing the tech support scammer from instructing grandma to dump the passkeys and email it to them.
Other than that, which is mostly only a benefit for edge cases around partially compromised devices or servers: yeah they're not much different than random unique passwords. Except they have vendor-lock-in.
But because most managers have no UI for doing this, it's impossible to trick someone into doing it.
I expect something akin to handing out the private key to your heirs is what happens. But the term "giving out" understates what happens: https://bitwarden.com/help/emergency-access/ It's an escrowed time lock. I haven't looked at the details, but I expect it's a multi step protocol involving at least two public keys. It the scheme of possibilities, it's pretty good.
If you die or become incapacitated, your emergency contact can click a button to request access to your vault. You receive a series of emails requesting that you approve or deny their request.
If you don't deny their request within a wait time that you specify in advance, your public key-encrypted user symmetric key is delivered to the the emergency contact for decryption with the their private key.
More here -> https://bitwarden.com/help/emergency-access/
I have heard this so many times that, given the big names behind the standard who benefit from vendor lock-in, it’s no wonder they are dragging their feet. Until there is a serious import/export mechanism, I’ll stay away.
I think that there are some objections about allowing user-friendly way to export passkeys as it's contradicts with their nature. But in the end they are exportable.
May be someone would build pure software implementation as browser extension which would allow export-import as PEM files and to hell with purists.
But yes, you can export passkeys. They take this format in the backed up JSON:
{
"passwordHistory": null,
"revisionDate": "2025-05-15T11:10:37.341Z",
"creationDate": "2025-05-15T11:10:37.134Z",
"deletedDate": null,
"id": "3b90b785-efb7-491b-92e8-525b446df781",
"organizationId": null,
"folderId": null,
"type": 1,
"reprompt": 0,
"name": "passkeys.io",
"notes": null,
"favorite": false,
"login": {
"fido2Credentials": [
{
"credentialId": "f167c754-5a4c-4c4a-b5e5-6faf18bde5a6",
"keyType": "public-key",
"keyAlgorithm": "ECDSA",
"keyCurve": "P-256",
"keyValue": "MIGHAgEAMBMGByqGSM49AgEGCCqGSM49AwEHBG0wawIBAQQgMnNsrXAHP50Glhs1vBPgCFVv3jj-nuZ9gHVRdGg2anehRANCAATtK7xFvDIn8mAOCniczaG5ytAE_eBR0kkgd5lFVahpI6tQ5U-nBAkgqvlmtObrWDNu0-RgiCgYnOLXFPEyda4j",
"rpId": "www.passkeys.io",
"userHandle": "47GTTn99QtyNUGaMFMzH2A",
"userName": "<masked against scrapers>",
"counter": "0",
"rpName": "passkeys.io",
"userDisplayName": "<masked against scrapers>",
"discoverable": "true",
"creationDate": "2025-05-15T11:10:37.645Z"
}
],
"uris": [
{
"match": null,
"uri": "https://www.passkeys.io/"
}
],
"username": "<masked against scrapers>",
"password": null,
"totp": null
},
"collectionIds": null
}
As for the lack of documented export options: that's kind of the point for many passkey providers. You can't export the key from a Yubikey, you can't export the keys from a smart card, you can't export the keys from an RFID dongle*, and in the same vein you cannot export the keys from many passkey providers.
What you can (or at least should be able to) do, is add a backup key. That can be someone else's PC/account in case your house burns down, or a physical Yubikey you store in a fire safe somewhere, whatever mitigations you need. You could also use a tiered setup; if you use hardware tokens to sign into your relatives' Apple/Google/Microsoft/1Password account, you can in turn use their cloud tokens to sign into whatever services they use. That way, you hand out some trust to their authentication provider, but in exchange managing physical backup keys becomes a lot easier as you don't need to open your safe every time you create a credential for an important website. You can use such a physical recovery key even if your relative prefers to log in with username+password.
On the flip-side, backup keys are not a solution for me in this instance. The model being proposed is one where we have hundreds of passkeys in our vaults, one for each service. I don't want to spend time setting up a backup key on every service; I want the ease of use of just hitting "use passkey" on a new site and having it all work. I just also want a 100% reliable backup option that has no dependency on any service, vendor-specific system or anything. Essentially, I want a backup that my grandmother could hand to a local kid with tech skills, and be able to get into my account(s) while sitting together at her computer.
This same pattern works for Google/iCloud accounts.
I can totally see the value for companies who serve users that don't use password managers—if you can get those people onto passkeys that's a clear security win.
I guess it will be a while before passkeys are the _only_ option that websites accept
Either one of us would have to choose to manually copy our logins into a phishing form in order to get phished.
I've weighed the risks and decided that I'm more comfortable relying on Bitwarden for the most critical service than I am hosting in on my own hardware and counting on my own skills to keep it available. I self host plenty of other things, but having `rm -rf /`'d my hard drive before I don't trust myself more than I trust the folks at Bitwarden.