SAMA Wants a Complete Cryptographic Inventory by December 2026
On 27 August 2026, the Saudi Central Bank issued Circular 482021280, Enhancement of Operational Resilience to Address Quantum Computing Risks. It is in force, and it applies to every bank operating in the Kingdom, credit information companies, finance companies, payment services companies, and support entities licensed by SAMA for financing activity.
Its first deadline is 31 December 2026: identify and classify all cryptographic assets, together with the data, systems and services they protect, classified by sensitivity and migration priority.
That word “all” is the hard part, and not for the reason most teams assume. Cryptographic assets divide into two categories that require completely different methods.
Some cryptography can be observed from outside.
- Certificates presented by a TLS endpoint
- Keystores sitting on a file system
- Signing algorithms recorded in a CA
- Algorithms/Keys an HSM will report when queried
Scanning finds these. The rest stays inside the system, where nothing on the wire reveals it.
- A core switch terminating management sessions on a clean TLS 1.3 endpoint may be using RSA internally for firmware verification or a control-plane protocol.
- A cloud service exposes an API and tells you nothing about the libraries behind it.
- A Windows service running as an executable with a dozen DLLs is opaque from the network.
For this half there is exactly one authoritative source: a Cryptographic Bill of Materials, either supplied by the vendor or generated against the software.
What the circular requires
| Requirement | What it asks for | Deadline |
|---|---|---|
| Dated obligationsTwo hard deadlines, one quarter apart — and the later one depends on the earlier. | ||
| First — Quantum risk assessment | An enterprise-level assessment of quantum computing risk, aligned to the institution’s enterprise risk management procedures, with action plans to address what it finds. Covers operational, legal, regulatory and strategic risk, including human resources. | 31 March 2027 |
| Second — Cryptographic asset inventory | Accuracy and comprehensiveness of the procedures for identifying and classifying all cryptographic assets. Identify the associated data, systems and services and classify them by sensitivity and migration priority. Assess the cryptographic resilience of priority assets and identify constraints, challenges and third-party dependencies. | 31 December 2026 |
| Bounded by the two aboveNo date of its own, but gated on both sides. | ||
| Third — Migration plans | Plans and initiatives to achieve the required level of cryptographic resilience, or appropriate alternative solutions, for all priority assets, in line with the outcomes of Item Second. | Not stated |
| Continuing obligationGovernance, not a deliverable. | ||
| Fourth — Board-level governance | Quantum computing risk as a standing item for periodic monitoring by the Information Security Supervisory Committee and the Board Risk Committee, with challenges and recommendations reported to the Board or its equivalent. | Ongoing |
The inventory is due a full quarter before the risk assessment listed above it. SAMA is not asking institutions to assess quantum risk and then go looking for the cryptography — the assessment has no basis until you know what you hold.
That is the right order, and the harder one to deliver. A risk assessment can be drafted in a workshop. A comprehensive cryptographic inventory cannot.
Item Third carries no date, but that is not slack. The plans are defined as flowing from the Item Second outputs, which are due in December, and they will be expected to appear inside the action plans that Item First requires by the end of March. In practice Item Third is bounded on both sides even though no date is printed against it.
Where to look, how it is found
| What you need to establish | How it is found | What comes next |
|---|---|---|
| Observable cryptographyExposed to the network or the host. Found by scanning, which produces evidence rather than assertion. | ||
| TLS endpoints presenting quantum-vulnerable certificates | PKI Insights > Network Discovery scans CIDR and port ranges and reports which endpoints nothing currently monitors. PKI Insights > Network Monitor tracks the live certificate’s key and signature algorithm. |
Bring the endpoint under CLM so it can be re-issued on demand. Track its post-quantum position in PQC Readiness by scan target. |
| Certificates and keystores sitting on servers | PKI Insights > Machine Discovery searches Windows and Linux hosts for pfx, p12, cer, crt, pem, p7b, keys and jks files, opening Java keystores and truststores with supplied passwords. |
Onboard to CLM and track in PQC Readiness. Orphaned keystores with no identified owner are a finding in their own right. |
| Whether an endpoint negotiates post-quantum key exchange | PKI Insights > Network Monitor assesses TLS handshake post-quantum support directly. | Server-side TLS configuration change to enable hybrid key exchange, then re-scan to evidence it. |
| What your issuing CAs sign with | PKI Insights > PKI Posture across ADCS, EJBCA and HashiCorp Vault, running 200 checks per certificate and rating a CA F outright when the CA’s own key is weak. | A CA that cannot issue post-quantum certificates is a structural constraint. Plan a PQC-capable issuing path — Khatim PKI Server issues ML-DSA certificates with HSM-protected keys today. |
| HSM algorithm, key size and cipher support | PKI Insights > HSM Monitor, with post-quantum assessment of key and crypto algorithms, key sizes, signature algorithms and SSH/TLS cipher components for Thales. | Firmware and model upgrade path with the vendor. Record the dependency in PQC Manage, because it carries a procurement lead time. |
| Declared cryptographyInternal to firmware, cloud services or compiled software. No scan reveals it — the only authoritative source is a CBOM. | ||
| Cryptography inside switches, routers and appliances | Not observable. A clean TLS management interface says nothing about the cryptography running inside the device. | Request a CBOM from the vendor. Import it into PQC Manage and map the algorithms against the asset. |
| Cryptography inside cloud services and commercial software | Not observable. An API tells you nothing about the libraries behind it. | Vendor CBOM where one exists. Where it does not, the vendor’s inability to state their cryptography is itself a documented constraint under Item Second. |
| Cryptography inside in-house applications | Not visible to network or host scanning, but reachable by source-level analysis. | PQC Manage generates the CBOM for software you own, mapping algorithms and key lengths against the asset in the same ledger. |
| Evidence that must outlive the algorithmNot a discovery problem at all. | ||
| Long-term validity of signatures already made | No inventory reveals this. It is a question about the future provability of signatures created today. | Signatures made now must remain provable after the algorithm behind them is broken. Khatim Sign Server, Timestamp Server and Verification Server handle long-term validation evidence. |
For in-house software, PQC Manage generates the CBOM itself, so that half of the declared estate does not depend on a separate toolchain. What no source analysis can reach — wherever it runs — is appliance firmware, cloud service internals and commercial binaries. There the vendor remains the only authoritative source, whatever tooling produced their answer.
PQC Readiness: the observable half
PQC Readiness, a feature of PKI Insights, consolidates five scanning surfaces into a single post-quantum view, showing overall PQC health as a percentage with Pass, Fail and Unknown counts per area, broken down by scan target and by CA, with a daily summary report.
It covers Discovery, Network Monitor, TLS handshake support, PKI Posture and HSM. Watch the Unknown count. It tells you how far the inventory is from complete, which is exactly what Item Second asks an institution to be able to state.
PQC Manage: the declared half
PQC Manage governs everything scanning cannot reach. It holds an asset ledger covering cloud environments, commercial software, internal software and physical hardware, with CBOMs attached to each asset linking cryptographic libraries, active key lengths and target algorithms directly to it. Vendor-supplied CBOMs are imported; for in-house applications, PQC Manage generates the CBOM itself.
Three of its fields map onto the circular almost word for word:
- Asset Priority and Asset PQC Needs answer the requirement to classify by migration priority.
- External Vendor Org and Vendor POC answer the requirement to identify third-party dependencies.
- Inventory Completeness and Confidence, shown as headline dashboard metrics, are the direct answer to “accuracy and comprehensiveness”. These are the two numbers to put in front of a supervisor.
Item First: the risk assessment is a business question
Item First is an enterprise risk management exercise and no platform performs it. The mistake to avoid is treating it as a technical question. Which algorithms are vulnerable is answered by the inventory. Item First asks something different: What happens to the business when they become vulnerable?
Two examples make the distinction concrete.
- Customer onboarding and KYC records. National identity data, biometric enrolment and account opening documentation are retained for years under AML obligations and protected in transit and at rest. Personal identity data does not expire. Traffic captured today and stored is worth decrypting a decade from now, which makes this a harvest-now-decrypt-later exposure with a regulatory and reputational consequence attached rather than a purely cryptographic one.
- Corporate signatory mandates and board resolutions. These are signed once and relied upon for the life of a banking relationship. The risk is not confidentiality but provability. A signature that cannot be demonstrated as valid years later, because the algorithm behind it has been broken, becomes a legal and evidentiary problem rather than a security one.
Neither surfaces from a scan. Both are exactly the operational, legal and regulatory risk that Item First names.
What a platform can do is supply the evidence base and hold the resulting plan:
- Named PQC heads
- An overall deadline
- Allocated budget
- Per-asset assignment to internal owners by organisation and sub-organisation
- A dashboard tracking PQC health
- Inventory completeness
- Confidence
- Execution timeline
- Budget across more than nineteen breakdowns.
Item First names human resources risk explicitly. Per-asset ownership is what turns a plan into distributed accountable work rather than a document held by one team.
PKI Insights also records PKIMM, the PKI Consortium’s PKI Maturity Model, over time. For an institution that has to show a supervisor improvement rather than a snapshot, a tracked baseline is useful evidence.
Item Third: resilience, or an appropriate alternative
It asks for plans to achieve cryptographic resilience or appropriate alternative solutions for all priority assets.
Some assets will not migrate:
- An appliance whose vendor has no post-quantum firmware roadmap
- A product at end of life
- An application built around fixed certificate size assumptions that will break on larger post-quantum certificates
The circular does not require the impossible. It requires a documented alternative. In practice those alternatives are compensating controls and lifecycle decisions:
- Network isolation
- Shortened key and certificate lifetimes
- Re-encryption of stored data, or
- Planned replacement and decommission.
PQC Manage records this per asset. Planned disposition is captured. A documented decision not to migrate an asset, with a reason and a date, is a compliant answer under Item Third. An undocumented one is a finding.
The rest of Item Third is structured per asset as well:
- Milestones across R&D, testing, production deployment and final validation
- Budgets attached to tasks
- Proof of work required at each phase.
One collision worth planning around
PQC aside, the CA/Browser Forum’s ballot on certificate lifetimes brings the maximum down to 100 days in March 2027. SAMA’s enterprise risk assessment is due 31 March 2027. Same quarter, same teams, same org.
Read the full analysis: The 100-day deadline lands March 2027
An institution renewing certificates manually will be doing it roughly four times a year per endpoint from that point, while simultaneously executing a cryptographic migration plan. PKI Insights performs zero-touch certificate lifecycle management for web servers, appliances and databases.
CLM today issues and deploys classical certificates, RSA and ECDSA. It is what keeps an organization operable through the migration window and what will carry out a mass re-issue once a post-quantum chain is in place. It is not itself a post-quantum issuance path. That path is Khatim PKI Server.
Item Fourth: what the Board actually sees
Item Fourth makes quantum risk a standing governance item, which means producing a credible report on a recurring cadence, indefinitely. It also moves post-quantum cryptography out of a conversation between cryptographers and security architects and into enterprise risk, where leadership has to understand and govern it.
PQC Manage records changes to PQC health. Every remediation step carries submitted proof of work, producing a chronological record of what was migrated, when, and by whom. Operator logs record who changed which configuration.
A spreadsheet cannot show a supervisor how the position changed over time, or who signed off on what.
The sovereignty question
A complete cryptographic asset inventory is one of the most sensitive documents a financial institution will ever produce. It maps every system, its cryptographic weaknesses, its owner, its vendor and its migration state.
Under a circular that explicitly requires institutions to identify third-party dependencies, producing that inventory on a SaaS platform makes the inventory itself a third-party dependency that must be declared and assessed.
PKI Insights and PQC Manage run entirely on-premises and deploy in air-gapped environments.
Where to start
The constraints that will shape this programme are mostly not cryptographic. HSM firmware support for ML-DSA is vendor and version dependent. Appliance vendors with no post-quantum roadmap take time to chase, and so do vendors who cannot produce a CBOM. Every one of those is a dependency with a procurement cycle attached.
Start two things now, and run them in parallel.
- Scan what can be scanned.
- Start asking for what cannot be scanned.
The gap between the scan results, the CBOMs received, and the current inventory is the size of the problem. It is also the number the March risk assessment depends on.
FAQ
Who does SAMA Circular 482021280 apply to?
The distribution list covers all banks operating in the Kingdom, finance companies, payment services companies, and support entities licensed by the Saudi Central Bank for financing activity.
What if an asset cannot be migrated to post-quantum cryptography?
Item Third allows for appropriate alternative solutions rather than requiring migration in every case. Compensating controls, replacement or planned decommission are valid answers provided the decision, its reasoning and its date are documented.
Does a cryptographic inventory have to be held on-premises?
The circular does not mandate it, but it does require institutions to identify third-party dependencies. A cryptographic inventory hosted externally becomes a third-party dependency that must be declared and assessed. PKI Insights and PQC Manage deploy entirely on-premises, including air-gapped environments.
