VARA Key and Wallet Management: What the Rules Say

If you run a VASP licensed by Dubai’s Virtual Assets Regulatory Authority, the binding key and wallet obligations are shorter than you think, and the detailed technical content that is usually quoted at you is not binding at all. Part I, Section D of the Technology and Information Rulebook contains four numbered Rules. That is the whole of the mandatory key and wallet management text that applies to every VASP.

The thirteen technical control standards that everyone cites - key generation, wallet creation, key storage, smart contract security, multi-signature, transaction verification, key compromise response, key holder management, authentication, developer workstations, security testing, unauthorised recovery, audit logging - sit in Schedule 1, Risk Category 2. Schedule 1 opens by describing itself as Guidance, and every standard in it is phrased as what VASPs are “expected to” do. Schedule 1 is a risk taxonomy for building your Technology Governance and Risk Assessment Framework. It is not a licensing tier, and there is no such thing as a “VASP in Risk Category 2”.

The third tier is the one most articles miss entirely: if you provide Custody Services, or simply hold Client VAs, a further set of binding wallet rules applies from the Custody Services Rulebook and the Client Virtual Assets Rules. That is where the seed-phrase split, the per-client wallet segregation and the hot/cold storage obligation actually live. This article walks all three tiers, with the rule reference against each requirement.

The Technology and Information Rulebook states that, unless otherwise stated, all its requirements are Rules with binding effect. Section D contains four:

This is the single most quoted and most misquoted sentence in the rulebook. Here is the whole of it:

“adopt industry best practices for storing the private keys of clients, including ensuring that keys stored online or in any one physical location are insufficient to conduct a Virtual Asset transaction, unless appropriate controls are in place to render physical access insufficient to conduct such Virtual Asset transaction. VASPs must further ensure that backups of the key and seed phrases are stored in a separate location from the primary key and/or seed phrase”

VARA Technology and Information Rulebook, Rule I.D.2.b

Four things are worth pulling out of that text, in order:

• It is about client private keys. The sub-rule opens with “storing the private keys of clients”. Your own treasury keys are governed by the no-single-point-of-failure duty in I.D.2.a, not by this sentence.
• It bites on location as well as connectivity. Keys held “in any one physical location” are caught alongside keys held online. An air-gapped safe with all the material in it fails the same test as a hot wallet.
• There is an escape clause, and it is doing real work. The insufficiency requirement applies “unless appropriate controls are in place to render physical access insufficient to conduct such Virtual Asset transaction”. VARA is not banning online signing outright; it is banning an arrangement in which getting to one place, or one system, is enough to move client assets. If you can show that physical or logical access to that single location cannot on its own produce a valid transaction, you are inside the rule.
• Backups must be elsewhere. Backups of keys and seed phrases must be stored in a separate location from the primary. This half of the sentence has no escape clause.

Two of the four sub-rules under I.D.2 are about people, and they contain the only hard cadence in the whole of Section D.

• Access logging (I.D.2.c). Strict access management controls to manage access to keys, “including an audit log detailing each change of access to keys”. Not each use of a key: each change of access to it.
• Leavers trigger an assessment, not an automatic rotation (I.D.2.c). The rule is precise: if Staff with access to a key, including a multi-signature arrangement key, leave the employment of the VASP, “the VASP must conduct an assessment to determine whether a new key must be generated”. VARA requires the assessment and a decision you can defend. It does not mandate rotation in every case.
• Revoked signatories must be cut off from the backup too (I.D.2.d.i). The key generation process must ensure that revoked signatories do not have access to the backup seed phrase, or knowledge of the phrase used in the key’s creation. Revoking a login is not enough if the person still knows the words.
• Quarterly internal audits (I.D.2.d.ii). VASPs must “perform internal audits on a quarterly basis concerning the removal of user access by reviewing access logs and verifying access as appropriate”. This is the one recurring obligation in Section D with a stated frequency, and it is scoped to the removal of user access.
• Document both directions (I.D.2.d.iii and iv). A procedure for documenting the onboarding and offboarding of Staff, and a procedure for documenting the VASP’s permission to grant or revoke access to each role in its key management system.

Read alongside Rule I.D.4 - access only for individuals with a demonstrable business need, with an access log - these five sub-rules are, in practice, a joiners-movers-leavers control on the key management system. The quarterly audit is what makes it evidenceable.

Schedule 1 states that it “is provided by VARA as Guidance to VASPs, to assist them in creating effective Technology Governance and Risk Assessment Frameworks”, and that VASPs “should consider” its risk categories and mitigation standards. Everything below is therefore an expectation you should be able to explain your position against, not a duty you either meet or breach. It is still the clearest statement VARA has published of the technical bar it has in mind.

This is the most precise thing VARA has written about custody architecture, and it deserves to be quoted exactly. Under the multi-signature security standard, VASPs are expected to implement robust multi-signature requirements including:

