Most VASP custody breaches in the last three years were not cryptographic failures — they were policy failures. ITSEC's forensic team has now seen the same eight Transaction Authorization Policy misconfigurations across nearly every major incident. This is the definitive operational guide for VARA-licensed VASPs: what each failure looks like, how attackers exploit it, and the quarterly audit cadence that prevents the next one.
In nearly every major VASP custody incident ITSEC's forensic practice has been retained to investigate, the cryptography held. The signers held. The hardware modules held. What gave way was the Transaction Authorization Policy — the rule engine that mediates between cryptography and operations. This article walks through the eight recurring TAP failure modes we now find in essentially every custody operation we audit, how attackers exploit them, and the disciplined quarterly cadence that prevents the next breach. Written for VARA-licensed VASPs, DFSA Crypto Token firms, ADGM virtual asset entities, and any institutional custody operation in the GCC.
In nearly every major Virtual Asset Service Provider incident our forensic practice has been retained to investigate over the past three years, the same thing has been true: the cryptography held.
The hardware security modules held. The threshold signature schemes held. The cold wallet ceremonies held. The custody platform itself — whether Fireblocks, Hex Trust, Liminal, Copper, BitGo, or a bespoke MPC implementation — performed exactly as designed. None of these systems failed in the way the marketing literature warns about. None of them were broken open by a novel cryptanalytic attack or a zero-day in the signing engine.
What failed, every time, was the layer between them. The layer that everyone in the regulated VASP world has been quietly aware of for years but has had remarkably little vocabulary to discuss. The layer that decides who can move what to where, under which conditions, with which approvers, after which checks. The layer that encodes the entire operational substance of a custody business — not its cryptography, but its judgement.
The Transaction Authorization Policy.
A Transaction Authorization Policy, or TAP, sounds like a piece of plumbing. In a regulated VASP, it is the load-bearing wall of the entire business. It is the rule engine that mediates between the cryptographic guarantees of the custody platform and the operational reality of running a digital asset business — onboarding counterparties, settling trades, paying staff, sweeping treasury, rebalancing reserves, listing new assets, accommodating regulatory holds, handling emergencies. Every one of those operations passes through the TAP. Every one of them is gated by a rule. And every one of those rules was written by a human being at a particular moment in the business's history, in response to a specific need that has since changed shape or disappeared entirely.
This is the layer where custody breaches happen. Not because anyone is incompetent. Because policies drift, organisations change, and the surface area of an institutional custody operation is far larger than any single rule author can hold in their head.
Over the course of dozens of audits and several major incident investigations, we have learned to recognise eight recurring failure patterns in TAP configurations. These eight patterns — which we now refer to as F-01 through F-08 — appear in some combination in nearly every custody operation we examine, regardless of the platform, the regulator, or the maturity of the firm. They are not exotic. They do not require sophisticated tradecraft to exploit. They require only patience, observation, and an attacker who is willing to wait.
The purpose of this article is to walk through each of those eight patterns in detail. What they look like in the wild, why they happen, how attackers exploit them, how to detect them, and most importantly, how to prevent them through a disciplined quarterly audit cadence. This is the article we wish every Head of Custody at a VARA-licensed VASP had read three years ago.
To understand why the TAP is now the single most important security surface in a modern VASP, it helps to look at how the threat landscape has changed.
A decade ago, digital asset custody was overwhelmingly a cryptography problem. Exchanges held private keys on hot wallets, and those hot wallets were the principal attack surface. Mt. Gox, Bitfinex, Coincheck — the canonical losses of that era — were all, at root, key compromise events. Steal the key, steal the funds.
That world is largely gone, at least in the regulated market. Institutional custody is now dominated by Multi-Party Computation, hardware security modules, threshold signature schemes, and air-gapped cold storage. Private keys, in the traditional sense, no longer sit in places where they can be lifted. A modern Fireblocks workspace, properly architected, has no extractable private keys at all. The same is true of Hex Trust, Liminal, Copper, BitGo's institutional product, and every serious MPC platform. The cryptographic primitive that protected funds a decade ago has been replaced by a distributed signing protocol whose mathematical guarantees are, for all practical purposes, ironclad.
What has not changed is that funds still need to move. Trades still need to settle. Treasury operations still need to happen. Customer withdrawals still need to be processed. And so the cryptographic question — "can the attacker get the key?" — has been replaced by a different question, harder to answer and harder to govern: "can the attacker get the policy to authorise their transaction?"
This is the operational risk frontier. And it is the frontier on which most modern custody breaches occur.
The shift is sometimes invisible to senior management because the language of custody security has not caught up with the threat model. Boards still ask about cold storage percentages and signer counts. Auditors still ask about key ceremonies. Insurance carriers still ask about hardware modules. All of these are reasonable questions about a category of risk that has, in the regulated market, become substantially less salient than it was. The question that should be asked — and is too rarely asked, in our experience — is: "Show me the current state of the Transaction Authorization Policy, and tell me how it has changed in the last six months."
The Virtual Assets Regulatory Authority has been increasingly explicit on this point. The VARA Custody Services Rulebook and the Broker-Dealer Services Rulebook both impose extensive obligations not just on the cryptographic posture of a licensed VASP, but on its policies, procedures, segregation of duties, change management, and the documentary evidence that those controls actually operate as designed. The supervisory expectation is no longer that custody is safe because the cryptography is strong. It is that custody is safe because the cryptography is strong and the operational layer surrounding it is governed, evidenced, and independently verified.
The TAP sits at the centre of that operational layer. Which means the TAP is the centre of the supervisory expectation. Which means, in a competitive UAE virtual asset market where licensing scarcity creates premium valuations for VARA-approved entities, the TAP is also the centre of franchise value.
Before walking through the eight failure modes, it is worth being precise about what a TAP is and how it operates, because the language varies between platforms and the conceptual model is frequently misunderstood by people who do not work inside it daily.
At its core, a Transaction Authorization Policy is a rule engine. When a transaction is proposed inside the custody platform — whether by a human initiator, an automated trading system, a treasury bot, or an API consumer — the proposal is evaluated against the active policy ruleset before any cryptographic signing occurs. The policy decides, in order:
Is this initiator authorised to propose this kind of transaction? From this source vault? To this destination address? In this asset? For this amount, within this time window? Does this transaction pass external screening — AML, Travel Rule, sanctions, address risk? If approvers are required, who must approve, and how many of them, and from which devices? If the transaction fails any of these checks, what happens — block, hold, escalate, or allow with logging?
Each of these questions is encoded as one or more rules. A mature institutional custody operation will have anywhere from forty to several hundred rules in its policy. Each rule has a position in the evaluation order, a set of conditions, an action when the conditions are met, and a set of metadata describing who created it, when, and why.
The critical thing to understand — and the source of nearly every failure pattern in this article — is that the policy is declarative, evaluated top-to-bottom, and first-match wins. This means three things:
First, the policy as written may not be the policy as enforced. A rule that exists in the configuration but is never reached during evaluation is, for practical purposes, not in the policy at all.
Second, the policy is sensitive to ordering in ways that are difficult for human operators to reason about. Inserting a new rule near the top of the policy can silently change the behaviour of every rule below it.
Third, the policy is sensitive to data freshness. Whitelists, approver lists, role assignments, and external callbacks all reference data that exists outside the policy file itself. When that external data changes — a counterparty rotates their wallet, a staff member leaves, an AML provider changes its API contract — the policy may continue to function syntactically while becoming semantically wrong.
These three properties — order sensitivity, semantic drift, and the gap between written and enforced — are the soil in which all eight failure modes grow.
The first and most common failure mode is the simplest to describe and yet the hardest to remediate at scale.
A rule shadows another rule when its position in the evaluation order causes the second rule to never be reached. Because TAP engines evaluate top-to-bottom and apply the first matching rule, a broader rule earlier in the policy will absorb all the traffic that a more specific rule later in the policy was intended to handle.
The classic shape of this failure looks like the following. An engineering team needs to allow a particular operational pattern — say, automated treasury sweeps from a hot wallet to a cold wallet, performed by a service account, during business hours. They write a rule near the top of the policy that allows this pattern. Later, a security review identifies a class of high-risk destinations — say, freshly created addresses with no transaction history — that should be blocked regardless of source. A new deny rule is added at the bottom of the policy to handle this case.
The deny rule never fires. The broader allow rule at the top has already matched and authorised the transaction by the time the evaluation engine would have reached the deny rule. The intent of the security review has been silently defeated by the position of the rule, not by any error in the rule itself.
Rule shadowing is endemic in policies that have grown organically over time, particularly in operations that have changed platforms, gone through team changes, or experienced a period of rapid asset onboarding. The original rule authors are no longer present, the documentation of why each rule exists has not kept pace with the rules themselves, and new rules tend to be appended at the bottom of the policy because that is the path of least resistance.
The detection method is straightforward in principle and laborious in practice. Every rule in the policy must be tested against the full envelope of traffic the policy is intended to handle. Rules that are never matched by any realistic transaction are either dead — meaning the operational pattern they were designed to handle no longer exists — or shadowed — meaning the pattern exists but is being handled by an earlier rule instead. In either case, the rule should not remain in the policy. Dead rules should be removed. Shadowed rules should either be moved earlier in the evaluation order so that they fire, or merged with the broader rule that is currently absorbing their traffic.
The remediation is procedural rather than technical. Quarterly policy review with full traffic replay against staging — where every active rule must be demonstrated to fire at least once during a representative period — eliminates rule shadowing at root. Without this discipline, every policy more than eighteen months old that we have audited has contained rule shadowing somewhere in its evaluation graph.
The second failure mode is the one that keeps senior security leadership awake at night, because it sits at the intersection of cryptography and judgement, and it is invisible to anyone reading the policy as written.
Modern custody platforms allow operators to require that a given transaction be approved by multiple human signers before cryptographic signing occurs. The TAP specifies the quorum — for example, "any two of these five approvers" — and the platform enforces it at the cryptographic layer. From a mathematical perspective, the security of a 2-of-5 quorum is well-understood, and the platform will not produce a signature unless two of the five designated approvers have authorised the transaction from devices they control.
The problem is that mathematical quorum and operational quorum are not the same thing.
Mathematical quorum says: two distinct cryptographic identities signed the transaction. Operational quorum says: two independently-minded humans, each exercising independent judgement, each with independent visibility into the transaction's context, agreed that it should proceed.
These are often very different conditions. The mathematical quorum is satisfied trivially in cases where:
The two approvers are the same human operating two devices. This is more common than auditors would like to admit, particularly in smaller VASPs where the operations team is lean and where convenience pressures cause one person to hold credentials on a laptop and a mobile device in order to "self-quorum" routine transactions.
The two approvers are members of a tight social cluster — colleagues who share a Slack channel, sit next to each other in the office, or travel together. In these clusters, the second approver's judgement is not independent of the first's. Whoever approves first effectively determines the outcome, because the social cost of refusing a peer's approval is non-trivial.
The two approvers are arranged in a default-approve relationship driven by operational pressure. If your treasury team needs to process eighty routine transactions per day and the quorum requires two of them to approve each one, the quorum will collapse to a check-the-box ritual within weeks. The cryptography continues to say two signatures. The threat model has one.
The third case is particularly insidious because it cannot be addressed by changing the quorum — making it 3-of-5 instead of 2-of-5 will only push the collapse one human deeper. The remediation is operational, not configurational. It requires that the quorum be structured so that the second approver has a genuinely different lens on the transaction than the first — for example, by ensuring that the second approver sits in a different function (compliance reviewing what trading approved, or finance reviewing what operations approved), and by ensuring that the second approver has access to context the first approver does not have.
Detection of quorum collapse requires graph analysis of approval history, looking for patterns in which the same pair of approvers consistently appear together, in which approval latency between first and second signature is implausibly short (sub-second second-approvals are a hallmark of automation or batch-approval workflows), and in which the rate of declined transactions by second approvers is near zero. A healthy second-approval layer will reject some non-trivial fraction of transactions; a collapsed second-approval layer will reject essentially none.
Quorum collapse is the single most damaging failure mode on this list when it intersects with an insider threat. Every major insider-assisted custody breach our forensic team has investigated has involved a quorum that was, in the moment of the attack, mathematically intact and operationally meaningless.
The third failure mode is the simplest to understand and the hardest to defend against in operations that have been running for more than two years.
Most TAPs include a whitelist of approved destination addresses for transfers out of custody. The whitelist enumerates the wallets controlled by trusted counterparties — partner exchanges, banking partners' on-ramp providers, treasury reserves at custodian banks, key clients with standing settlement relationships. Whitelisted destinations bypass the more onerous approval flows that apply to ad-hoc destinations. This is sensible: a custody operation that required full quorum approval for every settlement to a long-standing partner exchange would grind to a halt within a week.
The flaw in this design is that the whitelist is data, and data ages.
A wallet whitelisted in 2022 because it was, at that time, the deposit address for a particular counterparty may by 2026 be controlled by a third party entirely. Wallets are routinely rotated for operational hygiene; counterparties merge, dissolve, or are acquired; key personnel change roles and migrate institutional wallets to new addresses; addresses are sometimes leaked, compromised, or sold on secondary markets. The whitelist that was accurate when it was created is not necessarily accurate today.
The TAP does not know this. The TAP knows only that the address on the whitelist matches the destination of the transaction, and therefore the transaction is approved. If the underlying ownership of that address has changed, the funds will arrive at whoever now controls the key.
The detection methodology has three components. First, a rolling re-verification of every whitelisted address with the named counterparty — ideally on an annual cadence, no less than every eighteen months, and continuously for addresses associated with the highest-value relationships. Second, on-chain analysis of whitelisted addresses to identify changes in behavioural pattern (sudden movements out of an address that has been dormant; rotation of funds through mixing services; appearance of the address in connection with known illicit activity). Third, automated alerts on any whitelist edit — additions, removals, or modifications — with a mandatory review by a second function before the edit takes effect.
The procedural remediation is structurally tedious: a quarterly whitelist hygiene review in which every entry is either re-verified, retired, or escalated for further investigation. In our audits, we routinely find whitelists with twenty to forty percent of entries that have not been touched, re-verified, or even examined in over two years. Each of those entries is a latent risk.
A particularly dangerous variant of whitelist staleness occurs in operations that have migrated between custody platforms. The whitelist is exported from the old platform and imported into the new one, often with the original timestamps and approval metadata stripped. The new platform shows a clean whitelist with apparently fresh entries; the underlying addresses may not have been verified in years.
The fourth failure mode is the one that is most often overlooked, because the entire industry has been conditioned to think of "read-only" as synonymous with "safe."
In every modern custody platform, machine identities — API keys, service accounts, OAuth clients — are scoped to specific roles. The principal role distinction is read versus write: a read-scoped key can query the state of the custody platform but cannot initiate transactions, while a write-scoped key can both query and initiate. The convention across the industry is to provision read-only keys generously for any operational consumer that needs visibility — business intelligence dashboards, internal reconciliation scripts, finance reporting tools, audit data exports, third-party AML providers, executive monitoring dashboards.
The reasoning is intuitive. Read-only keys cannot move funds. Therefore, if a read-only key is compromised, the worst the attacker can do is observe. Observation is not theft. Therefore, read-only keys do not require the same rotation cadence, the same access controls, the same logging discipline, or the same scrutiny as write keys.
This reasoning is precisely wrong, and the gap between this reasoning and reality is one of the most fertile attack surfaces in modern custody.
A workspace-wide read-only key in a sophisticated custody platform can enumerate every vault, every balance, every signer, every recent transaction, every whitelist entry, every policy rule, and the full topology of how the custody operation is organised. It can be queried at high frequency without raising alarms, because read traffic is treated as benign by most monitoring tools. It can be exfiltrated and used continuously over months or years without producing any cryptographic signature, any transaction record, or any movement of funds.
What it enables is reconnaissance. And reconnaissance is the prerequisite for any sophisticated custody attack.
An attacker in possession of a workspace-wide read-only key can do the following over a period of weeks: identify which vaults contain the highest balances; determine which assets are held in which custody locations; profile the rhythm of normal transaction flows, including which approvers are routinely online and at what hours; identify after-hours periods of low approver coverage; map the relationships between vaults, identifying which are linked to operational sweeps and which are linked to cold reserves; observe the cadence and pattern of policy changes, identifying windows of administrative activity that might be exploited for confusion attacks; identify the email addresses, names, and roles of signers from approval metadata.
Equipped with this reconnaissance, the attacker now has the information needed to attempt a second-stage compromise — typically a social engineering attack against a specific signer, a credential phishing campaign timed to a known approval window, or an insider recruitment effort targeting a specific role with high access. The read-only key was the lever; the eventual breach is delivered through a different vector entirely.
The remediation is structural. Read-only keys should be scoped as narrowly as the write keys they accompany. A business intelligence dashboard does not need workspace-wide visibility; it needs visibility to specific vaults or specific event types. A reconciliation script does not need every transaction in real-time; it needs a daily summary of the specific accounts it is reconciling. Where workspace-wide read access is genuinely required — for SOC monitoring, for example — the key should be in a dedicated identity, rotated on the same cadence as write keys, monitored for unusual query patterns, and subject to the same alerting discipline as any write-capable identity.
Most importantly, the question "what is the legitimate use case for this key?" should be asked of every read-only key in the inventory, every quarter. Keys without a clear, named, current consumer should be revoked.
In our audits, we have found instances of read-only keys that were provisioned for projects that ended eighteen months earlier, with the key still active and still being queried — sometimes from infrastructure that no longer belonged to the original consumer. Each of those keys is a latent reconnaissance vector that may or may not have already been exploited.
The fifth failure mode is a product of the way custody platforms are deployed across multiple environments.
Most institutional custody platforms allow operators to provision multiple workspaces — typically a production workspace where real funds live, and one or more staging or development workspaces used for testing integrations, validating policy changes, training new staff, or experimenting with new asset types. This is good practice. Changes should be tested before they are applied to production. New signers should be trained against environments where mistakes do not move real money. Integration partners should be validated against sandboxes before they are connected to live custody.
The failure mode emerges from the gap between the cryptographic separation of these environments — which is typically rigorous — and the operational separation of them, which often is not.
The recurring pattern is that staging or development workspaces inherit configurations from production for convenience. The same signer identities are configured in staging as in production, because it is easier to test approval flows with the same humans. The same API key naming conventions are used, because it makes documentation simpler. The same destination whitelists are imported, because exporting and re-curating them would take days. The same external callbacks — to AML providers, to Travel Rule services, to address risk APIs — are wired up using the same credentials, because each provider is reluctant to issue test credentials and the staging integration is the only way to validate behaviour.
The result is a lower-trust environment that has full operational visibility into, and partial credential overlap with, the highest-trust environment in the business. Compromise of staging — perhaps via a lax developer laptop, a forgotten credential in a Git repository, a misconfigured CI/CD pipeline, or an over-privileged contractor — escalates to compromise of production through any of several vectors.
A signer's authentication credentials, used in staging for testing, are now valid for production. An API key naming convention, reverse-engineered from staging, allows an attacker to predict the format of production keys. A whitelist exported from staging can be cross-referenced against production to identify high-value destinations. External callback credentials, used in staging, are valid for production calls and can be poisoned to manipulate AML decisions in the live environment.
The remediation is conceptually simple and operationally demanding. Trust boundaries between environments must be real, not nominal. Each workspace should have its own signer identities, its own API key namespace, its own whitelist, its own callback credentials, and its own access control list. Staff who require access to both environments should authenticate separately to each. Configurations may be templated and replicated, but credentials must not be.
Test workspace inheritance is a failure mode that is rarely surfaced by routine compliance audits because each environment, examined in isolation, looks correctly configured. It only becomes visible when the trust boundaries between environments are examined in aggregate — which is precisely what a Digital Wallet Audit is designed to do.
The sixth failure mode lives in the part of the policy that most operators rarely think about: what happens when something outside the policy goes wrong.
Modern TAPs do not operate in isolation. They depend on a set of external callbacks to make decisions. Before authorising a withdrawal, the policy may call out to an AML provider to screen the destination address. It may call out to a Travel Rule service to verify the counterparty institution. It may call out to a sanctions screening API to confirm the address is not on any restricted list. It may call out to an internal compliance system to verify that the counterparty's KYC is current.
Each of these external callbacks is a potential point of failure. The AML provider may be experiencing an outage. The Travel Rule service may have a network partition. The internal compliance system may be down for maintenance. The sanctions list may be temporarily unreachable. What does the policy do when its external dependencies do not respond?
There are two architecturally legitimate answers. The first is fail-closed: if the callback does not return a positive answer within the timeout window, treat the transaction as denied. The second is fail-open: if the callback does not return a positive answer within the timeout window, treat the transaction as allowed and log the bypass for later review.
The choice between these is a business decision with security consequences. Fail-closed prioritises security at the cost of operational continuity; fail-open prioritises operational continuity at the cost of security. There is no single correct answer, but there is a correct way to make the decision: explicitly, with documented reasoning, with the awareness of the executive responsible for the trade-off, and with monitoring that surfaces every instance of the fallback path being taken.
The failure mode is that most policies fail-open by default — sometimes because the platform's default behaviour is fail-open, sometimes because the rule was written to fail-open during a previous outage as a temporary measure that was never reverted, sometimes because the policy author did not consider the failure mode at all and the platform applied its default behaviour silently.
Compounding this, most operations do not test their fail-open paths. They do not periodically force their AML provider into a degraded state to observe what the TAP actually does. They do not have alerting on the specific signal that an external callback has been bypassed. The first time the fail-open behaviour is exercised at scale is during a real outage, by which point it is too late to evaluate whether it was the right choice.
The remediation requires three things in combination. First, the fail-open versus fail-closed behaviour of every external callback must be explicitly documented in the policy, with a named executive owner of the decision. Second, every fail-open path must produce a distinct telemetry signal that is monitored in real-time, so that any execution of the fallback is visible to the SOC within minutes. Third, the fail-open behaviour must be tested quarterly through controlled exercises that force the external dependency into a degraded state in a staging environment and verify that the policy behaves as documented.
A particularly malicious threat actor — and we have seen this — will not attempt to break the TAP directly. They will attempt to induce a failure in one of its external dependencies, knowing that the resulting fail-open will give them a window in which the policy is materially weaker than its written specification.
The seventh failure mode is procedural rather than configurational, but its consequences are written into the policy.
A regulated VASP that lists new digital assets — whether through a token approval committee, a regulatory engagement with VARA, or a partnership with an issuer — needs to ensure that its TAP catches up with the listing before the asset is operational. The asset must be added to vault structures. Policy rules referencing assets by name or by network must be updated to include the new asset. Whitelists must be expanded to cover counterparty wallets for the new asset. Quorum requirements for the new asset must be set in line with its risk profile. SIEM detection content must be extended to cover events involving the new asset.
The failure mode is that the policy update lags the listing. The asset becomes operational — customers can deposit, withdraw, and trade it — before the policy specific to that asset has been written. In the interim, the asset moves under whatever default policy applies to "any asset not otherwise covered." This default policy is, almost without exception, more permissive than the curated rules that govern established assets.
The window between listing and policy update is typically measured in days, sometimes weeks, in the institutions we have audited. During that window, the new asset operates with thresholds that may be far higher than its risk profile justifies, with quorum requirements that may be far lower, and with whitelist coverage that is non-existent.
A patient attacker who follows the listing announcements of a target VASP can predict, with reasonable accuracy, the windows in which a newly-listed asset will be operating under default policy. If the attacker is positioned to move funds in the new asset — perhaps through a compromised counterparty account or a manipulated internal initiator — the listing window is the optimal time to do so.
The remediation is a procedural lockstep between the listing process and the policy process. No asset goes operational until its policy has been written, reviewed, and applied. The asset listing committee and the security function operate as a single workflow, with the security sign-off as a hard gate on operational availability.
In our audits, we frequently find policies in which the most recent asset additions are visibly less mature than the rules covering long-established assets. Sometimes this is acceptable because the new asset is genuinely under default policy by design; more often it is an artefact of a listing process that has outpaced the policy process. The latter case is a finding that should appear in every audit until the gap is closed.
The eighth and final failure mode is the most human, the most difficult to detect through technical means, and the most reliably present in any custody operation that has been running for more than a year.
Signers are people. People get tired. The custody platform is unforgiving about this in one direction — it will not authorise a transaction without the required cryptographic signatures — and forgiving in the other — it will not measure the quality of the human attention that produced those signatures.
In a busy institutional custody operation, designated signers may be asked to approve hundreds of transactions per day. The vast majority of those transactions are routine: settlement to a known counterparty, sweep to a treasury vault, customer withdrawal to a previously-used destination. Over time, the cognitive load of evaluating each transaction's parameters — destination, amount, asset, source, time-of-day, counterparty — gives way to muscle memory. The signer's mobile device buzzes; the signer glances; the signer approves. The cryptographic event is registered. The transaction proceeds.
The policy did its job. The signer's hardware authenticator did its job. The custody platform did its job. What did not happen is the substantive human review the entire approval architecture was designed to ensure.
Designated signer fatigue is the failure mode that turns every other failure mode in this article into a successful attack. A shadowed rule, a stale whitelist, a fail-open callback, a compromised read-only key, a recently listed asset under default policy — each of these is a structural weakness that becomes a successful breach only when the signer at the end of the chain approves the malicious transaction without recognising it as such. In every insider-assisted custody breach we have investigated, signer fatigue has been a contributing factor. In several cases, it has been the primary factor.
Detection requires telemetry that is not, in our experience, commonly instrumented. The relevant signals include: approval latency (how long between transaction proposal and approval, with sub-five-second approvals being a marker of fatigue or automation); approval rate per signer per hour (sustained approval rates above a certain threshold are not sustainable for substantive review); pattern of batch approvals (multiple transactions approved within seconds of each other suggests the signer is approving a queue rather than evaluating each transaction); rate of declined transactions per signer (a signer who has never declined a transaction is not exercising independent judgement). These signals are available in the audit logs of every major custody platform, but they are rarely surfaced in monitoring dashboards because they require interpretation rather than alerting.
The remediation has two layers. The technical layer is to instrument these signals and surface them in management reporting, so that signer fatigue becomes a visible operational metric rather than an invisible cultural drift. The procedural layer is to redesign the signer workflow so that the cognitive load on any individual signer is sustainable: by load-balancing approval flows across a larger signer pool, by introducing forced pause periods for high-value transactions, by requiring signers to enter a destination identifier or transaction note as part of the approval (which forces attention), and by structuring the approver pool so that no individual signer is the routine approver for more than a manageable number of transactions per day.
The point is not to prevent fatigue — that is impossible in operations at scale. The point is to ensure that the policy is not structurally dependent on the fiction that fatigued signers exercise full judgement.
Each of the eight failure modes above is, in some sense, a technical configuration issue. But they are produced by an organisational process, and remediation that does not address the process will not hold.
TAPs drift for predictable reasons. Custody operations grow. Teams change. Regulations evolve. New assets are listed. New counterparties are onboarded. New banking relationships replace old ones. New AML providers are integrated. New jurisdictions are entered. Each of these changes requires a TAP modification. Over the course of a year, a busy VASP may make several hundred such modifications.
Each modification is, individually, small. The team that makes it understands its rationale, tests it appropriately, and applies it cleanly. The problem is the accumulation. The TAP after three hundred modifications is no longer the TAP that was originally designed. It is a layered accretion of judgements made by people who may no longer be at the firm, in response to circumstances that may no longer obtain. The original architectural intent of the policy is, by year three, frequently no longer recoverable from the policy itself.
This is the soil in which the eight failure modes grow. Rule shadowing happens because new rules are appended without re-examining the existing evaluation order. Whitelist staleness happens because additions are easier than removals, and the procedural cost of re-verifying old entries is never paid. Test workspace inheritance happens because each new staging deployment copies from the previous one, and no one steps back to ask whether the trust boundaries are still meaningful. Fail-open defaults happen because the original architect of the integration is gone and the current operators do not know what the original intent was.
The remediation for all eight failure modes, taken together, is what we describe in our engagements as policy re-derivation. Periodically — we recommend annually at minimum, biannually for high-throughput operations — the policy must be re-derived from current business intent. The question is not "is the existing policy correctly configured?" but "if we were writing this policy today, from scratch, knowing what we know about the current state of the business, would it look like this?" The two policies — the existing one and the re-derived one — are then compared, and every divergence is examined to determine whether it is justified or whether it is drift.
This is intellectually demanding work. It cannot be done by checklist. It cannot be automated by a vulnerability scanner. It requires senior practitioners who have walked the timeline of dozens of policies in dozens of institutions and who can recognise drift patterns the operators themselves cannot see. It is also the work that produces the single most operationally valuable artefact of any Digital Wallet Audit engagement: the re-derived policy itself, written in the native rule syntax of the platform, ready to stage and apply.
The supervisory dimension of all this matters, because in the UAE virtual asset market the cost of a failed custody control is not only the loss of funds and the reputational damage. It is also the supervisory exposure to VARA, which has been increasingly explicit in its expectations of licensed VASPs.
The VARA Custody Services Rulebook and the VARA Broker-Dealer Services Rulebook are the two principal sources of obligation for any licensed entity providing custody services in or from Dubai. Both impose extensive requirements on the cryptographic, operational, and governance dimensions of custody. Both require licensed entities to maintain documented, tested, and independently verified controls. Both require that the supervisory authority be able to inspect the evidence of those controls on demand.
What the rulebooks do not do — and this is sometimes a source of confusion among operators — is specify a particular audit methodology. There is no VARA-mandated checklist for what a custody audit must contain. There is no required template for the findings register. There is no specified frequency for the audit cadence beyond the broad requirement that controls be maintained on an ongoing basis.
What the rulebooks do require is evidence. Evidence that controls exist. Evidence that they are tested. Evidence that they are independently verified. Evidence that findings are remediated. Evidence that the policy was reviewed within a reasonable cadence. Evidence that change management is governed. Evidence that segregation of duties is enforced.
A Digital Wallet Audit, performed with the methodology described in this article, produces precisely this evidence base. The executive report is written to be submissible. The findings register is structured for supervisory review. The re-derived policy is the audit trail of intent. The verification letter is the closure artefact. Each is designed not as a one-off deliverable but as a piece of the standing evidence package that any VARA-licensed VASP should be prepared to present at any time.
The supervisory expectation is not that licensed VASPs never have findings. Every operation has findings; the Authority understands this. The expectation is that findings are identified, ranked, remediated, and verified, on a defensible cadence, by an independent party with the expertise to surface findings the operator's internal team would not see. The cadence we recommend — and the one that we believe matches supervisory expectation — is a full audit annually, with quarterly delta reviews to catch drift between full audits.
The eight failure modes described above are not equally likely to emerge in any given quarter. Some — rule shadowing, whitelist staleness, signer fatigue — accumulate gradually and are visible only against historical baselines. Others — test workspace inheritance, fail-open defaults — are structural conditions that change rarely but with significant consequence when they do. Still others — token-listing lag — are tied to discrete business events whose timing can be predicted.
A quarterly audit cadence that recognises these differing temporal patterns will be more effective than a flat quarterly review.
Quarter one — full re-derivation. Each year begins with a full Digital Wallet Audit and TAP re-derivation. Every rule examined. Every whitelist re-verified. Every API key inventoried. Every signer reconciled. Every external callback tested. This is the heaviest engagement of the year and produces the baseline against which the remaining three quarters are measured.
Quarter two — change delta. Three months after the baseline audit, the focus is exclusively on what has changed. Every policy modification made in the intervening period is examined against the baseline. New rules are evaluated for shadowing against the existing evaluation order. New whitelist entries are verified. New signers are reconciled against HR records. New API keys are checked for least-privilege scoping. The deliverable is a short delta report — typically twenty to forty pages — focusing only on the gaps introduced by the quarter's changes.
Quarter three — adversary emulation. Six months after the baseline, the cadence shifts to active testing. Adversary emulation exercises are run against staging environments, testing the policy's response to scenarios that include rule-shadowing exploits, quorum-collapse simulations, stale-whitelist abuses, read-scope reconnaissance, fail-open inducement, and signer-fatigue exploitation. The findings are validated against the baseline to determine which exposures have been introduced, which have been mitigated, and which remain open.
Quarter four — verification and submission preparation. Nine months after the baseline, the focus turns to preparing the next year's evidence package. Findings from previous quarters are confirmed as remediated. The standing evidence pack for VARA — executive summary, findings register, policy version history, verification letters, telemetry coverage map — is assembled into a single submission-ready package. The result is a posture that can be presented to the supervisory authority on demand, at any time, throughout the following year.
Twelve months after the baseline, the cycle restarts with the next full audit. The policy that emerges from each annual re-derivation is materially better than the one that preceded it. Over three to five years of this cadence, the institutional posture of the VASP matures into something that genuinely matches the supervisory standard the rulebooks describe — not as a one-off compliance exercise but as a steady-state operating discipline.
A TAP is one half of a custody control. The other half is the detection layer that observes the TAP in operation.
A perfectly written TAP, in an operation with no detection, is materially less secure than an imperfectly written TAP in an operation with comprehensive detection. The reason is that no TAP catches every edge case, and a control that catches ninety-five percent of malicious activity but has no observability for the remaining five percent is a control that will be defeated eventually. Detection is what closes the gap between the policy's design and the policy's enforcement.
Every major custody platform produces event logs. Every state-changing action — transaction proposal, transaction approval, transaction denial, policy edit, whitelist mutation, signer change, API key creation or revocation, configuration change — generates a log entry. Those log entries are the raw material of detection.
The failure pattern we encounter most often is not the absence of logs but the absence of monitoring. The logs exist; they are generated correctly; they are stored in the custody platform's audit trail. They are not, however, routed to a SIEM. Or they are routed to a SIEM, but no alert rules have been written against them. Or alert rules exist, but they are tuned to obvious anomalies and miss the patterns that matter — the slow enumeration via read-only keys, the after-hours policy edit, the rapid burst of single-signer approvals, the fail-open callback bypass.
A mature custody detection layer integrates the custody platform's logs into the same SIEM that handles the rest of the firm's security telemetry, with alert content specifically designed for the TAP's failure modes. Alerts fire on policy edits made outside business hours, on whitelist additions that bypass the standard review workflow, on API key creations not associated with a documented service, on approval latencies below a fatigue threshold, on enumeration patterns characteristic of reconnaissance, on external callback bypasses that suggest fail-open behaviour is being exercised.
These alerts feed the SOC, which has a runbook for each scenario. The runbook is tested quarterly. The on-call rotation knows what to do at three in the morning when the alert fires. The chain from custody event to SOC response to senior leadership escalation is exercised, not assumed.
This is the detection posture that turns a strong TAP into a strong custody operation.
After several thousand words of failure modes, processes, and remediation, it is worth ending on the affirmative: what does a well-run custody operation, examined through this lens, actually look like?
It looks like a policy that has been re-derived in the last twelve months, in which every rule's purpose is documented and every rule has been demonstrated to fire against realistic traffic in the last quarter.
It looks like a whitelist in which every entry has been verified with the counterparty in the last eighteen months, and in which additions go through a documented review by a second function before they take effect.
It looks like an API key inventory in which every key has a named owner, a documented consumer, a clear scope, and a rotation history that matches policy.
It looks like a signer roster that is reconciled monthly against HR records, with offboarding workflows that revoke custody access within the same window as building access.
It looks like external callbacks whose fail-open versus fail-closed behaviour is documented, monitored, and tested quarterly.
It looks like a quorum architecture in which the second approver routinely has different context from the first, and in which a non-trivial fraction of transactions are declined by second approvers.
It looks like a SIEM that ingests every state-changing custody event, with alert content specific to the failure modes described in this article, and a SOC that has a runbook for each scenario.
It looks like a standing evidence pack — executive summary, findings register, policy version history, verification letters, telemetry coverage map — that can be presented to VARA on demand, at any time, without preparation.
This is not an aspirational picture. It is the operating standard we have helped multiple VARA-licensed VASPs achieve in the GCC. It is the standard that licensing scarcity makes commercially valuable; it is the standard that supervisory clarity makes increasingly necessary; and it is the standard that the eight failure modes in this article are designed to drive operations toward.
The work of auditing custody operations to this standard is, in the most honest description, slow and patient. It is not glamorous. It does not produce screenshots of dramatic exploits. It produces, instead, the steady accumulation of evidence that the policy is what it says it is, that the controls operate as they are described, and that the operation is one that a regulator, a counterparty, an auditor, or a board can have justified confidence in.
That confidence is the franchise. It is what permits a VARA-licensed VASP to attract institutional flow, to negotiate banking relationships, to retain customer trust through market volatility, and to operate in a market where licensing scarcity makes franchise value a primary asset.
The eight failure modes described here — F-01 through F-08 — are not exhaustive. There are others we encounter less commonly, and there are new patterns emerging as the regulated VASP market matures. But these eight, in our forensic experience, account for the great majority of preventable custody breaches in the last three years. Every one of them is addressable. None of them require novel technology to remediate. All of them require disciplined attention sustained over time.
The Digital Wallet Audit and Transaction Authorization Policy Review engagement that ITSEC offers is the structured form of that disciplined attention — a four-to-six-week engagement that walks every rule, every key, every signer, every whitelist, every callback, every telemetry signal, and produces the evidence base described in this article. We deliver it onshore from Dubai, fixed-price, with a verification letter that any UAE regulator will accept. Our annual Continuous Custody Assurance subscription extends that posture across the four quarters of the year, with delta reviews, real-time monitoring, and an incident response retainer built in.
If you operate a VARA-licensed VASP, a DFSA Crypto Token firm, an ADGM FSRA virtual asset entity, a MiCA-regulated CASP, or any institutional custody operation in the GCC or MENA region, and the eight failure modes in this article are not currently being independently audited on a defensible cadence, this is the conversation we would like to have.
The policy that is examined this quarter is the policy that holds when the timeline starts running against it. The policy that is not examined is the policy that holds only by luck. In a regulated market with the supervisory expectations VARA has set, luck is not a control.
ITSEC is the UAE's first AI-augmented cybersecurity firm, headquartered in Dubai and operating onshore since 2011. We hold a 100% VARA licensing approval rate across the VASPs we have advised, have secured over $2 billion in digital assets through audits and continuous assurance engagements, and have led custody-breach investigations involving eight-figure losses with findings presented to regulators, law enforcement, and litigation counsel.
Request a Digital Wallet Audit scoping call: WhatsApp +971.52.509.7278 | hello@itsecnow.com | +971.4.257.2406
Solution URL: Digital Wallet Audit
Get a comprehensive security assessment from our expert team. Protecting businesses since 2011.