Unlike the UK's guidance-led approach or the UAE's four-way sector split, Saudi Arabia's cryptography obligation converges on one authority, the NCA, and one technical document already naming algorithms and key lengths, with a post-quantum update in draft.
Saudi Arabia's cryptography regulation is the most centralised of the three we have covered in this series. The UK assembles its obligation from a guidance timeline plus a broadly applied assessment framework; the UAE splits into four separate sector regimes. Saudi Arabia runs almost everything through a single authority, the National Cybersecurity Authority (NCA), and a single technical document that already names algorithms and minimum key lengths in binding text, something neither the UK's CAF nor most of the UAE's regimes do directly. The gap it has not closed yet is post-quantum specificity, and that gap is already visibly closing: a draft update adding post-quantum algorithms finished public consultation in December 2025.
This guide covers what the NCA's Essential Cybersecurity Controls and National Cryptographic Standards actually require, how the Personal Data Protection Law and SAMA's financial-sector framework relate to them, and what the pending NCS-2:2025 update signals about where the binding algorithm minimums are headed.
Where the UK's obligation is a chain (guidance flows into a statutory "appropriate" test, tested against an assessment framework) and the UAE's is a set of parallel, sector-specific regimes, Saudi Arabia's structure is closer to a hub. The NCA's own mandate is itself centralised: Royal Order number 6801, dated 31 October 2017, tasks the NCA with drafting national cryptographic policies and standards, ensuring compliance with them, and reviewing and updating them periodically. From that single mandate, the NCA issues both the Essential Cybersecurity Controls (the governance-level framework) and the National Cryptographic Standards (the technical algorithm-and-key-length document) directly. The Personal Data Protection Law's implementing regulation explicitly instructs controllers to follow NCA-issued security standards rather than setting its own separate bar. SAMA's Cyber Security Framework, predating the NCA's own standards and covering financial institutions specifically, sits alongside this structure as a coordinating sector layer rather than a strictly subordinate one.
The practical consequence: fewer separate regimes to reconcile than in the UAE, but each one, once it applies to you, tends to be more textually specific about what "compliant cryptography" actually means, because the NCA's National Cryptographic Standards names algorithms and minimum key lengths directly in binding text.
The NCA's Essential Cybersecurity Controls set the minimum cybersecurity baseline for organisations in the Kingdom. The current version, ECC-2:2024, restructured the framework into 4 main domains, 28 subdomains, and 108 main controls, with 92 subcontrols beneath them. Cryptography sits inside the framework's defence-oriented domain, alongside identity and access management and data protection, but the ECC itself does not spell out algorithm-level detail. Instead, its cryptography control points outward to the NCA's separate National Cryptographic Standards document for the actual technical requirements, the same "governance framework references a dedicated technical standard" pattern NIS2's Implementing Regulation uses for its Section 9, just issued by one authority instead of split across a directive and a regulation.
The National Cryptographic Standards, NCS-1:2020, is the document doing the actual technical work. Published by the NCA in July 2020, it sets minimum acceptable cryptographic requirements for civilian and commercial purposes, protecting national data (in use, at rest and in transit), systems and networks, built on two classification tiers, MODERATE and ADVANCED, targeting 128-bit and 256-bit security levels respectively. Each national entity chooses the appropriate tier based on the sensitivity of what it is protecting, though other NCA-issued regulations may mandate a specific tier for specific data or systems:
| Algorithm family | MODERATE (128-bit security) | ADVANCED (256-bit security) |
|---|---|---|
| AES (FIPS-197) | 128-bit or 192-bit keys | 256-bit keys |
| Camellia / Serpent | 128-bit or 192-bit keys | 256-bit keys |
| RSA | 3072-bit minimum, e > 65537, strong primes | Not accepted |
| Diffie-Hellman / Finite Field | 3072-bit minimum | Not accepted |
| Elliptic curve (ECDLP) | NIST P-256, P-384, Curve25519, BrainpoolP256r1, BrainpoolP384r1 | NIST P-521, Curve448, BrainpoolP512r1 |
| Hash functions | SHA2-384, SHA2-512/256, SHA3-256, SHA3-384, SHAKE128/256 | SHA3-512 |
Two details are easy to miss and matter in practice: RSA, Diffie-Hellman and finite-field schemes are excluded entirely from the ADVANCED tier, elliptic curve algorithms are the only asymmetric option once you are targeting 256-bit security, and MODERATE explicitly accepts 192-bit AES keys as well as 128-bit, a middle option the ADVANCED/MODERATE binary elsewhere obscures.
Beyond the algorithm table, NCS-1:2020 sets protocol-specific requirements across DNSSEC, IPsec, SSH, TLS, Bluetooth, Kerberos, WPA and cellular standards (UMTS, LTE and 5G, where 128-NEA2/128-NIA2 are the mandated 5G algorithms), which matters directly if your infrastructure includes telecom-facing systems: a 5G network slice or an IPsec gateway terminating in Saudi Arabia is expected to meet the protocol-specific profile NCS-1:2020 sets for that protocol, not just a generic "strong encryption" standard. Section 6, Key Lifecycle Management, is equally specific: private keys in hardware modules are capped at 5 years' validity for MODERATE and 3 years for ADVANCED, private keys in software modules are capped at 2 years and not accepted at all for ADVANCED, and eight distinct KLM processes (generation, registration/certification, distribution/installation, use, storage, revocation/validation, archive, destruction) each carry their own documented requirements.
This is meaningfully more prescriptive, in binding text, than the UK's CAF (which names no specific algorithm) and most of the UAE's regimes other than NESA's IAS. If you operate infrastructure in the Kingdom, NCS-1:2020's tables are the actual technical bar, not a best-practice reference to interpret.
NCS-1:2020 already flagged this gap in its own text. Its appendix on Post-Quantum Cryptography states plainly: "no international standards for Post-Quantum Cryptography are available yet, and it is expected that they will be issued by international standardization bodies over the next three years. Post-Quantum Cryptography will be considered in the upcoming versions of the NCS." That was written in 2020, before NIST finalised ML-KEM and ML-DSA in 2024, and the NCA is now following through on it: the NCA ran a public consultation on an updated standard, NCS-2:2025, from 10 to 25 December 2025. Based on the consultation record and the published draft, the update's main additions are new appendices covering post-quantum cryptographic algorithms, pseudo-random number generation (PRNG), quantum key distribution (QKD), and side-channel attack considerations, alongside the existing algorithm-and-protocol tables NCS-1:2020 already sets.
As of this writing, public reporting confirms the consultation closed and the draft moved into a "processing consultation" phase, but does not confirm the standard has been finalised and published as binding. Treat NCS-2:2025 as a strong signal of direction, not yet an enforceable deadline: the NCA has already drafted the specific technical content (which post-quantum algorithms, what PRNG requirements, how QKD is treated) that will eventually become binding, which is considerably more concrete, this early, than most countries' PQC posture. Organisations building infrastructure in the Kingdom now have an unusually clear preview of what the next binding cryptographic standard will contain, even before its effective date is confirmed.
For infrastructure decisions today, this argues for deploying the same NIST-standardised hybrid PQC (ML-KEM alongside a classical algorithm) that UK and EU guidance already recommend, both because it satisfies NCS-1:2020's current requirements through the classical half and positions you ahead of NCS-2:2025 once it is finalised, rather than waiting for the Kingdom's own finalisation before starting.
The Saudi Central Bank (SAMA, the name it is still commonly known by) issued its Cyber Security Framework on 24 May 2017 (28/8/1438H), under Circular No. 381000091275, applying to all banks, insurance and reinsurance companies, financing companies, credit bureaus, and financial market infrastructure operating in Saudi Arabia. Section 3.3.9, Cryptography, requires that "the use of cryptographic solutions within the Member Organizations should be defined, approved and implemented," with a cryptographic security standard covering "an overview of the approved cryptographic solutions and relevant restrictions," the circumstances requiring cryptography, and explicitly, "the management of encryption keys, including lifecycle management, archiving and recovery."
Notably, the SAMA framework does not itself prescribe specific algorithms or key lengths in this section, it mandates that your organisation define and document its own cryptographic standard, covering key lifecycle management as a distinct requirement from algorithm choice. For a Saudi-regulated financial institution, the practical reading is: SAMA requires you to have a documented cryptography and key-management policy; the NCA's NCS-1:2020 is the most natural, authoritative technical content to base that policy's algorithm choices on, even though SAMA's framework does not explicitly cross-reference it the way the PDPL does.
Saudi Arabia's Personal Data Protection Law, enforced by the Saudi Data and Artificial Intelligence Authority (SDAIA) and in full effect since 14 September 2024 after a one-year grace period, takes a structurally different approach from the UK's and UAE's data protection laws at this specific point. Article 19 requires controllers to take the necessary organisational, administrative and technical measures to protect personal data, including in storage, in use and in transit. Its Implementing Regulation, Article 23, goes further than UK GDPR's Article 32 or PDPL (UAE)'s Article 20 by naming the standard explicitly: controllers are required to follow security standards issued by the NCA, or recognised cybersecurity best practices, rather than an open-ended "appropriate to risk" test alone.
This closes a gap the UK and UAE data protection laws leave open. Under UK GDPR or the UAE's PDPL, "appropriate" is interpreted against best practice at the time, with no single named authority. Under the Saudi PDPL, the Implementing Regulation points directly back at the NCA's own standards, meaning the algorithm minimums in NCS-1:2020 (and, eventually, NCS-2:2025) are not just a reasonable reference for justifying "appropriate" security, they are close to the literal statutory answer to what appropriate means for personal data protection.
Given how much of the Saudi landscape routes through one authority, a working programme looks more like "implement one standard well" than "reconcile several regimes," with three specific priorities:
NCS-1:2020's algorithm tables and protocol-specific profiles are exactly the kind of structured requirement a CBOM (Cryptography Bill of Materials) is built to check an estate against: a CycloneDX-standardised, machine-readable inventory of every algorithm, certificate and key in scope. Our CBOM guide covers generating one via filesystem, source-code and domain scans, with the get_vulnerable_assets MCP tool flagging anything below NCS-1:2020's minimums, such as an RSA-2048 certificate where 3072-bit is the floor.
For deploying ahead of NCS-2:2025's post-quantum requirements, our F5 BIG-IP and FortiGate guides cover NIST-standardised hybrid key exchange (ML-KEM alongside a classical algorithm) on common edge and IPsec infrastructure, directly relevant given NCS-1:2020's own dedicated IPsec and TLS protocol profiles, using the agentic MCP tools (ensure_f5_mlkem_profile, ensure_fortinet_mlkem_ipsec) to deploy consistently across a multi-site estate.
Q: Is NCS-1:2020 still the binding standard, or has NCS-2:2025 already taken effect?
NCS-1:2020 remains the current binding standard as of this writing. NCS-2:2025 completed public consultation in December 2025 and is understood to be in a post-consultation processing phase, but its finalisation and binding effective date have not been publicly confirmed. Build to NCS-1:2020 today while tracking the NCA's channels for NCS-2:2025's finalisation.
Q: Does the ECC itself set algorithm requirements?
No. The Essential Cybersecurity Controls set the governance-level requirement that cryptography be defined, approved and implemented, and point to the separate National Cryptographic Standards document for the actual algorithm and key-length detail.
Q: We're a Saudi fintech regulated by SAMA. Do we also need to follow the NCA's NCS directly?
SAMA's Cyber Security Framework requires you to define and document your own cryptographic standard, including key lifecycle management, but does not explicitly mandate NCS-1:2020 by name in the publicly available control text. In practice, using NCS-1:2020 as the technical basis for that internal standard is the most defensible choice, since it is the Kingdom's own authoritative, NCA-issued reference, and if you also process personal data, PDPL Article 19's Implementing Regulation makes following NCA standards a more direct requirement on that side of your operations.
Q: How does Saudi PDPL's security requirement compare to the UK's and UAE's?
It is more specific. UK GDPR's Article 32 and the UAE PDPL's Article 20 both set an open-ended "appropriate to risk" test, interpreted against best practice generally. The Saudi PDPL's Implementing Regulation Article 23 names the reference point directly: controllers must follow NCA-issued security standards or recognised best practices, which ties personal-data security requirements back to NCS-1:2020's specific algorithm minimums more directly than either of the other two frameworks.
Q: Does NCS-1:2020 cover 5G and telecom infrastructure specifically?
Yes. It includes protocol-specific requirements for UMTS, LTE and 5G alongside DNSSEC, IPsec, SSH, TLS, Kerberos, WPA and Bluetooth, which matters directly for telecom operators and any organisation running 5G network infrastructure in the Kingdom.
Saudi Arabia's cryptography obligation is the most concentrated of the three covered in this series: one authority, the NCA, issuing both the governance framework (ECC-2:2024) and the technical standard (NCS-1:2020) that actually names algorithms and key lengths, with the Personal Data Protection Law's Implementing Regulation explicitly deferring to that same authority rather than setting an independent bar. SAMA's financial-sector framework layers on top for regulated institutions, requiring a documented cryptography and key-management policy without itself naming algorithms. The open question is post-quantum specificity, and it is closing faster than in most countries covered so far: NCS-2:2025's draft already names its post-quantum, PRNG and QKD content, ahead of a confirmed binding date. Build to NCS-1:2020 today, with a cryptographic inventory and hybrid-PQC deployment path ready before NCS-2:2025 needs one.
Written by
Nagib Aouini
Related Resources
Tell us where control is difficult today. We will help you identify a practical next step.
