VARA Compliance 2025: What the Updated Rulebooks Require From Dubai VASPs

What Changed in June 2025

Dubai's Virtual Assets Regulatory Authority issued substantive updates to its full rulebook suite, effective 19 June 2025. These are not minor amendments. For any virtual asset service provider (VASP) operating in or entering the Emirate, the updated requirements include mandatory threat-led penetration testing, formalised technology governance at board level, quarterly AML/CFT client risk assessments, and hard Travel Rule compliance under FATF. If your security programme was designed before June 2025, it is now materially out of date.

This post sets out what VARA requires, what the June 2025 updates changed, and what documented evidence regulators expect to see. It applies equally to traditional financial institutions establishing a VASP operation in Dubai and to blockchain-native projects pursuing VARA authorisation to scale into regulated markets.

What VARA Is

VARA is the world's first independent regulatory authority dedicated exclusively to virtual assets. Established under Dubai Law No. 4 of 2022, it covers all VASP activity in Dubai's mainland and free zones, excluding DIFC, which operates under its own DFSA framework. VARA is not a sandbox. It is a full licensing and supervision authority with enforcement powers including fines, licence suspension, and referral for criminal prosecution.

VARA operates a rulebook-based framework. Every licensed VASP must comply with a set of mandatory rulebooks that apply across all activity types, plus activity-specific rulebooks relevant to their particular business. The mandatory rulebooks include the Compliance and Risk Management Rulebook, the Technology and Information Rulebook, the Market Conduct Rulebook, and the Company Rulebook.

Who Requires a VARA Licence

Any entity conducting virtual asset activities in Dubai requires a VARA licence. The regulated activity categories include:

• Advisory services (virtual asset advisory and asset management)
• Broker-dealer services
• Exchange services (operating order books or matching engines for virtual assets)
• Lending and borrowing services
• Management and investment services
• Transfer and settlement services
• Virtual asset custody
• Virtual asset issuance (including stablecoins and tokenised instruments)

This scope is not limited to large centralised exchanges. DeFi platforms facilitating lending or staking, bridge operators, tokenisation platforms, and custody providers all fall within VARA's remit if they operate from or materially into Dubai. If you are in any doubt about whether your activity is caught, the position VARA takes is that doubt is not a defence.

The Consequences of Non-Compliance

VARA's enforcement powers are material. Non-compliance can result in:

• Financial penalties from AED 10,000 to AED 500,000 per violation, with additional penalties applied for repeat or unpaid fines
• Immediate cessation orders stopping virtual asset activity
• Licence suspension or revocation in coordination with relevant commercial trade licence authorities
• Referral for criminal proceedings in cases involving money laundering, fraud, or comparable offences

For institutions deploying capital alongside a VASP, a VARA enforcement action is not an operational inconvenience. It is a material event. The regulatory standing of counterparties and investee entities is increasingly a standard due diligence item for institutional allocators. Compliance is not only a legal obligation. It is a signal of operational maturity.

The June 2025 Updates: What Changed

Threat-Led Penetration Testing Is Now Mandatory

The updated Technology and Information Rulebook formalises Threat-Led Penetration Testing (TLPT) as a regulatory requirement. This is not a conventional point-in-time vulnerability scan. TLPT is an adversarial test that simulates realistic threat actors targeting a VASP's live production environment, based on actual threat intelligence relevant to the sector and to the specific organisation. TIBER-EU and CBEST are the established reference frameworks. The test must be conducted by a qualified external provider, scoped and coordinated with threat intelligence inputs, and the resulting report must evidence realistic adversarial testing of the VASP's critical business functions in a format suitable for regulatory submission.

This requirement represents a meaningful uplift from standard penetration testing. A TLPT exercise is more complex to scope, more resource-intensive to run, and produces a qualitatively different output. VASPs that have been running annual penetration tests against a standard methodology should review whether those tests satisfy the TLPT mandate or whether a separate exercise is required.

Technology Governance and Risk Assessment Framework Formalised

