You'll need to implement views for handling recovery tokens, processes for people losing their second factor due to stolen phone or corrupted app, and FAQ pages for questions about why my second factor is not accepted.

Bingo. The support cost of MFA, especially non-SMS methods where some of the recovery process is delegated to the mobile operator, is the top-level bit.

It’s frustrating to see technical people discount or ignore that side of the deployment work, because that’s the kind of issue that actually blocks most security and cryptography measures in practice.

If I had a thousand dollars for every time I heard “just make the user keep a key safe” I could fund so much UX research :)

sneak’s law: users can not and will not securely manage* key material

* generate, authenticate, distribute, back up

Google Authenticator AFAIK doesn't even let you backup the codes. When your phone is lost or breaks, you have to reset every account by some other way.

Use Authy, 2faone or any other totp tool than google authenticator. Shame on Google, honestly, for not enabling a backup mechanism for that. If you can’t do it right, don’t do it at all.

I use AndOTP. But I imagine most people will use use Google Authenticator and not think about backups until it's too late.

https://github.com/andOTP/andOTP

(And yep, I found out about Google Authenticator the hard way, trying to transfer from my previous phone!)