NCA National Cryptographic Standards (NCS) Guide

The National Cryptographic Standards (NCS – 1: 2020) are the shortest route from a Saudi compliance obligation to a concrete engineering change. Where the NCA's control sets say "use cryptography", the NCS names the algorithms, the key lengths, the TLS cipher suites, the certificate lifespans and the maximum lifetime of a private key held in software.

It also rules out things most organisations are currently using. At the higher of its two strength levels, RSA is not accepted. Neither is SHA-2. Neither is a private key stored in a software cryptographic module.

What the NCS is

The NCA is mandated to draft national cryptographic policies and standards under Royal Order No. 6801 dated 31 October 2017. The NCS discharges that mandate, prescribing the minimum acceptable cryptographic requirements for civilian and commercial purposes to protect national data, systems and networks.

Its scope covers data in use, at rest and in transit, plus systems and networks, and the document is explicitly built assuming the absence of quantum computing capabilities while accounting for foreseeable advances in affordable computational power.

It covers, in order: cryptographic primitives; cryptographic schemes; commonly used protocols; Public Key Infrastructure; and Key Lifecycle Management, with appendices on Pseudo Random Number Generation, Post-Quantum Cryptography and Side-Channel Attacks.

MODERATE and ADVANCED

The NCS defines two strength levels, targeting 128-bit and 256-bit security respectively:

Each national entity chooses and implements the appropriate level itself, based on sensitivity — but that discretion is bounded: other NCA cybersecurity regulations may require a specific level. Any requirement in the document not tied to one of the two levels applies equally to both.

Accepted primitives

At ADVANCED, the NCS is an elliptic-curve-and-SHA-3 standard. RSA, Diffie-Hellman and the entire SHA-2 family fall away. For most Saudi enterprises that is not a configuration change — it is a certificate, HSM and application-compatibility programme.

The document also accepts a lightweight cryptography set for constrained systems where conventional standards are not applicable, drawn from the ISO/IEC 29192 series — PRESENT and CLEFIA block ciphers, Enocoro and Trivium stream ciphers, PHOTON, SPONGENT and Lesamnta-LW hashes, and Chaskey12 and Tsudik's keymode for MAC. That set is the one to reach for in IoT and OT deployments, alongside the Cybersecurity Guidelines for IoT.

Schemes and modes

• Block cipher modes — CTR, CBC, XTS-AES, OFB and CFB are accepted, but CBC is accepted only for MODERATE.
• MAC — CMAC and HMAC, both with a tag length of at least 96 bits and protected authentication keys. HMAC must be used with SHA-2 or SHA-3 as listed in the primitives section.
• AEAD — GCM with a nonce of at least 96 bits, a unique IV within the key change period, and short authentication tags not accepted; and CCM.
• Key wrap — KW and KWP (NIST SP 800-38F).
• KDF — HKDF (RFC 5869), IKE-v2-KDF, TLS-v1.2-KDF and X9.63-KDF, complying with NIST SP 800-56 A/B (single step), SP 800-56C (extract-then-expand) or SP 800-108.
• Signatures — ECDSA (256–384-bit for MODERATE; 512-bit or Curve448 for ADVANCED), RSA-PSS and RSA-DS2 at 3072-bit modulus for MODERATE only, and Merkle signatures using the accepted hash functions.

Protocols

Section 4 is the part that turns into tickets. Protocols not listed must follow the accepted primitives and schemes, and future versions of listed protocols are accepted provided they do the same.

Two of these are quietly disruptive. WPA3-Enterprise as the only accepted Wi-Fi version obsoletes WPA2 estates and, in many buildings, the access points themselves. And the Kerberos requirement at ADVANCED — CAMELLIA256-CTS-CMAC — is not an encryption type that mainstream directory services offer by default, which makes it a design constraint on how ADVANCED-level systems authenticate.

PKI: algorithms and certificate lifespans

Certificates, CRLs and ARLs must comply with X.509 / RFC 5280, must use SHA-2 or SHA-3 as listed in Section 2, and must match the strength of the asymmetric key algorithm to the strength of the hash algorithm.

Key Lifecycle Management

Section 6 sets maximum private key lifetimes, and this is where the hardware requirement becomes explicit:

The KLM table then sets requirements across the full lifecycle — generation (keys must not be vulnerable to prediction or bias; weak keys must not be used), registration and certification (keys associated with their owner via a certificate, issued by a trusted CA), distribution and installation (secure transport protecting confidentiality and authenticity, all copies securely installed and stored), use (protection against unauthorised use and against misuse by owners, with storage on secure hardware and/or software with authorisation checks), storage (secure backups where encryption is supported; non-repudiation keys under the sole control of the user), revocation and validation (CRL and OCSP, with validation performed against them), and archive (secured archival preserving confidentiality, expired keys archived to keep old data accessible, retention per relevant regulations).

