Most national security frameworks tell you to use “industry-accepted cryptography” and leave it there. Qatar’s National Information Assurance standard is more specific than that, and the way it became more specific is genuinely instructive for anyone thinking about post-quantum readiness.
The current version does something quietly sophisticated: it takes the list of approved algorithms out of the standard entirely and points at a separately versioned document instead. That is textbook cryptographic agility, designed in deliberately. It also means that if you want to know what a Qatari organisation is actually required to run, you have to follow the pointer. So let us follow it.
What NIA is, and who it binds
Qatar’s National Information Assurance Policy v2.0 was issued by the Ministry of Transport and Communications, alongside a National Information Classification Policy dated February 2014. It has since been superseded: the National Cyber Security Agency, established under Amiri Decision No. 1 of 2021, republished it in May 2023 as the National Information Assurance Standard v2.1, and that is the version certification is now assessed against.
Three features matter for what follows.
Its scope is broad, and more layered than it first appears. Where v2.0 spoke of “Agencies”, defined in a footnote as “all entities in Qatar (inclusive of Government, Semi-Government and Private entities)”, v2.1 addresses “Organizations” and leaves the question of who is actually in scope to the National Data Classification Policy. State entities are unambiguously bound: the 2021 decision establishing NCSA requires state entities to implement the policies, decisions and circulars it issues. Beyond them, obligation arrives sectorally rather than as a blanket national mandate, and the standard’s own compliance section does not name an enforcement mechanism.
The clearest example of that sectoral route is banking. Qatar Central Bank’s technology risks circular folded National Information Assurance Policy requirements directly into its own regulation, and requires that the NIA baseline controls appear in third-party service delivery agreements. Note the version lag, because it matters for everything below: that circular dates from 2018 and points at v2.0, the version whose algorithm appendix no longer exists. Anyone reconciling those obligations against the current standard is already chasing pointers between documents that move at different speeds.
It is auditable. Controls marked with an asterisk are baseline and mandatory. The v2.0 manual put it plainly: they “form auditable items, against which conformance will be sought.” Under v2.1’s Audit and Certification domain, being audited by an audit organisation designated by NCSA, at least once every year, is itself a baseline control. Certification is something an organisation applies for and NCSA may decline; the annual audit, for an in-scope organisation, is not optional.
It is classification-driven. Assets carry separate confidentiality, integrity and availability ratings. Confidentiality runs from C0 (public) up through C3 and above; integrity runs I0 to I3, where I3 means authenticity and integrity “should be provable to third party.” The cryptographic controls attach directly to those labels, which turns out to be useful.
The standard organises its baseline controls into 26 security domains, from Governance Structure and Risk Management through to Virtualization. One of them is Cryptographic Security.
Cryptographic Security [CY]
Cryptography gets its own domain, and the rest of the standard defers to it rather than restating requirements. Network Security sends DNS origin authentication and mail server TLS to it. Information Exchange sends secure messaging to it. Access Control sends remote access encryption to it. It is the single place the standard defines what “encrypted” is permitted to mean.
The controls are sensible and familiar:
- CY 3 (baseline) requires C3 assets to be encrypted and protected against unauthorised disclosure “when stored and/or in transit regardless of the storing format or media.”
- CY 4 requires I3 assets to have integrity assured using cryptographic hashing.
- CY 5 (baseline) fixes the protocols permitted for C3 data in transit: TLS for web traffic, SFTP for file transfer, SSH v2 or IPsec for remote access, S/MIME v3 or better for email.
- CY 7 (baseline) requires HSMs certified to at least FIPS 140-2 Level 2 or Common Criteria EAL4.
- CY 9 requires a defined key management lifecycle: custodian roles, generation, dual control and split knowledge, storage, distribution, backup and recovery, periodic status checking, compromise handling, revocation and destruction, with audit trails throughout.
- CY 12 (baseline) requires any digital certificate in a production system to be issued by a certification service provider licensed in Qatar.
And then there is CY 1, the control that decides which algorithms are acceptable. This is where the two versions diverge, and the difference is the interesting part.
The change almost nobody noticed
In v2.0, CY 1 required that algorithms, encryption hardware and software, key management systems and digital signatures “meet the requirements specified in Appendix B of this manual for Approved Encryption/Cryptographic Algorithms and Systems.”
Appendix B was a normative table embedded in the standard itself. It approved AES-256 and 3DES for symmetric encryption; SHA-n at 256 bits or above, and MD5, for hashing; and for asymmetric cryptography exactly two entries, RSA and DSA, both listed at 1024-bit keys with a footnote instructing a move to 2048-bit RSA “by 2013”.
The drafters knew this would age. The appendix opened by declaring its own shelf life:
“All Cryptographic algorithms recommended in this Appendix B are valid for one year after the date of issue of this manual.”
An algorithm list with a one-year expiry, embedded in a document that then went nine years between revisions, is a structural problem. And v2.1 fixed it properly. The appendix is gone. Where v2.0 had four appendices, including normative ones for algorithms and incident classification, v2.1 has three, and Appendix B is now a sample non-disclosure agreement. The algorithm table has been removed from the standard altogether.
In its place, CY 1 now requires that cryptographic systems “demonstrate compliance with the Approved Encryption/Cryptographic Algorithms and Systems as specified by the competent authority within the Law No. (16) of 2010 on the Promulgation of the Electronic Commerce and Transactions Law.” CY 5 is more explicit still, requiring approved algorithms as “outlined in Qatar National Cryptographic Standard – English v1.0 (or higher).”
That is the right architecture. The algorithm list is now a separate, independently versioned document that can be revised without reopening the entire assurance standard, and the phrase “or higher” means any future revision becomes binding automatically. This is exactly what cryptographic agility looks like at the regulatory layer, and Qatar built it in 2023, before most jurisdictions had thought about it.
So the obvious question is what the pointer currently points at.
Following the pointer
The Qatar National Cryptographic Standard is a 19-page document, version 1.0, published in October 2019 by the Public Key Management and Digital Identity Section. Its own framing is unusually thoughtful. It says it “proposes algorithms and parameters suitable for defined periods”, and that it applies “in a mandatory manner, by both the private and public sectors.”
It even explains its selection philosophy in terms that should sound familiar to anyone working on post-quantum migration:
“this document deliberately dispenses with the specification of current cryptographic mechanisms, which are still considered to be secure at the time of the publication of this document, but can not be recommended in the future, as they have theoretical vulnerabilities that can be exploited in the long term.”
That is precisely the reasoning behind post-quantum migration: exclude what is fine today but has a known long-term break. Applied consistently, it is an argument for moving off RSA and elliptic curve cryptography.
It was written in 2019, though, and it does not reach that conclusion. The document contains no mention of quantum computing, post-quantum cryptography, or any quantum-resistant algorithm. Its recommended asymmetric encryption schemes are ECIES, DLIES and RSA. Its recommended signature algorithms are RSA-PKCS#1 v1.5, RSA-PSS, DSA, EC-DSA and EC-SDSA. Every one of those rests on integer factorisation or discrete logarithms, which is to say every one of them is broken by Shor’s algorithm on a sufficiently large quantum computer.
The parameter guidance has also simply run out. The standard’s tables give recommended key lengths against horizons labelled one year (2018), three years (2020) and six years (2023). Its note on asymmetric encryption says 2048-bit keys were “expected to remain in conformance with the present document until 2022”, and that beyond 2022, 3000-bit keys are recommended. The furthest year the document names anywhere is 2023, and it has passed. Nothing in it speaks to 2026, let alone to the decade in which a cryptographically relevant quantum computer might appear.
None of this is a failure of drafting. It is a 2019 document doing 2019’s job well. NIST’s post-quantum standards did not exist yet: FIPS 203 and FIPS 204, which standardised ML-KEM and ML-DSA, were only published on 13 August 2024, five years later.
But it does mean the honest description of the position today is this: Qatar’s assurance standard has a well-designed, agile pointer to an algorithm list, and that list is entirely classical, has no quantum-resistant options in it, and has passed its own stated horizons.
Two more places the references have aged
Two details in the current v2.1 text are worth checking against your own environment, because both are still live requirements.
CY 5 cites RFC 4346 for web traffic. RFC 4346 is TLS 1.1. RFC 8996 moved TLS 1.0 and 1.1 to Historic status in March 2021. The control says “the following protocols or better“, so a modern TLS deployment complies comfortably, but the citation is not a useful floor any more and should not be read as one.
CY 7 requires HSMs validated to FIPS 140-2 Level 2. NIST’s Cryptographic Module Validation Program stopped accepting new FIPS 140-2 submissions in September 2021, and all remaining FIPS 140-2 certificates move to the historical list on 21 September 2026. If your HSM estate was procured against that baseline, its validations are about to become historical, which makes this a natural moment to ask what those modules will support when the algorithm list does change.
What “or higher” actually costs you
Here is the part that deserves attention from anyone responsible for NIA conformance.
By externalising the algorithm list and binding to “v1.0 or higher“, NIA v2.1 has made your cryptographic compliance obligation mutable without notice to you. When the Qatar National Cryptographic Standard is revised to add quantum-resistant algorithms and to sunset RSA and elliptic curve, that revision becomes binding through CY 1 and CY 5 without the assurance standard being reissued, without a new NIA version number, and without anything in your existing certification documentation changing.
That is the correct design. It is also a transfer of burden. Under v2.0, you could read Appendix B and know where you stood. Under v2.1, staying compliant means continuously reconciling a live, external, independently versioned algorithm list against what your estate is actually running.
Which requires knowing what your estate is actually running. Not what the architecture documents say. What is negotiated in practice: in TLS terminations and load balancers, service-to-service authentication, code signing pipelines, VPN concentrators, database and backup encryption, every certificate issued under CY 12, every key held under CY 7 and CY 9, and the embedded and operational technology nobody has logged into in years.
Most organisations cannot produce that view on demand, in Qatar or anywhere else. CY 1 has always quietly assumed a discovery capability. Externalising the list makes that assumption load-bearing.
CY 3 and the data already exposed
There is a second reason not to wait for the list to be revised.
CY 3 requires C3 assets to be encrypted in transit and at rest. C3 means disclosure would cause severe damage. If that traffic is protected by a key exchange resting on RSA or elliptic curve Diffie-Hellman, an adversary who records the ciphertext today can decrypt it once a sufficiently capable quantum computer exists. The encryption satisfies CY 3 exactly as written. It does not protect the data across its real confidentiality lifetime.
This is the harvest now, decrypt later problem, and NIA’s classification scheme is unusually well suited to reasoning about it. Most organisations struggle to prioritise post-quantum work because they cannot say which data still matters in ten or fifteen years. A NIA-conformant organisation has already done that labelling. C3 and I3 assets are, by definition, the ones where disclosure causes severe damage or authenticity must be provable to a third party. That is a ready-made prioritisation input most enterprises have to build from nothing.
The two risks also run on different clocks, and CY 3 and CY 4 separate them neatly. Confidentiality failures are retroactive: recorded now, broken later. Signature failures are prospective: once RSA or ECDSA signatures can be forged, an I3 asset whose authenticity must be provable to a third party loses that property going forward. Different clocks, different remediation order.
Where ECEM fits
Enterprise Cryptographic Exposure Management exists to answer the question CY 1 assumes you can already answer. Mapped onto NIA’s own obligations, the six-stage ECEM lifecycle lines up closely:
- Discover – find the cryptography actually in use across endpoints, servers, applications, databases, PKI, HSMs, cloud environments and source code. This is the evidence base CY 1 conformance rests on, and what every cross-reference to the Cryptographic Security domain quietly depends on.
- Inventory – consolidate it into a living Enterprise CBOM. NIA already requires key lifecycle records under CY 9 and a governed certificate estate under CY 10 and CY 12; a CBOM is the structure that holds those alongside everything else.
- Assess – identify which systems depend on the classical asymmetric algorithms the national cryptographic standard currently recommends, and which conformance claims therefore expire when that document is revised.
- Prioritise – rank by exposure using the C and I ratings NIA already required you to assign. CY 3 and CY 4 tell you where to look first.
- Transition – re-point systems at quantum-resistant algorithms, working through the CY 5 protocol list, the CY 7 HSM estate and the licensed-CSP certificate chain under CY 12. Hardware and certificate dependencies have the longest lead times and should start earliest.
- Monitor – keep the picture current, because the binding algorithm list now lives outside the standard and can change independently of it.
It is also worth knowing what horizon the rest of the world is working to, because multinational organisations operating in Qatar will meet these dates regardless of when Qatar’s own list moves. NIST’s draft IR 8547 proposes that RSA, ECDSA and Diffie-Hellman at the 112-bit security level be deprecated after 2030 and disallowed after 2035, with stronger parameter sets also disallowed after 2035. The UK’s NCSC has published a 2028, 2031 and 2035 migration timeline. Those dates are not binding in Qatar, but vendors, certificate authorities and hardware suppliers are moving to them, which shapes what a Qatari organisation can actually procure and when.
What to do before the list moves
Inventory the asymmetric dependencies first. AES-256 and the longer SHA-2 outputs are in good shape; Grover’s algorithm offers only a quadratic speed-up, and NIST’s position is that doubling key size preserves security. The damage is concentrated in key exchange, digital signatures and certificate issuance. Narrowing initial discovery to those three gets to the material exposure fastest.
Treat certificates and HSMs as long-lead items. CY 12 ties production certificates to a CSP licensed in Qatar, so part of your transition depends on provider readiness rather than internal change. CY 7’s hardware baseline is a procurement cycle measured in years, and its FIPS 140-2 validations go historical in September 2026. Neither can be compressed once a deadline exists.
Build the inventory as a standing capability, not a project. This is the direct consequence of the “or higher” clause. An estate that can only be surveyed through a one-off manual exercise will fall out of conformance the moment the external list is revised, and will not know it until an audit says so.
Qatar got the architecture right. It separated the slow-moving assurance standard from the fast-moving algorithm list, and wrote in a forward reference so updates bind automatically. The remaining work is on the other side of that pointer, and on the organisations that have to satisfy it. When the Qatar National Cryptographic Standard gains its post-quantum revision, the entities that can act on it will be the ones that already know what they are running.
Further reading: what Enterprise Cryptographic Exposure Management is, crypto-agility maturity models compared, and our quantum readiness checklist for financial services.