Custody is the one part of a digital asset business where a security failure is final. A payment platform that authorises a fraudulent transfer has a reconciliation problem and a difficult conversation with a scheme. A custodian that authorises a fraudulent withdrawal has lost the asset, and no amount of subsequent process improvement brings it back. That asymmetry should shape how the platform is modelled, and in our experience it frequently does not: custody gets modelled as one component among many, with the same depth of analysis as the marketing site.
What follows is the structure we use when facilitating a threat modelling session for a regulated digital asset service provider. It is deliberately unremarkable — decompose, enumerate actors, map trust boundaries, walk the attack paths, test whether the controls named actually stand where they are claimed to stand. The value is not in the novelty of the method. It is in doing it at the right level of granularity for an asset class where the transfer cannot be reversed.
Start with the transfer, not the architecture
Most threat models begin with a component diagram. For custody, begin with a single question: what is the complete set of sequences that can result in value leaving the platform? Write them out. A typical mid-size custodian has more than the three everyone names first.
- Customer-initiated withdrawal through the standard interface
- Customer-initiated withdrawal through the API, which frequently has different limits
- Internal treasury movement between wallet tiers
- Rebalancing, sweeping and consolidation, often automated
- Fee collection and settlement to firm accounts
- Manual intervention by operations to correct a stuck transaction
- Emergency procedures, including whatever the disaster recovery runbook authorises
- Staking, delegation or bridging operations where the platform supports them
Each of those is an authorisation path. The standard withdrawal path is usually well controlled because it is the one everybody thinks about. The last three on that list are where we find the highest-severity issues, because they were built under time pressure during an incident and inherited the privileges of whoever built them.
Actors worth modelling
Generic actor lists produce generic findings. For custody the useful categories are narrower.
External attacker with no access
Reaches the platform through public interfaces. Their realistic goals are credential compromise at scale, an application flaw that yields authorisation, or a supply chain route into the build pipeline. Model them against the internet-facing surface and the dependency graph, not against the wallet directly.
Compromised customer account
The most common real-world scenario. Model what a single fully compromised customer account can extract, how fast, and whether any control other than the customer's own authentication stands in the way. Address allowlisting with a time delay is the control that most reliably converts this from a loss into an alert.
Compromised internal operator
A support, operations or engineering account under external control. The question is not whether this can happen — assume it can — but what the account reaches. Model each internal role against the withdrawal paths above and identify every path a single role can complete alone. Those are the findings that matter.
Malicious insider with legitimate access
Distinct from the compromised operator because they can wait, observe controls, and choose a moment. Model against detection and quorum rather than prevention: a control that a patient insider can satisfy alone is not a control.
Compromised third party
Node providers, blockchain analytics services, custody technology vendors, identity verification providers, and the CI/CD supply chain. Model what each one can influence. A compromised analytics provider that returns a clean risk score for a sanctioned address creates a regulatory failure rather than a direct loss, which is exactly why it is often omitted.
Trust boundaries that matter
Draw boundaries where authority changes, not where the network changes. In a custody platform the boundaries worth marking are: between the customer-facing application and the internal API; between the internal API and the withdrawal orchestration service; between orchestration and the policy engine that authorises signing; between the policy engine and the signing service itself; and between the signing service and key material.
The critical property to test at each boundary is whether the downstream component independently verifies authority or trusts the caller. A signing service that signs whatever the orchestrator sends has no boundary at all, regardless of the network segmentation drawn around it. This is the single most productive question in a custody threat model, and it is answered by reading the signing service's validation logic rather than the architecture document.
Walking the attack paths
With actors and boundaries in place, walk each withdrawal path from each actor's starting position and record what would have to be true for them to complete it. Keep the analysis concrete. "Attacker escalates privileges" is not a step; "attacker uses the support console's account-unlock function to remove the address allowlist delay" is.
Three patterns recur often enough to check for explicitly:
- Chain entry. The control sits at step two, but step four accepts a request that was never validated at step two. Test by constructing the step-four request directly.
- Quorum collapse. The policy says two approvers. In practice one person holds two credentials, or the second approver is a service account, or the approval UI accepts both approvals from one session.
- Concurrency. Two requests each pass the balance or limit check before either commits. This has caused real losses at real platforms and is trivially testable in a staging environment.
From model to evidence
A threat model that stays in a workshop document has no regulatory value. Convert each identified path into one of three artefacts: a control that exists and can be evidenced, a control that needs building with an owner and a date, or an accepted residual risk with a named accepting authority. Supervisory reviewers are generally satisfied by the third category when it is explicit and unsatisfied by the absence of the category entirely, which reads as a model that only recorded good news.
Re-run the model when the withdrawal paths change — a new chain, a new automation, a new emergency procedure — rather than on a calendar. Calendar reviews tend to re-examine the paths that were already understood, which is not where the next incident comes from.