The rulebook now requires a documented, board-level Technology Governance and Risk Assessment Framework (TGRAF). This is a governance structure, not a checklist. It must demonstrate accountability from board level down to operational security controls, with documented ownership, review cycles, and evidence of board sign-off. VASPs that have treated technology governance as an internal operations matter rather than a board-level responsibility will need to restructure how that governance is documented and evidenced.

AML/CFT Client Risk Assessments Every Three Months

Previously, client risk assessments under the Compliance and Risk Management Rulebook were conducted at onboarding and upon trigger events. The updated rulebook requires ongoing assessments every quarter. For VASPs with large client books, this is a significant operational change. The resources and tooling required to run quarterly assessments at scale are materially different from what most VASPs had in place under the previous regime.

FATF Travel Rule Compliance Is a Hard Requirement

The FATF Travel Rule requires VASPs to collect, verify, and transmit originator and beneficiary information for virtual asset transfers above the applicable threshold. VARA had previously referenced Travel Rule compliance as a forthcoming obligation. From June 2025, it is a hard requirement under the updated Compliance and Risk Management Rulebook. VASPs that have not yet implemented compliant Travel Rule procedures, either through a purpose-built technical solution or a compliant manual process for lower-volume operations, are now in breach.

Wind-Down Plans Are Required

VASPs must now maintain documented, operationally tested wind-down plans demonstrating that the VASP can achieve orderly cessation while protecting client assets throughout. For platforms that hold or custody client assets, this is a material planning exercise. VARA expects plans that have been reviewed and signed off at board level, not theoretical documents produced for the filing cabinet.

Qualified Investor Threshold Raised

The threshold for Professional Investor classification under VARA has been raised to AED 3.5 million net assets. VASPs offering products or services subject to Professional Investor restrictions will need to review their client classification records and update onboarding procedures accordingly.

What VARA's Technology and Information Rulebook Requires

Beyond the June 2025 updates, the Technology and Information Rulebook establishes baseline cybersecurity requirements applicable to all VASPs. These are not aspirational standards. They are licence conditions.

Independent Security Assessments

Annual independent security reviews of smart contracts and on-chain infrastructure, including prior to any new deployment. These cannot be conducted on a self-assessed basis. VARA expects external, qualified third parties to conduct and document them. The scope must cover the full on-chain footprint, not selected components.

Penetration Testing

Regular internal and external penetration testing across application and infrastructure layers. The June 2025 update adds TLPT for critical systems as a separate, higher-standard requirement. Standard penetration testing and TLPT serve different regulatory purposes and are both required.

Cryptographic Key and Wallet Management

Documented, auditable key management policies covering key generation, storage, access controls, backup procedures, and single-point-of-failure analysis. The requirement includes evidence of testing against documented procedures, not just the policies themselves. Open-source library dependencies used in key management or wallet infrastructure must also be assessed and documented.

Incident Response

Formal incident response procedures with root cause analysis requirements and documented corrective actions. Any incident affecting personal data must be reported to VARA within 24 hours of detection. This 24-hour window applies from when the VASP becomes aware of the incident, not when investigation is complete. Incident response plans that have not been tested against realistic scenarios are unlikely to satisfy VARA review.

Threat Modelling

Formal threat modelling is required before deploying any new system or material feature. This must be documented and must cover the threat actors, attack vectors, and mitigations relevant to the specific deployment, not a generic template applied across all releases.

Configuration Review

Documented configuration reviews of servers, endpoints, and network devices, with evidence of tactical hardening. Emergency access revocation procedures, network segmentation, and pre-approved emergency change procedures must all be documented and tested.

Security Awareness Training

Regular, documented security awareness training for all personnel, with evidence of completion. The training must cover threats relevant to the VASP's operations, which in practice means it must address on-chain-specific risks, not only conventional corporate IT threats.

Why Documentation Is the Specific Problem

A significant proportion of VARA licence applications and competent authority reviews stall not because the underlying security programme is inadequate, but because the evidence is not in a form the regulator can assess. VARA does not accept informal assurances. The regulatory audience requires written policies and procedures, dated evidence of testing with findings and remediation records, documented risk assessments, board-level governance sign-off, and third-party audit reports structured for regulatory review.

