A more simple solution would be to use multi sig, which is basically what you are proposing, except in a round about way.
I think this is not exactly for the same purpose, multisig is not as simple to use for not power user or big entity imo, it has some pitfalls (
https://medium.com/shiftcrypto/the-pitfalls-of-multisig-when-using-hardware-wallets-9b0e98e4c19c)
With my solution the user will have to carry only his main key, the failover will be use only in emergency cases.
But I already see a weakness with this that could be exploit: the bad guy could also see there is a contract and monitor the "unlock" message and could be the first to boradcast after the locktime.
That's why I imagine another better solution. The contact could remain the same but instaead of using a message to unock, any outcoming transaction will be delayed between the broadcast to broadcast + RTL. In the same period only transactions to the failover adress will be imediatly processed.