During the #nostrasia event, someone mentioned doing a multisig to verify the authenticity of a secondary nostr key if someone has had their primary nostr key compromised.
It was in Japanese, so I might not have gotten the full picture; however, if that's the whole story, there is one issue with it:
An attacker can forge a multisig with a different secondary key they control and fake an older data/time than the truthful one. Since nostr doesn't have a timestamp-enforcing mechanism, this method is not necessarily a 100% verifiable solution.
However, a solution to it would be to involve Bitcoin in the process, by deriving a Bitcoin address from both the primary and secondary key and conducting the multisig process on that level, which would give it the security/timestamp it needs to properly act as a 100% verifiable backup solution. The only 'con' about this is the cost of money to do so.
I'd do that, but I'd also do it differently, the reverse in fact, where the primary key is kept hidden/secure while the secondary key is the one to be used publicly and would be the one being exposed to the risk of being compromised, where if it does happen, then you simply use a different/new secondary key that does another multisig with the primary key, and clients would adapt to this new system where if you follow my primary key, you'd also see posts from my secondary key (with a label 'proxy' so you'd know).