A crypto custody model defines how an organisation stores, protects, authorizes, and recovers access to digital assets. The model must align with business risk, jurisdictional requirements, and operational maturity, because weak key handling or unclear responsibilities can turn custody into a direct loss event.
What a crypto custody model actually covers
A crypto custody model is more than a storage choice. It defines who can move assets, how authority is exercised, how recovery works, and which operational assumptions must hold if keys, signers, or controls fail.
That makes the model a security and operating design, not just a treasury preference. The important question is whether the organisation can prove control over access, preserve recoverability, and keep loss of a signing path from becoming loss of the asset.
Common custody model patterns
Most custody designs fall along a spectrum from self-custody to delegated or institutional custody. Self-custody maximises direct control but concentrates operational burden on the organisation. Third-party custody can improve segregation of duties, resilience, and process discipline, but it also introduces dependency on provider controls and service continuity.
Hybrid models are common because they separate functions such as key generation, transaction approval, policy enforcement, and recovery. In practice, the model matters most when the organisation needs to distinguish routine signing from exceptional recovery, because those paths often carry very different risk.
Security controls that shape the model
Custody is usually built around key management, transaction authorization, backup and recovery design, access control, and auditability. For that reason, NIST SP 800-57 Key Management is a natural reference for cryptoperiods, key lifecycle decisions, and destruction or rotation requirements, while ISO/IEC 27001:2022 Information Security Management is useful when the custody model must fit broader governance and control expectations.
Where custody depends on API-driven wallets, signing services, or integrated platforms, the design also has to withstand authentication and authorization failures. In those cases, NIST SP 800-53 Rev 5 Security and Privacy Controls provides a control vocabulary for access control, identification and authentication, audit, and system integrity.
Business and operational trade-offs
The right custody model depends on the value at risk, transaction frequency, response time needs, and tolerance for human intervention. High-assurance custody usually increases process friction, because stronger approval flows and recovery checks slow down routine movement of assets.
At the same time, weak or ambiguous custody design can create hidden concentration risk. If one compromised credential, one signing workflow, or one operator decision can move funds, then the organisation has effectively turned a governance choice into a direct loss path.
Risk and Threat Considerations
Crypto custody creates direct exposure to theft, insider misuse, operational error, and irrecoverable key loss. The central risk is that compromise of the signing authority, not just the wallet software, can allow irreversible transfer or permanent denial of access.
Failure mechanism: Attackers or insiders target the weakest control in the custody chain, often secret handling, approval workflow, or recovery process. If keys, seed phrases, or signing permissions are exposed, the asset can be moved without a realistic reversal path.
Impact: The organisation can suffer immediate financial loss, regulatory scrutiny, and loss of trust, especially when custody responsibilities are unclear or recovery procedures are not independently tested.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-57 and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-57 | Key Management | Crypto custody is fundamentally about key lifecycle, rotation, storage, and recovery control. |
| Recommendation — Apply key lifecycle discipline to limit exposure, rotation drift, and unrecoverable loss. | ||
| ISO/IEC 27001:2022 | A.8.24 — Use of cryptography | Custody models rely on cryptographic protection and operational rules for key handling. |
| A.5.15 — Access control | Custody depends on restricting who may approve, sign, or recover asset access. | |
| Recommendation — Define cryptographic handling rules that govern custody, storage, and recovery practices. Restrict custody actions to approved roles and enforce least-privilege access. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Custody workflows depend on secure lifecycle management of authenticators and secrets. |
| AC-6 — Least Privilege | Custody authority should be minimized because excessive signing power creates loss risk. | |
| Recommendation — Manage authenticators and secrets so custody access remains controlled and revocable. Limit custody permissions to the minimum authority needed for each role. | ||
Practitioner Guidance
Governance implication: The custody model should be chosen as an accountable control design, not a generic platform feature. Define who owns key policy, who can approve transfers, who can invoke recovery, and which events require escalation or dual control.
What to watch for: Watch for long-lived keys, informal recovery practices, overbroad signing authority, and custody setups that rely on a single person or single service. Those are the conditions most likely to turn a contained control weakness into an irreversible asset event.
