Owning a recent hardware wallet, a metal backup and a passphrase does not prove that a crypto architecture is secure. Real security depends on how secrets were created, backed up, used, controlled and recovered — and on the dependencies connecting all of those elements.
A useful audit therefore does not simply search for the “right wallet brand.” It searches for failure points, abuse scenarios and situations in which the setup stops behaving as intended.
1. Map assets and responsibilities first
Before discussing seeds or multisig, the auditor needs to understand what is actually being protected.
The review should identify:
- the blockchains and assets involved;
- every wallet in real use and its purpose;
- the people able to sign, approve or prepare transactions;
- systems providing addresses, balances or transaction data;
- emergency and recovery procedures.
This prevents a common mistake: heavily protecting a treasury wallet while overlooking an operational wallet, an administration key or a software account capable of changing the system.
2. Review how the keys were generated
Key security begins before the first deposit.
The device model, firmware used at generation time, entropy method, optional dice input and origin of the seed should be documented. A seed imported from an older device keeps the properties of its original generation process.
The 2026 COLDCARD incident was a reminder that a BIP-39 phrase can look entirely valid while its effective search space is smaller than expected. An audit therefore needs to examine where the secret came from, not only where it is stored today.
3. Treat backups as sensitive assets
A backup is another copy of the power to spend.
The audit should determine:
- how many copies actually exist;
- where they are stored;
- whether several copies share the same physical risk;
- whether a photograph, scan or digital transcription has ever existed;
- whether a passphrase is used and how its existence is documented;
- whether the media can still be read and recovered.
Physical durability matters, but distribution matters more. Three metal plates stored in the same place are still one failure domain.
GLOV SSS can be used as a distributed backup building block for a healthy seed. It does not replace architectural review or improve the original cryptographic quality of the secret.
4. Look for correlated dependencies
A 2-of-3 multisig is not automatically three times more resilient.
Three signers using the same vendor, firmware, generation procedure and storage location may share a common vulnerability. Likewise, physically separated keys can remain dependent on the same computer, coordination software or backup provider.
The objective is to identify failure domains: vendor, firmware, operating system, location, person, cloud provider, communication channel or internal process.
That is why a custody architecture should be designed as a system rather than as a collection of devices.
5. Verify what the operator actually sees before signing
An architecture can protect keys perfectly and still fail at transaction time.
The review should determine how operators verify:
- the destination address;
- the amount;
- the network;
- fees;
- smart-contract data;
- permissions created by a signature.
A hardware-wallet screen is useful only when the operator knows what must be compared on it. A security process that routinely trusts an address copied from a potentially compromised computer remains exposed.
6. Test recovery procedures
A backup that has never been tested is an assumption.
The audit should verify that recovery can be performed without unnecessarily exposing secrets and that all required information is available: seed format, optional passphrase, derivation paths, multisig descriptors, cosigner order, compatible wallets and control procedures.
For organizations, a recovery drill should answer a harder question: what happens when the person who understands the setup is unavailable?
7. Review powers and roles, not just keys
Inside an organization, the question is not only “who has a seed?”
It also matters who can:
- request a transaction;
- prepare it;
- approve it;
- sign it;
- change the rules;
- activate an emergency process.
When all of these capabilities are concentrated in one person, a multisig can create the appearance of shared control without genuine separation of duties.
8. Search for bypass paths
Real systems often contain shortcuts: a secondary wallet, emergency seed, admin key, exchange account, remote access, old phone, configuration file or a “temporary” process that was never removed.
An audit should actively search for those paths because an attacker rarely chooses the best-documented route. They choose the weakest one.
9. Prioritize remediation according to actual risk
A good audit should not end with twenty recommendations presented as equally urgent.
Remediation should be ranked by impact and urgency: potentially compromised secret, single backup, outdated firmware, missing recovery process, excessive concentration of authority, critical dependency or lack of documentation.
Some changes can be made immediately. Others require a wallet migration, a new multisig policy or a governance redesign.
The goal: understand the system before making it more complex
Adding more hardware wallets, more shards or more rules does not automatically improve security. An architecture that is too complex can become impossible to operate correctly, especially during an incident.
The right architecture is one whose risks are understood, responsibilities are explicit and recovery has actually been tested.
GLOV Secure supports individuals and organizations in this analysis without taking custody of funds or retaining client secrets. A crypto security audit can be the starting point before a migration, multisig deployment or complete redesign.
GLOV Solutions does not provide legal, tax or financial advice as part of this security work.