“minimum multi-signatures for high-value operations, where the minimum number of signers (M) is greater than the total number of signatories (N) divided by two (2) (i.e. M > N/2)”

VARA Technology and Information Rulebook, Schedule 1, Risk Category 2, standard 5.a

Two qualifiers matter and are usually stripped out when this is repeated. First, it is Guidance, not a Rule. Second, it is scoped to high-value operations, not to every signing operation you run. What it means arithmetically is a strict majority: an equal split does not clear the bar.

The rest of standard 5 is often forgotten and is harder to retrofit than the threshold: geographic distribution of signing authorities; diverse authorisation mechanisms and separation of duties between signers; and regular testing of signature processes. A 3-of-5 scheme where all five signers sit in the same office and use the same authentication method satisfies the arithmetic and misses the point.

VARA’s published rulebooks do not mention MPC or threshold signature schemes, so there is no VARA text stating how M > N/2 maps onto MPC-TSS. If you run MPC, the defensible position is to document how your threshold configuration achieves the stated purpose of the standard - eliminating single points of failure and remaining resilient to the compromise of individual signers - rather than to claim a VARA rule that does not exist.

Section D is silent on wallet segregation, seed-phrase splitting and hot versus cold storage. Those obligations are real, binding, and live in two other places. Under the Client Virtual Assets Rules in the Compliance and Risk Management Rulebook, which reach any VASP holding or controlling Client VAs:

• Separate wallets, and a label (Part V.B.3). “VASPs shall hold Client VAs in separate VA Wallets from all Virtual Assets of the VASP. VASPs must include the label ‘Client VA Wallet’ in their books and records for all wallets holding Client VAs at all times.”
• One-to-one, no rehypothecation (Part V.B.4). Client VAs must be held on a one-to-one basis, with rehypothecation prohibited unless there is explicit prior client consent granting discretionary authority and the VASP is licensed for the relevant VA Activity.
• Daily reconciliation (Part V.D.1). A system ensuring accurate reconciliations of the Virtual Assets owned by each client are carried out daily, including full lists of individual client credit and debit ledger balances. Material unrectified discrepancies must be notified to VARA.

If you are licensed for Custody Services, Part III of the Custody Services Rulebook adds a further layer, and it is materially stricter:

• Per-client wallets (III.B.3). Custodians “shall segregate the Virtual Assets of each client in separate VA Wallets containing the Virtual Assets of that client only”. Not just client versus house: client versus client.
• No rehypothecation at all (III.B.2). Custodians must not authorise or permit rehypothecation regardless of client consent, and must not seek that consent.
• Hot and cold storage (III.C.1). Custodians must maintain appropriate certifications as required under industry best practices; should conduct a risk-based analysis to determine the storage method including wallet type; and should document in detail the methodologies and behaviour determining transfers between hot, cold and warm wallets, with those mechanisms subject to internal controls and audits performed by an independent third-party auditor.
• Split the mnemonic (III.C.2.c). “All key and seed backups must be stored in a separate location from the primary key and seed. Key and seed backups must be stored with encryption at least equal to the encryption used to protect the primary seed and key. If VASPs use mnemonic back-up seed phrases, it should ensure that the mnemonic back-up seed phrase is broken into at least two (2) parts. Any backups that when combined could facilitate a transaction, must not be stored in a single point of access.”
• Keep the seed creator away from signing (III.C.2.a). Custodians must consider all risks associated with producing a private key or seed for a signatory, including whether the signatory should be involved in the generation process at all, and whether creators of the seed or key should be prohibited from cryptographically signing any transaction or from having access to any relevant systems.
• Collusion is a named risk (III.C.2.e). Custodians must mitigate the risk of collusion between all authorised signatories able to authorise movement of client assets, and must evaluate collusion and other internal points of failure for materiality and probability during recurring operational risk assessments.
• Lost or stolen keys (III.C.3). Policies and procedures covering recovery of affected Virtual Assets, timely communication with clients and counterparties, cooperation with law enforcement and regulators, and where applicable the preparation and public disclosure of wind-down arrangements.

Knowing the boundary of the text is as useful as knowing the text. None of the following appears anywhere in VARA’s published rulebooks, and each of them is regularly asserted as a VARA requirement:

• A hot/cold split. No percentage, no cap, no minimum. The Custody Services Rulebook requires a risk-based analysis and documented transfer methodologies, and stops there.
• An HSM mandate. Schedule 1 expects HSMs for key generation “where possible” and for “critical key storage”. It is Guidance, it is qualified, and it names no certification level.
• Named cryptographic standards. No NIST publication, no FIPS level, no entropy bit-count and no named curve appears in the Technology and Information Rulebook. Schedule 1 says “industry-approved methods with sufficient entropy” and “minimum standards for encryption” without naming them.
• A key rotation period. There is no calendar-based rotation requirement. There is an assessment obligation on leaver events (I.D.2.c) and an expectation of “rapid key rotation capabilities” for compromise response.
• A tabletop exercise frequency. Schedule 1 expects “regular testing and simulation” of the key compromise response plan and “regular testing of signature processes”. It gives no interval.

