A custody recovery drill that never exposes a key
A custody recovery drill produces four numbers and a list. The time from “go” to a verified extended public key. The count of keysets in the backup against the count in the live workspace. The count of known wallet addresses that failed to re-derive from the recovered keys. The value held in positions a sweep cannot touch. And every place the written procedure and reality disagreed. Everything else about the drill is staging for those five outputs, and none of them requires a private key to exist outside the recovery tool’s memory.
That last point is the one that gets drills cancelled. The standard objection is security: “we don’t want to handle live key material more often than we must.” The instinct is right and the conclusion does not follow from it. I have read the verify paths of the recovery tooling most MPC custody customers would use, and in the Fireblocks Recovery Utility the difference between verifying and recovering is one boolean, dangerouslyRecoverPrivateKeys, false on the Verify page. The private key is reconstructed in memory, its public key is compared against the backup’s own record, and the private half is deleted from the result before anything reaches the screen. So the drill stops at that line. Any step that would print or export a private key is out, and everything before it is in.
That rule has a useful side effect. Because nothing sensitive is produced, the drill can be run by more people, more often, and witnessed by people who would never be allowed near a real recovery, which is how procedures get found wrong.
Where the findings come from
Rarely from the cryptography. The reconstruction either matches or it does not, and it usually matches. The findings come from retrieving the inputs the way they would really be retrieved, the backup archive from wherever it actually sits and the recovery key from whoever actually holds it. That is where you meet the safe-deposit process that needs a signature from someone who left, the passphrase that was rotated without re-wrapping the backup, the second key share nobody can locate. It is also where the hours go when the recovery is real, and after Coldcard nobody should need reminding that the clock is set by the attacker.
The other place findings come from is the operator. The drill is worth most when run by the second-most qualified person, and if there is no second-most qualified person, write that down as finding one before the drill starts.
What the drill measures
Verification is the easy part. Most of the afternoon goes on reconciliation. The backup’s metadata lists keysets and the account ranges they cover, and the live workspace has its own count. The difference is key material that exists and is not backed up. A backup taken before the last keyset was created verifies perfectly and covers none of the assets in that keyset. Then the addresses: export the list from the console, let the tool re-derive every one from the recovered keys, and count the ones that did not match. In the Fireblocks tool a mismatch is logged and dropped rather than shown, so the count lives somewhere other than the screen. Then the long tail, on paper, every staked, locked or contract-held position with its exit path and unbonding timeline, because none of it can be swept and some of it takes weeks to unwind.
The record that comes out is eight lines long. I have not yet seen a drill report from the field with more than three of them.
In practice organisations sit somewhere on a four-rung ladder. A backup exists, because someone downloaded it once. The backup has been verified, once, which proves it decrypted on that day. Verification is scheduled and evidenced. Recovery is rehearsed, with the people, the environment, the runbooks and the long tail all tried under drill conditions.
Most institutions holding digital assets are on rung one and believe they are on rung four. Nothing in normal operation tells the two apart.