A seed phrase is not a complete security plan.
It may be the ultimate recovery secret for a self-custody wallet, but it is only one part of the system that controls crypto assets. Funds can also be exposed through compromised signing devices, malicious contract permissions, weak exchange accounts, unsafe recovery procedures, shared cloud storage, or poorly governed multisignature wallets.
That creates a basic problem for both individuals and businesses: they often know where their assets are, but not every source of authority over those assets.
A useful wallet inventory should therefore answer more than “Which addresses do we own?” It should show which credentials can initiate transactions, which devices can sign them, which applications can request them, which contracts already have permission to move tokens, and which recovery mechanisms can replace lost access.
Call it an authority map. Without one, security teams and self-custody users are protecting an incomplete picture.
Wallet balances do not reveal the control structure
A portfolio tracker can show balances across addresses. It cannot necessarily show how those addresses are controlled.
Two wallets with identical balances may have radically different risk profiles. One could sit behind a dedicated hardware signer, an offline recovery backup, and a carefully tested transaction process. The other could be accessed through a browser extension on an everyday laptop, with its recovery phrase stored beside unrelated personal documents.
The blockchain sees addresses and valid signatures. It does not evaluate whether the device producing a signature was compromised or whether the person approving a transaction understood what it would do.
An authority map begins with each wallet or custody account and works backward through the control chain. At minimum, it should record:
- The wallet address or custody account - The assets and networks involved - The signing method - Every authorized signer - The devices used for signing - The applications allowed to connect - Existing token or protocol permissions - The recovery method - The people who can access recovery materials - Any exchange, email, or identity account tied to access
This is not busywork. It identifies hidden concentrations of risk.
If five wallets rely on the same laptop, browser profile, password manager, or cloud account, they are not five independent security zones. They share a failure point.
Separate transaction authority from recovery authority
The ability to sign a transaction and the ability to recover a wallet are different powers. Both can lead to control of the funds.
That distinction matters because users often secure routine signing while leaving recovery poorly governed. A hardware wallet may protect day-to-day private-key use, but a photographed seed phrase, exposed backup, or weak recovery service can bypass that protection.
The authority map should therefore distinguish among three roles:
1. Routine authority: Credentials and devices used for normal transactions. 2. Emergency authority: Recovery materials or processes used when routine access fails. 3. Administrative authority: Accounts or procedures that can change security settings, replace signers, or alter policies.
For an individual, one person may hold all three roles. The distinction is still useful because the controls should differ. A daily signing device should not be stored with its recovery backup, and a recovery procedure should not depend entirely on the device it is meant to replace.
For a business, combining these roles in one employee or one device can defeat the purpose of institutional controls. A multisignature arrangement is not meaningfully distributed if the same administrator controls several signer backups.
Contract permissions belong on the map
Self-custody risk does not end after a transaction is signed. Some transactions grant continuing authority to smart contracts.
A wallet can therefore remain exposed even when its private key has not been stolen. The key may be secure while an old or unnecessary approval still permits a contract to move certain tokens under specified conditions.
That makes permissions part of the wallet’s authority structure. Users should record which protocols and contracts have active approvals, what assets those approvals cover, and whether the permissions remain necessary.
The practical discipline is straightforward:
- Review permissions on a defined schedule. - Revoke access that no longer serves a purpose. - Avoid treating every wallet as a permanent DeFi identity. - Separate long-term holdings from wallets used for frequent application interactions. - Recheck permissions after changing strategies or leaving a protocol.
Revocation is not a substitute for protecting keys, and key protection does not make permissions irrelevant. They address different paths to loss.
A clean separation between storage wallets and active wallets can also reduce the consequences of a mistake. The wallet connecting to unfamiliar or frequently changing applications does not need to hold the entire portfolio.
Account security can undermine wallet security
Crypto users often draw a hard line between self-custody and custodial accounts. Operationally, the boundary is less tidy.
Email accounts may receive exchange notices or device alerts. Password managers may store account credentials. Mobile numbers may be involved in recovery. Cloud drives may contain wallet records. Messaging accounts may be used by colleagues to request transactions.
Compromise in any of these systems can support impersonation, phishing, or unauthorized account changes even if it does not directly reveal a private key.
The authority map should include these dependencies rather than dismissing them as “off-chain.” For each important crypto account, users should know:
- Which email address controls it - Which authentication method protects it - Which devices are currently authorized - Which recovery channels can reset access - Which withdrawal addresses or restrictions are configured - Who receives security notifications - How a suspected compromise will be escalated
The weakest recovery channel can become the practical security boundary. Strong passwords do not fix a poorly protected email account, and an authenticator does not help if the recovery process can bypass it without adequate scrutiny.
Phishing defenses require a verification route
Most advice about phishing focuses on recognizing suspicious messages. That is necessary but incomplete. Attackers benefit when users have no trusted alternative route for verification.
A robust process specifies how to confirm a request without using the contact method that delivered it. If a message claims that an account must be secured immediately, the user should open the provider through a known application or manually saved address—not through the message’s link.
Businesses need the same discipline for internal requests. A transaction instruction arriving over email or chat should not become valid merely because the sender’s name and profile image look familiar.
Higher-risk actions should require an independent check based on known contact details or an approved workflow. That includes:
- Adding a new withdrawal destination - Replacing a signer - Exporting wallet or account data - Changing recovery information - Increasing transaction limits - Approving an unusual transfer - Installing new wallet software or firmware
The point is not to distrust every request. It is to avoid relying on the same potentially compromised channel for both instruction and confirmation.
The map must stay current
An authority map becomes dangerous if users assume it is accurate after devices, employees, applications, or accounts have changed.
It should be updated whenever a wallet is created, a signer is replaced, a device is retired, a contract permission is granted, or a custody relationship changes. Periodic reviews should confirm that listed controls still exist and that recovery instructions still work.
For businesses, each entry should have an owner and a review date. Departing personnel should trigger a review of every authority they held—not only the accounts that appear in a standard IT checklist.
Individuals can use a simpler version, but they should still document enough for an emergency. The document itself must be protected because a complete authority map would be valuable to an attacker. It should not contain raw seed phrases or private keys. Its purpose is to identify control paths, not consolidate the secrets that activate them.
Security starts with knowing who can do what
Self-custody is usually framed as a choice between controlling keys and trusting an intermediary. In practice, control is distributed across keys, devices, software, permissions, recovery methods, and human procedures.
That distribution can improve security when it is deliberate. It can also create blind spots when users protect the most visible secret while ignoring the rest of the control system.
The grounded takeaway is simple: inventory every route that can move funds, change access, or restore control. Then reduce unnecessary authority, separate critical roles, and test the remaining paths.
A wallet balance tells you what is at stake. An authority map tells you how it could be lost.