A security review that produces internal findings without regulatory-grade documentation is operationally useful but regulatorily insufficient. The review and the evidence trail are both required. This distinction matters most for institutions entering from traditional finance, who typically have policies and a governance culture, but frequently lack documented evidence that those policies have been tested against on-chain-specific threat models and that findings have been closed with documented remediation.

Where Blockchain-Native Projects Tend to Miss the Mark

The converse problem affects DeFi-native and blockchain-native projects scaling toward VARA compliance. They have smart contract audits. They have on-chain monitoring. What they frequently lack is the operational security layer.

VARA's Technology and Information Rulebook is not only about what the code does. It is about how the organisation manages access to that code. Who controls the admin keys. What the multisig threshold is and whether it reflects genuine separation of duties rather than a nominally decentralised structure with de facto single-person control. Whether there is a documented procedure for key rotation following a personnel departure. Whether signing workflows for material on-chain transactions have been reviewed and tested against the documented policy.

The Bybit incident in February 2025 was not a smart contract vulnerability. It was an operational security failure at the signing workflow level, exploited through social engineering. The same pattern has driven the majority of the largest losses in the sector. VARA's framework addresses this class of risk directly. Projects that approach compliance as a code audit exercise will find the operational layer requirements harder than expected.

What a VARA-Ready Security Programme Looks Like

VARA compliance is not a single audit. It is an ongoing security programme with annual, quarterly, and event-driven components. A VARA-ready programme looks like this:

• Annually: Independent smart contract and infrastructure security review; penetration testing (application and infrastructure); TLPT exercise for critical business functions; configuration review; key management audit
• Quarterly: AML/CFT client risk assessments; technology risk register review; security awareness training cycles
• Before each deployment: Threat modelling for new features or systems; independent review prior to production go-live
• Continuously: Incident response readiness; 24-hour VARA reporting capability; Travel Rule compliance on transfers; sanctions screening
• Governance cadence: Board-level TGRAF review; documented sign-off on risk appetite; wind-down plan maintenance

Each of these components must produce documentation suitable for regulatory review. A VASP that runs the programme but does not document it to the required standard is not compliant in VARA's terms.

What We Provide

Security4Web3 provides the independent security reviews, operational assessments, and regulatory-grade documentation that VARA-licensed and licence-seeking VASPs require. Our work combines institutional-grade cybersecurity disciplines with on-chain infrastructure expertise. That combination is genuinely rare in the sector. Most blockchain security providers came from crypto. Most traditional cybersecurity firms have not worked across live on-chain infrastructure at institutional scale. We came from both.

For VARA compliance specifically, we cover:

• Smart contract and on-chain infrastructure audits structured for independent regulatory review, covering the full on-chain footprint prior to deployment and annually thereafter
• Threat-led penetration testing of live production environments against threat intelligence relevant to the VASP's specific activity type and profile
• Operational security review covering key management architecture, multisig governance structures, signing workflow procedures, access control design, and wallet custody controls
• Incident response planning producing documented, tested response procedures with 24-hour VARA reporting capability built in from the outset
• Technology governance documentation supporting TGRAF build-out with evidence of testing, board-level governance records, and risk register structures
• AML/CFT security controls review confirming the technical controls that underpin your compliance and risk management programme, including transaction monitoring architecture and sanctions screening integration

Our reports are written for regulatory audiences. They are structured to satisfy competent authority review, not only internal sign-off. Where a regulator asks for evidence of a specific requirement, our report should be the document you hand them.

Getting Started

Whether you are a traditional financial institution establishing a VASP operation in Dubai or a blockchain-native project seeking VARA authorisation to scale into regulated markets, the security posture VARA requires is achievable. What it demands is genuine operational discipline, independently evidenced and maintained over time.

Most programmes stall at the gap between what a team believes about their security posture and what they can document to a regulatory standard. Closing that gap is where we work.

If you are in the pre-application phase, a readiness assessment will identify what you have, what you are missing, and what your evidence trail needs to look like. If you are already licensed and the June 2025 updates have created new obligations, we can scope the work required to get you back to full compliance.