Self-custody systems are often presented as a hardware problem: choose a hardware wallet, protect a seed and perhaps add multisig. Yet many incidents happen while the cryptography is working exactly as designed.
A user signs the wrong transaction. A backup is photographed “for just a few seconds.” Sensitive information is shared through the wrong channel. An emergency procedure has never been tested. The technical controls remain intact, but the real system fails.
Security depends on repeated decisions
A crypto architecture is not used once. It passes through many situations:
- receiving a new address;
- preparing a transfer;
- signing a transaction;
- updating firmware;
- changing phone or computer;
- adding a cosigner;
- restoring a wallet;
- losing access to a key person;
- responding to a security incident.
At each step, the operator needs to know what to verify and in what order. As value and team size increase, relying on one person’s memory becomes increasingly fragile.
A procedure is not bureaucracy
A good procedure is not designed to slow people down. It reduces the number of decisions that must be improvised under pressure.
For a high-value transaction, it might require a small number of controls: confirm the network, display the destination on an independent device, compare the amount, verify the beneficiary through a second channel, understand the signed data and retain evidence of approval.
The objective is not to add ten approvals to every payment. It is to define in advance what changes when the risk level rises.
Emergencies are the most dangerous moments
A message announcing a critical vulnerability, a missing device or an unknown transaction creates strong pressure to act quickly.
That is exactly when fake support channels, phishing sites and fraudulent recovery procedures become most effective.
A mature organization therefore prepares an incident process before the incident:
- who may decide to migrate;
- which devices are considered clean;
- how official sources are verified;
- how a new receiving address is created;
- how a test transaction is performed;
- who must be informed;
- which secrets must never be disclosed.
Preparation makes it possible to move quickly without moving blindly.
Independent verification reduces silent errors
One person can prepare and verify a transaction, but both actions remain exposed to the same biases and potentially compromised environment.
For important operations, a second person or second device can add useful independence. This does not always require multisig: it may simply mean validating the address, amount or context before the actual signature.
Inside an organization, this separation can become formal: requester, preparer, approver and signer do not necessarily have the same powers.
A hardware wallet cannot explain a transaction for you
A hardware wallet protects the private key and displays information before signing. But if the operator cannot interpret what is shown, the screen alone is not enough.
This matters especially with smart contracts. A signature may authorize future spending, change permissions or interact with a complex contract. “The hardware wallet asked me to confirm” is not a risk analysis.
Training therefore needs to cover the meaning of operations, not only which buttons to press.
Operational procedures should not contain secrets
Documenting a process does not mean documenting the seed.
A healthy procedure explains how to find the right process, which roles are involved, which checks to perform and how to recognize the devices in use. It can record that a passphrase exists without recording its value.
Secrets should remain within their intended backup system. Operational documentation should make the architecture understandable without making the document itself sufficient to compromise it.
Exercises expose what documentation hides
A procedure can look excellent on paper and still fail on first use.
A recovery drill or controlled transaction can reveal:
- an unreadable backup;
- a missing cable or adapter;
- incompatible software;
- a missing multisig descriptor;
- a person who does not understand their role;
- a process depending on an inaccessible account.
These exercises should be designed so they do not unnecessarily expose real assets. The goal is to test operational readiness, not create a new attack surface.
Complexity must remain proportional
The answer to human risk is not a hundred-page manual for a personal wallet.
A useful procedure should match the context. An individual may need a short checklist for high-value transfers and a recovery sheet. A company may need role separation, approvals, logging and periodic drills.
The more complex the architecture becomes, the more important documentation and training become.
Build security that remains usable
The best setup is one that stays secure in real life, including when someone is tired, under time pressure or unavailable.
GLOV Secure works on this operational layer through architecture, audits, procedures and crypto security training, always within a non-custodial model. GLOV does not hold funds and does not need to retain client secrets to review a setup.
Crypto security should not depend on perfect human behavior. It should depend on an architecture that makes good decisions easier and critical mistakes harder.