There should be a simple high-level explanation—for example, “we use MPC, which means that the key only exists in pieces, and we don’t have all the pieces” or “the key is only ever decrypted in secure hardware.” The devil’s in the details, though; below, we outline three edge cases where custody stories often fall apart.
Key export
To stay non-custodial, key managers let users export their keys. In the B2B case—e.g., for treasury management—this means giving an organization access to their own keys; in the B2C case—e.g., for end user wallets—this means giving developers access to APIs that let end-users access their keys. In both cases, implementing key export goes against the general premise of the key manager: instead of keeping the key encrypted or sharded, it requires returning the key to the user such that the user can see it.
To begin thinking through the custody implications of export, consider a strawman example: in order to return a key to the user, an MPC-based key manager reconstructs the key in plaintext. Once the key manager has the plaintext key, though, the non-custody story falls apart: the vendor has access to the key, and thus has custody of the funds. Many MPC-based key managers use some version of this (broken) process. One, for example, sends key backups as password-protected zip files. Since there’s no MPC protocol for turning a sharded key directly into a password-protected zip file, the key manager had access to plaintext user keys in order to zip them up.
Cross-device signing
Most key managers today let users sign transactions from multiple devices. This is important for convenience—you might need to approve transactions when you're traveling—and redundancy—if you lose your device, you should not lose your whole treasury. In the B2C case, providing a smooth Web2-like user experience where end-users sign in with social login (e.g., Google, Apple, and X) and have immediate access to their accounts is similarly critical.
How do you accomplish this without taking custody of the user's keys? If your key manager relies on sharing—MPC or Shamir Sharing—this is relatively easy: the key manager can implement a syncing protocol that copies a share stored on one device to another, without ever revealing the share to their server. The catch? The devices must be online: you should not be able to put your existing device in a Faraday cage, unpack a brand new phone and log into your account, and somehow recover your share—and sign transactions. In reality you can. But, this "spooky action at a distance" is easier to understand than quantum entanglement: the vendor is privy to your key.
System upgrades, failures, and auto scaling
Like most systems, key managers fail (e.g., because the hard-disk crashed), they require software (or hardware) upgrades, and they often automatically scale to keep up with user traffic. Doing this while preserving the non-custody property is tricky. To understand why, let's consider one of these scenarios: your key manager's machines go down (e.g., because of a power outage in a region). How does the key manager recover from this?
In the MPC case this is easy: a key manager implementing an ideal MPC protocol could automatically spin up new instances and read its shares from a highly-reliable database. (Alas these systems are far from ideal as we describe above.)
This is trickier for key managers that rely on enclaves for the root of trust (and not HSMs or MPC): normally, the enclaves have full copies of keys residing in memory, so when they crash they must spin up new enclaves and somehow reconstruct these keys (really the keys that encrypt the user keys). They deal with this by falling back to sharing: the system administrators can spin up an enclave and manually reconstruct keys using their administrator keys. Alas, this also means they can reconstruct keys at any point—and there is no way to check if/when they do.
