I think the initial question can be understood in two different ways:
- Incorrect recovery phrases: It seems unlikely that a recovery phrase would just “stop working” short of being replaced/deleted either accidentally or as part of an attack. That said, for some weeks last summer, the flow that II used to create those recovery phrases was suboptimal: the phrase was generated and displayed on the user’s screen before the corresponding public key was stored in the canister. That left some people with non-functional recovery phrases, because they never advanced far enough in the creation flow to have the canister store the relevant information. (We changed the flow since then, now we first store the public key and then show the recovery phrase on screen.)
- Deletion of recovery phrases by accident or as part of an attack: That is an issue, as witnessed by the case quoted by @Icdev2dev. The reason, as discussed in the quoted thread, is that all “devices” associated with a user’s II are equal, so any other device (in that case a Yubikey) could be used to delete and ultimately replace the recovery phrase.
Our current thinking is that we should enable II to support two levels of authentication mechanisms where the “less trusted” mechanisms cannot add/delete “more trusted” mechanisms – but it is the individual user’s choice which mechanisms are marked as “more” and “less” trusted. That way, each user can make their choice according to their own workflow and preference, and in it is still possible to replace “more trusted” mechanisms by specifying multiple ones.