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.
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 distinguishes 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.
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 different such document, you can ask the relevant government whether it identifies the same person as the previous document you saw.
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.
Thus why I say that probably only SSO providers can manage TOTP 2FA: without a secure 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 secure flow.
——
...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 bound 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.
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.