A bank's most exposed asset in the quantum transition is not its TLS configuration. It is the archive: transaction histories, customer identity files, contracts, ledgers and regulatory records that must be retained for seven, ten or thirty years and that are being copied by adversaries today for decryption later. The G7 Cyber Expert Group's January 2026 roadmap gives the sector a shared vocabulary for the transition, six activities from awareness to monitoring. Most institutions are well into the first three. The fourth and fifth, migration execution and migration testing, are where the long-lived data sits, and where the tooling built for network migration runs out.
This article is for the people who own that problem: heads of cryptography and key management, CISOs and their architects at banks, insurers, payment networks and market infrastructure, and the internal auditors and examiners who will ask them to prove the transition happened. It explains what the two middle activities require for stored records, what an assembled toolset can evidence, and how 8DB was designed to perform the migration as a database operation with receipts an auditor can check without trusting the operator.
Why the archive is first
Harvest now, decrypt later is not a theoretical risk for financial data. The value of a copied record is a function of how long it stays sensitive, and the sector's retention rules guarantee that many records stay sensitive past the dates NIST IR 8547 sets for retiring quantum-vulnerable public-key algorithms: deprecation in 2030, disallowance in 2035. Anything encrypted under a key that was established or shared with RSA or elliptic-curve cryptography, and anything whose integrity rests on a classical signature, is exposed for as long as the copy exists.
Two clarifications keep the priority honest. Symmetric encryption is not the problem: AES-256 remains approved and a purely symmetric key hierarchy has no quantum exposure in its stored bytes. And the operational cost is not the algorithm, it is the migration: identifying every record that depends on retiring material, changing its protection while the business keeps running, proving the change completed, and being able to do it again when the next algorithm retires. The roadmap's execution and testing activities are, for stored data, exactly that operation.
What examiners will ask for
Migration testing in the roadmap's sense means that migration functions are tested and the ecosystem exercises quantum resilience. Applied to records, an examiner's questions become concrete.
- Which records still depend on a retired algorithm, and how is that determined from the data rather than from a project plan?
- When protection was changed, did reads and writes continue, and what happened to records the sweep did not reach?
- Can the integrity of a batch of historical records be verified by a party who does not run the database?
- If a backup from before a permission was revoked is restored, does the revoked party regain access?
- Can the same evidence be produced again next year, on demand, by a different team?
An institution that can answer these from the system itself is in a different position from one that answers from a change ticket. The design goal for 8DB is that the answers are properties of the store.
How 8DB carries out execution and testing
8DB is an embedded data engine written in Rust with unsafe code denied. It runs in software on commodity hardware and was built around the operation the roadmap describes.
Execution: the algorithm is a versioned property of each record. Every ciphertext produced through the engine's cryptographic registry carries an algorithm version. Two versions can be registered at once, the new one active for writes and the old one still decrypting, and an algorithm placed in quarantine refuses new writes while continuing to serve reads. Migration is a state the store is in, not an outage the business schedules.1
Execution: the post-quantum cost lands at the boundary, not on every row. Key establishment uses ML-KEM-1024 (FIPS 203) in a hybrid with X25519, once per established key. Each record is encrypted with AES-256 (AES-256-GCM-SIV by default, with an AES-256-GCM profile for approved-mode deployments). Data keys are never stored; each is derived at use from a root secret and the record's governance state at write time, so there is no key database to exfiltrate and no key store to migrate.
Testing: integrity evidence an auditor can hold. Batches of records are authenticated by one ML-DSA-87 (FIPS 204) signature over a SHA-384 Merkle root, with a per-record inclusion proof. A reviewer can be handed a record, its proof and the signed root and verify inclusion without access to the rest of the batch or to the operator's systems. Tampered leaves and forged roots are rejected. The 4,627-byte signature is paid once per batch rather than beside every transaction.
Testing: recovery under current authority. Access decisions are part of the record's governance state, and the design requirement for restore is that a backup taken under an older policy cannot revive a reader that current policy has revoked. This is the property that turns "we have backups" into "our backups obey today's rules".
What has been measured
Financial institutions should not accept architectural claims about performance, so here is what has been executed and published with raw logs on our stored-data evidence page. In release builds on four hosts, Windows and Linux, x86_64 and aarch64, with the same cipher on both sides, a 115-byte record encrypts to 131 bytes whether its key came from a classical key-derivation function or from ML-KEM, and median per-record encrypt and decrypt times agreed within one percent on every host. The post-quantum cost is one 1,616-byte object per established key and one signature per batch, accounted separately. The ML-KEM-1024 and ML-DSA-87 implementations passed NIST's ACVP demonstration server in June 2026 (session 744723), and a 35-vector offline known-answer suite reproduces that result on demand.
Every figure arrives with its harness, written so a second evaluator can reproduce every step. That is the standard we would ask any institution to hold its vendors to, and it is the standard your examiners are moving toward.
Where the same engine is already applied to settlement
The financial sector's other transition, from application-layer compliance to compliance an examiner can verify, is one we are building ourselves on 8DB. Sovereign Clearinghouse, which 8Braid builds and operates under our Digital Fabric settlement brand, is a regulated clearing service for cross-jurisdiction crypto-asset transfers in which sanctions, jurisdiction and operator policy are evaluated as preconditions on every routing decision, each decision is committed to a replayable audit chain, and regulators, auditors and operators each receive a lawful view of the same record.2
It matters here for one reason: it shows what a data store that treats governance as a property of the record does for a compliance function. The migration evidence described in this article and the settlement evidence in that product come from the same mechanism, and an institution evaluating one is most of the way to evaluating the other.
Where this fits in your program
Most institutions will keep their core banking platforms and their key infrastructure. 8DB is not a proposal to replace them. It is the place to put the records whose retention horizon exceeds the algorithm's, so that the transition for that data becomes one operation with evidence, and so that the next transition is a version change rather than a second program. Typical first candidates are long-retention archives, records subject to legal hold, identity and onboarding files, and any dataset whose integrity must be demonstrable to a third party years after it was written.
What to bring us
The most useful first conversation is about one dataset and one examiner's question.
- One long-retention dataset. Its size, retention horizon, current protection and the systems it lives in. We will map it to the roadmap's execution and testing activities and return an acceptance plan your architects and auditors can hold us to.
- The evidence your examiners ask for today. The exact artefacts you produce for a cryptographic control review are what we want the store to produce on demand.
- A machine to reproduce on. The benchmark and known-answer suite run from source with one command each. Ask for the reproducibility package and run it inside your own environment.
Write to hello@8braid.com with the subject "G7 roadmap: stored-records acceptance plan". You will hear back from an engineer.
Sources and further reading
- G7 Cyber Expert Group: Advancing a Coordinated Roadmap for the Transition to Post-Quantum Cryptography in the Financial Sector
- NIST IR 8547: Transition to Post-Quantum Cryptography Standards
- NIST CSWP 39-upd1: Considerations for Achieving Crypto Agility
- NIST FIPS 203: ML-KEM and FIPS 204: ML-DSA
- 8DB: Post-Quantum Cryptography for Stored Data, Measurements and Method
- 8DB: What a Post-Quantum Database Actually Has to Protect
Footnotes
-
The migration itself, performed on a running store with reads continuing, unconverted records accounted for and recovery under current authority proven, is on the trustdb main branch (PR #3484, merged 2026-09-12). Evidence folders
protection-lifecycle-2026-09-11,managed-restore-source-2026-09-12andcombined-lifecycle-qualified-2026-09-12hold the runs, the CycloneDX 1.6 posture exports account for completion per dataset, and the harness is written so a second evaluator can reproduce every step. ↩ -
Sovereign Clearinghouse is in a structured pilot programme for MiCA-licensed providers, regulated custodians and sovereign operators, with the post-quantum signing posture staged on its hardening roadmap. ↩
Continue the technical conversation
Where could this help your work?
Bring a research question, a database workload or an application you want to build. Let’s connect the ideas in this article to an evaluation that matters to your team.
Discuss this work