Post-quantum, PRNG and side channels

The appendices carry the NCA's positions on Pseudo Random Number Generation, Post-Quantum Cryptography and Side-Channel Attacks. The main body is explicitly written assuming no quantum capability, so the post-quantum appendix is where forward-looking guidance sits — worth reading before committing to a long-lived Root CA, given the 20-year maximum validity the same document permits.

The side-channel appendix also explains an otherwise puzzling choice: Curve448 is accepted for ADVANCED despite operating at a 224-bit security level, because of its performance, its resistance to a wide range of side-channel attacks, and its ease of implementation. The standard is optimising for implementations that survive contact with real hardware, not just for headline key sizes.

An NCS readiness sequence

1. Assign a level to each system. MODERATE or ADVANCED, based on data sensitivity — and check whether another NCA regulation already mandates one.
2. Inventory cryptography, not just certificates. Algorithms in application code, TLS configurations, SSH versions, Wi-Fi security modes, Bluetooth profiles, Kerberos encryption types, and the modules holding private keys.
3. Flag the ADVANCED exclusions early — RSA, Diffie-Hellman, SHA-2, CBC, SOSEMANUK, software key storage. Anything ADVANCED that relies on these needs a migration plan, not a remediation ticket.
4. Fix the quick protocol wins — disable TLS downgrade, retire SSH-1, move end-user certificates onto the 5-year (or 3-year) ceiling.
5. Plan the Wi-Fi and HSM programmes separately. WPA3-Enterprise and hardware key storage carry procurement and refresh timelines the rest of the work does not.
6. Build the KLM processes as controlled procedures — generation, registration, distribution, use, storage, revocation, archive — each with an owner and evidence, since these are what an assessor tests.

How GRC Vantage supports NCS compliance

GRC Vantage's compliance module holds the NCS requirements as an assessable control set with the MODERATE and ADVANCED variants distinguished, so assigning a system its strength level produces the applicable algorithm, protocol, certificate and key-lifetime requirements rather than the full standard. Cryptographic assets — certificates, keys and the modules holding them — carry their expiry dates against the NCS ceilings, so the 20/10/5/3-year certificate limits and the 5/3/2-year key limits generate renewal tasks instead of outages.

Where a system sits at ADVANCED, the platform flags dependencies the level rules out — RSA, Diffie-Hellman, SHA-2 and software key storage — as open gaps against the ECC cryptography and key management controls the NCS underpins, with the resulting risks scored on the NFCRM matrix.

For the full family, see the NCA frameworks pillar guide. To plan an NCS migration, talk to our team.

Frequently asked questions

What are the NCA National Cryptographic Standards?

The National Cryptographic Standards (NCS – 1: 2020) prescribe the minimum acceptable cryptographic requirements for civilian and commercial purposes in Saudi Arabia, covering data in use, at rest and in transit, plus systems and networks. They define accepted primitives, schemes, protocols, PKI algorithms and key lifecycle management requirements across two strength levels.

What is the difference between MODERATE and ADVANCED?

MODERATE targets 128-bit security and ADVANCED targets 256-bit security. Each entity chooses the level based on the sensitivity of the data, systems and networks being protected, although other NCA regulations may mandate a particular level. Requirements not tied to a level apply to both.

Is RSA allowed under the NCS?

RSA is accepted at MODERATE — at least 3072 bits, with e greater than 65537 and strong primes, and 3072-bit modulus for RSA-PSS and RSA-DS2 signatures. RSA is not accepted at ADVANCED, where only elliptic-curve algorithms (NIST P-521, Curve448, BrainpoolP512r1) are permitted.

What TLS versions and cipher suites does the NCS accept?

TLS 1.2 is acceptable using the strongest primitives and schemes with a configuration that prevents downgrading; TLS 1.3 is recommended for future applications. For TLS 1.3 the accepted suite is TLS_AES_256_GCM_SHA384 at both MODERATE and ADVANCED.

How long can certificates and keys be valid?

Root CA certificates at most 20 years, intermediate/subordinate/issuing CA certificates at most 10 years, and end-user certificates at most 5 years (MODERATE) or 3 years (ADVANCED). Private keys in hardware modules may be valid at most 5 years (MODERATE) or 3 years (ADVANCED); in software modules at most 2 years for MODERATE, and software modules are not accepted at ADVANCED.