Every security product solves a specific problem and leaves others untouched. The honest version of "Threshold Vault protects your secrets" is more useful than the marketing version. Here is what threshold custody actually defends against, where the math runs out, and what you need to handle yourself.
Threshold custody is a precise tool. It removes single points of failure from how a secret is stored, and it does that very well. It does not, by itself, defend against compromise of the devices you use, the people you trust, or the procedures you follow. Both columns below are equally important to understand.
Information-theoretic security applies to the split itself. Fewer than M shard cards cannot reconstruct the encryption key. They do still reveal visible metadata by design, threshold parameters, holder identifiers, and a card ID, so the guarantee is precise rather than absolute. Everything outside it (the room you split the secret in, the people who hold the shards, the printer that committed them to paper) is procedural, and procedure can fail.
This is not a flaw in the design. It is the design. Threshold Vault solves the cryptographic problem cleanly, on the assumption that the user will solve the procedural problems with care. The best practices section exists for exactly this reason.
The core split/recover path does not rely on public-key cryptography or blockchain signing. Threshold Vault encrypts the secret locally with AES-256-GCM, then uses Shamir's Secret Sharing to divide the encryption key. That narrower claim is the one we can defend.
Shamir's portion is information-theoretically secure. If an attacker has fewer than M shard cards, they cannot reconstruct the encryption key. The cards still carry visible metadata by design, but not the key material needed to decrypt the secret.
AES-256 remains strong against known quantum attacks. What we do not claim is "quantum-proof" status overall. That phrase would blur together the mathematics, the device, the printer, the holders, and the underlying asset. Those are different risks, and they fail in different ways.
This split/recover design does not protect:
· the device you perform the split on, which may be compromised today by classical malware
· the printer that committed your shares to paper, which has classical firmware
· the secret you started with (e.g., a BIP-39 seed protecting a cryptocurrency address whose elliptic-curve signature scheme is not quantum-safe)
· the holders themselves, whose trustworthiness is unrelated to mathematics
If the underlying secret protects an asset on a system whose signatures are vulnerable to future quantum attack, threshold custody does not change that. It protects the storage and recovery of the secret. It does not modify what the secret unlocks.
A threat model is only useful if it names the failures it does not address. Below is the full list of risks that fall outside Threshold Vault' boundary, with our assessment of how serious each is in practice and what you can do about it.
| Threat | Status | What you can do |
|---|---|---|
| Compromised splitting device | Outside | Use a clean device, ideally air-gapped. Verify the build hash. Disconnect from the internet before pasting the secret. |
| Phishing, spoofed Threshold Vault site | Outside | Verify the URL. Run from source after cloning the public repository. Bookmark the real domain. |
| Browser extension key-logging | Outside | Use a fresh browser profile or incognito session with no extensions during the split. |
| Printer firmware retaining jobs | Outside | Use a personal printer, not an office or shared one. Print and forget, or write shards by hand. |
| Cloud-synced clipboard or screenshots | Outside | Disable clipboard sync. Avoid screenshots of any view that contains a secret or share. |
| Storing multiple shards in one location | Outside | Physical separation is the entire point. One file, one safe, one envelope per shard. Different rooms, ideally different buildings. |
| Losing too many shards to reconstruct | Outside | Choose redundancy in your threshold. 3-of-5 tolerates two losses. 5-of-7 tolerates two losses with more participants involved. |
| Mistyping the secret before splitting | Outside | Always test with a dummy secret first. Verify the round-trip reconstruction matches before splitting the real secret. |
| Coordinated coercion of M holders | Outside | Choose holders across legal jurisdictions. Inform holders that no individual coercion can extract the secret. M-of-N raises the cost of coercion, but does not eliminate it. |
| Single lost shard | Protected | Nothing required: the threshold scheme tolerates loss of N − M shards by design. |
| Single compromised holder | Protected | Nothing required: a single shard reveals nothing about the secret. |
| Threshold Vault (the company) shutting down | Protected | Nothing required: the open-source library and standalone HTML let you recover with or without us. |
If you split a high-value secret on a laptop with one malicious browser extension, then print the shares on an office printer with a network spool, then photograph them and email them to yourself "for backup": the threshold scheme has done its job, and you have still failed.
The list above is not theoretical. Every one of these mistakes has been made by sophisticated users. Read it, then read it again before you split anything that matters.
The cryptography only protects what the procedure preserves. These eight rules close the gaps the math cannot. They appear in every kit we ship and on the security page, but they belong in the threat model too, because the procedure is the threat surface.
If you discover a vulnerability in the Threshold Vault cryptographic core, please disclose it to us privately via our contact form. Our policy follows a standard 90-day responsible disclosure window: we acknowledge within 48 hours, work toward a fix within 90 days, and credit reporters who request it.
The full disclosure policy will be published as SECURITY.md in the public repository when it goes live.