A security alert should not trigger only an update or a transfer. It should also prompt a review of the entire architecture: devices, seeds, backups, software, people and procedures.
The purpose of an audit is not theoretical perfection. It is to identify real risks and establish an order of action.
Map the wallets
Start with a list of the wallets in use, their function and the assets involved.
Separate daily-use wallets, long-term storage, treasuries, test wallets, multisig setups and succession arrangements.
This makes priorities visible and avoids an unnecessarily risky global migration.
Trace seed origins
For each seed, record the model and firmware used during generation, approximate creation date, additional entropy sources, optional passphrase and later imports.
A seed moved to a new device keeps its history. The origin of the secret matters more than the current hardware alone.
Review backups
A backup should be readable, complete, confidential and recoverable. Check the number of copies, their locations, storage materials and the people who know they exist.
For multisig, seeds may not be enough. Descriptors, extended public keys, fingerprints and derivation paths may be required for reconstruction.
Check software dependencies
The audit should include companion software, computers, update methods and download sources.
Addresses should be verifiable on the device screen. Firmware should come from official sources and, where supported, be authenticated before installation.
Test recovery
An untested backup remains an assumption. Recovery procedures should be validated in a controlled environment, with limited funds and without exposing secrets.
The test should confirm expected addresses, access to any passphrase and, for multisig, the ability of a backup quorum to sign.
Review people and roles
Who can act? Who understands the setup? Who can replace an unavailable signer? Who receives security alerts?
A technically strong setup can remain fragile when it depends on one person or when responsibilities are undocumented.
Build a remediation plan
Classify actions: immediate emergency, planned migration, backup improvement, documentation update or governance change.
For each migration, prepare a verified new seed, a test transaction, on-device address confirmation and a confirmation period before retiring the old setup.
Turn the incident into maturity
An alert can reveal dependencies that already existed: one vendor, one complete seed in one place, missing procedures or recovery that was never tested.
Custody Architecture turns these findings into a durable setup. GLOV Secure supports that work without taking custody of funds or retaining secrets.
To organize a confidential review, request a crypto security audit or contact GLOV.