The UAE has no single cryptography law either, but a more prescriptive, sector-specific landscape than the EU or UK: NESA's IAS, DESC's ISR v2, CBUAE's brand-new Regulation C 1/2026, the PDPL, and a real national post-quantum migration program launched in 2026.
The UAE does not have a single cryptography law either, but where the UK assembles its obligation from one national assessment framework applied broadly, the UAE splits by sector into several regimes, each more prescriptive than the UK's principle-based approach once you are actually inside its scope. Which one binds you depends on what kind of organisation you are, and several regimes can apply to the same organisation at once. Layered on top of all of them, since May 2026, is a coordinated national post-quantum migration program that predates most other countries' equivalent efforts.
This guide maps the landscape: who NESA's Information Assurance Standards actually bind, what Dubai's DESC ISR v2 adds on top for government entities, what the Central Bank's brand-new Regulation C 1/2026 requires of financial institutions, how the PDPL's Article 20 functions as the catch-all, and what the National Post-Quantum Migration Program means in practice regardless of which of the above applies to you.
| Regime | Who it binds | Crypto specificity | Governing body |
|---|---|---|---|
| NESA / UAE IAS | Federal government entities; de facto standard for critical infrastructure | High: named algorithms and minimum key strengths | Originally NESA, now under the Cybersecurity Council / Signals Intelligence Agency |
| DESC ISR v2 | Dubai Government Entities and their contractors | Medium: dedicated cryptography domain, risk-proportionate | Dubai Electronic Security Center |
| CBUAE Regulation C 1/2026 | All licensed financial institutions | Medium: ICT/cybersecurity risk framework, no named algorithms published | Central Bank of the UAE |
| PDPL Article 20 | Any controller or processor of personal data | Low: "appropriate" measures, encryption named as an example | UAE Data Office |
Most organisations sit in more than one row. A bank in Dubai handling customer personal data is, at minimum, under CBUAE's regulation and the PDPL simultaneously, and depending on which systems it runs, potentially NESA's IAS as a de facto critical-infrastructure baseline too.
The National Electronic Security Authority (NESA) issued the UAE Information Assurance Standards (IAS), organised across 14 control domains covering asset management, access control, cryptography, physical security, network security, systems development, incident management, business continuity, compliance and audit, totalling roughly 188 individual controls. Governance has since moved: NESA's functions now sit with the Cybersecurity Council and the Signals Intelligence Agency (SIA), though the standards are still commonly referred to by the NESA name across UAE compliance practice, and public reporting on the exact current org chart is not fully consistent, which is itself worth confirming directly with your sector regulator rather than assuming.
Unlike the UK's CAF, which sets a principle ("data in transit is protected") and leaves the technical detail to be assessed against evolving best practice, the IAS's cryptography domain is understood to name concrete minimums: AES-256 for data at rest and TLS 1.2 as a floor for data in transit, alongside required key management procedures, approved-algorithm policy, and certificate management. Compliance is mandatory for federal government entities and has become the de facto expected baseline for private-sector critical infrastructure operators, even where it is not directly imposed on them by statute.
If your organisation is a federal government entity or a critical infrastructure operator (energy, water, telecom, aviation, banking-adjacent infrastructure), treat the IAS cryptography domain as your binding technical floor, not just a best-practice reference.
On 11 May 2026, the UAE Cyber Security Council signed a partnership with the Advanced Technology Research Council (ATRC), through its commercial arm VentureOne, alongside the Technology Innovation Institute (TII), UAE-based QuantumGate, and the UAE National Cryptography Center, to advance what is described as "one of the world's first coordinated national post-quantum migration plans." The program combines cryptographic inventory assessment, technology deployment, workforce training and regulatory compliance validation across UAE government and enterprise systems.
The technical components are specific and unusual for a national-level program:
Unlike the NCSC's explicit 2028/2031/2035 milestone dates, no fixed national completion deadline has been published for the UAE program as of this writing. The messaging from program leadership is urgency without a hard date: "the transition to quantum-safe security cannot wait until quantum threats arrive." For a critical-infrastructure operator or federal entity already bound by NESA's IAS, the practical read is that a cryptographic inventory (what the CDT is built to produce) is about to become an expected artefact whether or not a specific compliance deadline is ever formally published, in the same way the NCSC timeline functions as a de facto UK deadline without technically being law.
The Dubai Electronic Security Center (DESC) issued the Information Security Regulation (ISR) v2.0, applying to all Dubai Government Entities, their employees, consultants, contractors and visitors handling government information in any form, spanning 13 domains. Domain 11, Cryptography, requires an encryption policy, key management procedures, approved-algorithm governance, certificate management, and controls to keep cryptographic implementations effective as algorithms evolve, covering data both at rest and in transit.
The ISR's implementation is explicitly risk-proportionate: an entity handling top-secret or highly sensitive government data is expected to implement Domain 11 with materially more rigour than one managing publicly available administrative records. This is closer in spirit to NIS2's data-classification-driven approach than to NESA's more uniformly stated minimums, which matters if you operate in both federal and Dubai-government contexts and need to reconcile two different cryptography domains against the same infrastructure.
If you are a private-sector contractor or technology provider to a Dubai Government Entity, ISR v2 compliance is typically a contractual requirement flowed down from your government counterparty, not a direct statutory obligation on your organisation, which is a meaningfully different enforcement mechanism from NESA's or CBUAE's direct regulatory reach.
The Central Bank of the UAE's Operational Risk Management Regulation, Regulation No. C 1/2026, took effect on 14 September 2026, repealing and replacing the previous Circular No. 163/2018. It applies to all licensed financial institutions with legal personality, not just banks, and places information and communications technology (ICT) risk management and cybersecurity at the core of the operational risk framework rather than as a bolted-on annex.
Financial institutions are required to implement an ICT and cybersecurity risk framework covering risk identification and assessment, mitigation measures, incident response and recovery, change management, data and technology services, patch management, and business continuity and disaster recovery, reviewed regularly to stay aligned with "industry standards, best practices, and new and emerging threats." Incident reporting is tiered and fast: institutions must notify the Central Bank within four hours for events significantly impacting critical operations, with 24-hour brief reports and 72-hour detailed reports for high-severity incidents. Outsourcing to a technology, cloud or payment-processing provider does not relieve an institution of responsibility to the regulator, and critical functions require independent, board-reported penetration testing.
What the publicly reported detail does not include is algorithm-level or key-lifecycle cryptographic specificity comparable to DORA's Commission Delegated Regulation 2024/1774, Articles 6 and 7 (see our DORA checklist) or NESA's named AES-256/TLS 1.2 minimums. The Central Bank retains explicit authority to issue further standards and detailed guidelines, so this may change; until it does, financial institutions should treat NESA's IAS cryptography domain (as the closest UAE analogue with named technical minimums) as the substantive standard to design against, while tracking C 1/2026's incident-reporting and third-party-accountability obligations as the process layer around it.
Federal Decree-Law No. 45 of 2021 on the Protection of Personal Data, in force since 2 January 2022, requires controllers and processors under Article 20 to take "appropriate technical and organisational measures and procedures to ensure achievement of the information security level commensurate with the risks associated with Processing, in accordance with best international standards and practices, which may include encryption of Personal Data and application of Pseudonymization." The article also requires measures ensuring confidentiality and integrity of processing systems, timely data recovery after a technical failure, and regular testing of the effectiveness of those measures.
This runs on the same structural logic as UK GDPR's Article 32 and NIS2's Section 9: encryption is named as an example measure, not mandated unconditionally, with the actual bar set by "appropriate to risk," tested against "best international standards and practices." That phrase is doing real work: it is an explicit invitation to point to whichever named external standard (NIST, ISO 27001, or the UAE's own IAS) is relevant to your sector when a regulator or auditor asks what "appropriate" meant in practice. An organisation with no other applicable regime (not NESA-bound, not a Dubai Government Entity, not CBUAE-regulated) still needs an answer to that question the moment it processes personal data with any meaningful confidentiality requirement.
Across all four regimes, three things keep recurring, which means building them once, rather than per-regulator, is the efficient path:
The cryptographic inventory that NESA's IAS, DESC's ISR v2 and the National PQC Program's own Crypto Discovery Tool all assume is exactly what a CBOM (Cryptography Bill of Materials) is built to produce: a CycloneDX-standardised, machine-readable record of every algorithm, certificate and key in scope. Our CBOM guide covers generating one via filesystem, source-code and domain scans, with the get_qrs_score and get_vulnerable_assets MCP tools tracking readiness continuously rather than producing a one-time snapshot for an audit cycle.
For the "migration path that survives the next question" half of the checklist, our F5 BIG-IP and FortiGate guides cover deploying NIST-standardised hybrid key exchange (ML-KEM) on common edge infrastructure, the same algorithm family TII's national cryptographic libraries are aligned to, using the agentic MCP tools (ensure_f5_mlkem_profile, ensure_fortinet_mlkem_ipsec) to turn a prioritised list into deployed configuration.
Q: Is NESA still the right name to use, or has it been fully replaced?
Governance of the UAE Information Assurance Standards has moved to the Cybersecurity Council and the Signals Intelligence Agency, but "NESA" and "NESA compliance" remain the names in common use across UAE compliance practice, including by regulators referencing the same standards. Confirm current attribution with your sector regulator if precision matters for a specific filing or audit.
Q: Does the National PQC Migration Program have a compliance deadline like the UK's NCSC timeline?
Not published as of this writing. The program emphasises urgency rather than a fixed date. Treat it as a strong signal that a cryptographic inventory will become an expected artefact, particularly for federal and critical-infrastructure entities already bound by NESA's IAS, rather than waiting for a formal deadline before starting discovery.
Q: We're a fintech regulated by CBUAE but not directly by NESA. Do the AES-256/TLS 1.2 minimums still apply to us?
Not as a direct statutory requirement under C 1/2026's published detail, which does not currently name specific algorithms. In practice, NESA's IAS cryptography domain is the closest UAE-published technical minimum, and CBUAE retains authority to issue further, more specific standards, so building to the IAS minimums now is a reasonable hedge against a more prescriptive CBUAE standard arriving later.
Q: How does PDPL Article 20 compare to GDPR's Article 32?
Structurally very similar: both require security measures "appropriate" to risk, both name encryption as an example rather than a mandate, and both leave the specific technical bar to be interpreted against external best-practice standards at the time. The PDPL's added specificity is the explicit reference to "best international standards and practices," which functions as an invitation to point to a named framework like NESA's IAS or ISO 27001 when justifying what "appropriate" meant for your organisation.
Q: If I operate in both Dubai and at the federal level, do I need to satisfy NESA and DESC ISR v2 separately?
Potentially yes, since they are governed by different bodies with different scopes (federal versus Dubai Government Entities specifically) and DESC's ISR v2 applies its cryptography domain in a risk-proportionate way that can differ in practice from NESA's more uniform minimums. A single, well-documented cryptographic inventory and key management programme built to the stricter of the two requirements in each area is more efficient than maintaining two separate compliance postures.
The UAE's cryptography obligation is more fragmented than the UK's but, once you have identified which of NESA, DESC ISR v2, CBUAE's Regulation C 1/2026 and the PDPL actually bind you, individually more prescriptive: NESA names AES-256 and TLS 1.2 directly, where the UK's CAF only requires you to demonstrate "appropriate" practice against evolving guidance. Layered on top, the National Post-Quantum Migration Program launched in May 2026 is a genuinely early, coordinated national effort, without a published deadline yet, that is worth building toward now rather than waiting for one to be set. Identify which rows of the landscape above apply to your organisation, and build the cryptographic inventory and key management programme that satisfies the strictest of them.
A note on sourcing: the National PQC Migration Program details (ATRC reference) and the CBUAE Regulation C 1/2026 details (Gulf News references) come from primary or first-party institutional and major-outlet reporting, individually verified. NESA/IAS's specific AES-256/TLS 1.2 minimums and DESC ISR v2's Domain 11 detail are corroborated across multiple independent secondary compliance sources rather than a directly fetchable primary regulatory PDF (both the CBUAE Rulebook and DESC's standards portal returned access-blocked responses during research). Reviewers with direct access to the CBUAE Rulebook, the UAE IAS text or the DESC ISR v2 document are encouraged to verify the specific control language before this article is used in a compliance-sensitive context.
Written by
Nagib Aouini
Related Resources
Tell us where control is difficult today. We will help you identify a practical next step.
