Personally, I think true 2FA—of TOTP-type 2FA tokens that most people mean when they say “2FA” these days—can only work in the context of a SSO service / “identity provider” (in OpenID parlance) which requires KYC document submission (birth certificate, passport, etc.) upon sign-up.<p>In order to be able to prove who you are to reset your auth credentials, you have to have proven who you are when you set up the account, in a way which <i>distinguishes</i> your identity from that of others who share some-but-not-all of your attributes (e.g. your legal name.) Otherwise, anyone with those same attributes “has the key” to your account.<p>The only convenient way to create such a distinguished profile, is to hand over some legal identifying document that is linked to a pool of other identifying documents, such that if you later see a <i>different</i> such document, you can ask the relevant government whether it identifies the same person as the previous document you saw.<p>This requires keeping around identity documents for later comparisons, which is a fraught problem. I’d rather trust as few companies with my identity documents as possible—especially if I know that they’re going to need to keep them on file.<p>Thus why I say that probably only SSO providers can manage TOTP 2FA: without a <i>secure</i> 2FA-reset flow, they don’t “really” have 2FA; and only very few companies (i.e. identity providers) are able to be trusted with the documents required to implement such a <i>secure</i> flow.<p>——<p>...none of which matters all that much, because the real problem is TOTP itself, and the solution is to switch to a better type of 2FA. In the original enterprise 2FA smart-card implementation, it wasn’t the company with the account requiring auth that issued the 2FA token, but rather a separate 2FA issuer. The client would then get their card <i>bound</i> to each account they wanted to use it to authenticate. The card had a signing key, and the services just needed its matching public key.<p>With “real” 2FA impls like this, you aren’t supposed to need N 2FA tokens that you would need to reset separately with each rinky-dink authable service, but rather just one 2FA token, with token rollover—and the security around it—handled by the issuer. Use better 2FA.