I’m an advocate for passkeys and I abolished passwords and embraced discoverable passkeys for our org’s key internal systems exclusively. So the battle cry of a title immediately put me on the defensive, unfortunately. The urge to not read is strong. A more measured title may help here.
But there’s definitely a kernel of truth here. 1Password recently began to enforce userVerification: required[1][2], and suddenly on the desktop without TouchID I have to enter my login password to use the passkey on a good number of websites. I didn’t sign up for 1Password 15 years ago so that I have to enter both my very complex master password and very complex login password to sign into websites, the “one password” contract is suddenly broken after 15 years. This experience independently alarmed me about the additional constraints potential of the passkey standard and power wielded by the FIDO Alliance and partnering organizations addressed in TFA, which are, to be clear, useful for security in an organization. (We use userVerification: preferred now btw.)
Therefore, I believe the passkey technology is great for enforcing a standard of security in an organization and stand by my choice for my org. But as a general purpose B2C auth tech, if the additional constraints become widely adopted, user freedom will be seriously harmed.
Edit: I asked Opus 5.5 to vibe code a passkey auth solution in Go a few times without saying anything specific about userVerification. It chose required each time. So expect to see more of these. Oh and vibe coding auth without understanding it entirely is bad, please don’t do that.
[1] https://web.dev/articles/webauthn-user-verification
[2] https://www.1password.community/1password-at-home-31/user-ve...
1Password suddenly offering to save passkeys without mentioning that they can't be exported to other apps (but are seamlessly synced between devices using 1Password) is what lost them "good guys" status in my mind.
It immediately creates a huge lock-in in a hard-to-notice way. Luckily, I did noticed early on and manually removed the 20 or so passkeys I had created.
Earlier this year, I lost my iPhone and restored from backup. I was shocked to see that I could log into my 1Password account using only the master-key, and that the secret-key was not required. 1Password clearly stated that the secret-key was required to setup a new device, but it turns out that they also (perhaps recently) configure it to upload to all devices in your iCloud account[1]. Ever since then, I've lost faith in 1Password's ability to communicate their security model to me and started looking for an off-ramp.
[1] https://support.1password.com/secret-key-security/
Oh, also, the firefox extension recently rolled out this feature, I think it was default-enabled:
What the f does 'next-generation' mean? No link for more information. Obviously I have to turn it off, else for all I know it will start setting up passkeys (now or in a future update) or do something else anti-user. And it also means that I need to be careful about updates to 1password. Sad to watch my relationship with my password manager go downhill.
For all I can tell it simply moved the popup widget from below the actual input to the top middle of the page, and now preemptively prompts a lot more aggressively, sometimes not even on a sign-in page.
> What the f does 'next-generation' mean? No link for more information.
It means "Just shut up and use it, someone's bonus and/or promotion packet is depending on the usage metrics.". :P
For passkey export, there is a FIDO specification for both a format and secure protocol for exchanging passwords and passkey information between password managers, with support on all Apple platforms, and implemented by 1Password, Bitwarden, Dashlane, and more:
https://rmondello.com/2026/09/07/switching-password-managers...
https://fidoalliance.org/download-credential-exchange-specif...
For the iCloud syncing, I believe they've done that since iCloud Keychain/Apple Passwords was first a thing; I've been aware of it since they introduced it, but perhaps that was more explicit when it was first added. The comment below from a now-defunct 1Password employee account describes the thinking there:
> Importantly, the entire role of the Secret Key is to protect you from us and anything that might happen on our end, like a breach of 1Password’s servers. It does not (and can not) protect you from a local attack. This is mentioned in 1Password’s Security Design white paper [ed: on page 74 of an old PDF; I've linked the newer HTML document below], which goes into detail about the locally exposed Secret Key.
https://www.reddit.com/r/1Password/comments/10iqhdp/comment/...
https://agilebits.github.io/security-design/index.html
I do get why that might be surprising. Without going through the whole onboarding process on a fresh device I can't say how well they highlight that or how easy it is to blow past. All I can say is 1) I've known about it for years and 2) having read through the white paper of how iCloud Keychain works I _personally_ trust iCloud Keychain/Passwords about as much as I trust 1Password, maybe _slightly_ more - but I am also not a security professional, so take my word with very little salt :)
To be explicit, 1password did not offer passkey export for more than a year after they were introduced. 4 years later, here is 1password's page on exporting your data[1]. It says:
So that's not great. Let's look at their page on the 1pux export[2]:
And the word "passkey" does not appear on that page. Why are these docs still written like this after 4 years?
And for the record, this is not impossible. Bitwarden does it[3] via the magic of "ignoring the part of the specification that says not to give users their data." Any open source software would do the same. This is why 1Password is no longer the "good guys" despite having rationalizations for their actions.
[1] https://support.1password.com/export/
[2] https://support.1password.com/1pux-format/
[3] https://bitwarden.com/help/export-your-data/
This is where the attestation feature comes in, there's a reason it was part of the initial spec and key transfer was a "we'll get to it later". They will use it as a weapon to blacklist providers that don't play by their rules.
https://github.com/keepassxreboot/keepassxc/issues/10407#iss...
https://github.com/keepassxreboot/keepassxc/issues/10406
If you want to see an example of pro-user behavior, read the github thread where a FIDO developer asked keepassxc to disallow exports of passkeys[1] or to reprompt for the db password if the website requests it[2]. The conversation was roughly:
[1] https://github.com/keepassxreboot/keepassxc/issues/10407
[2] https://github.com/keepassxreboot/keepassxc/issues/10406
> For passkey export, there is a FIDO specification for both a format and secure protocol for exchanging passwords and passkey information between password managers, with support on all Apple platforms, and implemented by 1Password, Bitwarden, Dashlane, and more.
Does (more) here include free software like keepassxc and friends which don't restrict what key owners do with their keys? Last I heard, FIDO was moving to ban them.
Regarding just the iCloud syncing, I appreciate the additional color.
Though, I do find it amusing that I commented about 1password's inability to communicate their security model, and your reply links a reddit post[1] in which everyone is disagreeing over whether or not iCloud secret key syncing actually occurs.
[1] https://www.reddit.com/r/1Password/comments/10iqhdp/comment/...
> For passkey export, there is a FIDO specification for both a format and secure protocol for exchanging passwords and passkey information between password managers, with support on all Apple platforms, and implemented by 1Password, Bitwarden, Dashlane, and more:
Note who is excluded from this list: the End User. The protocol only allows exchange between password manager vendors who choose to interconnect.
hmm, I'm sure with a model that is not restricted, one might be able to extract these locally.
That's not a "not good guys" event. That's a "lifetime in prison for all people involved" event.
They'll have to do this or they'll be blackballed using attestation and certification weapons the FIDO alliance possesses: https://github.com/keepassxreboot/keepassxc/issues/10406
You don't get to decide how to use your passkeys, some on else does.
The vibecoding part is probably because "userVerification: required" is essential to have it work somewhat-securely as your sole form of security - like Passkeys is heavily promoting. Without it anyone with physical access to the device can use it to log in. This might not be so bad for a password manager which already has strict session password requirements and short timeout periods of its own, but it is a completely different story with, say, a Yubikey.
If you're building a Passkey-based login page and you specify "userVerification: preferred" or "userVerification: discouraged" you are essentially reducing your security to a single factor - namely the "something you have" one.
The vibe coding attempts I tried weren’t passwordless. For the actual passwordless internal system, AAGUID is checked so only whitelisted password managers are allowed, “something you have” hardware keys are not accepted. I know AAGUID can be spoofed but employee somehow hacking part of the process just to register a hardware key against policy isn’t really part of the threat model.
The change to 1Pass is annoying and I don't mention these to discount your valid concerns with it, only to make people aware of the options that can help with this and make it less taxing than continuously entering a password:
* On Windows you can enable Windows Hello for biometric authentication.
* On Mac, as shit as it is, you can buy Apple's magic keyboard with TouchID (for crazy money, but still) and use it while the notebook is shut.
I hope 1Password can eventually consider adding something like face recognition from a webcam as an alternative method.
Unfortunately, without this they are not compliant and it gives a false sense of security to claim it is multi-factor when it's actually only one factor. You'll find the same with other Passkey stores like Kevault that require biometrics as well.
Yeah I thought about getting a Magic Keyboard with TouchID for this, but ultimately decided against being strong armed into replacing my beloved keyboard for a decade plus with one I may not like. And I happen to like Apple’s keyboards (at least the early mid 2010s ones) and sport an old Magic Keyboard; it’s even less of an option for people who swear by loud mechanical keyboards with long key travel.
If you have or acquire an Apple Watch - yes, I know, it's a _different_ several hundred dollar device - and enable the "unlock your Mac with your Apple Watch" feature, it will function in _just_ about every place that Touch ID is required, including the 1Password Touch ID prompts. Like some other Apple functionality, it does some sort of fancy Wi-Fi/Bluetooth time-in-flight calculations to ensure the watch is close by before it unlocks your Mac, with a tap on the wrist and a button to re-lock your Mac if needed; and it requires a double-tap on the side button for application authentication prompts.
Huh I didn’t realize that feature worked with Mac Studio & mini too, thought it’s MacBook only. Definitely a solution for some. I have one gathering dust since the benefit of feeling nothing on my wrist outweighs the value it provides, after wearing one for a couple years.
Substitute the title for Passkeys Considered Harmful.