Conscious · agentic assuranceWhitepaper 10 · Post-quantum readiness

Cryptography on a clock

An inventory, a dated policy and a harvest-now exposure score, for a deadline that is already in force

Saudi Arabia’s central bank has set its supervised institutions two dates: a cryptographic inventory by the end of the fourth quarter of 2026, and an enterprise quantum risk assessment by the end of the first quarter of 2027. NIST has set 2030 and 2035 for the cryptography most organisations are running today. This paper is about building the inventory those deadlines require, and scoring the exposure in a way an auditor can recompute.

Audience

CISOs, heads of cryptography and PKI, bank risk and compliance officers

Published

October 2026

Edition

First edition, October 2026

Series

The assurance papers

What this paper establishes

• Every algorithm rule carries the publication and the date it rests on — NIST IR 8547, SP 800-131A Rev. 2, SP 800-52 Rev. 2 — so a verdict names the deadline that bites first.
• Harvest-now-decrypt-later exposure scored by Mosca’s inequality, with the full formula on the screen beside the score so an auditor can recompute it.
• The two SAMA deadlines — a cryptographic inventory by the end of Q4 2026 and an enterprise risk assessment by the end of Q1 2027 — carried as assessable rows under the regulator’s own numbering.

consciousgrc.comOctober 2026

The hardest thing about post-quantum migration is not the mathematics. It is that most organisations cannot produce a list of where their cryptography is. Not a policy saying which algorithms are approved, which every organisation has, but an inventory of what is running, on which systems, with which key sizes, expiring when.

Until recently that was a defensible gap. It is now a dated obligation.

What an inventory has to contain to be worth building

An inventory of algorithm names is not an inventory. The platform judges an asset on every part it is made of: an algorithm with its parameter set and curve, a certificate’s key and signature algorithms, a key’s algorithm and size, a protocol’s version, cipher suites and key-exchange groups.

The verdict for the asset is the worst status among its parts, and where two parts share a status, the one whose next change comes soonest decides, so the verdict names the date that bites first. Three details of that rule carry most of the honesty.

• A part carrying a post-quantum scheme is judged as that scheme. A hybrid key exchange is not held to the dates of its classical half.
• A public key whose size is not stated is held to the earliest timetable, because an unsized key is not evidence of a large one.
• Anything recognised but unclassified is recorded as unknown, never as allowed. The inventory’s unknowns are the work, and hiding them inside a green figure defeats the exercise.

The inventory is fed from the sources an organisation already has rather than from a questionnaire: a cryptographic bill of materials produced by an open-source scanner against the organisation’s own code, an export from a certificate lifecycle system, and optionally a check of endpoints the organisation has itself declared. That last one is off by default, limited to declared public addresses, and switched on deliberately or not at all.

Harvest now, decrypt later, scored so it can be argued with

The risk that matters before a quantum computer exists is that encrypted traffic and stored data can be recorded today and read later. Mosca’s inequality is the standard way to reason about it: if data must stay secret for x years, and replacing the cryptography protecting it takes y years, the data is exposed whenever x plus y exceeds z, the years until a cryptographically relevant quantum computer exists.

No one knows z. A platform that picks one and hides it has made the most consequential assumption in the model invisible. In Conscious the horizon is a dated scenario the workspace chooses, with the source it rests on, and every exposure is computed against each scenario the organisation holds. A horizon already in the past counts as zero.

Counting an unknown as broken is the decision that makes the model useful. The alternative — treating unclassified cryptography as acceptable until proven otherwise — produces a reassuring first report and a migration plan that starts in the wrong place.

Agility is the deliverable, not a one-off migration

The organisations that will handle this well are not the ones that replace an algorithm fastest. They are the ones that can replace the next one without a programme. Crypto agility is measurable: whether an algorithm is a configuration or a recompilation, whether certificates can be reissued at scale, whether a dependency is pinned to a library version that will not get the new scheme, whether a vendor product can be updated at all.

Beside the inventory, the platform carries a maturity assessment across the domains this work spans — governance, inventory, agility, third parties, data protection, people and planning — with the organisation’s answers banded and dated. It is an assessment like any other in the platform, which means its evidence, its rating and the person who signed it sit in the same record as everything else.

Why this belongs in the compliance platform and not in a separate tool

Three joins make the case, and all three are the reason a standalone cryptography tool ends up as another system to reconcile.

1. The requirement is an obligation like any other. The circular’s four requirements are assessable rows under the regulator’s own numbering, rated by a named person, evidenced, and reported with everything else that regulator asks about.
2. The exposure is a risk. A quantum exposure score that lives in a dashboard is interesting; one that raises a risk, takes a treatment, gets an owner and a date, and appears in the committee pack is managed.
3. The third-party dependency is a supplier. The circular names third parties explicitly, and the supplier holding the weak cryptography is already a record in the same workspace, with its contractual obligations and its assessment.

What to do in the next ninety days

1. Produce the inventory from what you already have: a bill of materials from your own code, an export from your certificate system, and your declared external endpoints. Completeness comes later; the unknowns are the finding.
2. Classify every part, and leave the unknowns visibly unknown rather than assuming the best case.
3. Choose your horizon scenarios and write down what each rests on. This is the assumption every later number depends on.
4. Score the exposure, then sort by score rather than by system importance. The two orders are different and the second one is the intuition that gets migrations wrong.
5. Raise the top exposures as risks with owners and dates, and put the third-party ones to the suppliers in writing.
6. Record the maturity assessment and have it signed. For a SAMA-supervised institution, that assessment is the Q1 2027 deliverable.

None of those six steps requires a decision about which post-quantum algorithm to adopt. That decision is the easy one and it is already made by the standards bodies. The work that takes the two years no one has is finding out where the cryptography is.