Build a cryptographic inventory for Saudi post-quantum readiness

Saudi financial institutions have a concrete near-term engineering task: identify and classify every cryptographic asset by the end of Q4 2026. The Saudi Central Bank circular does not merely ask for a list of algorithms. It requires links to data, systems and services, sensitivity and migration priority, resilience assessment, constraints and third-party dependencies. The useful output is therefore an owned, queryable inventory that can drive migration decisions—not a spreadsheet assembled once for an audit.

This article is a technical explanation of an in-force circular issued on 27 August 2026, not a new announcement and not legal advice. It translates the published requirements into an implementable architecture for security, platform, cloud and application teams. The safest first move is discovery and evidence. Replacing algorithms before understanding their usage can break identity, payments, certificates and data recovery while leaving the most exposed assets untouched.

What SAMA requires and what it means technically

The circular asks financial institutions to complete an enterprise quantum-risk assessment by the end of Q1 2027 and to identify and classify all cryptographic assets by the end of Q4 2026. The inventory must connect each asset to the data, system or service it protects, classify sensitivity and migration priority, evaluate resilience, and record constraints and third-party dependencies. It also asks for initiatives that achieve an appropriate level of cryptographic resilience for priority assets.

These are governance requirements, but they imply technical data contracts. An asset record needs an accountable owner, deployment location, purpose, algorithm and parameter set, key-management boundary, protected-data class, dependency chain, replacement mechanism and collected evidence. Without those fields, a committee can see that RSA or elliptic-curve cryptography exists but cannot decide which instance should move first or whether a vendor can support the change.

The circular does not prescribe one post-quantum algorithm for every application. That distinction matters. NIST has finalized ML-KEM for key establishment and ML-DSA and SLH-DSA for signatures, but protocol support, library maturity, certificate ecosystems, hardware modules and partner interoperability differ. Inventory and prioritization must precede migration.

Inventory cryptographic use, not just certificates

A certificate-manager export is a useful input, not a complete inventory. Public-key cryptography is embedded in TLS termination, service-to-service mTLS, code and container signing, mobile application signing, JSON Web Tokens, SSH, VPNs, database drivers, backup workflows, hardware security modules, payment terminals, partner file exchange and vendor SaaS. Some assets are visible through scanners; others exist only in configuration, source code or a commercial appliance.

Build discovery from several evidence streams. Query cloud certificate managers, load balancers, API gateways, Kubernetes ingress controllers, service meshes, KMS and HSM audit logs. Scan repositories and software bills of materials for cryptographic libraries and protocol configuration. Inspect network handshakes at approved observation points. Ask vendors for their post-quantum roadmap and supported upgrade path. Reconcile these signals into one asset identifier instead of keeping separate lists that cannot be compared.

Do not store private keys or secrets in the inventory. Store references to their management boundary, such as a KMS key ARN, HSM partition or certificate-manager identifier. Access to the catalogue should be controlled because it reveals security architecture, yet the data must remain usable by the teams expected to remediate it.

Use a minimum viable asset contract

A practical record separates discovered fact from assessment. The discovery portion says what exists and where the evidence came from. The assessment portion states business criticality, migration risk and the planned action. Keeping them separate makes reassessment possible when standards or vendor support change.

{
  "asset_id": "crypto-api-gateway-prod-tls",
  "service": "customer-payments-api",
  "owner": "payments-platform",
  "environment": "production",
  "use": "external TLS key establishment and authentication",
  "algorithm": "ECDHE_ECDSA",
  "implementation": "managed-api-gateway",
  "key_boundary": "cloud-kms-reference",
  "data_class": "restricted",
  "confidentiality_years": 10,
  "third_parties": ["gateway-provider", "certificate-authority"],
  "rotation_tested_at": "2026-09-15",
  "evidence": ["config-snapshot:sha256:...", "tls-scan:sha256:..."],
  "migration_state": "vendor-roadmap-required"
}

Version the schema, record when each field was observed, and retain immutable evidence hashes. A stale inventory is dangerous because certificates rotate, services move and unmanaged dependencies appear. Set freshness targets by criticality: an internet-facing payment endpoint should be checked more often than an archived internal tool.

Prioritize by exposure, lifetime and changeability

A high-risk queue is not simply a list of the oldest algorithms. Score at least five dimensions: the sensitivity and useful lifetime of the protected data; exposure to collection today; the quantum vulnerability of the cryptographic function; the criticality of the business process; and the difficulty of changing all dependent parties. Long-lived confidential data deserves attention because an adversary can capture encrypted traffic now and attempt to decrypt it later.

Signing and key establishment also have different failure consequences. A vulnerable signature can threaten software provenance, identity and transaction authorization. Vulnerable key establishment can expose confidentiality. Symmetric encryption and hashing are affected differently from public-key systems, so a blanket “replace all AES” program would consume effort without following the risk model expressed by the guidance.

Add a changeability score. A library controlled by one team may be simpler to migrate than a payment connection shared with banks, terminal vendors and certificate authorities. High business risk plus low changeability is a signal to start coordination early, not to postpone the asset.

Build crypto agility before forcing migration

Crypto agility means a system can change algorithms, parameters, keys and providers without rewriting the business workflow. It is not a magic abstraction that hides every difference. Key-encapsulation mechanisms and signatures have distinct APIs; larger keys and signatures can affect handshakes, packets, certificates, queues and storage; and some hybrid modes require both peers to agree on a specific protocol construction.

