A smooth login says little about recovery and transaction authority.
An audit applies to a scope and version, not every later deployment.
Map privileged roles and rehearse loss, compromise and service exit.
Technical due diligence and proposed tests. This does not certify any wallet, contract or supplier, recommend holding digital assets, or establish a product’s regulatory eligibility.
Control and recovery acceptance matrix
| Scenario | Demonstration | Evidence to record |
|---|---|---|
| Lost device | Complete the documented recovery path | Required proof, approvals, notifications and old-access revocation |
| Privileged change | Propose an upgrade or role change | Actual role holders, delay and execution permissions |
| Supplier outage | Exercise the agreed degraded operation | Unavailable functions, recovery owner and user communication |
| Changed contract | Compare release and audit identifiers | Deployed version, review scope and unresolved findings |
Authentication, custody, contract security and regulatory suitability require separate assessments.
Draw the control map
For each wallet and contract, list who can initiate transactions, recover access, change permissions, upgrade code, pause activity and move assets. Distinguish the player, your team, the supplier and any shared authorisation arrangement. Do not infer custody or recovery rights from a marketing label such as embedded or non-custodial. Ask the supplier to demonstrate the implemented model and the powers retained by each party.
Separate login protection from transaction intent
NIST identifies WebAuthn as an example of phishing-resistant authentication through binding to the verifier’s domain. That is a useful property for account login; it does not mean every transaction a logged-in person signs is safe. Our proposed buying test checks whether amount, recipient, network and requested permission are understandable at the point of approval, and whether unexpected permissions can be refused.
Inspect contract administration
OpenZeppelin documents role-based access control and timelocks that delay privileged operations. Its documentation also discusses availability risks when critical proposer or executor accounts are lost. These mechanisms illustrate trade-offs rather than proving a deployment is secure. Request the actual role holders, upgrade path, delay configuration and emergency process for the contracts you will use.
Read an audit as scoped evidence
Ethereum’s security guidance recommends independent review while warning that audits do not find every bug. Ask for the report’s repository, commit or release reference, scope, unresolved findings and remediation evidence. Compare those identifiers with the deployed contract and configuration. A logo or an old report cannot establish that a newly changed component was reviewed. Keep front-end, wallet, service and contract risks separate when they were not all within the audit scope.
Ethereum.org — Smart contract security and independent review
Rehearse recovery without weakening control
Our proposed recovery exercise covers a lost device, unavailable email account, compromised signing authority and a supplier outage. Record what the user must prove, who approves recovery, what delays or notifications apply and which existing access is revoked. A process that restores access quickly but lets an attacker take over the wallet is not a successful recovery. Test the support route as well as the happy-path interface, using controlled test accounts and assets.
Plan for exit and incident response
Ask which keys, records and transaction histories can move if the supplier relationship ends, and which operations depend on its continued service. For each emergency action, assign an authorised owner and an observable confirmation that it worked. Rehearse revoking an excessive permission and disabling a compromised integration. Retest after material changes. Treat the resulting evidence as a release decision record with known limitations, not as a permanent guarantee against loss.
Sources and scope
Technical due diligence and proposed tests. This does not certify any wallet, contract or supplier, recommend holding digital assets, or establish a product’s regulatory eligibility. Sources reviewed 2026-10-18; check the linked originals for later changes.
NIST SP 800-63B-4 — Phishing-resistant authenticationOpenZeppelin Contracts — Access control and timelocksEthereum.org — Smart contract security and independent reviewCompare the same requirements across suppliers and record evidence, tests and unresolved gaps. The editable workbook starts with no supplier results or approvals.
Get the free supplier evaluation worksheetThis educational guide is independent, free to access and designed as a practical starting point. Regulatory and legal requirements should always be confirmed with the relevant authority and qualified advisers.
Our evidence methodology