Maybe (T6549). I think it mostly serves to reduce the support burden on administrators, and no one's really complaining about that today.

For Phacility, attackers will just say "I also lost / didn't save my backup codes". I don't think there's a case where we'd say "okay, we'll strip" today, but would say "sorry, we won't strip" if we had backup codes, so this doesn't do much to improve cluster security.

I think the quorum approach (T7639 / T9515) is more promising on both the "support burden" and "actual security" dimensions -- in basically every case, I'd change "okay, we'll strip" to "okay, we'll modify your quorum to include the other instance managers and you can ask them for help getting access to your account" if we had the quorum feature. Pretty much the only exception is one-user installs.

(A short term "fix" for this is that I'm planning to deprecate admin.phacility.com MFA, but that's because users keep enrolling themselves by mistake, not because instance managers are losing their phones.)

If a customer install was like "I'm an administrator and spend all day verifying secret handshakes and stripping factors, can we make this easier" I'd probably still try to push toward quorum over backup codes -- I think quorum is just generally a better approach here on every dimension. Maybe that'll turn out to be untrue after we build it, but it seems like it's easier for users, more secure, gives administrators more flexibility in not making a call with limited information, can't be lost or stolen or observed by an attacker, etc. And you can stage attacks on it for fun to keep everyone on their toes.

I think it's only worse if users turn out to be wildly eager to approve absolutely anyone's account recovery without verification, and if that's true it's probably good that you can discover it by staging an attack, since it represents a generally poor attitude toward security.