Key Management and Signing Authority
In traditional finance, security is layered. Identity, authentication, authorization, custody, and recovery are separated across systems and teams. If one layer fails, others often catch the problem before funds are lost.
In Web3, those layers collapse into a single artifact: the private key.
That key represents who you are, what you can do, and what you own. Lose it, and there is no escalation path. Leak it, and there is no fraud department to call.
Key management is a central security boundary.
State the responsibilities and protections associated with wallet authority clearly.
Wallet and Account Threat Models
The threat model should include phishing, device compromise, credential reuse, recovery abuse and sensitive account changes.
Threat modeling should include phishing, credential reuse, session theft, device loss, malware and protocol vulnerabilities. Prioritize controls using evidence about the users and system under review.
Users multitask, skim and rely on familiar cues. Security interactions should account for these behaviors.
Security design should account for ordinary user behavior and predictable mistakes.
Wallets Are Powerful—and Incomplete
Wallets manage signing authority through software, hardware or other custody and recovery arrangements. Key storage and exposure depend on the implementation.
What they do poorly is everything around that moment of signing.
Wallet capabilities vary. Assess supported recovery, phishing warnings, device management and authorization policies for the chosen wallet.
Hot wallets trade isolation for convenience. Hardware wallets trade convenience for isolation. Both rely on the same brittle assumption: that the user can safeguard a single secret indefinitely.
Assess each wallet’s supported safeguards and remaining risks.
Design platform controls around the chosen wallet’s actual capabilities and limits.
The Seed Phrase Paradox
Seed phrases are one of the most powerful—and least user-friendly—security mechanisms ever created.
A properly generated seed has substantial entropy. Backup handling, phishing, device security and recovery remain practical risks; users need guidance specific to their wallet.
Life happens. Paper degrades. Homes change. Memories fade.
Design backup and recovery around foreseeable device loss, mistakes and compromise.
Seed-phrase handling needs appropriate generation, backup, storage and recovery safeguards.
Why Platforms Still Matter Even With Self-Custody
Separate wallet signing authority from application account controls. Document which actions the platform can authorize, restrict, record or recover.
Platform controls can protect actions mediated by the platform. A compromised wallet key may authorize direct on-chain actions outside that boundary. State the scope of account controls clearly.
Security design should reduce exposure and define response options when risk materializes.
Passkeys: Security That Fits Human Behavior
Passkeys offer a practical phishing-resistant authentication option for supported platform accounts.
Passkeys use public-key credentials bound to a relying party. They may be device-bound or syncable; activation and recovery depend on the authenticator and service.
Passkey usability depends on enrollment, device support and clear recovery. Test these flows alongside the authentication mechanism.
Passkeys can protect application sign-in through relying-party-bound credentials. Assess authenticator activation, synchronization, recovery and sessions separately from wallet signing authority.
Requiring a correctly verified passkey can protect a login despite password exposure. Session theft, recovery abuse and compromised endpoints remain relevant threats.
Why Passkeys and Wallets Belong Together
Wallets authorize signing actions. Passkeys can authenticate application access within their relying-party scope.
Wallet signing and platform authentication protect distinct boundaries. Document which actions require each and the effects of compromise at either boundary.
Layer controls with explicit scopes and assess their shared dependencies.
The Problem With "2FA" as a Buzzword
Authentication methods address specific threats. Evaluate factor independence, phishing resistance, session management and recovery for the actions the account can perform.
Assess email confirmation, TOTP, passkeys and backup codes by their defined purpose, phishing resistance, factor independence and recovery properties.
Treating all of these as interchangeable leads to false confidence.
Select authentication methods according to the required assurance, recovery design and action risk.
Account Recovery Scenarios
Recovery is where security systems are truly tested. It’s easy to design for the happy path; the real challenge is designing for failure: lost devices, new laptops, and social engineering attempts.
Recovery should restore legitimate access through an adequately verified and recorded process.
Lost phone scenario: recovery depends on the wallet, authenticator and service. Use the established recovery method, verify the request and apply documented risk controls. Delays and notifications should follow a tested policy; this example sets no universal waiting period.
New laptop scenario: Assess the authorization required to enroll a device, including existing account evidence and appropriate verification. Record enrollment and session changes, and define how compromised or obsolete sessions are revoked.
Social engineering attempt: a recovery requester provides conflicting signals. Follow the documented verification and escalation process, notify established channels where appropriate and record the decision.
In practice, recovery works when multiple controls reinforce each other: step-up verification, session management, anomaly detection, and time delays that protect users during their most vulnerable moments.
Platform Controls: Session Management, Step-Up Verification, and Suspicious Login Detection
Account protection includes session control, anomaly review and action-appropriate authentication.
Session management limits how long access persists and where it can be used. When device, location, or risk posture changes, sessions should be re-evaluated: require re-authentication, shorten duration, or invalidate sessions after sensitive events.
Step-up verification raises assurance for a sensitive action. Choose it according to the existing authenticator, session state and action risk.
Suspicious login detection is the early-warning layer. It flags unusual patterns (new devices, impossible travel, rapid attempts) and triggers protective responses: additional verification, temporary holds, or user alerts.
Session controls can limit exposure within a platform’s authority. Direct wallet transactions and assets held outside that boundary require their own controls.
What Safe Recovery Actually Requires
A recovery process needs adequate verification and visible safeguards.
A well-designed recovery process introduces friction deliberately. It requires multiple signals of legitimacy, time delays that prevent rushed takeovers, and auditability so actions can be reviewed later.
Recovery timing should follow the documented assurance and risk requirements.
Attackers optimize for speed. Legitimate users value certainty.
Assessing Recovery Controls
Assess recovery by its proof requirements, attack resistance and user safeguards. Duration alone gives limited evidence of security.
Recovery needs proportionate verification and protection against social engineering. Appropriate notifications, holds and escalation depend on the recovery method and threat model.
Security-By-Design prioritizes protection over immediacy when stakes are high.
Backup Codes: Unsexy and Essential
Backup codes can provide an established recovery mechanism where the service supports them.
Store backup codes securely for the service’s defined recovery procedure. Treat them as sensitive account credentials.
Evaluate each control by its purpose and effectiveness.
Privileged Account Controls
One of the most common security failures in platforms is treating all users the same.
Administrative and privileged roles require stricter controls because their compromise has outsized impact. Elevated roles should require stronger authentication, stricter recovery policies, and clearer audit trails.
This separation limits blast radius and aligns with institutional expectations.
Security Interaction Design
Security that users don't understand will be bypassed.
Explain why extra steps are required using clear, contextual guidance in the interaction.
The goal is to help users make informed decisions.
Designing for Failure
Keys will be lost. Devices will fail. People will make mistakes.
Plan how the system handles device loss, mistakes and compromise.
Security-By-Design assumes imperfection and plans for it. It replaces brittle expectations with layered defenses, recovery paths, and transparent communication.
Why Institutions Care About User Key Management
Institutional review can examine protocol and operational risk, including access, revocation and recovery procedures.
Even when users self-custody, account takeovers create real platform risk: support burden, reputational damage, and loss of confidence. Institutions look for mature handling of these incidents—clear escalation paths, time-bounded containment, and communication that matches the evidence.
This is part of operational assurance.
The Bigger Picture: Security That Respects Reality
Usable controls should help participants understand account permissions, signing actions and recovery choices.
By combining self-custody, passkey-protected accounts, layered authentication, and thoughtful recovery, platforms can reduce risk without demanding perfection.
Security controls should account for real user behavior.
Planning for User Error and Recovery
Key management addresses the likelihood and consequences of loss or compromise.
The objective is to reduce the likelihood and consequences of key loss or compromise.
Security-By-Design is built for real people living real lives. It acknowledges human limits, anticipates failure, and builds systems that protect users when things go wrong.
Preparedness should be supported by documented procedures and test evidence.
It's built by proving you're ready when it does.
This is how we Become Alpha.