Create explicit cryptographic boundaries. Application code should request operations such as establish_session, sign_release, verify_partner_message or wrap_data_key through a versioned capability interface. Policy selects an approved implementation by environment and partner. Telemetry records algorithm family and result without exposing keys or sensitive payloads. Emergency rollback remains possible because the previous interoperable path is retained during a controlled transition.

Avoid inventing cryptographic constructions. Use standardized algorithms through maintained, validated implementations and follow protocol-specific guidance. NIST lists FIPS 203, 204 and 205 as finalized standards, while its transition and migration material explains that organizations still need discovery, interoperability testing and roadmaps. A standard algorithm is necessary but not sufficient for a safe production protocol.

Test interoperability as a dependency graph

The migration unit is rarely one microservice. A TLS path can include a client library, mobile operating system, CDN, web-application firewall, load balancer, service mesh, upstream application and monitoring probe. A signature path can cross a build service, HSM, package registry, deployment controller and runtime verifier. The inventory should model these as dependency graphs, because upgrading one node without the others can cause an outage.

Create a compatibility matrix for every priority path. Record supported classical, post-quantum and approved hybrid modes; key and signature sizes; handshake and verification latency; HSM support; certificate constraints; failure behavior; and rollback. Run tests with production-like payload sizes and concurrency. A successful unit test proves very little if an intermediate proxy rejects the larger handshake or a partner SDK cannot parse the new certificate.

Where a standards-compliant hybrid mode is available, it can reduce transition risk by requiring both a classical and a post-quantum component to fail before confidentiality is lost. It also adds bytes, computation and operational complexity. Hybrid deployment should therefore be a measured protocol decision, not a checkbox applied everywhere.

Roll out in stages with evidence and rollback

Use a sequence of discovery, ownership, classification, laboratory validation, shadow or canary deployment, monitored expansion and retirement. Each gate should have an owner and objective evidence. Useful evidence includes signed configuration snapshots, scanner results, dependency attestations, interoperability test reports, latency and error comparisons, HSM capability statements, vendor commitments and rollback drills.

Start with a path that is important enough to teach the organization but bounded enough to recover. Mirror a non-sensitive handshake to a test endpoint, validate certificates and observability, then expose a small eligible cohort. Watch connection failures, CPU, response size, timeout distribution, certificate errors and downstream compatibility. Do not remove the prior path until reconciliation and rollback have been demonstrated.

The migration backlog should be generated from inventory queries. For example: priority assets using quantum-vulnerable public-key algorithms, protecting data with confidentiality longer than five years, and depending on a vendor without a dated roadmap. That is more actionable than a manually curated slide deck.

Best uses and cases where migration should wait

The inventory-first approach is useful for regulated financial platforms, payment integrations, identity systems, long-lived confidential records, signed software supply chains and multi-cloud environments where cryptography is distributed across many owners. It is also valuable before a vendor selection because it turns “quantum ready” into testable capabilities and dates.

Do not replace a production protocol merely because an experimental library exposes a post-quantum primitive. Wait when the protocol construction is not standardized, required peers cannot interoperate, the implementation lacks the assurance required by the institution, or rollback cannot be performed safely. Waiting on one migration does not justify waiting on discovery: inventory, ownership, data-lifetime classification and vendor questions are useful now.

For internal symmetric encryption with strong approved key sizes, the action may be key hygiene, agility and monitoring rather than immediate algorithm replacement. For data that has no useful confidentiality lifetime and no signature dependency, another asset may deserve priority. The assessment should document that decision and its evidence rather than marking the asset “safe” indefinitely.

Anti-patterns to avoid

Do not treat the programme as a certificate spreadsheet, a one-time scanner run or a blanket library upgrade. Do not mark a product compliant because a cloud provider announced PQC support; the exact service, region, protocol mode and client path still need verification. Do not store secrets in discovery output. Do not let every team invent a scoring formula or algorithm allowlist. And do not use current quantum-computer estimates as the sole deadline: data lifetime and migration lead time are more useful engineering inputs.

Another anti-pattern is changing application code and infrastructure simultaneously without an observable compatibility gate. Separate capability enablement from traffic migration. Feature flags should be scoped to a cryptographic path, protected from casual use and audited. A kill switch is only credible when it has been exercised under load.

An executable 90-day plan

In the first 30 days, establish the inventory schema, owners, evidence store and approved discovery methods. Import certificates, KMS and HSM metadata, internet endpoints, service-mesh policy, signing systems and high-value vendor connections. Label unknown fields instead of guessing.

In days 31–60, reconcile duplicates, validate ownership, classify data lifetime and business criticality, and build dependency graphs for the highest-risk paths. Request dated capability statements from vendors and map available protocol support to approved standards. Select one bounded pilot and define success, failure and rollback metrics.

In days 61–90, run interoperability and performance tests, publish the first migration decision records, execute a canary where appropriate and feed the results back into scoring. Produce a dashboard that shows coverage, freshness, unknown ownership, high-risk dependency blockers, tested rotation and migration state. This does not complete a multi-year transition; it creates a reliable control plane for the decisions that follow.

Executive conclusion

SAMA's requirement is valuable because it starts with the part many migration programmes skip: a comprehensive, classified view of cryptographic assets and their dependencies. The engineering goal is not to claim that every system is “quantum safe” by one deadline. It is to make every important cryptographic dependency visible, owned, prioritized, testable and changeable.

A strong inventory connects technical facts to data sensitivity, business impact, vendor constraints and evidence. With that foundation, teams can adopt finalized standards where protocols and implementations are ready, defer unsafe migrations with a documented reason, and move priority paths through measured, reversible stages.

Prepared by: Noor Yasser