Authentication transition to Passage

As mentioned in this weblog post, we’re going to be upgrading to Passage by 1Password for authentication. It’s going to be great! And pretty much seamless for everyone, with the exception of needing to add a new passkey (sorry, no way to avoid that).

I’m dropping this post here for any questions or discussion related to the change. :+1:


I understand your motivation to want to drop 2fa, but isn’t it to soon to completely drop 2fa?
On every device except for my phone) I’m going to have to use the email fallback method if I can believe this site: Device Support -
And somehow a link send via email feels not as secure as a password with 2fa.


I know we discussed this at length on IRC, but I’m sharing a response here for everyone’s benefit. I think dropping 2FA is safe given the nature of passkeys and the secure way that Passage’s email authentication flow works. Email fallbacks are never ideal, but at least Passage’s is really well-designed and super fast/efficient. And finally, we’re seeing rapid expansion of support for passkeys in general, especially given the way that cross-platform password management apps are adding support for the technology. I think we’ll soon be at a point where there really won’t be any need for the email fallback (but it’ll always be there) and passkeys will be ubiquitous!


Maybe also important to say is that if you don’t have well supported devices (like Linux) some password managers seems to make it possible (or going to make it possible) to store passkeys over there: bitwarden or 1password for example.

I wasn’t aware of that…


Handing over auth to a 3rd party, even 1pass, does give me some pause. Passage docs say that SMS is a fallback method, anyway to disable that?

1 Like

I completely understand, though for me it’s less about “handing over” and more about using a trusted partner to deliver a top-notch service, just as I do with Stripe for payments. We rarely feel any level of pause over indie devs using third parties for payment processing, yet I’d argue that there’s just as much personal security at stake in that than in authentication. And in this case, with Passage specifically, there is virtually no risk in this equation — all Passage holds is an email address and your passkey’s public key. I wouldn’t be making this move if I felt that it would be problematic for members or endanger their privacy or security in any way.

For me, this is about streamlining things in a way that provides the best possible experience, and using a solid service that does a darn good job of accomplishing that goal. My own present passkey implementation has some flaws (there are some folks on Android devices that have never been able to get their passkeys to work), and I’d rather spend my time working on features than staying stuck in the engine room working on the least interesting components of the service (like authentication).

Of course I’ll keep my own email-based authentication online in the background for a hot-swappable fallback in the event of any disruptions with Passage, so we don’t have to be concerned with any show-stopping problems with a third party.

Finally, yes, SMS will be disabled entirely. Just passkeys with an email fallback. :+1:


Congratulations on the update, @Adam!

From a support standpoint, I noticed that creating a passkey failed because I already had one for Is there a way to catch the error condition on the server side and tailor an error message that says “you’ve already got one; delete it and try again”? The error message just said “try again”.

1 Like

How will the initial login work once this purging of all old login details occurs? Will it be via email link, and then once in we reset the passkey?

1 Like

I was able to add multiple passkeys yesterday from a single device (an m1 macbook):

  • touchId using the fingerprint reader on device
  • a plugged in yubikey 5c
  • from my nearby pixel 6 using qr code + bluetooth

Today, none of those passkeys were present on my account, and I can only add a touchId passkey.

@mfisher good question; I’ll need to look into this. I think a lot of it depends on the OS and device; I also had a passkey for but didn’t have any issue adding a second one on the same device earlier. Let me do some digging and see what’s up and what the options might be for catching any kind of conflict like this.

@pimoore precisely — your first login will be with a “magic link”, and then you’ll be prompted to add a passkey. Subsequent logins can be with a passkey (if added) or with email links. It remembers you in either case, though, making the process a bit speedier after the initial login.

1 Like

@asdf Depending on when you added those, they may have been with my prior home-grown passkey solution (which was not a great solution — case in point, it allowed hardware keys like the Yubikey, which the actual passkey spec doesn’t allow). With the cutover to the new authentication process, all prior passkeys no longer work, but if you add a new one through the new UI today, that one will work indefinitely.

I’m sorry for the confusion on that! I’m still working on cleaning up a few things and will get an email out to all members with more clarification later today.

Passkeys are so full of win, so I for one definitely appreciate your adopting them so quickly!


unfortunate that (external) hardware keys are out of the passkeys spec. hardware token + pin seems just as secure as the other devices with hardware tokens built in

1 Like

It does seem a bit strange, though the caveat being you need two devices instead of just using your current one to login. Apple’s devices in particular are so secure between the biometrics and hardware enclave, that using a physical key for passkeys would be questionable. Not necessarily from a security standpoint, rather from being a lateral move with no tangible benefit nor improvement, IMO.

1 Like

I’m really excited about this change. As someone that deals with lost passwords from customers daily, it will be nice when this transition is over and we’re all on the same page with it.

I am curious how much this scenario is going to play out in the support’s day to day world, tho.

“It’s been 2 years since I setup my passkey. My email address has changed, but I didn’t change it in my account. Now I need to login on this new device, but it’s sending email to my old address that I don’t have access to anymore. How do I get access?”

This type of scenario happens all the time for us - mostly students or employees that have moved on from the organization. Currently, as long as they remember their password, they can login, then change their email and be fine. But in this passkey scenario with email as backup, that wouldn’t be available, right?

I really want to move toward this at my organization. Thanks for taking the big leap forward for the rest of us. I’ll be watching closely! :eyes:


This is not true, this is just a limitation.

1 Like

You’re right, and I stand corrected! Sorry for the inaccurate info. Passkeys can use both roaming and platform authenticators, but Passage has made the decision to pursue an implementation that emphasizes the user experience.

More info here: Platform Compatibility - Passage Docs

My conspiracy theory is that 1Password is just waiting to finish their own implementation, which will obviously both be a roaming authenticator and supported by Passage, and they don’t want people getting used to their competitors in the meantime :laughing:

Edit: Tomorrow, apparently!

Edit 2: Interestingly, Passage does support signing in with roaming authenticators, it just doesn’t allow you to register a roaming authenticator. So this seems mostly intended to specifically exclude hardware security keys :cry: (and also makes me suspect roaming authenticator support won’t be added when 1Password releases Passkey management unfortunately).

1 Like


1 Like