Post-Quantum Survival: The Saudi Central Bank’s (SAMA) Quantum Resilience Requirements
Quantum computing risk has entered the Saudi Central Bank's regulatory rulebook... and yes, it arrived with deadlines!
Welcome to my GRC and architecture-led reading of SAMA’s quantum-resilience requirements, Enhancement of Operational Resilience to Address Quantum Computing Risks (No: 482021280), published 27th August 2026, accompanied by a FREE practical Navigator for turning regulatory direction into structured discovery, risk assessment and action. If you wish to skip to the navigator, just click here.
This article draws on the whole circular, in force, originally titled:
رفع مستوى المتانة التشغيلية لمواجهة مخاطر الحوسبة الكمية
SAMA requires regulated institutions to:
- Complete an enterprise-level quantum-risk assessment and associated action plans by the end of Q1 2027.
- Ensure accurate and comprehensive procedures for identifying and classifying cryptographic assets by the end of Q4 2026.
- Develop initiatives to establish suitable cryptographic resilience for priority assets.
- Institutionalise quantum risk within periodic security, risk-committee and board oversight.
At first glance, you could be forgiven for mistakenly thinking that this appears to be a specialist cryptography requirement prompted by an incipient technology. However, a deeper reading reveals an immediate and rather less exotic question:
Does the institution know where it depends upon cryptography, what those dependencies protect, what their failure would imperil and how they could be changed without disrupting the enterprise?
For many institutions, answering this may prove even harder than explaining the quantum threat. It seems that the quantum computer is not yet the immediate operational problem. Architectural oversight is.
Does SAMA's circular on quantum computing risks apply to you?
If any of the following applies to your organisation, the short answer is yes.
A sector-specific directive does not create universal legal obligations. It does expose a common architectural deficiency: pervasive cryptographic dependence combined with meagre visibility and limited adaptability.
Discuss your challenge with us
Whatsapp an expert
More Views From The Nexus
TL;DR
Download the Eternal Nexus SAMA Quantum Readiness Navigator—a practical Excel workbook for structuring cryptographic discovery, risk assessment, ownership and migration planning.
Brief registration required. Delivered by email.
Quantum risk - what's all the hype about?
Quantum computing applies properties of quantum mechanics to particular classes of computation. It does not make every calculation instantaneous, nor does it render every security control obsolete.
Its cybersecurity significance arises from the prospective ability of a sufficiently capable, fault-tolerant quantum computer to solve mathematical problems underpinning widely used public-key cryptography.
Public-key cryptography permeates the digital enterprise. It supports secure key establishment, digital signatures, certificates, software authenticity, identities and communications. Implementations based on integer factorisation or discrete logarithms (including RSA and elliptic-curve cryptography) are the principal concern.
This does not mean every encrypted database becomes immediately legible or that symmetric cryptography and hashing fail identically. Quantum effects vary by mechanism, parameter, implementation and use case. Credible assessment therefore requires discrimination, not wholesale classification of all cryptography as equally vulnerable.
The material future capability is commonly termed a cryptographically relevant quantum computer: one sufficiently powerful and reliable to defeat cryptography used by operational systems.
Its imminent arrival date remains conjectural, but conjecture does not justify apathy.
The information-longevity complication
What if your information required confidentiality for fifteen years and an architecture required five years to migrate? Well, it’s reasonable to say that a plausible quantum threat arising anywhere within that combined horizon creates a present exposure.
Information may also be intercepted or exfiltrated while still encrypted. An adversary unable to decipher it today may preserve it for future decryption. CST highlights this “harvest now, decrypt later” scenario and recommends attention to long-retained information, legacy systems, critical infrastructure, credentials and other high-value assets.
The useful question is therefore not:
When will the quantum computer arrive?
It is:
How long must this asset remain trustworthy, and how long will its protective architecture take to change?
The first question invites speculation. The second enables risk management.
Post-quantum cryptography is not quantum computing
- FIPS 203: ML-KEM for shared-key establishment
- FIPS 204: ML-DSA for digital signatures
- FIPS 205: SLH-DSA, a hash-based digital-signature standard
SAMA's Four Directions - a coherent operating model for quantum resilience
Four connected directions translate an uncertain future threat into a present programme of risk, visibility, resilience and governance.
Assess quantum risk across operational, legal, regulatory, strategic and human-resource dimensions; then formulate commensurate action plans.
By Q1 2027Identify and classify cryptographic assets; relate them to data, systems and services; expose sensitivities, constraints and third-party dependencies.
By Q4 2026Devise migration initiatives or suitable alternatives for priority assets, resolving architectural impediments and supplier constraints.
Priority-led programmeInstitutionalise periodic oversight, escalate material challenges and recommendations, and sustain board-level accountability.
Continuing obligationUnderstand the risk – assess quantum risk at the enterprise level
SAMA calls for an enterprise-level assessment aligned with existing enterprise risk-management procedures, not merely a deep-dive technical review.
The assessment must encompass operational, legal, regulatory and strategic risks, including human-resource considerations.
This breadth is deliberate.
“Understand the risk” has two levels:
- Preliminary risk framing: establishes scope and directs discovery.
- Formal enterprise risk assessment: uses the completed inventory and is due by end-Q1 2027.
It is therefore important to recognise that even a technically impeccable demonstration of quantum computing and related algorithms may still fail as an enterprise-risk assessment. The analysis must connect technical susceptibility to institutional consequence (just as any sound operational-risk assessment should. AI, data and cybersecurity professionals may consider that a polite reminder, accompanied by a discreet wink. 😉)
Questions that risk practitioners should consider when assessing post-quantum risks are:
- Which information requires prolonged confidentiality?
- Which identities, transactions and decisions rely upon digital signatures?
- Which relationships depend upon certificates and public-key infrastructure?
- Which services would suffer material disruption during cryptographic change?
- Which products possess long operational lives or constrained upgrade paths?
- Where could migration failure impair customer access, payments, settlement or regulatory reporting?
- Which legal, privacy or evidential obligations could be compromised?
- Which competencies and specialist roles are required?
- Which decisions depend upon vendors, standards bodies or market-wide interoperability?
The resulting register should not contain a solitary entry labelled “quantum-computing risk.” Such aggregation obscures ownership, exposure and treatment.
Long-lived customer information, a software-signing root, an external API certificate, an embedded payment device and a supplier-managed HSM all employ cryptography. Their risk profiles differ markedly.
Well-architected risk scenarios decompose the general threat into governable scenarios.
Establish Visibility – Identify and classify cryptographic assets
SAMA’s second direction may prove the most arduous for many organisations because they must ensure accurate and comprehensive procedures for identifying and classifying cryptographic assets. They must associate those assets with relevant data, systems and services; classify them by sensitivity and migration priority; assess the resilience of priority assets; and identify constraints, challenges and third-party dependencies.
In my experience, for many organisations, this will be less an inventory exercise and more of a cartography exercise.
An entry stating “RSA certificate – expires December” is useful but inadequate. The institution must also determine:
- Which service uses it
- Which process depends upon that service
- Which information or identity it protects
- Whether it provides confidentiality, integrity, authentication or non-repudiation
- Where its key is generated and stored
- Who owns and administers it
- Which product, protocol or provider implements it
- Whether the implementation is quantum-vulnerable
- How long the protected asset must remain trustworthy
- What migration would entail
- Which systems must remain interoperable
- Whether a supplier controls the upgrade path
This body of knowledge is sometimes referred to as a cryptographic inventory or a cryptographic bill of materials (CBOM). The nomenclature matters less than the relationships captured, particularly since SAMA’s directive calls for relationship, dependency and architectural models spanning the cryptographic asset ecosystem. This is, after all, the correct context in which to consider operational resilience.
Discovery may combine automated scanning with evidence from certificate-management platforms, HSMs, cloud key-management services, application repositories, network infrastructure, API gateways, identity platforms, architecture catalogues and supplier attestations.
No solitary tool, that I am aware of, will reveal the entire estate.
Some cryptography is visible in certificates or network traffic. Some is embedded within source code, compiled applications, firmware, appliances or managed services. Some resides in operational practice: key ceremonies, signing procedures, recovery arrangements and externally administered trust services.
Download the Eternal Nexus SAMA Quantum Readiness Navigator—a practical Excel workbook for structuring cryptographic discovery, risk assessment, ownership and migration planning.
Brief registration required. Delivered by email.
Develop cryptographic resilience
SAMA’s third direction requires plans and initiatives to establish the requisite cryptographic resilience (or appropriate alternatives) for priority assets, here, “Priority” being the operative word.
Migrating every cryptographic implementation simultaneously would be impracticable and potentially injurious. Poorly orchestrated change can introduce outages, interoperability failures, implementation defects and insecure fallback behaviour.
Prioritisation should consider:
- Business criticality
- Information sensitivity and longevity
- Cryptographic function
- Exposure to interception or compromise
- Lifetime of signatures and trust anchors
- Remediation complexity
- Technology obsolescence
- Supplier readiness
- Protocol and market dependencies
- Planned transformation or replacement
- The strategic objective should be crypto-agility.
NIST (National Institute of Standards and Technology) defines crypto-agility as the capabilities required to replace and adapt cryptographic algorithms across protocols, applications, software, hardware, firmware and infrastructure while preserving security and ongoing operations.
This definition transcends PQC.
Quantum computing is not the first catalyst for cryptographic change, nor will it be the last. Algorithms weaken. Implementations fail. Keys are compromised. Standards evolve. Regulations change.
An enterprise built around fixed or invisible cryptographic choices will struggle repeatedly.
Crypto-agility may require:
- Separating cryptographic policy from application logic
- Using governed cryptographic services and approved libraries
- Maintaining algorithm and protocol inventories
- Supporting controlled algorithm negotiation
- Designing replaceable cryptographic components
- Introducing hybrid classical and post-quantum mechanisms where appropriate
- Testing interoperability before production migration
- Preventing insecure fallback
- Aligning certificate, key and trust-store lifecycles
- Securing supplier notification and upgrade commitments
- Retiring recalcitrant legacy technology
- Embedding transition requirements within new architectures and procurements
A credible roadmap should distinguish immediate risk reduction, enabling architecture and eventual migration.
Institutions cannot independently make every external service quantum-resistant. They can identify the dependency, assess its materiality, engage the provider, stipulate requirements, examine alternatives and govern the residual risk.
Establish continuing governance
SAMA’s fourth direction makes quantum-computing risk a standing subject for periodic monitoring within the Information Security or Cybersecurity Supervisory Committee and the board-derived Risk Committee, where applicable. Material challenges and recommendations must reach the board or its equivalent.
This rescues quantum readiness from the innovation laboratory.
Boards require neither quantum-physics tutorials nor speculative countdowns. They require decision-grade information:
- Confidence and coverage of cryptographic discovery
- Critical services and information assessed
- Priority risk scenarios and accountable owners
- Long-term confidentiality exposure
- High-value trust anchors and signature use cases
- Material supplier dependencies
- Migration impediments and investment requirements
- Exceptions and accepted risks
- Progress against milestones
- Relevant changes in standards, threats and vendor capability
- Metrics require circumspection.
“Eighty per cent of certificates inventoried” sounds reassuring. It may conceal that the remaining twenty per cent supports the institution’s most consequential services!
Coverage should be articulated in business as well as technology context. Which critical services have been assessed? Which sensitive information classes are mapped? Which essential suppliers have provided credible evidence? Which migration decisions remain impeded?
Good governance renders uncertainty visible without transmuting it into panic.
Discuss your challenge with us
Whatsapp an expert
More Views From The Nexus
Where quantum risk exposure emerges across the enterprise
Cryptography is not isolated within the security function. It permeates throughout the enterprise.
Information and data
Customer records, identity documents, financial histories, contracts, communications, audit evidence and analytical datasets possess different confidentiality and integrity lifetimes.
Not all encrypted information warrants identical priority. Classification must consider the prospective harm from disclosure or undetected alteration—and the duration of that harm.
Applications and APIs
Cryptography inhabits web and mobile applications, APIs, transport security, tokens, message signing, session establishment and application libraries.
Externally connected applications introduce interoperability dependencies. Institutions cannot unilaterally change an algorithm where counterparties, merchants, customers or providers cannot support it.
Identity and trust
Public-key infrastructure, certificate authorities, machine identities, device identities, authentication services and digital signatures constitute enterprise trust systems.
Confidentiality must not eclipse authenticity and integrity. Long-lived signing keys, software signatures and trust anchors may remain consequential long after a network session ends.
Infrastructure and cloud
Cryptographic mechanisms operate within cloud key-management services, HSMs, load balancers, gateways, service meshes, VPNs and administrative channels.
Managed infrastructure can simplify operations while obscuring implementation detail. Cloud adoption does not absolve the institution from understanding its exposure.
Software supply chain
Code-signing certificates, package signatures, container signatures, firmware validation and release pipelines safeguard software integrity.
Where signature trust becomes questionable, the risk extends beyond disclosure. Malicious software or fraudulent updates may acquire a veneer of authenticity.
Payments and digital financial services
Payment gateways, cards, wallets, transaction messages, merchant integrations, account access and settlement connections depend upon multiple forms of cryptographic trust.
Responsibility is dispersed across institutions, processors, schemes, vendors, devices and infrastructure providers. Migration is consequently ecosystemic.
Third parties
SAMA expressly requires institutions to identify third-party dependencies affecting priority assets.
A supplier may control the cryptographic library, certificate model, HSM firmware, protocol or upgrade timetable. Existing contracts may specify availability and support while remaining silent on cryptographic transition.
An internal technology risk thereby becomes a supply-chain governance problem.
Legacy technology and acquisitions
Legacy systems frequently contain hard-coded algorithms, unsupported libraries, forgotten certificates and appliances with meagre upgrade paths.
Acquisitions compound the issue. Each organisation may possess distinct trust models, identity platforms, key-management practices and suppliers. Integrating services without integrating cryptographic visibility produces a larger yet less intelligible estate.
AI is not the quantum threat. It's an accelerant!
Let’s dispel a common myth about AI and quantum computing risk from the outset, AI can’t run Shor’s algorithm on a conventional computer, but, that doesn’t make it irrelevant to post-quantum risk.
AI can accelerate cryptographic research, uncover vulnerabilities, inspect code and test implementations. In July 2026, NIST reported that an AI model had found a vulnerability in HAWK, a post-quantum signature candidate later withdrawn from consideration. The discovery didn’t affect NIST’s finalised PQC standards. Even so, it illustrated the point: AI doesn’t need to become quantum computing to influence the post-quantum threat-risk landscape.
AI can also help defenders inspect source code, configurations, certificates, architecture records and supplier documentation. It can help connect fragmented evidence, infer dependencies and suggest credible risk scenarios. For institutions already operating mature CMDB, PKI, KMS, GRC and software-analysis capabilities, this could considerably accelerate cryptographic discovery and reconciliation.
The AI estate belongs in the inventory too. Models, agents and MLOps platforms rely on APIs, machine identities, tokens, signatures, secrets and protected datasets. As these systems proliferate, so does the cryptographic surface that institutions must understand and eventually migrate.
But an AI-generated inventory doesn’t become evidence simply because it looks comprehensive. Every finding needs a source, confidence rating, accountable owner and means of reproduction. Sensitive architectural information shouldn’t enter unapproved models. Key material must never enter them.
The cryptographic asset is not the business asset
A common analytical error is to place the cryptographic asset at the centre of the assessment.
A key, certificate, library or algorithm has relatively insignificant enterprise meaning in isolation. Its significance emerges from what depends upon it.
A certificate authenticates an API. The API supports a wallet. The wallet enables customers to access funds. The certificate’s business importance resides in this chain, not in its algorithm alone.
An encryption key protects a backup. The backup contains information requiring fifteen years of confidentiality. Its migration priority derives from the information and obligation, not merely the key specification.
Enterprise Security Architecture preserves this lineage.
Without it, quantum programmes risk producing vast technical inventories bereft of defensible prioritisation. With it, cryptographic discovery becomes an intelligible business-risk capability.
The arrival date of a cryptographically relevant quantum computer remains uncertain. The location of today’s cryptographic dependencies should not.
Quantum readiness is not a claim of clairvoyance. It is the cultivation of sufficient visibility, ownership and adaptability to respond safely as the future clarifies.
SAMA's regulatory perimeter is not the final frontier
Financial institutions are not solitary systems. They operate through ecosystems comprising cloud providers, payment processors, schemes, fintechs, identity providers, telecommunications operators, software vendors, managed-security providers and outsourced services.
A regulated institution cannot substantiate the resilience of a priority service while disregarding the suppliers sustaining its trust. It’s true that this does not render every supplier directly subject to SAMA’s directive. It renders supplier capability germane to the institution’s regulated outcome. As institutions complete their inventories and assessments, suppliers should anticipate questions such as:- Which cryptographic algorithms and protocols does the service employ?
- Where is public-key cryptography embedded?
- Can mechanisms be changed without wholesale product replacement?
- Which standardised PQC mechanisms are supported or planned?
- Are hybrid migration patterns supported?
- What are the performance and interoperability consequences?
- Which subcontractors or cloud services constrain the roadmap?
- How will customers be notified of cryptographic changes?
- What evidence substantiates a “quantum-safe” claim?
A practical quantum-readiness lifecycle
Frame & Mobilise
Establish scope, sponsorship, governance and a shared vocabulary.
Identify executive accountability, risk ownership, architecture leadership and delivery responsibility. Connect the programme to enterprise risk, operational resilience, cybersecurity, data governance, procurement and transformation.
Discover
Identify cryptographic assets across applications, infrastructure, data platforms, identity systems, networks, devices, development pipelines and suppliers.
Combine automated discovery with architecture records, configuration evidence, interviews and provider attestations. Record uncertainty and confidence explicitly.
Classify
Relate each relevant cryptographic asset to the information, identity, system or service it protects.
Classify business criticality, information sensitivity, trust lifetime, cryptographic purpose, quantum exposure, ownership and migration constraints.
Assess
Develop discrete risk scenarios and evaluate their operational, legal, regulatory, strategic and workforce consequences.
Consider future cryptanalytic capability alongside present-day information capture. Identify concentration risk where many critical services depend upon one platform, provider or trust anchor.
Prioritise
Prioritise the highest-risk assets and dependencies.
Treatments may include configuration improvement, architectural refactoring, supplier engagement, technology replacement, controlled pilots, hybrid migration, compensating controls or explicit risk acceptance.
Transition
Maintain the inventory, reassess risk, monitor standards and vendors, and report material impediments.
New architectures should incorporate crypto-agility. New contracts should address algorithm support, evidence, notification and transition responsibilities. Acquisitions should include cryptographic due diligence.
What should organisations avoid?
Postponement. Waiting for an incontrovertible quantum date before establishing visibility. Discovery and dependency mapping are lengthy irrespective of the threat horizon.
Product-first thinking. Tools can facilitate discovery and migration. They cannot determine business criticality, assign accountability or orchestrate an ecosystem.
Inventory without architecture. Thousands of cryptographic observations have little value when severed from services, information and ownership.
Conflating PQC adoption with resilience. New algorithms still require secure implementation, key management, interoperability, operations and monitoring.
Indiscriminate prioritisation. Treating every asset as equally urgent creates an unmanageable programme and obscures material exposure.
Supplier complacency. Outsourcing operations does not extinguish dependency, accountability or exit risk.
Quantum theatre. Dramatic predictions, premature procurement and conspicuous experiments that leave the institution’s underlying opacity untouched.
Questions or Observations?
Frequently Asked Questions about SAMA's circular on quantum computing risks
Does SAMA require every cryptographic system to be migrated by Q1 2027?
Not within the published wording.
SAMA requires the enterprise-level risk assessment and action plans by the end of Q1 2027. Identification and classification procedures are required by the end of Q4 2026. The direction also requires resilience plans and initiatives for priority assets.
Institutions should seek clarification from SAMA where their precise obligations or evidential expectations remain uncertain. If you want to contact SAMA directly with queries, please contact the Executive Department of Operational Resilience Control via email at (CFC@SAMA.GOV.SA).
Is SAMA asking institutions to purchase quantum computers?
No such requirement appears in the direction.
Its focus is risk assessment, cryptographic visibility, resilience planning and governance. Post-quantum cryptography normally operates on conventional systems.
What is a cryptographic asset?
SAMA’s concise direction does not provide a detailed taxonomy.
A practical scope may include algorithms, keys, certificates, libraries, protocols, HSMs, KMS platforms, trust stores, signing services and other mechanisms providing confidentiality, integrity, authentication or trust.
The inventory should also capture the information, identities, systems and services associated with those mechanisms.
Can an existing CMDB satisfy the requirement?
It may contribute, but is unlikely to suffice alone.
A conventional CMDB rarely provides the necessary cryptographic detail, information sensitivity, trust lifetime, third-party dependency and migration priority.
Is all current encryption equally vulnerable?
No.
Quantum effects differ across public-key cryptography, symmetric cryptography and hashing. Algorithms, parameters and uses require differentiated assessment. Assertions that quantum computing “breaks all encryption” are inaccurate and unhelpful.
What is crypto-agility?
Crypto-agility is the organisational and technical capacity to replace and adapt cryptographic mechanisms while preserving security, interoperability and operations.
It encompasses architecture, governance, engineering, inventories, procurement and supplier management, not simply algorithm selection.
Should organisations deploy quantum key distribution?
Quantum key distribution is distinct from post-quantum cryptography and may suit particular high-value communication scenarios. It is not a general substitute for cryptographic discovery or enterprise-wide migration.
Any investment should be justified by risk, architecture, feasibility and cost, not novelty.
Does the direction apply directly to technology suppliers?
The wording addresses financial institutions.
However, institutions must identify third-party dependencies, constraints and challenges. Suppliers may therefore encounter quantum-readiness requirements commercially and contractually through regulated customers.
Who should own the programme?
Cybersecurity may coordinate it, but cannot execute it alone.
Enterprise risk, Enterprise Security Architecture, applications, infrastructure, identity, data governance, privacy, legal, compliance, procurement, vendor management, operational resilience and business-service owners all have material roles.
The fourth direction establishes continuing oversight through relevant security and board-derived risk governance.
Some final thoughts
SAMA’s direction is timely because it demands preparation before quantum risk becomes a realised crisis.
Its deeper value lies in exposing a visible condition: cryptography is ubiquitous, yet its ownership, dependencies and mutability are often poorly understood.
The institutions best prepared for the post-quantum era will not necessarily be those making the boldest claims or procuring the most conspicuous technology. They will be those able to answer four deceptively simple questions:
Download the Eternal Nexus SAMA Quantum Readiness Navigator—a practical Excel workbook for structuring cryptographic discovery, risk assessment, ownership and migration planning.
Brief registration required. Delivered by email.
Sources, translations and attributions
Primary source: Saudi Central Bank, Enhancement of Operational Resilience to Address Quantum Computing Risks, No. 482021280, dated 27 August 2026 and shown as in force.
Saudi cryptographic context: National Cybersecurity Authority, National Cryptographic Standards. The standards address accepted cryptographic primitives and schemes, PKI, key lifecycle management and post-quantum cryptography.
Saudi quantum-readiness guidance: Communication, Space and Technology Commission, Securing Data in the Quantum Computing Era for the ICT Sector. The guidance discusses harvest-now-decrypt-later exposure, cryptographic inventories, data longevity, vendor readiness, governance and PQC pilots.
PQC standards: National Institute of Standards and Technology, Approval of Three Federal Information Processing Standards for Post-Quantum Cryptography, covering FIPS 203, FIPS 204 and FIPS 205.
Migration guidance: NIST National Cybersecurity Center of Excellence, Migration to Post-Quantum Cryptography.
Crypto-agility: NIST, Considerations for Achieving Crypto Agility: Strategies and Practices, CSWP 39upd1.
Independence statement: This article is an independent practitioner interpretation. It has not been prepared, approved or endorsed by SAMA, NCA, CST or NIST. It does not constitute legal, regulatory or cryptographic-engineering advice. Institutions should validate obligations and technical decisions against authoritative requirements and their own risk context.
Sources last reviewed: 7 September 2026.