The practical consequence is that your Technology Governance and Risk Assessment Framework has to carry the argument. Rule I.A.2 requires the policies and controls addressing these risks to take into account the nature, scale and complexity of the business, the diversity of operations and the volume and size of transactions. Where VARA leaves a number open, you are expected to set it, justify it against your own risk assessment, and be able to show your working.

Turning the rulebook into a control set you can evidence

Venvera does not ship a VARA framework module, and this article is not a pitch for one. What the platform does provide is the structure the obligations above resolve into: a control library where each control has an owner, a review date and an implementation status; an evidence repository with freshness tracking, for artefacts like the quarterly access audit under I.D.2.d.ii; a risk register for the risk-based judgements VARA leaves open; incident management for the key compromise path; and a control crosswalk so the same evidence serves ISO 27001, NIST CSF and UAE Information Assurance rather than being rebuilt for each.

Frequently Asked Questions

Does VARA require a minimum percentage of client assets in cold storage?

No. No hot/cold ratio appears in any VARA rulebook. Custody Services Rulebook Rule III.C.1.b says custodians “should conduct a risk-based analysis to determine the method of Virtual Asset storage including different types of VA Wallets (e.g. hot versus cold storage)”, and Rule III.C.1.c requires the methodologies governing transfers between hot, cold and warm wallets to be documented in detail and subject to internal controls and independent third-party audit. The split is yours to set and to justify.

Does VARA ban hot wallets?

No. Rule I.D.2.b requires that keys stored online, or in any one physical location, are insufficient to conduct a Virtual Asset transaction, “unless appropriate controls are in place to render physical access insufficient to conduct such Virtual Asset transaction”. The target is the single point of failure, not connectivity as such. An architecture in which reaching one system or one room is enough to move client assets fails the rule; an online signing path with controls that prevent single-point access from producing a valid transaction does not.

Is the M > N/2 multi-signature threshold a binding VARA rule?

It is Guidance, not a Rule. It appears in Schedule 1, Risk Category 2, standard 5.a of the Technology and Information Rulebook, which VARA expressly issues as Guidance, and it is scoped to “high-value operations”. The formula is exact: the minimum number of signers (M) must be greater than the total number of signatories (N) divided by two. A 2-of-4 scheme fails because 2 is equal to, not greater than, 2. Separately, Custody Services Rulebook III.C.2.d states that custodians “should consider using multi-signature approaches where appropriate” and that VARA reserves the right to require them in specific situations.

Must a VASP rotate keys when a key holder leaves?

Not automatically. Rule I.D.2.c requires that where Staff with access to a key, including a multi-signature arrangement key, leave the VASP’s employment, “the VASP must conduct an assessment to determine whether a new key must be generated”. The binding obligation is the assessment. Separately, Rule I.D.2.d.i requires the key generation process to ensure that revoked signatories do not have access to, or knowledge of, the backup seed phrase.

How long must VASPs retain key and wallet logs?

Schedule 1, Risk Category 2, standard 13 expects logs to capture all security-relevant events, be stored securely with tamper-evidence, and be maintained for a minimum of one year, covering all wallet and key operations, with real-time alerting for security events. As a binding Rule, I.D.2.c separately requires an audit log detailing each change of access to keys, and I.D.4 requires an access log for individuals granted access to systems and data.

Does VARA require seed phrases to be split?

For custodians, yes in substance. Custody Services Rulebook III.C.2.c says that if VASPs use mnemonic back-up seed phrases, the phrase should be broken into at least two (2) parts, that backups must be stored in a separate location from the primary key and seed with encryption at least equal to that protecting the primary, and that any backups which combined could facilitate a transaction must not be stored in a single point of access. For all VASPs, the binding Rule I.D.2.b requires backups of keys and seed phrases to be stored in a separate location from the primary.

Primary sources

Every requirement in this article is taken from VARA’s published rulebooks. Confirm the current version before relying on any specific rule.

• Technology and Information Rulebook, Part I Section D - Cryptographic Keys and VA Wallets Management, Rules I.D.1 to I.D.4.
• Technology and Information Rulebook, Schedule 1, Risk Category 2 (Technical) - the thirteen technical standards, issued as Guidance.
• Custody Services Rulebook - Part III, VA Storage and Custody Rules, including segregation (III.B), hot and cold storage (III.C.1), seed and key generation, storage and use (III.C.2) and lost or stolen keys (III.C.3).
• Compliance and Risk Management Rulebook - Part V, Client Virtual Assets Rules, including separate Client VA Wallets (V.B.3), rehypothecation (V.B.4) and daily reconciliation (V.D.1).

Last updated: July 2026. This article is general information, not legal advice. Confirm the current rulebook text and consult VARA directly for entity-specific guidance.